Have you consider deploying the ODE JBI implementation to GlassFish's JBI container?
Aaron ________________________________ From: Michael Hollatz <[email protected]> To: [email protected] Sent: Tue, August 24, 2010 1:34:13 AM Subject: Re: Hiring an ODE developer On 08/24/2010 07:15 AM, Aaron Anderson wrote: > 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. Yepp, I'm lazy too. I refuse looking into upstream code until I have a problem. :) > > > 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. Nice to hear that. I was not going that far yet. > > 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 ? I'm about to use all the new things available with OSGi including EJBs, web services and http services deployed and managed with the OSGi lifecycle. So this version won't even work in a container without such capabilities. What I currently have is a backported version of axis2-osgi for Axis2 1.3 which is used by ODE 1.3.4. Additionally I'm trying to trim down the required libraries to embed in the war for the ODE bundle (currently ~ 30 bundles deployed directly in glassfish, including apache commons.*, axiom, xstream, log4j, ...). In a later version (with code from ODE trunk) I will try to get rid of that monolithic war altogether and deploy the bits as a set of bundles. This also should apply for Axis2 although it does make sense to use the implementation (if any) provided by the container (in case of glassfish this would be jaxws). Anyhow it will be very difficult to maintain that for all the available containers as versions of libraries and capabilities differ a lot. So I'm building a glassfish-v3.1-only solution quite now. > > 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? From my point of view the thread pools that are available in glassfish would be a perfect choice for the thread management. If in another case they are not available I would fall back to the mechanisms already available in ODE. Well, to be honest I'll take the full profile at first, but later on I'm sure there would be the need for a dynamic self-configuration based on the runtime when ODE is started. Additionally building several distributions for different runtime profiles would also make sense so that the packages would just contain the bits actually required. The currently used plug-and-play (-in-tomcat) distribution is a nice thing for new users but not really an enterprise requirement. Here we have to face integrability. > > 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.
