Issue 96 - How opaque correlations makes WS-Addressing useful inBPEL

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

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