ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <guillaume.no...@worldonline.fr>
Subject Re: Integration API (Resend)
Date Sat, 15 Apr 2006 04:41:03 GMT
The BPEL engine should be able to handle transactional synchronous 
request / response invocations, both as a consumer and a provider.
For example if you invoke an EJB, the whole invocation can be 
transactional, not only the request operation.
 From the sequence diagram, it seems that such cases can not be handled.

Guillaume Nodet

Maciej Szefler wrote:

>The attachment mentioned can be found at
>Apparently, the list does not bigger attachments.
>On Fri, 2006-04-14 at 12:47 -0400, Maciej Szefler wrote:
>>As to the last points, attached is a proposed "Integration API". The
>>purpose of this API is to facilitate integration of the BPEL engine with
>>service technologies / messaging frameworks (e.g. JBI, Axis, Mule,
>>etc.). This API is consistent with the current working of the PXE BPEL
>>engine (that is to say only trivial modifications to the bpel-runtime
>>will be required). This API is also consistent with JBI. Otherwise,
>>every effort has been made to keep it as simple as possible. Features
>>* abstraction of thread management -- integration layer has full
>>responsibility for thread management, BPEL engine does not start
>>* abstraction of transaction management -- integration layer has full
>>responsibility for transaction management, JTA can be used, but not
>>* abstraction of scheduling -- integration layer provides the
>>transactional scheduler: permits leveraging of Quartz, J2EE scheduling
>>* abstraction of content -- content is opaque, content handling
>>mechanism TDB: permits specialized (non-XML) implementations
>>* abstraction of communication -- all communication with partners is
>>handled by the integration layer
>>* asynchronous communication model -- permits
>>request-only/request-response message exchange pattern with unreliable
>>(e.g. HTTP), reliable (e.g. WS-RM, JMS), and transacted (e.g. WS-TX
>>(shudder), JCA,  JDBC) partners.
>>I will send sequence diagrams showing how a correct integration
>>implementation would handle invocations of different types of
>>We have not defined the content handling mechanism except to say that
>>content is opaque to the engine for the most part. 
>>-- attachment left out -- 
>>On Fri, 2006-04-14 at 08:49 -0600, Bill Flood wrote:
>>>I missed two paragraphs on the front side of this commentrary...
>>>- We need to determine the most capable and useful entry point API for
>>>any common Ode implementation.  It's probably productive to avoid
>>>introducing any external dependencies to any bus architecture or
>>>external protocols so that the core engine can be used by as many
>>>external projects as possible while avoiding unnecessary dependencies.
>>> This implies that the proprietary JBI-like bus currently used by the
>>>PXE contribution would need to be abandoned.
>>>- The implementation should support both a transactionally contiguous
>>>invoke-to-endpoint transaction model as well as an asynchronous
>>>coupling (callback-enable implementation) to the endpoint from the
>>>engine (the latter requirement is specific to current PXE usage
>>>scenarios).  The transactional requirements imply some isolation of
>>>the thread semantics, currently present in the PXE contribution, would
>>>be necessary.
>>>On 4/14/06, Bill Flood <bill.f.flood@gmail.com> wrote:
>>>>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
>>>>-  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
>>>>- 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
>>>>        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.

View raw message