Re: [wsbpel] Issue 96 - How opaque correlations makes WS-Addressinguseful in BPEL

["Yaron Y. Goland" <ygoland@bea.com>]

In the WS-A case the compelling scenario is that one process makes 
several asynchronous calls to another process. The term 'conversation' 
is too heavyweight to describe what they are doing. These are simple 
asynchronous request/responses using WS-A for correlation. Using 
multiple partnerLinks for simple asynchronous request/response seems 
perverse. The whole point of a partnerLink is to track messages to a 
single partner. Perhaps there is some argument about multiple 
partnerLinks in the case of multiple long running conversations but that 
is explicitly what is not being discussed in this e-mail.

Since (A) is inappropriate for this common scenario it would seem that 
(B) (e.g. issue 96) is a good resolution.

		Yaron

Satish Thatte wrote:
> I think we all agree that using WS-Addressing or any other WS-* protocol based 
> mechanism in BPEL today is not possible.  This is a consequence of the decision 
> to keep BPEL-usage of web services at the abstract port type level, which is the 
> right decision since service orientation is a broader concept than WS-* protocols.
>  
> Regarding opaque correlation, one can look at this in one of two ways.
>  
> (A) simply acknowledge that correlation is not always explicit, and remove any 
> lingering language that implies otherwise
>  
> (B) add an explicit opaque correlation mechanism as you have proposed
>  
> With (A) we would be able to use the async r/r pattern you describe, if there is 
> a policy/contract annotation of some sort attached to the partnerLinkType 
> through appropriate extensibility, which instructs the correlation 
> infrastructure to use WS-A properties.  This could be extended to session-like 
> protocols and other kinds of conversation-protocol-based correlation where the 
> conversations are confined to the two-party relationship expressed in a 
> partnerLinkType and there is at most one ongoing conversation between the two 
> parties involved at any given time (within that process instance).
>  
> I can see a need for (B) if one wants to extend the correlation beyond a single 
> partnerLink, since the only thing bringing the multiple partLinks together is 
> the BPEL process instance.  The other possibility is multiple simultaneous 
> two-party conversations occuring through the same partnerLink.  I haven't heard 
> or thought of any other compelling scenario.  Both types of scenarios are 
> possible but we need to decide if they are common enough to support with a 
> language extension.
>  
> Note that whether you use (A) or (B), async r/r has the problem of not being 
> able to use the MEP identity concept we have since the r/r operation is not 
> reflected in the portType.  Thus multiple simultaneous r/r's would have a 
> problem.  In general multiple simultaneous conversations between the same two 
> parties are hard to keep track of.  Which is a reason to avoid encouraging them.
>  
> Satish
> 
> --------------------------------------------------------------------------------
> *From:* Yaron Y. Goland [mailto:ygoland@bea.com]
> *Sent:* Fri 4/1/2005 12:10 PM
> *To:* wsbpeltc
> *Subject:* [wsbpel] Issue 96 - How opaque correlations makes WS-Addressing 
> useful in BPEL
> 
> Summary: This e-mail explains how WS-Addressing handles asynchronous
> request/response operations in WSDL 1.1. It then shows that using
> WS-Addressing's capabilities in BPEL as it exists today would be
> somewhere between difficult to impossible. Finally, it shows that adding
> opaque correlations to BPEL makes using WS-Addressing with BPEL trivial.
> 
> ***HOW WS-ADDRESSING HANDLES ASYNCHRONOUS REQUEST/RESPONSES***
> 
> WS-Addressing's base specifically defines two related but independent
> information sources. Section 2 defines EPRs. Section 3 defines message
> properties. The combination of these two sources of information are what
> enable one to implement asynchronous request/response MEPs on top of
> WSDL 1.1 one way operations.
> 
> 
> SA ---------------MessageID(MID1) ---------------> SB
>     <---Relationship(MID1, .../addressing/reply)--
> 
> The scenario is that service SA sends a message, using a WSDL 1.1 one
> way operation, to service SB. The message SA sent contains within it the
> WS-Addressing message ID message property which provides a unique IRI
> (a.k.a. an internationalized URI) to identify that message. In this
> example the message ID value for the message SA sent is MID1.
> 
> SB then sends its response using a WSDL 1.1 one-way operation. Except
> this message contains the WS-Addressing relationship message property
> which is made up of two values, a message ID and a relationship
> description. The message ID is MID1, indicating the SB's message is
> related to SA's message. The relationship description uses the default
> IRI value defined in ws-addressing
> <http://www.w3.org/@@@@/@@/addressing/reply>. This indicates that SB's
> message is a response to SA's message.
> 
> ***USING WS-ADDRESSING IN BPEL TODAY***
> 
> Now let's look at writing SA without issue 96.
> 
> To make this work the SA BPEL process has to know the message ID sent
> out in initial request (e.g. MID1) and it has to be able to match
> properties against both the MID1 value and the relationship IRI
> <http://www.w3.org/@@@@/@@/addressing/reply> in the response.
> 
> In theory what could be done is that both the request and response WSDL
> operation definitions could be extended to include a direct reference to
> the WS-Addressing header. Then correlation sets could be used on the
> WS-Addressing header for both request and reply to correlate on the
> message ID.
> 
> But there is, of course, a major catch.
> 
> If the WS-Addressing header value is specified in the operation then
> when the SA BPEL process calls Invoke there MUST be a properly defined
> WS-Addressing header value inside of the outgoing message or a fault
> will be thrown (assuming validation is being used). So this means that
> the poor SA BPEL programmer will have to write their own code to handle
> WS-Addressing logic so they can fill in their own WS-Addressing header
> values and pass validation!
> 
> To make matters worse two properties are needed to correlate the
> response from SB. One value is the message ID value that SA can get from
> the request. But the other value is the relationship type identifier
> (e.g. http://www.w3.org/@@@@/@@/addressing/reply). How can SA correlate
> on the relationship type identifier when it was never sent out in any
> request and so couldn't use it to initiate the correlation set?
> 
> Also, how exactly did SA generate the message ID in the first place?
> That value is supposed to be unique but we closed the issue on adding a
> function to BPEL to generate unique values.
> 
> Therefore I think it's fair to conclude that dealing with WS-Addressing
> in BPEL today is somewhere between painful to impossible.
> 
> ***USING WS-ADDRESSING IN BPEL WITH OPAQUE CORRELATIONS***
> 
> Now let's look at writing SA with issue 96. In that case none of the
> operations would ever have to mention WS-Addressing much less require a
> BPEL process to create its own WS-Addressing headers. Instead the BPEL
> process just specifies "initiate=yes" on the Invoke with an opaque
> correlation set. Then on a response the BPEL process uses the same
> opaque correlation set. It then becomes the deployment admin's job to
> set up the connection to WS-Addressing, something that can be handled
> out of scope of BPEL.
> 
> I think we will do a huge favor to all WS-Addressing users if we
> introduce opaque correlations to BPEL.
> 
>                 Yaron
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>