[jbpm-dev] [Design of JBoss jBPM] - Re: EJB 2.1 Beans in jbpm 4?

Okay, I checked the Remote configuration now. Quite cool! Pretty nice for normal use cases I think. I still have some concerns: 1.) For Marketing reasons I would like to see EJB 3 inside of it. Even if you don't use it directly, EJB 2.1 is just "odd old" ;-) Too unsexy for jbpm 4. Maybe not a high priority, but still. And as Jorram pointed out, the developers supporting it or people trying to figure out transaction problems or whatever have a harder live here. 2.) I wouldn't completly let got of the commands. Zwo use cases from my last projects of a big customer, where I still would prefer them: a) Batch Commands: We just added a thin layer around the commands in order to be able to call them in a batch. The same command, but just with different parameters (e.g. from a csv). So in one batch you could execute a couple of thound commands (sync or async. Normally async with a big amount). Would be possible with the current API as well, but was/is much easier by using the commands directly. b) Chained Commands: Think of the use case, where you have to fix an instance. E.g. you have to cancel it, start a different "fixing" process for it, maybe jump to a special node and execute a Groovy script to fix process variables. Okay, maybe not the best example here, but we had business requirements to do stuff like this. Therefro we introduced a CommandChain which can execute other commands IN ONE transaction. (Clue is you can execute the chain as batch :-)). If you use the remote ProcessEngine it executes every call in its own transaciton, right? And again, I think it is even easier to implement with the commands, than with the API... This is why I still like the commands. But maybe I am just too used to it? So if you have good points agaionst it just let me know :-) Thoughts? Cheers Bernd View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238174#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...