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)
Access to local EJBs from service tasks is exactly what I need. Do you know when this feature will be included in an official release? I've seen the patch in JIRA, but I'd prefer to use an official release.
