OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[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]