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 08:11:18 GMT
Oops, after re-reading the api (and not only the sequence diagram), the 
api should be able to handle such a case...
My mistake.  More comments will follow.

Guillaume Nodet

Guillaume Nodet wrote:

> 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.
> Cheers,
> Guillaume Nodet
> Maciej Szefler wrote:
>> The attachment mentioned can be found at
>> http://pxe.intalio.org/public/iapi-20060414.tgz
>> 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
>>> are:
>>> * abstraction of thread management -- integration layer has full
>>> responsibility for thread management, BPEL engine does not start
>>> threads.
>>> * abstraction of transaction management -- integration layer has full
>>> responsibility for transaction management, JTA can be used, but not
>>> necessary
>>> * abstraction of scheduling -- integration layer provides the
>>> transactional scheduler: permits leveraging of Quartz, J2EE scheduling
>>> mechanisms
>>> * 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
>>> partners. 
>>> 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 -- -mbs
>>> 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
>>>>> 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.

View raw message