ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maciej Szefler <...@intalio.com>
Subject Re: Integration API (Resend)
Date Wed, 19 Apr 2006 15:55:15 GMT
Lance, Guillaume:

So after thinking about your comments, I've come up with a modification
to the IAPI that should address two of the  issues. The modification is
basically to make the BpelEngine responsible for implementing the
MessageExchange objects. I think this will cover the JMS use case
Guillaume pointed out (where some reply-to information needs to be saved
with the message exchange) quite nicely. Also, by inverting this
relationship and making the IL the "consumer" of these objects, it now
makes sense to add a setReply / getReply() method that Lance wanted for
the case when the response is immediately available. This should
simplify the logic for synchronous invocations by eliminating the need
to separately notify the engine about the response becoming available.
I'll upload the revised interfaces to the WIKI as soon as I clean them
up. 

-maciej




On Mon, 2006-04-17 at 11:11 -0400, Maciej Szefler 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. 
> 
> 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
> 
> 


Mime
View raw message