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] Question about section 6.2


Alex, Mark,

Thanks for the quick update. I somehow missed R29 in all the noise, so it appears I've been going over old ground. This might be a good sign about the stability of the current draft!

-Ron

Alex Yiu wrote:

Hi Ron,

In the F2F of Costa Mesa, we basically removed the whole paragraph (which was added in Stuttgart F2F as an elaboration on how initializePartnerRole feature is being used). (Not just the second bullet, but the first bullet and the premable paragraph as well)

The main reason that the paragraph is removed: After reading an email digged up by Mark Ford, the intent of original issue resolution (by Yaron) seems to indicate that WS-Addressing reply-to feature (if apply) would fall into the side of initializePartnerRole = "yes", while the elaboration text, which just got deleted, classifies that scenario as initializePartnerRole = "no".

To avoid confusion, we decide remove those normative text.

At the same time, during Costa Mesa F2F, I suggested to change default of initializePartnerRole. initializePartnerRole now does not have any default value. If that attribute is missing, it truely means "silent". In that case, the WS-BPEL processor *MAY* initialize the partnerRole of the partnerLink.

My proposal was accepted as the F2F.

(My intent was: the omission of this attribute is to allow WS-Processor to do whatever static analysis needed on BPEL logic + deployment info to decide whether and how the partnerLink's partnerRole is initialized ... to achieve better usability and the "DRY" principle that you have been advocating ... )

My question to the TC is: is this view of WS-Addressing accurate?

Since the whole paragraph got removed, the WS-Addressing view issue becomes orthogonal for now. (However, I would be personally interested in discussing this topic in another email thread ...)


Thanks!


Regards,
Alex Yiu



Ron Ten-Hove wrote:
I was puzzling over the following text in section 6.2:

References to a WS-BPEL processor initializing the EPR of a partnerRole relate to the infrastructure logic specific to that processor. A typical example is process deployment logic. This is in contrast to EPR initialization mechanisms outside a WS-BPEL processor, such as:

    • Business logic expressed in the process definition

    • Auto-assignment of EPR logic in an underlying EPR scheme, such as the reply-to feature in WS-Addressing

The second bullet seems a bit odd. If a wsa:ReplyTo header contains something other than the anonymous URI, then the SOAP processor sends the response to the specified endpoint, as per the W3C recommendation "Web Services Addressing 1.0 - SOAP Binding" (9 May 2006). The second bullet says that a WS-BPEL implementation might elect to make this "sticky", by copying the EPR in the wsa:ReplyTo header to the appropriate partnerLink. I'm not sure this actually complies with the cited recommendation from the W3C, since it calls for SOAP processors to treat lack of a wsa:ReplyTo header as the same as using such a header with the anonymous URI (meaning send the response to the requestor).

It also looks strange since the wsa:ReplyTo header affects responses to received requests. It does not imply a change to the EPR of the partnerRole in the partnerLink (the EPR where request messages for <invoke>s performed by the process on that partnerLink are sent). A request received containing a wsa:RepyTo header is associated with the "myRole" endpoint of the partnerLink.

I realize this part of WS-BPEL isn't normative language, but it seems that we are encouraging implementors to contemplate being non-compliant with another specification, and perhaps promoting confusion about EPRs and partnerLinks.

My question to the TC is: is this view of WS-Addressing accurate? If so, then I suggest we simply strike all the text following the comma in the second bullet ("such as the...").

-Ron



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]