You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ode.apache.org by James Strachan <ja...@gmail.com> on 2006/02/20 17:16:31 UTC
are we really gonna end up with 1 engine anyway?
There seems to have been an assumption that there should only be one
orchestration/BPEL/workflow engine in the Ode project. So far I seem
to be MrNegative repeatedly doubting whether this assumption is valid
or useful so I just wanted to get feedback on peoples thoughts on
this specific issue, particularly from the Sybase/PXE folks.
Here's my personal take:
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.
In summary they are both very different, solving things in different
ways - I see value in both codebases as they are today. I also see
areas they can collaborate (as PaulB mentioned recently). So we can
definitely have code reuse across the two engines. However I honestly
have no idea if we can ever merge the two codebases into one - the
experiment has some merit for sure but it could be too big a leap.
Putting that ServiceMix hat on again; we certainly have a use case for
* a general purpose orchestration engine that we can use from Java code
* BPEL 1.1
* BPEL 2.0
* any new XML language that comes out in the orchestration/workflow
space
So both engines have immediate value to ServiceMix.
Putting that Ode hat on again, my personal priorities on the ODE
project are are to get both engines working well in their new Apache
home, then looking to where we can reuse code & infrastructure across
the two. But unifying the code into one engine isn't on my personal
list of itches to scratch (and I've lots of itches :). I'm perfectly
happy for them to stay separate and let reuse happen iteratively over
time.
Specifically to Sybase & PXE folks, what are your thoughts?
James
-------
http://radio.weblogs.com/0112098/
Re: are we really gonna end up with 1 engine anyway?
Posted by Lance Waterman <la...@gmail.com>.
Thanks Paul - I just wanted to make sure I wasn't missing something. I know
its tough trying to hit a moving spec ;)
Lance
On 2/23/06, Paul Brown <pa...@gmail.com> wrote:
>
> Hi, Lance --
>
> > I can see how the BpelIfActivityState maps into the bom (
> SwitchActivityImpl
> > ), however I'm a bit lost on <forEach> and <repeatUntil>. I don't see
> parser
> > classes for these constructs nor do I see them registered in
> BpelGraph_2_0.
>
> If they're not in BpelGraph_2_0, then they weren't in on the last pass
> over the spec. It's not difficult to add the pieces to the
> bpel-parser and bom modules for new activities. Adding the right bits
> to the compiler and VM infrastructure is a little more involved but
> also not too difficult if you've got the Zen down. That said, I'm
> reasonably sure that Maciej and company have been holding off on
> adding them to the compiler pipeline until, e.g., 242 and 243 are
> settled. (The precise behavior of scopes vis a vis iteration needs to
> be clarified before the runtime semantics can be implemented.)
>
> -- Paul
>
Re: are we really gonna end up with 1 engine anyway?
Posted by Paul Brown <pa...@gmail.com>.
Hi, Lance --
> I can see how the BpelIfActivityState maps into the bom ( SwitchActivityImpl
> ), however I'm a bit lost on <forEach> and <repeatUntil>. I don't see parser
> classes for these constructs nor do I see them registered in BpelGraph_2_0.
If they're not in BpelGraph_2_0, then they weren't in on the last pass
over the spec. It's not difficult to add the pieces to the
bpel-parser and bom modules for new activities. Adding the right bits
to the compiler and VM infrastructure is a little more involved but
also not too difficult if you've got the Zen down. That said, I'm
reasonably sure that Maciej and company have been holding off on
adding them to the compiler pipeline until, e.g., 242 and 243 are
settled. (The precise behavior of scopes vis a vis iteration needs to
be clarified before the runtime semantics can be implemented.)
-- Paul
Re: are we really gonna end up with 1 engine anyway?
Posted by Lance Waterman <la...@gmail.com>.
Thanks Paul,
It helps to look at the right thing ;)
I can see how the BpelIfActivityState maps into the bom ( SwitchActivityImpl
), however I'm a bit lost on <forEach> and <repeatUntil>. I don't see parser
classes for these constructs nor do I see them registered in BpelGraph_2_0.
Thanks for your help walking through this!
Lance
On 2/23/06, Paul Brown <pa...@gmail.com> wrote:
>
> Hi, Lance --
>
> > I have been looking through the bpel-parser and bom and want to make
> sure
> > I'm on right track. I got the source from here (
> > http://pxe.intalio.org/public/pxe-src-r812.zip ) and have been focusing
> on
> > the packages com.fx.pxe.sax.fsa.bpel_2_0 and com.fx.pxe.bom.api. I am
> > looking for parser/bom support for some of the new 2.0 constructs ( i.e.
> > <if>,<forEach>, etc ... ) and I don't see these objects ( i.e.
> > com.fx.pxe.sax.fsa.bpel_2_0.BpelIfState ). Am I looking in the right
> place
> > or perhaps I'm making a bad assumption as to the implementation?
>
> The BPEL 2.0 specific sub-handlers are here:
>
> http://tinyurl.com/jufvy
>
> And here's the <bpel:if> activity piece:
>
> http://tinyurl.com/eo2xo
>
> The BOM SwitchActivity suffices for both 1.1 and 2.0, so if you were
> to look into the bit that handles SAX events for a <bpel:if>
> (IfActivityState in com.fs.pxe.sax.fsa.bpel_2_0), you'd see that get
> created:
>
> 24 protected Activity createActivity(StartElement se) {
> 25 return new SwitchActivityImpl();
> 26 }
>
> Things like expressions (attributes in 1.1 versus bodies of elements
> in 2.0) are abstracted in the BOM and then mapped in the bpel-parser
> module. The *State objects are expected to know what to do with their
> children, so you can see what's happening in the
> handleChildCompleted(State pn) method to attach an expression, a then
> clause, an elseif clause, an else clause.
>
> I wrote a blog entry about how the bpel-parser module was motivated
> and constructed:
>
>
> http://mult.ifario.us/articles/2006/02/05/populating-a-java-object-model-from-xml
>
> Best,
>
> -- Paul
>
Re: are we really gonna end up with 1 engine anyway?
Posted by Paul Brown <pa...@gmail.com>.
Hi, Lance --
> I have been looking through the bpel-parser and bom and want to make sure
> I'm on right track. I got the source from here (
> http://pxe.intalio.org/public/pxe-src-r812.zip ) and have been focusing on
> the packages com.fx.pxe.sax.fsa.bpel_2_0 and com.fx.pxe.bom.api. I am
> looking for parser/bom support for some of the new 2.0 constructs ( i.e.
> <if>,<forEach>, etc ... ) and I don't see these objects ( i.e.
> com.fx.pxe.sax.fsa.bpel_2_0.BpelIfState ). Am I looking in the right place
> or perhaps I'm making a bad assumption as to the implementation?
The BPEL 2.0 specific sub-handlers are here:
http://tinyurl.com/jufvy
And here's the <bpel:if> activity piece:
http://tinyurl.com/eo2xo
The BOM SwitchActivity suffices for both 1.1 and 2.0, so if you were
to look into the bit that handles SAX events for a <bpel:if>
(IfActivityState in com.fs.pxe.sax.fsa.bpel_2_0), you'd see that get
created:
24 protected Activity createActivity(StartElement se) {
25 return new SwitchActivityImpl();
26 }
Things like expressions (attributes in 1.1 versus bodies of elements
in 2.0) are abstracted in the BOM and then mapped in the bpel-parser
module. The *State objects are expected to know what to do with their
children, so you can see what's happening in the
handleChildCompleted(State pn) method to attach an expression, a then
clause, an elseif clause, an else clause.
I wrote a blog entry about how the bpel-parser module was motivated
and constructed:
http://mult.ifario.us/articles/2006/02/05/populating-a-java-object-model-from-xml
Best,
-- Paul
Re: are we really gonna end up with 1 engine anyway?
Posted by Lance Waterman <la...@gmail.com>.
Paul,
I have been looking through the bpel-parser and bom and want to make sure
I'm on right track. I got the source from here (
http://pxe.intalio.org/public/pxe-src-r812.zip ) and have been focusing on
the packages com.fx.pxe.sax.fsa.bpel_2_0 and com.fx.pxe.bom.api. I am
looking for parser/bom support for some of the new 2.0 constructs ( i.e.
<if>,<forEach>, etc ... ) and I don't see these objects ( i.e.
com.fx.pxe.sax.fsa.bpel_2_0.BpelIfState ). Am I looking in the right place
or perhaps I'm making a bad assumption as to the implementation?
Lance
On 2/21/06, Paul Brown <pa...@gmail.com> wrote:
>
> Hi, Lance --
>
> > At this point, I think I used the term "parser" a bit too generically. I
> > should have used the term "translator".
>
> Then you'd want bpel-parser + bom. :)
>
> The bpel-parser module is a SAX-only, grammar-based approach to
> parsing both dialects of BPEL and mapping them to a normalized object
> model that contains the necessary information for both 1.1 and 2.0.
> The current tool chain within PXE is something like this:
>
> text -[xml parser]-> SAX -[bpel-parser]-> BOM -[bpel-compiler]-> O-model
>
> And the O-model is what's used to generate the "byte code" for the PXE
> PVM at runtime. The bpel-compiler contains most of the static
> analysis logic and enforcement, while the parser is based on the BPEL
> grammar but not according to the schema, since XML Schema doesn't
> capture a good number of the semantics needed. (Non-deterministic
> content model blah blah.)
>
> I'll go on record as stating that I don't think that having one engine
> makes sense as a goal, but I do think that it makes sense to have an
> emphasis, as a collective, on generating independently useful
> artifacts from each engine effort, e.g., parsing and static analysis.
>
> We can start with the notion of having a Crimson and a Xerces, which
> is appropriate if you think about how the two parsers were originally
> conceived (SUN/IBM, different implementation approaches) and donated
> to Apache.
>
> Cheers.
>
> -- Paul
>
Re: are we really gonna end up with 1 engine anyway?
Posted by Davanum Srinivas <da...@gmail.com>.
+1 to merge the tests and get both engines to pass them (when they
implement the version of the spec)
thanks,
dims
On 2/22/06, Lance Waterman <la...@gmail.com> wrote:
> Dims/Paul,
>
> Thanks, I have the PXE source and will take a look to see if the bpel-parser
> + bom would make sense to reuse.
>
> I would like to try and steer this discussion back to my original question
> on defining a common set of BPEL acceptance tests. Do you think this sounds
> like a reasonable thing to achieve? I noticed there are BPEL documents
> located at ( pxe\bpel-scripts\src1.1\good and pxe\bpel-scripts\src\2.0\good
> ). Do you consider these the PXE acceptance tests? The Sybase donation has
> BPEL test documents located at ( bpe\bpelTests ). Does it make sense to
> start by merging these two groups of tests?
>
> Lance
>
> On 2/21/06, Paul Brown <pa...@gmail.com> wrote:
> >
> > Hi, Lance --
> >
> > > At this point, I think I used the term "parser" a bit too generically. I
> > > should have used the term "translator".
> >
> > Then you'd want bpel-parser + bom. :)
> >
> > The bpel-parser module is a SAX-only, grammar-based approach to
> > parsing both dialects of BPEL and mapping them to a normalized object
> > model that contains the necessary information for both 1.1 and 2.0.
> > The current tool chain within PXE is something like this:
> >
> > text -[xml parser]-> SAX -[bpel-parser]-> BOM -[bpel-compiler]-> O-model
> >
> > And the O-model is what's used to generate the "byte code" for the PXE
> > PVM at runtime. The bpel-compiler contains most of the static
> > analysis logic and enforcement, while the parser is based on the BPEL
> > grammar but not according to the schema, since XML Schema doesn't
> > capture a good number of the semantics needed. (Non-deterministic
> > content model blah blah.)
> >
> > I'll go on record as stating that I don't think that having one engine
> > makes sense as a goal, but I do think that it makes sense to have an
> > emphasis, as a collective, on generating independently useful
> > artifacts from each engine effort, e.g., parsing and static analysis.
> >
> > We can start with the notion of having a Crimson and a Xerces, which
> > is appropriate if you think about how the two parsers were originally
> > conceived (SUN/IBM, different implementation approaches) and donated
> > to Apache.
> >
> > Cheers.
> >
> > -- Paul
> >
>
>
--
Davanum Srinivas : http://wso2.com/blogs/
Re: are we really gonna end up with 1 engine anyway?
Posted by Paul Brown <pa...@gmail.com>.
Hi, Lance --
> I would like to try and steer this discussion back to my original question
> on defining a common set of BPEL acceptance tests. Do you think this sounds
> like a reasonable thing to achieve? I noticed there are BPEL documents
> located at ( pxe\bpel-scripts\src1.1\good and pxe\bpel-scripts\src\2.0\good
> ). Do you consider these the PXE acceptance tests? The Sybase donation has
> BPEL test documents located at ( bpe\bpelTests ). Does it make sense to
> start by merging these two groups of tests?
You're looking in the right place. PXE has a harness (probably
similar to what BPE does...) that injects messages into ports via a
synthetic endpoint and then looks for responses and checks XPaths.
There are BPEL processes that are constructed to check for various
functional behaviors, check for runtime faults, etc. Each of the
subdirectories contains specific tests for assign, event handlers,
etc.
There are additional verifications of static analysis behaviors in the
tests for the bpel-compiler module as JUnit tests.
So, I think it makes sense to figure out a kind of combination of spec
verification (with explicit clarifications for areas of ambiguity in
1.1 (fault handlers, e.g.) and functional verification. Because of
the level of detail that's required, this is an area where many hands
(and eyes) help to make light work, and I can say that as the guy who
had to write a bunch of those BPEL processes in Emacs...
-- Paul
Re: are we really gonna end up with 1 engine anyway?
Posted by Lance Waterman <la...@gmail.com>.
Dims/Paul,
Thanks, I have the PXE source and will take a look to see if the bpel-parser
+ bom would make sense to reuse.
I would like to try and steer this discussion back to my original question
on defining a common set of BPEL acceptance tests. Do you think this sounds
like a reasonable thing to achieve? I noticed there are BPEL documents
located at ( pxe\bpel-scripts\src1.1\good and pxe\bpel-scripts\src\2.0\good
). Do you consider these the PXE acceptance tests? The Sybase donation has
BPEL test documents located at ( bpe\bpelTests ). Does it make sense to
start by merging these two groups of tests?
Lance
On 2/21/06, Paul Brown <pa...@gmail.com> wrote:
>
> Hi, Lance --
>
> > At this point, I think I used the term "parser" a bit too generically. I
> > should have used the term "translator".
>
> Then you'd want bpel-parser + bom. :)
>
> The bpel-parser module is a SAX-only, grammar-based approach to
> parsing both dialects of BPEL and mapping them to a normalized object
> model that contains the necessary information for both 1.1 and 2.0.
> The current tool chain within PXE is something like this:
>
> text -[xml parser]-> SAX -[bpel-parser]-> BOM -[bpel-compiler]-> O-model
>
> And the O-model is what's used to generate the "byte code" for the PXE
> PVM at runtime. The bpel-compiler contains most of the static
> analysis logic and enforcement, while the parser is based on the BPEL
> grammar but not according to the schema, since XML Schema doesn't
> capture a good number of the semantics needed. (Non-deterministic
> content model blah blah.)
>
> I'll go on record as stating that I don't think that having one engine
> makes sense as a goal, but I do think that it makes sense to have an
> emphasis, as a collective, on generating independently useful
> artifacts from each engine effort, e.g., parsing and static analysis.
>
> We can start with the notion of having a Crimson and a Xerces, which
> is appropriate if you think about how the two parsers were originally
> conceived (SUN/IBM, different implementation approaches) and donated
> to Apache.
>
> Cheers.
>
> -- Paul
>
Re: are we really gonna end up with 1 engine anyway?
Posted by Paul Brown <pa...@gmail.com>.
Hi, Lance --
> At this point, I think I used the term "parser" a bit too generically. I
> should have used the term "translator".
Then you'd want bpel-parser + bom. :)
The bpel-parser module is a SAX-only, grammar-based approach to
parsing both dialects of BPEL and mapping them to a normalized object
model that contains the necessary information for both 1.1 and 2.0.
The current tool chain within PXE is something like this:
text -[xml parser]-> SAX -[bpel-parser]-> BOM -[bpel-compiler]-> O-model
And the O-model is what's used to generate the "byte code" for the PXE
PVM at runtime. The bpel-compiler contains most of the static
analysis logic and enforcement, while the parser is based on the BPEL
grammar but not according to the schema, since XML Schema doesn't
capture a good number of the semantics needed. (Non-deterministic
content model blah blah.)
I'll go on record as stating that I don't think that having one engine
makes sense as a goal, but I do think that it makes sense to have an
emphasis, as a collective, on generating independently useful
artifacts from each engine effort, e.g., parsing and static analysis.
We can start with the notion of having a Crimson and a Xerces, which
is appropriate if you think about how the two parsers were originally
conceived (SUN/IBM, different implementation approaches) and donated
to Apache.
Cheers.
-- Paul
Re: are we really gonna end up with 1 engine anyway?
Posted by Lance Waterman <la...@gmail.com>.
Dims,
At this point, I think I used the term "parser" a bit too generically. I
should have used the term "translator".
Lance
On 2/21/06, Davanum Srinivas <da...@gmail.com> wrote:
>
> Lance,
>
> > I am currently looking into a BPEL 2.0 parser
>
> Looked at bpel-parser in pxe yet?
> (http://svn.intalio.org/viewrep/PXE/pxe/bpel-parser). If it does not
> serve your purposes, the pxe folks may(hopefull will :) be able to
> whip it to shape to suit your purposes. WDYT?
>
> thanks,
> dims
>
> On 2/21/06, Lance Waterman <la...@gmail.com> wrote:
> > James,
> >
> > This sounds reasonable to me. Perhaps a starting point would be a set of
> > BPEL 1.1/2.0 acceptance tests ( which have been mentioned in other
> threads
> > )?
> >
> > I am currently looking into a BPEL 2.0 parser for the Sybase engine. My
> plan
> > was to migrate our current BPEL 1.1 tests to BPEL 2.0, however I
> > think having a common set of BPEL acceptance tests in Ode would be a
> good
> > idea.
> >
> > I have not had a chance to look through the PXE contribution for BPEL
> > acceptance tests. What do folks think about merged BPEL acceptance tests
> as
> > a starting point?
> >
> > Lance
> >
> >
> > On 2/20/06, James Strachan <ja...@gmail.com> wrote:
> > >
> > > There seems to have been an assumption that there should only be one
> > > orchestration/BPEL/workflow engine in the Ode project. So far I seem
> > > to be MrNegative repeatedly doubting whether this assumption is valid
> > > or useful so I just wanted to get feedback on peoples thoughts on
> > > this specific issue, particularly from the Sybase/PXE folks.
> > >
> > > Here's my personal take:
> > >
> > > 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.
> > >
> > > In summary they are both very different, solving things in different
> > > ways - I see value in both codebases as they are today. I also see
> > > areas they can collaborate (as PaulB mentioned recently). So we can
> > > definitely have code reuse across the two engines. However I honestly
> > > have no idea if we can ever merge the two codebases into one - the
> > > experiment has some merit for sure but it could be too big a leap.
> > >
> > > Putting that ServiceMix hat on again; we certainly have a use case for
> > >
> > > * a general purpose orchestration engine that we can use from Java
> code
> > > * BPEL 1.1
> > > * BPEL 2.0
> > > * any new XML language that comes out in the orchestration/workflow
> > > space
> > >
> > > So both engines have immediate value to ServiceMix.
> > >
> > > Putting that Ode hat on again, my personal priorities on the ODE
> > > project are are to get both engines working well in their new Apache
> > > home, then looking to where we can reuse code & infrastructure across
> > > the two. But unifying the code into one engine isn't on my personal
> > > list of itches to scratch (and I've lots of itches :). I'm perfectly
> > > happy for them to stay separate and let reuse happen iteratively over
> > > time.
> > >
> > > Specifically to Sybase & PXE folks, what are your thoughts?
> > >
> > > James
> > > -------
> > > http://radio.weblogs.com/0112098/
> > >
> >
> >
>
>
> --
> Davanum Srinivas : http://wso2.com/blogs/
>
Re: are we really gonna end up with 1 engine anyway?
Posted by Davanum Srinivas <da...@gmail.com>.
Lance,
> I am currently looking into a BPEL 2.0 parser
Looked at bpel-parser in pxe yet?
(http://svn.intalio.org/viewrep/PXE/pxe/bpel-parser). If it does not
serve your purposes, the pxe folks may(hopefull will :) be able to
whip it to shape to suit your purposes. WDYT?
thanks,
dims
On 2/21/06, Lance Waterman <la...@gmail.com> wrote:
> James,
>
> This sounds reasonable to me. Perhaps a starting point would be a set of
> BPEL 1.1/2.0 acceptance tests ( which have been mentioned in other threads
> )?
>
> I am currently looking into a BPEL 2.0 parser for the Sybase engine. My plan
> was to migrate our current BPEL 1.1 tests to BPEL 2.0, however I
> think having a common set of BPEL acceptance tests in Ode would be a good
> idea.
>
> I have not had a chance to look through the PXE contribution for BPEL
> acceptance tests. What do folks think about merged BPEL acceptance tests as
> a starting point?
>
> Lance
>
>
> On 2/20/06, James Strachan <ja...@gmail.com> wrote:
> >
> > There seems to have been an assumption that there should only be one
> > orchestration/BPEL/workflow engine in the Ode project. So far I seem
> > to be MrNegative repeatedly doubting whether this assumption is valid
> > or useful so I just wanted to get feedback on peoples thoughts on
> > this specific issue, particularly from the Sybase/PXE folks.
> >
> > Here's my personal take:
> >
> > 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.
> >
> > In summary they are both very different, solving things in different
> > ways - I see value in both codebases as they are today. I also see
> > areas they can collaborate (as PaulB mentioned recently). So we can
> > definitely have code reuse across the two engines. However I honestly
> > have no idea if we can ever merge the two codebases into one - the
> > experiment has some merit for sure but it could be too big a leap.
> >
> > Putting that ServiceMix hat on again; we certainly have a use case for
> >
> > * a general purpose orchestration engine that we can use from Java code
> > * BPEL 1.1
> > * BPEL 2.0
> > * any new XML language that comes out in the orchestration/workflow
> > space
> >
> > So both engines have immediate value to ServiceMix.
> >
> > Putting that Ode hat on again, my personal priorities on the ODE
> > project are are to get both engines working well in their new Apache
> > home, then looking to where we can reuse code & infrastructure across
> > the two. But unifying the code into one engine isn't on my personal
> > list of itches to scratch (and I've lots of itches :). I'm perfectly
> > happy for them to stay separate and let reuse happen iteratively over
> > time.
> >
> > Specifically to Sybase & PXE folks, what are your thoughts?
> >
> > James
> > -------
> > http://radio.weblogs.com/0112098/
> >
>
>
--
Davanum Srinivas : http://wso2.com/blogs/
Re: are we really gonna end up with 1 engine anyway?
Posted by Lance Waterman <la...@gmail.com>.
James,
This sounds reasonable to me. Perhaps a starting point would be a set of
BPEL 1.1/2.0 acceptance tests ( which have been mentioned in other threads
)?
I am currently looking into a BPEL 2.0 parser for the Sybase engine. My plan
was to migrate our current BPEL 1.1 tests to BPEL 2.0, however I
think having a common set of BPEL acceptance tests in Ode would be a good
idea.
I have not had a chance to look through the PXE contribution for BPEL
acceptance tests. What do folks think about merged BPEL acceptance tests as
a starting point?
Lance
On 2/20/06, James Strachan <ja...@gmail.com> wrote:
>
> There seems to have been an assumption that there should only be one
> orchestration/BPEL/workflow engine in the Ode project. So far I seem
> to be MrNegative repeatedly doubting whether this assumption is valid
> or useful so I just wanted to get feedback on peoples thoughts on
> this specific issue, particularly from the Sybase/PXE folks.
>
> Here's my personal take:
>
> 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.
>
> In summary they are both very different, solving things in different
> ways - I see value in both codebases as they are today. I also see
> areas they can collaborate (as PaulB mentioned recently). So we can
> definitely have code reuse across the two engines. However I honestly
> have no idea if we can ever merge the two codebases into one - the
> experiment has some merit for sure but it could be too big a leap.
>
> Putting that ServiceMix hat on again; we certainly have a use case for
>
> * a general purpose orchestration engine that we can use from Java code
> * BPEL 1.1
> * BPEL 2.0
> * any new XML language that comes out in the orchestration/workflow
> space
>
> So both engines have immediate value to ServiceMix.
>
> Putting that Ode hat on again, my personal priorities on the ODE
> project are are to get both engines working well in their new Apache
> home, then looking to where we can reuse code & infrastructure across
> the two. But unifying the code into one engine isn't on my personal
> list of itches to scratch (and I've lots of itches :). I'm perfectly
> happy for them to stay separate and let reuse happen iteratively over
> time.
>
> Specifically to Sybase & PXE folks, what are your thoughts?
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
Re: are we really gonna end up with 1 engine anyway?
Posted by Bill Flood <bi...@gmail.com>.
The Sybase contribution did not attempt to address the JBI problem or bus
problem at all as we are assumed to be plugged into a bus. That's probably
why some people find this contribution easier to grok. The contribution is
very targeted to a specific part of the problem. Likewise, the engine can
run outside of any container as is. The transaction semantics are delegated
to the container, if there is one. Likewise, the BPEL support is not
injected directly into the engine.
Re: are we really gonna end up with 1 engine anyway?
Posted by Paul Brown <pa...@gmail.com>.
Hi, James --
> 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.
I think that there are a couple of points here:
1) Without some guidance, PXE code is more difficult to grok, but once
you're into it, it can be impressively productive. (For example, you
can change-out the way that the engine implements BPEL in about a week
of effort. We did this multiple times as the spec changed.)
2) The Jacob virtual machine is a generic durable continuation engine
suitable for many purposes. I don't know if the prime sieve example
made it into the Subversion tree, but that would be one place to grok
what's going on.
3) PXE actually runs both 1.1 and 2.0 against the *same* runtime; only
the compiler is different... You could also, within reason, set up
variants of each if you wanted to have compatibility with other
engines that made tradeoffs with areas of ambiguity in the BPEL4WS 1.1
spec. This means that you can do lots of cool things... For example,
if you had the same set of ports and port types, you could run
*different* versions of a process in the same pool of instances;
they're just differen expressions to be reduced but with the same
"free" symbols.
4) The current JBI integration is less than ideal, as it doesn't fully
replace PXE's internal JBI-like messaging framework with the JBI
equivalent. This has its moments (PXE is WSDL 1.1-biased, JBI is WSDL
2.0-biased), but it would be doable if there was motivation.
#4 is something that we should address.
I'll let Bill or someone else from the Sybase side talk about how BPE
works, but it's my initial impression that it's at a higher level.
You should find a way to get a JaCOb overview from Maciej and then
make a fresh assessment.
-- Paul
Re: are we really gonna end up with 1 engine anyway?
Posted by Davanum Srinivas <da...@gmail.com>.
James,
we may end up with 1 or 2 only time will tell. Please let everyone to
make a pitch about their respective code bases their strengths and
weaknesses. Let everyone poke around a bit *AFTER* the code bases get
checked in. How can we really make up our mind one way or another
without enough information?
> "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
thanks,
dims
Re: are we really gonna end up with 1 engine anyway?
Posted by James Strachan <ja...@gmail.com>.
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/
Re: are we really gonna end up with 1 engine anyway?
Posted by Alex Boisvert <bo...@intalio.com>.
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.
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. 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.
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. What I hear from you is that the ServiceMix project is
interested in a small embeddable orchestration engine. I, for one, would
be very much in agreement that whatever to come out of the Ode project
should be easily reusable and embeddable, and be as small as possible
considering the constraints of other goals (e.g. implementing BPEL 2.0).
regards,
alex