Hi Paul
On 17 Feb 2006, at 18:44, Paul Brown wrote:
Then inside the Ode podling we figure out over time what BPEL stuff
we can merge etc. Over time the Twister code could merge/move into
Ode. BPM code from Ode could move into Agila. Or we can merge
everything into Ode, or Agila can become the BPM project again and
Ode can be the BPEL project - we'll see, we can figure that out
later. But the structure from day one would be we'd have a new
podling with a similar structure to the existing Agila project.
I would think that getting everything into one place would be a good
plan, and I could envision a unified functional testing framework
(like the "Spexerciser" in PXE's codebase) as an initial deliverable
that will ensure that there is a uniform notion of what a BPEL engine
should do.
I can't imagine swapping activity implementations between PXE's
pi/actor machine and the backplanes that run BPE or Agila BPEL, but I
can definitely imagine achieving quick consensus on a uniform BPEL
parsing/static analysis framework, a uniform external eventing API,
and maybe even a uniform debugging API so that all of the engines can
plug into the same toolchain and the project can start feeding
libraries to other BPEL-related efforts within Apache and elsewhere
(like the Eclipse tooling project) and bubbling functionality up to
the level that real users really care about. (Ultimately, users will
care about good support for BPEL variants (1.1/2.0/other) and
business-focused functionality, but engine plumbing is for the nerds.)
Agreed. (I guess that makes me a nerd :)
I'm sure we might figure out some other reusable pieces too.
Does this structure seem reasonable to everyone?
Sounds reasonable to me.
Cool
James
-------
http://radio.weblogs.com/0112098/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
