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 Mon, 17 Apr 2006 14:30:26 GMT

Thanks for the feedback. See my comments inline.

On Sat, 2006-04-15 at 10:16 +0200, Guillaume Nodet wrote:
> Here are a few comments on the proposed API.
> Btw, i 'd like to put this api in svn (under ode/scratch/ode/iapi, with 
> a package name
> of org.apache.ode.iapi) so that it will be easier to track things, but some
> of the files have headers copyrighted to FiveSight. Is that on purpose ?
I've refactored these from an existing PXE files; i'll have to change my
eclipse settings  :)

> Event scheduler:
>   * How are scheduled events sent to the BPEL engine ?
Looks like I left this out. there should be a method
BpelEngine.onScheduledJob(Map jobDetail)

>   * In Scheduler#scheduleVolatileJob, what is the transacted parameter ?
If set, then when the scheduler will run the job in a transaction. The
bpel engine has no direct access to transaction management, so it needs
to rely on the Integration Layer to do this.

>   * Which implementation classes should be provided by the integration 
> layer ?
>      It seems that all the interfaces but BpelServer and BpelEngine have to
>      be provided.
Correct. Everything but BpelServer/BpelEngine is provided by the
Integration Layer.

> Persistence:  
>     In the case where the BPEL engine is invoked in a request / response 
> pattern,
>     but the process can not finish in the current transaction, there may 
> be a need
>     for the integration layer to persist some data, so that the response 
> can be sent
>     by the integration layer.  For example a JMS integration layer may 
> need to persist
>     the replyTo destination, or a JBI integration layer may need to 
> persist the JBI
>     exchange.  This persistent data should be made available when one of 
> the
>     MyRoleMessageExchange.reply will be invoked by the BPEL engine.   
> Such informations
>     may be stored on the MyRoleMessageExchange, or keyed by the
>     MyRoleMessageExchange#getMessageExchangeId.
Yes good point: with the API as it is, it is the responsibility of the
IL to persists this information. This imposes a bit of a hardship on
things like a JMS protocol adapter which needs to persist this
relationship (so it needs a DB). We could tweak interfaces around so it
is the responsibility of the BPEL engine to store such things.

>   1) What is the lifecycle of the MyRoleMessageExchange ?
>      If this object stored by the BPEL engine and recreated upon restart ?
The Integration Layer creates the MyRoleMessageExchange when it receives
a request for a BPEL process. The created instance is valid for the
duration of the call on the BpelEngine (BpelEngine.invokeProcess). If
the process is long-running, the BpelEngine will save the identifier for
the MyRoleMessageExchange and use it to re-create the
MyRoleMessageExchange object in subsequent transactions.

>   2) Should needed persistent informations be put on this object ?
As per my previous comment, it certainly would be handy and simplify
implementations of things like JMS integrations. It will invert the
relationship between IL and BpelEngine a bit (the BpelEngine would be
responsible for storing IL-specific data)

>   3) When will the MessageExchangeContext#resolveMessageExchange be used ?
See Q1: the MessageExchange objects live only for the duration of a
transaction; the BPEL engine stores MessageExchange identifiers in the
DB if the process is long-running. It uses this method to re-create the
objects when it is actually ready to do the <reply>.

>   4) Could the burden of creating a persistence layer could be put on 
> the BPEL engine
>      (that needs one in any case) instead of the integration api ?

It is for the most part; however the persistence layer is "tied" to the
integration layer in the choice of transaction mechanism. So currently
we have a JTA/Hibernate data layer that would work with any IL
implementation that used JTA transactions. If however, you wanted to
create an embedded integration that did not use JTA, you would need to
write your own data layer.

> Use of EnpointReference:
>     When the integration layer calls BpelEngine#invokeProcess, it gives a
>     MyRoleMessageExchange implementation that contains an EndpointReference.
>     When the MessageExchangeContext#invokePartner is called by the BPEL 
> engine,
>     the integration layer receives an EndpointReference.  As this is the 
> only
>     data given to identify the invoked BPEL process / external service, the
>     format of this endpoint has to be common to both sides.  What is 
> this common
>     format ? 
The BPEL engine is actually not aware of the format. When you deploy the
engine you specify for each "myRole" an EPR in the form of an XML blob.
The BPEL engine asks the IL to create an EndpointReference object from
this XML blob. It then relies on EndpointReference.equals to route a
message exchange to the correct "myRole". It never needs to interpret
the content of the EPR.

>  Why not just use the portType qualified name (which is the 
> only information
>     provided by the bpel process) instead of the endpoint reference ?
Port type is not enough. You need to identify the specific partnerLink instance.   

>     Also, the bpel schema allows the addition of attributes and elements 
> defined in
>     an external namespace.  Such informations can provide a simple way 
> for the
>     end-user to provide meta-informations for the integration layer, 
> instead of
>     having to rely on an external configuration file.  For example the 
> invoke
>     bpel element could contain attributes / elements that the 
> integration layer
>     would use to send the request.
It could, but this would be contrary to the spirit of the BPEL

> Transactional transports, request / response:
>     From the javadoc of the MessageExchangeContext#invokePartner:
>      "In all cases, this method MUST NOT block, and actual invocation 
> MUST be deferred"
>     This means the invokePartner method should not actually perform 
> anything, but just
>     store the fact that the request must be send at a later time within 
> the transaction ?
Yes, although this prohibition may be too strict. If the partner is
known to be idempotent this prohibition need not apply. Also, this is
assuming that you want a reliable/transactional IL implementation; if
this is not the case, then you can do whatever you want.

>     The same thing happens when invoking the BPEL engine: the response, 
> if provided synchronously,
>     will be provided by a callback.
>     Is that a side effect of pi-calculus reduction ?
Not really a consequence of pi-calculus; however if the API is to
support all the use cases then it really needs to be asynchronous in
this way. You can always build a synchronous interface from an
asynchronous one, but you can't go the other way.

>     Such a mechanism is great when the integration layer is 
> asynchronous, but if the integration
>     layer can do the needed work to defer processing of the partner 
> response and
>     take back the BPEL process response, the BPEL engine should be able 
> to do that also
>     (maybe using a thin layer on top of the engine).
I don't understand this point.   

> Message:
>     The message interface is minimalist, but may be enhanced to provide
>     at least a way to retrieve the existing part names.

> Support for document centric invocations (WSDL 2)
>     WSDL 2 and JBI mainly use document centric invocations (there is 
> only one unnamed part,
>     not several parts as in rpc mode).  Could such a thing be supported ?
Absolutely. We just need to specify how this maps into the existing BPEL


> Cheers,
> Guillaume Nodet  
> 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.). 
> >
> >  
> >

View raw message