Lance Waterman wrote:
Thanks guys, I like this API. A couple of questions:
1) Not quite sure I follow how "PartnerRoleMessageExchange.replyAsync()"
works? This seems to imply the partner is dynamically changing the
signature
of the service interface.
I guess it does not mean that the response will be provided with a
callback, but rather
that the underlying transport is asynchronous and that the response is
not available at the
moment. This may happen when using JMS for example. If using JMS,
synchronous
transactional request / response is not possible, because the request
can only be received
when the transaction is commited.
From my understanding, when the BPEL engine invokes a partner, you have
to call one
of the method defined on PartnerRoleMessageExchange. If you call
replyAsync, it
just means that you will have to call another method later when the
response is received.
2) MyRoleMessageExchange.setClientData() - is this used to set
"out-of-band"/partnerLink data (i.e. EPR,JMS properties, etc ... )? I can
get to this data from within a BPEL process using partnerLink in a <from>
clause - correct?
I think this was one of my concern. If the integration layer receives a
request from jms for example,
it may need to store the replyTo jms destination in a reliable way so
that when the process response
is available, the integration layer can retrieve it to send the response
(this would also be the case
for JBI). I thought it would be easier to put the burden of storing
this data to the bpel engine rather
than on the integration layer, because the bpel engine already needs to
store data, so it's just
another field to store.
3) I'm trying to correlate how an EPR fits into deployment. I'm assuming
that the EPR required for BpelEngine.createMessageExchange() is
produced/queried by deploying a BPEL document. The deployment API
produces
an EPR for each registered BPEL <process> definition. In your API it
looks
like you have a stub for deployment "BpelServer.deploy()" that returns a
QName. Is the assumption that the client translates the QName into an
EPR?
Maybe one thing missing / implied, is that the deployment API is
reponsible for
creating EPR for all receive operations (my role) and invoke operations.
Else I do not really see how the BPEL engine could know the EPR to use
when invoking a partner, how to process the BpelEngine.isMyRoleEndpoint
or how to route the message to the right BPEL process when using the
BpelEngine.createMessageExchange.
And I still do not understand why the operation name is the only
attribute available
on message exchange. Either put all attributes in the EPR or put all
available
attributes on the exchange (imho we should at least have the PortType
QName).
Cheers,
Guillaume Nodet
Lance
On 5/25/06, Matthieu Riou <[EMAIL PROTECTED]> wrote:
Hi all,
I've just imported the revised version of the integration API
specified by Maciej (if somebody with the necessary karma reads this,
Maciej's CLA has been received but he's the last one without an
account) for review. He also brushed up the javadoc.
Comments are welcome (even just to say "Good job Maciej!" :-) ).
Cheers,
Matthieu.
