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 ?
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 ?
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.
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).
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.).
