-
1. Re: EJB 2.1 Beans in jbpm 4?
camunda Jun 10, 2009 5:59 AM (in response to camunda)By the way: Biggest issue I have with it is, that then you have to work with a RemoteCommandExecutor instead of a CommandService (the real interface).
In my app I want to use the CommandService (interfcae), not knowing that a RemoteCommandService sits behind it. Would be possible with EJB 3 out of the box, without using the "EjbRemoteCommandService" wrapper...
For the EjbRemoteCommandService I have a question: Why is the InitialContext created every time I execute a command (isn't that expensive?)? Should be improved I think (lazy create it once).
And why can't it read the jndi.properties from the classpath as an alternative?
Can I improve that class a bit? If you don't use it in the ProcessEngine wiring but directly from a remote client, it is not that nice this way... -
2. Re: EJB 2.1 Beans in jbpm 4?
kukeltje Jun 10, 2009 7:24 AM (in response to camunda)I second this.
In combination with the command interface in jBPM 3.0 not being really supported/documented and thus probably not being used much, I think switching to ejb 3.0 now would be a good moment (also marketing wise ;-)) -
3. Re: EJB 2.1 Beans in jbpm 4?
camunda Jun 10, 2009 9:43 AM (in response to camunda)+1
Maybe I could even help there, but I will run out of "jbpm time" in the next week I guess, so not sure... -
4. Re: EJB 2.1 Beans in jbpm 4?
jbarrez Jun 10, 2009 10:31 AM (in response to camunda)I agree, the initialContext should be cached
I thought the discussion of ejb2 vs ejb3 was done in the past and I think that tom wanted to have support on as many application servers as possible. Altough I must agree that I like EJB3 much much more ;)In combination with the command interface in jBPM 3.0 not being really supported/documented and thus probably not being used much
Everywhere I've done jbpm consultancy, they are using the CommandService ;-) -
5. Re: EJB 2.1 Beans in jbpm 4?
tom.baeyens Jun 10, 2009 12:42 PM (in response to camunda)bernd, you should not use the remote command service directly.
instead, you use the other jbpm services. internally they delegate to the command service. (which can be an ejb2 remote command service)
so even in the ejb remote case, you should not be confronted with ejb 2 details.
so i don't see the problem yet. -
6. Re: EJB 2.1 Beans in jbpm 4?
tom.baeyens Jun 10, 2009 12:43 PM (in response to camunda)in fact, i think the command service should be removed from the api module and be moved to the internal classes.
-
7. Re: EJB 2.1 Beans in jbpm 4?
camunda Jun 10, 2009 12:46 PM (in response to camunda)If you have a remote client you can ONLY use the CommandService. Why this should be not allowed?
The CommandService + Commands are a pretty good defined interface I think.
Using the ProcessEngine only works from INSIDE the app server. -
8. Re: EJB 2.1 Beans in jbpm 4?
tom.baeyens Jun 10, 2009 2:46 PM (in response to camunda)the current integration tests run as a remote application client.
the services (repository, execution, task,...) delegate internally to the command service. the examples and test-db test suites use the these services directly (not the command service)
user doesn't see the difference in their client api. between local usage and remote app server client usage. -
9. Re: EJB 2.1 Beans in jbpm 4?
kukeltje Jun 10, 2009 9:37 PM (in response to camunda)hmmm... ok, I did not know this. Time for me to start reading some more. I was under the same impression as Bernd and thinking about using the same approach.
-
10. Re: EJB 2.1 Beans in jbpm 4?
camunda Jun 11, 2009 12:35 AM (in response to camunda)Okay, I have to investigate a bit more here as well. But i still think, there is a use case to use the CommandService, e.g.
- sending Commands either via JMS asynchronously or execute the synchronously (think of batch operations)
- migration from jbpm 3, would be possible to write a simple "CommandTranslator" and plug it in the CommandService, so you don't have to change existing client code using Commands (okay, maybe you have to change some, but not all)
So basically I like the CommandService and want to keep it for sure in the API, don't make it internal please.
And I still would like to see an EJB3 implementation. For us, the development team, to make it easier but as well for marketing purposes (even if you don't see it in the code, the people ask what runs under the hood). But maybe it doesn't have a high priority, ok... -
11. Re: EJB 2.1 Beans in jbpm 4?
tom.baeyens Jun 11, 2009 4:21 AM (in response to camunda)also async commands can be done behind the same interface.
in that case, the command service can be replaced with a version that sends an async message to the job executor to execute the job asynchronously.
in that case you have to choose if you want to use the whole api asynchronously or not. i'm not yet sure if we have to introduce a way to let users choose async or not on a method by method basis... wdyt ?
the code is present but not yet tested/documented. that's for later as that doesn't have a priority yet. -
12. Re: EJB 2.1 Beans in jbpm 4?
jbarrez Jun 11, 2009 5:06 AM (in response to camunda)I believe we shouldn't impose a fixed sync/async way of working on the users of the remote api. I also think that usng a method param to change to async invocation is cumbersome for most users.
So, perhaps we should create a sync CommandService and an Async CommandService?
I'm also in favour of using EJB3. Since the commandservice normally is behind the service interfaces ... why not use a modern and cool implementation where everybody loves to work with? EJB3 runs today on all app servers I'm aware of (JBoss, Glassfish, Oracle, IBM, ...). -
13. Re: EJB 2.1 Beans in jbpm 4?
tom.baeyens Jun 11, 2009 5:12 AM (in response to camunda)Commands and CommandService are not necessary to give the user the capability of async commands.
There is already an AsyncCommandService, but it should be hidden behind the other services.
So I would translate your point into:
There should be a way for users to obtain a synchronous and an asynchronous version of the ProcessEngine. E.g. by adding a method ProcessEngine getAsyncProcessEngine() on the process engine itself. -
14. Re: EJB 2.1 Beans in jbpm 4?
jbarrez Jun 11, 2009 5:18 AM (in response to camunda)Sorry, didnt know about the AsyncCommandService, should've checked before posting ;-)
There should be a way for users to obtain a synchronous and an asynchronous version of the ProcessEngine. E.g. by adding a method ProcessEngine getAsyncProcessEngine() on the process engine itself.
Isn't this confusing to have 2 process engines for people that want to use both sync and async commands (altough the use cases are limited, but they do exist). Can't the services returned by the processEngine be sync or async?