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