ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <james.strac...@gmail.com>
Subject Re: are we really gonna end up with 1 engine anyway?
Date Mon, 20 Feb 2006 18:09:51 GMT
On 20 Feb 2006, at 17:04, Alex Boisvert wrote:
> James Strachan wrote:
>> Right now today the Sybase code is geared more towards being a
>> generic orchestration/workflow engine that today supports BPEL 1.1
>> and can support other orchestration/workflow languages and could be
>> ported to 2.0 without huge amounts of effort. PXE is specifically
>> geared towards BPEL 2.0 as its primary design which could well be a
>> good thing if you want a BPEL 2.0 engine - though I do find the PXE
>> code harder go grok  - but maybe that's because its more BPEL 2.0
>> specific.
> James, I'd like add some precision to your comment because it may be
> interpreted in different ways.

Yeah sorry about that - I should have added a very large disclaimer  
saying "this is the view of someone with only a vague grasp of the  
details of PXE and who's struggled to grok it" :).

> While it is true that PXE specifically targets BPEL 1.1/2.0 as its
> primary goal it does not mean that PXE is limited to, or  
> constrained by
> this objective. PXE is designed to be extensible and is built on a
> strong fundation (the Jacob virtual machine) which provides ample
> opportunity to extend PXE into various other orchestration/workflow
> capabilities beyond what is prescribed by BPEL. I will echo your
> sentiment that PXE may be harder to grok, possibly because of its more
> complex architecture and because as it stands, its scope is larger  
> than
> BPEL alone and includes -- among other things -- a microkernel, a
> SOAP/HTTP binding, integration with 3rd-party transaction managers  
> (e.g.
> Minerva) and a service framework similar to JBI.

Agreed - I think its sheer size could well be one of the reasons its  
hard to figure out where to start.  Last time I looked in detail it  
did have lots of packages with acronyms in them I didn't recognise  
that didn't help either.  I was hunting around for javadoc to see if  
thats still the case (but the URL doesn't seem to work)

> This allows PXE to run
> standalone without an application server or a JBI environment.
> We certainly hope to reduce the size of the PXE codebase to make it
> easier to grasp and also make it more agile. As a matter of fact,  
> we are
> considering adopting JBI as our "native" service framework, and
> leveraging existing JBI components + J2EE environments to trim the
> codebase even further. Without a doubt, ServiceMix and Gernimo
> integration are beneficial to the project.

Great! :)

> Which brings us back to the original questions about goals of the
> project. Since we are at such early stage of the project, I believe it
> would be easier to build concensus on goals than the relative  
> merits of
> each engine.

The reason for me starting this thread wasn't really meant to be  
comparing the merits of the 2 engines other than to say that they  
both are quite different and both have value today - it was really  
just to ask if we really think we're going to end up with just 1  
engine any time soon or do we really think that we'll have 2 engines  
for some time while we have some reuse across them both.


View raw message