ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Flood" <bill.f.fl...@gmail.com>
Subject Planning assumptions
Date Fri, 14 Apr 2006 14:38:45 GMT
I'd like to try to recap some of the ongoing efforts and assumptions
in order to get some level of consensus for planning purposes...

In theory, we would like to set on a common implementation simply as a
matter of economy of scale.  The devil is in the details so let's get
to some of those now.

Several of us, unfamiliar with the PXE implementation, are spinning up
on the approach taken in that implementation to determine what
components might be leveraged for a common Ode implementation.  There
is a lot of productive dialog and education about both the motivation
and make up of the PXE contribution.  We are not quite there yet but
there are several statements that we can make at this point in our
analysis.

-  There appears to be a desire to remove the current PXE dependency
on Hibernate, which is licensed under the LGPL.  The abstraction layer
developed for BPE could be useful for a common Ode implementation..
The BPE implementation relies on J2EE CMP for stateful persistence.
Stateless usage scenarios do not require persistence.  EJB3 might be a
suitable candidate for state persistence where needed.

- A data abstraction layer developed for the BPE could be useful for
isolating the BPEL engine from a specific content model.  This
probably has implications to the entry point API mentioned above.
There is an existing ODE thread of discussion on the topic.

- Two deployment models will be supported, one through pre-compilation
at design time (model currently supported by PXE), and the other
through pre-compilation at deployment time (model currently supported
by BPE).  The prior scenario is useful for tools that rely on early
error detection specific to BPEL and the latter is useful when BPEL is
not the originating language.

- Neither implementation (BPE or PXE) supports BPEL 2.0 today so this
needs to be remedied in any common Ode implementation. within the
constraints of the WS-BPEL 2.0 specification timeframe.

- We will support optimizations for stateless business processes
within the implementation

- We desire to supply run-time engine debugging support that is
capable of referring back to the originating BPEL markup for purposes
of tooling support

- The management interfaces represented in the PXE implementation are
compelling

- The Jacob engine is interesting in itself because it appears to be
analogous to the focused approach taken in BPE of walking the object
model.  We need to examine this further and consider the thread and
container isolation issues.

- Testing
        a) Unit test suites can be contributed for BPEL 1.1 and BPEL
2.0 initially based on the PXE and BPE contributions and the final set
will be derived from the intersection of the two test suite 
contributions.
        b) A benchmarking framework should be created to assess
typical messaging scenarios and stress tests

I may have missed some points but I hope this is a useful starter.

Mime
View raw message