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.
