Hi Michael, Coincidentally I am interested in enhancing ODE to support a Java EE 6 web profile implementation as well. Unfortunately I am unavailable to work on this full time but I would be glad to contribute to the effort in a month or so. After contributing a little bit towards the JPA refactoring and examining the ODE internals here are my ideas towards a JavaEE 6 implementation which are somewhat similar to your own:
1) Maintaining the existing ODE architecture and implementations. The Axis and JBI ODE implementation are very stable and widely deployed. Any modifications to the existing engine implementation should be carefully conducted as to not impact the existing architecture. 2) Introduction of JSR 331 injection annotations into the ODE engine and DAO classes to support dependency injection in ODE. This is inline with your desire to utilize application server managed JPA and JTA resources. Introducing primitive dependency injection would also facilitate embedding ODE in other frameworks such as Spring or SCA. 3) Introduction of a JAXWS implementation in addition to the Axis and JBI ones and also introducing a slightly different deployment process. The currently ODE deployment process dynamically binds web service endpoints at runtime. In accordance with the JSR 109 spec this is not allowed in JavaEE. In order for webservices to be managed and to take advantage of any application server web service features they must be explicitly deployed as an EJB or WAR module. To get around this limitation I have been researching using the new Java EE 6 global JNDI feature so that a new JAXWS ODE deployment WAR archive could possibly be deployed to the app server and then communicate with the central ODE server in a federated manor. This would allow for the web service endpoints to be managed by the application server and then be "activated" or "deactivated" as part of an ODE specific deployment process. 4) JPA 2.0 support - JPA 2.0 has some new features that would slightly simplify some of the scheduling code. 5) Investigate creating custom JSR331 scopes that are BPEL specific to simplify dependency injection and transaction management. 6) Creating a JSR 299 extension to wire everything together A couple questions for you: 1) You mentioned running ODE in the GF3 felix OSGI container. Are you planning on adding a OSGI bundle deployment capability to ODE or running ODE in a pure Java EE environment deployed as an EAR or set of WAR files ? 2) What are your thoughts on externalizing the thread management of ODE? While thread management is technically forbidden in the JavaEE Spec practically every web application framework does it including many of Sun's former productions. JavaEE 6 supports async operations and JCA resource adapters which natively support application server managed threads but both these features require the full EJB profile. JAXWS does support async service invocations and the ExecutorService can even be obtained to perhaps perform some additional work. Another thing to consider is that the scheduler must run in an independent thread to perform scheduling task and while there is the new scheduler feature in EJB 3.1 it requires the full profile. I think targeting the EJB light profile would be a more popular choice. What do you think? Cheers, Aaron ________________________________ From: Michael Hollatz <[email protected]> To: [email protected] Sent: Sun, August 22, 2010 2:59:20 PM Subject: Hiring an ODE developer Hi devs, I know the subject sounds a bit strange. So I will first explain what I talk about: I currently work in a company located in Berlin/Germany. We are working hard on a new Java Enterprise project that requires a process engine and we chose ODE for that as it is widely adopted and seems to be rather stable comparing to other open source alternatives. Our main problem here is that we have not enough in-House knowledge about ODE or BPEL to extend its functionality according to our needs. What I'm missing in ODE is a nice enterprise grade integration with application servers. As we are working with the latest bits of Glassfish v3.1, utilizing the flexible OSGi infrastructure, we also want that ODE benefits from that or at least integrates nicely. I'm currently working on that task for quite some time now (minimizing the libraries required to be included in the ODE-bundle). As we expand and face new requirements we want to make sure that ODE is capable of doing that. And so this is the moment where I decided to write to this mailing list I'm watching quite some time now. What we would do is to pay an ODE developer for integrating our needs. Those requirements would be aligned with the overall ODE roadmap and we wouldn't enforce anything proprietary. Additionally all the code that is written by the corresponding developer will be directly available upstream at ODE so that anyone can benefit from that. I know ODE is integrated into ServiceMix but we really don't need an ESB as we have a rather pure JavaEE environment here. Areas of work that the developer would be faced with for the next months would include: 1.) ODE running in Felix (especially Glassfish v3.1) 2.) ODE using an external JTA datasource from an application server (ideally using an externally provided JPA inplementation - just like JBoss or Glassfish provide) 3.) getting rid of the internal Threads inside an JEE environment (as we have a lot of different concepts here that are - and should be - managed by the container) 4.) Exporting the management API as EJB to be directly available (so stripping the web service overhead) 5.) ability to directly call EJB's or at least providing an easy generic integration concept here ...and last but not least: 6.) teach our devs some internals/best practices I've already done some work on tasks 1) and 2) but for me without real insight knowledge it takes a lot of time facing the various problems. So in basic we want someone getting paid for working on this nice open-source project and thus sponsoring the ODE development in some specific directions. So is there someone interested here? Additionally it would be really nice to have someone that can work directly inside our company which would make communication a lot easier and speed-up development. Kind regards, Michael "Kane" Hollatz ProfitBricks GmbH Greifswalder Str. 207 D - 10405 Berlin Office: +49 - 30 - 51 64 09 21 Fax: +49 - 30 - 51 64 09 22 Email: [email protected] URL: http://www.profitbricks.com/ Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 125506 B. Geschäftsführer: Andreas Gauger, Achim Weiss. Please consider the environment before printing this email.
