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
|