Maciej,
Thanks for putting this together, I think its a very informative reference
point. I would like to touch on a couple of Guillaume's points ...
Lance
On 4/15/06, Guillaume Nodet <[EMAIL PROTECTED]> 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 ?
Agreed, a scratch area would be a nice way to collaborate on the API and
then begin to move in implementation pieces.
Event scheduler:
> * How are scheduled events sent to the BPEL engine ?
> * In Scheduler#scheduleVolatileJob, what is the transacted parameter ?
> * Which implementation classes should be provided by the integration
> layer ?
> It seems that all the interfaces but BpelServer and BpelEngine have
> to
> be provided.
>
> 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.
>
> 1) What is the lifecycle of the MyRoleMessageExchange ?
> If this object stored by the BPEL engine and recreated upon restart ?
> 2) Should needed persistent informations be put on this object ?
> 3) When will the MessageExchangeContext#resolveMessageExchange be used ?
> 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 ?
>
> 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 ? Why not just use the portType qualified name (which is the
> only information
> provided by the bpel process) instead of the endpoint reference ?
I'm a bit confused by this as well. I don't quite understand if the
EndpointReference passed into BpelEngine.invokeProcess() will be passed into
the engine as the partnerLink context or if it is to be used by the engine
to lookup the BPEL process definition. If its the latter then I agree with
Guillaume that the interface should define the specific attributes required
by the engine ( i.e. namespace, portType, operation ).
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.
Are you saying that this should be left up to the packing/integration layer
and that should a packager add these attributes into the BPEL file the
engine should not break?
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 ?
> 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 ?
> 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).
In general I think the API is a bit strong in shaping the sync/async
relationship between the integration layer and the engine. I would be nice
if both the engine and integration layer could set/identify the sync/async
nature dynamically. Perhaps InvokeResponse.CorrelationResult could support a
couple other enumerations ("SYC-RESPONSE","ASYNC-RESPONSE") and when
returned would mean MyRoleMessageExchange supports ".getReply()" or
".onReply()"? Need to think through what this would look like on
MessageExchangeContext where I think its even more important to support
this. Thoughts?
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 ?
>
> 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.).
> >
> >
> >
>
