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 <[EMAIL PROTECTED]> 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. > > > >
