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)
http://pxe.intalio.org/docs/apidocs
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.
James
-------
http://radio.weblogs.com/0112098/
