ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maciej Szefler <...@intalio.com>
Subject Re: Integration API (Resend)
Date Fri, 14 Apr 2006 17:00:15 GMT
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.
> > >
> 


Mime
View raw message