ejb service task 'interface'

[ronald_van_kuij]

As discussed with Tom in the userforum, we'll be implementing the ejb and jms service tasks. There are many ways the calls can take place. I'd like to propose some things here for the initial implementation of the ejb service task. A similar post will come for the jms service task

First of all there is the local or remote option. Initially I think focussing on local is good enough, but if someone disagrees, feel free to comment.

Secondly, there is the choice to just call an existing ejb with a predefined interface or to have it implement an activiti specific interface kind of like the java delegate. I prefere to initially focus on existing interfaces where context variables are passed on in the method call, but again, if someone disagrees…. So a method name is needed, a list of parameters (order is important)

Thirdly there is the return value. Should it be taken into account? It probably needs to be if it is about existing interfaces where you cannot add variables to the execution (if possible at all).

But most importantly, is it a new service task or is it an addition to the java service task. Personally I'm in favour of the latter. The difference is not that big and it is probably even possible to use juel to resolve ejb's (high om my todo list, cdi?) and call the corresponding methods like in Seam. Using a 'type' like for the mail task is not what I'd do for ejb calls (I would for jms though)

So to summarize and propose element/attribute names
- only local calls (attribute, activiti:jndi-name)
- define a method name (attribute, activiti:method)
- define parameters (extension element, activiti:arg, order is important, should be like the method signature and is comparable to the activiti:field)
- define return value (extension element, optional: activiti:return)

Thoughts?

[tombaeyens]

First of all there is the local or remote option. Initially I think focussing on local is good enough, but if someone disagrees, feel free to comment.

starting with local is OK. later you could add remote if there is demand for it.

Secondly, there is the choice to just call an existing ejb with a predefined interface or to have it implement an activiti specific interface kind of like the java delegate. I prefere to initially focus on existing interfaces where context variables are passed on in the method call, but again, if someone disagrees…. So a method name is needed, a list of parameters (order is important)

it's important that you stick to the existing ejb interfaces.  users should not implement JavaDelegate.
Apart from method name and parameters, I think you also will need the local ejb name (JNDI name?) to look up the local home interface.

Thirdly there is the return value. Should it be taken into account? It probably needs to be if it is about existing interfaces where you cannot add variables to the execution (if possible at all).

It should be possible to pass in the execution as a parameter in a method invocation (just like any other parameter)
Apart from that, the return value should optionally be captured and stored in a variable.

In terms of passing the parameters, compare it with method expressions passing in parameters.  There's already a lot that you can do with that.  And it is already possible somehow to invoke an ejb through a method expression.  (maybe Joram can give pointers) Can you first evaluate when users should use method expressions with parameters and when they should be using the ejb activity?  Once that is cleared out, then it also gives you better guidance for which features to develop first.

But most importantly, is it a new service task or is it an addition to the java service task. Personally I'm in favour of the latter … Using a 'type' like for the mail task is not what I'd do for ejb calls (I would for jms though)

Tijs, is there a preferred way from the designer point of view?  Maybe in context of the pluggability?

… and it is probably even possible to use juel to resolve ejb's (high om my todo list, cdi?) and call the corresponding methods like in Seam.

first I explain that idea in detail and now you pretend that you had already thought about it before…  tsssss

So to summarize and propose element/attribute names
- only local calls (attribute, activiti:jndi-name)
- define a method name (attribute, activiti:method)
- define parameters (extension element, activiti:arg, order is important, should be like the method signature and is comparable to the activiti:field)
- define return value (extension element, optional: activiti:return)
Thoughts?

looks perfect to get started, but first evaluate how and where this is different from method expressions.

it might also be early days for creating unit tests for this. i have high on my agenda to run the test suite in container on hudson (this release?). but i'm not there yet.

[jbarrez]

Regarding the 'pointer' refers to. A few months ago, I tried to wrap an EJB in a Spring bean anc call it through a method expression. That just worked as a charm, but you needed Spring obviously.

[ronald_van_kuij]

it's important that you stick to the existing ejb interfaces.  users should not implement JavaDelegate.

Ok, good to get my view confirmed. I could not find a good reason to go this way.

In terms of passing the parameters, compare it with method expressions passing in parameters.  There's already a lot that you can do with that.  And it is already possible somehow to invoke an ejb through a method expression.  (maybe Joram can give pointers) Can you first evaluate when users should use method expressions with parameters and when they should be using the ejb activity?  Once that is cleared out, then it also gives you better guidance for which features to develop first.

Personally I prefer the expression way. Most likely this can only be used if the ejb has a mapped name or something. Will try this out comming days

But most importantly, is it a new service task or is it an addition to the java service task. Personally I'm in favour of the latter … Using a 'type' like for the mail task is not what I'd do for ejb calls (I would for jms though)

Tijs, is there a preferred way from the designer point of view?  Maybe in context of the pluggability?

If expressions already work, I'd certainly try to use the same task and not create an ejb-service task

… and it is probably even possible to use juel to resolve ejb's (high om my todo list, cdi?) and call the corresponding methods like in Seam.

first I explain that idea in detail and now you pretend that you had already thought about it before…  tsssss

Sorry…. 🙂

looks perfect to get started, but first evaluate how and where this is different from method expressions.

it might also be early days for creating unit tests for this. i have high on my agenda to run the test suite in container on hudson (this release?). but i'm not there yet.

I've used arquilian from JBoss for this recently somewhere. Works great… it supports more than ejb-unit, is a bit slower when the container needs to be started, but it's only 30 seconds

[ronald_van_kuij]

Regarding the 'pointer' refers to. A few months ago, I tried to wrap an EJB in a Spring bean anc call it through a method expression. That just worked as a charm, but you needed Spring obviously.

Ok, but that would require coding? Or can the spring bean be generic? Isn't a resolver for juel another option?

[jbarrez]

Or can the spring bean be generic

Good question, didnt try that yet. I'll give it a try tonight.

Isn't a resolver for juel another option?

If you want method expression without a spring bean, probably yes.

[ronald_van_kuij]

Or can the spring bean be generic

Good question, didnt try that yet. I'll give it a try tonight.

Ok

Isn't a resolver for juel another option?

If you want method expression without a spring bean, probably yes.

I'll focus on this one then…

[bernd_ruecker]

I would like to see the resolving of the EJB references pluggable, so JNDI is the default, but Service Registry could be maybe plugged in later.

I don't see a big difference between local and remote (except for the JNDI name and call by reference semantic), so I would target both. Actually I think remote is the bigger use case.

[ronald_van_kuij]

For remote you also need to provide context information like url, usename, password. But no worries, it will be taken into account for 5.3 the rest could maybe make it in 5.2

pluggability for resolving would be an option, but I don't think  not implementing it now makes it more difficult later

[ronald_van_kuij]

sorry that should both be a minor version more… jira freeze was aleady passed for 5.2