ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance Waterman" <lance.water...@gmail.com>
Subject Re: Integration API (Resend)
Date Mon, 17 Apr 2006 21:40:32 GMT

Just a couple more questions inline for clarification ..



On 4/17/06, Maciej Szefler <mbs@intalio.com> wrote:
> 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.
> IL must implement EndpointReference.equals, EndpointReference.hashCode,
> EndpointReference.toXML().

I would like to run an example by you to make sure I'm on track here. Let's
say I have some WS-Addressing instance I've pulled off a transport and in
the instance are ( wsa:To, wsa:ReplyTo, wsa:FaultTo ). Is the IL pushing
both myRole and partnerRole (wsa:ReplyTo,wsa:FaultTo) data into the
EndpointReference? I can see the .equals() and .hashCode() using the myRole
data to identify a process but I don't see how a partnerRole EPR is exposed
to the engine ( i.e. <from partnerLink="partnerLinkX"
endpointReference="partnerRole" /> ).

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

Agreed, this could be IL implementation license, however the engine will
need to set the message should it decide to send a response back
synchronously. Likewise, when the engine invokes
MessageExchangeContext.invokePartner() I don't see see a way for the engine
to acquire a response message should the IL decide to return a response

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.

I would lean toward leaving it in just to have more JavaDoc around the


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message