Lance,
See my comments inline.
> 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 ).
>
I touched on this in my response to Guillame, but perhaps I should
elaborate even more. The idea is that the BPEL engine is not aware of
the EPR scheme. Here's how it works:
Deployment:
* When you deploy a process, for each "myRole" you specify an EPR via an
XML blob (in the BPEL deployment descriptor).
* Process engine reads the XML blob EPR, asks the IL to convert it to an
EndpointReference object.
* IL does the conversion in an implementation-specific manner.
* BpelEngine takes the EPR from the IL and puts it in some internal
HashMap, associating it with the (process,partnerLink).
Invocation:
* IL receives an invocation at some location (say on some HTTP
port/path)
* IL converts the location into an EndpointReference object (again,
mechanism is up to IL)
* IL calles invokeProcess with the EndpointReference object above as
argument.
* BpelEngine finds the correct process by looking up the
EndpointReference in its HashMap.
NOTES:
IL must implement EndpointReference.equals, EndpointReference.hashCode,
EndpointReference.toXML().
Now what is in the EPR? Well that's up to the IL, in the simplest case
it could just be a URL, so long as the equals/hash methods are
implemented BpelEngine could not care less. Except....for the small fact
that BPEL allows copying the myRole EPR into a message that is sent to
a partner... For this we need the toXML() method; we still don't care
what the XML is. This means that in an ESB context, this EPR may need to
be something complicated and quite implementation-specific (like a JMS
destination).
It is important to note what the engine actually needs here: it needs to
be able to resolve any incoming message to a particular (process,
partnerLink) tuple. This opaque EPR mechanism allows it do so in a very
general manner that permits the IL to be as simple (EPR=URL) or
complicated (EPR=WS-Complexity,ESB-specific) as necessary.
> 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?
I understand your concern. However, it is the IL that implements the
MessageExchange object, so if it likes, it is free to add a
MessageExchange.getReply() method and implement the pattern exactly as
you describe. There's no reason to put this in the interface as the
BpelEngine would never call this method (and all the interfaces except
for BpelEngine, BpelServer, InvokeResponse should be viewed as provided
for the benefit of the engine only).
As for the other InvokeResonse enumerations: I had exactly what you
propose in there but then took it out (then put it back, then took it
out). On the one hand, the IL should already know what kind of operation
it is invoking and could therefore infer this information. On the other
hand, IL developers may be lazy and having the information right there
could simplify IL implementation. So, here I'm quite ambivalent.
-Maciej
