1 2 Previous Next 25 Replies Latest reply on Jun 23, 2009 7:55 AM by tom.baeyens

    EJB 2.1 Beans in jbpm 4?

    camunda

      Hey guys,

      I just saw that we have EJB 2.1 beans again for jbpm 4. Any reason for not switching to ejb 3?

      Sooner or later we have to provide a EJB 3 version I think. And I would like to have it early to be honest. If we ship it from the beginning maybe we can skip supporting and EJB 2.1 version, which would be some cleaning up!

      Only thing which doesn't work in EJB 3 like in EJB 2.1 is the EntityBean -> Timer construct. Everything else could be easier done with EJB 3.

      What do you think? Because I hate it to make nowadays shocases with the new release with ugly EJB 2.1...

      But maybe I have missed a discussion about that?

      Cheers
      Bernd

        • 1. Re: EJB 2.1 Beans in jbpm 4?
          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

            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

              +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

                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

                  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

                    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

                      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

                        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

                          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

                            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

                              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

                                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

                                  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

                                    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?

                                    1 2 Previous Next