[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Contribution suggestions just uploaded
The contribution I just uploaded[1,2,3] represents another improvement on (but not the culmination of everything required to fix) the issues discussed in my long-ago "Summary of WS-Reliability 1.01* issues discussed over past week" email as well as the more recent "Detailed review of Section 2-2.5, 5.2 and related definitions" and "about review of Section 2-2.5, 5.2". We have made a lot of progress on improvements in this area but a bit more remains. Note that the two footnotes I inserted are not intended for the final document but simply explain a few deletions. Those deletions also make the footnotes much less sensible when not viewing the differences. Primary areas of concern addressed in this contribution include: - The BP 1.0 WSDL / SOAP / HTTP restrictions inappropriately were applied to the allowed abstract operations used at the producer / consumer level. It does not make sense to apply HTTP and SOAP restrictions to the way in which a SOAP processor (our RMP component) is invoked. That represents an unnecessary restriction reaching across 3 abstraction layers. - A few remaining clarity issues. For example, while WSDL might be written down to describe the RMP use of the underlying protocol, we have not done so. In spite of this lack, "WSDL" is occasionally used in ways that are ambiguous. - A lack of support for the BP 1.0 restrictions presented in Section 6. We need to generically describe various message exchanges as following the patterns introduced in Section 2.3 ("SOAP one-way MEP" and "SOAP request-response MEP") before the HTTP binding builds on those assumptions. A few more assumptions and implications needed to be written down. This was particularly troubling in light of the over-generality previously in 2.5.2 and 2.5.3. - Application of a SOAP One-way MEP restriction in 6.3 to the synchronous Poll RM-Reply Pattern case. Fixed by moving the appropriate restrictions into 6.3.1 and 6.3.2. The specification still does a poor job describing when the Respond operation is or is not supported. Nor does it make clear the "meaning" of a payload in a message containing only a Response header or that messages with none of the Request, Response or PollRequest headers have no significance under the WS-Reliability protocol. Both classes of change would likely be more significant than I undertook. For example, it might be reasonable to link the first Reliable Message "mentioned" in a Response element with a payload in the same message but that would extend the rules in 4.4 beyond the Response RM-Reply Pattern. This contribution attempts to illustrate the differences between the Producer / Consumer interface and the SOAP message exchanges the RMPs implement but may not be "complete" in this respect either. thanx, doug [1] http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/8586/WS-Reliability-2004-08-07-drb.sxw [2] http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/8587/WS-Reliability-2004-08-07-drb.pdf [3] http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/8588/WS-Reliability-2004-08-07-drb-diff.pdf
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]