[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue 96 - How opaque correlations makes WS-Addressing useful inBPEL
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]