[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Prelim minutes of Wed F2F meeting
The wed prelim minutes are attached -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133Title: Draft Agenda to WSRM TC Conference Call – May 06, 2003
|
Preliminary Minutes WSRM TC Face to Face Meeting –November 10 and 11, 2004 Face to Face meeting held at Fujitsu Software Corp Conference Room: Montego/Barbados 1
Draft
Agenda:
1 Draft Agenda to WSRM TC Meeting [Wednesday Nov 10] 9:00 AM – 2 Roll Call 3 Minutes Discussion 4 Action Item Status Review 5 Progression Vote For WS-Reliability after Member Vote 6 Discussion of Press Release, Member Quotes, and Talking points 10:30 AM Teleconference Bridge Closes – break begins 7 Discussion of ongoing Errata Process 8 General Discussion of Implementer’s Guide 9 Discussion of White Paper by Alan W 10 General Discussion of Composition with other Web Services Standards 11 Discussion of Composition with Web Services Security Standards 3:30 PM Break 12 Discussion of Future Enhancements for Version 2 [Thursday Nov 11] 13 Report of Interop SC with possible demo 14 Review of Homework Assignments 15 Continuation of Future Work Items Discussion 16 Continued Discussions of Press Release talking points 17 Future meeting planning 3:00 PM Meeting closes 2
Roll
Call
Attendance:
Meeting is quorate. 3
Minutes
Discussion
3.1 Appointment of Minute TakerTom Rutt will take minutes. Minutes will serve to record issue resolutions. 3.2 Approval of previous meeting minutesThe minutes of the October 19eleconf are posted at: http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/9847/MinutesWSRMTC101904.htm Alan moved to approve, Iwasa seconded. No opposition, minutes are approved. 4
Status of Action
Items
4.1 Action 052503-1 (Tom Rutt) closedTom took an action item to complete the status column of pre public review issues list, with correct URLs.Completed Pre CD .992 issues list with resolutions was posted at:http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/9983/PreCD992-wsrm-resolved-issues.html 4.1 Action 060104-5 (Jacques) PendingAction: Jacques, will propose further edits, on the FAQ for composability. Still open, low priority 4.2 Action 090704-1 (Tom) PendingAction: Tom will try to find, from previous minutes, a list of features we have put off for future versions and will post it to the list for discussion. 5
Progression of
WS-Reliability Spec after Member Vote
The
Ballot closed on Voting
Summary:
Text
accompanying the No Vote from SAP is at: · SAP comment with No Vote for WS-Reliability From Tom Rutt
<tom@coastin.com> on Reasoning for SAP
AG’s “No” vote on making the OASIS Web Services Reliable Messaging TC’s WS-Reliability v1.1 Committee Draft an OASIS Standard The WS-Reliability v1.1 Committee Draft contains an optional, but
normative appendix ("Appendix B. WS-Reliability Features, Properties and Compositors") that introduces a means to advertise RM
capabilities in WSDL 1.1. There are several issues that led SAP to vote “no” on making
WS-Reliability a committee draft in the first place (see http://www.oasis-open.org/apps/org/workgroup/wsrm/ballot.php?id=392&)
and that still hold true: ·
The specification appears to be back porting the features and
properties concept, which is currently part of WSDL 2.0. However, it also adds
a new “compositors” concept to WSDL 1.1, which is not part of WSDL 2.0. This
addition breaks the intended forward compatibility. ·
The mechanism is optional, which does not help to achieve
interoperability. SAP strongly believes that this is the wrong place to add such generic
functionality. As far as the compositor concept is concerned, there have been
previous attempts to gain support from the W3C Web Services Description Working
Group (WSD WG) for introducing the concept in WSDL 2.0, but the WSD WG has
denied doing so (for example, see http://lists.w3.org/Archives/Public/www-ws-desc/2004Mar/0039.html ). Besides the
minority opinion to still introduce this concept (see http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0371.html ), there is also
a minority opinion to completely remove the features and properties concept
from WSDL 2.0 (http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0375.html and http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0395.html ). After having
the W3C Workshop on Constraints and Capabilities for Web Services (see
http://w3.org/2004/06/ws-cc-cfp.html), it seems very likely that the W3C will
establish a separate working group for this very subject and that it will be
scoped to develop a technology more flexible than the features and properties
concept. Ignoring these developments and introducing a generic concept in a
domain-specific specification now will most likely lead to inconsistency with
core Web services standards in the future. A
draft response to this comment was prepared by Tom Rutt
and Jacques Durand at: · Rationale for Approval Despite SAP NO Vote From Tom Rutt
<tom@coastin.com> on The WSRM TC has considered the SAP comments accompanying their NO
vote on the OASIS WS-Reliability Specification. There is currently no standard to represent the RM capabilities
associated with a Web Service. Appendix B of the WS-Reliability specification (i.e., Features,
Properties and Compositors) provides a normative WSDL 1.1 extension mechanism
to meet this requirement. This mechanism is normative, but optional for conformance to the
WS-Reliability Specification. This
provides one mechanism which may be implemented today to realize this
requirement, but does not preclude usage of future standard mechanisms (e.g.,
for WSDL 2.0). Without specifying a representation of reliability capabilities
that a WS endpoint can advertise, web service providers and web service users
would have to define their own ad-hoc ways to represent and exchange such
capabilities. The current specification provides a WSDL extension for describing RM capabilities which, even though optional, will
facilitate interoperation for those who decide to use it. We do not think the optionality weakens interoperability in this case, as SAP claims. We believe that not specifying such a feature at all would make
it harder to agree on a representation mechanism between partners. The WSRM TC (subject to Vote on Nov 10) agreed to request the
OASIS TC Administration to approve the specification as submitted despite the
SAP negative vote. Jaques stated a better resolution would
be “we discussed this before with SAP, on the CD .992 Vote, and decided to go
forward”. Iwasa moved, Abbie seconded to approve the following resolution: “ The
WSRM TC requests the OASIS TC Administration to approve the WS-Reliablity Specification as an OASIS Standard, despite the
single no vote from SAP. The committee
discussed the concern of SAP, which also accompanied their NO vote on CD. .992,
and agreed at that time to go forward with Appendix B as a normative, but
optional, part of the specification. “ No opposition, motion passes. 6
Discussion of
WS-Reliability Press Release
Carol Geyer prepared a Draft Press Release at: · Member Quotes for Draft OASIS Press Release:
WS-Reliability dueNov 9 The meeting
produced the following edited version of the press release (minor changes): WS-Reliability
Ratified As OASIS Standard Booz Allen Hamilton,
Cyclone Commerce, Fujitsu, Hewlett-Packard, Boston, MA, USA; 15
November 2004 -- The OASIS international standards consortium today announced
that its members have approved WS-Reliability version 1.1 as an OASIS Standard,
a status that signifies the highest level of ratification. Developed through an
open process, WS-Reliability provides a method to guarantee message delivery
over the Internet, enabling companies to conduct reliable business-to-business
trading or collaboration using Web services. "Reliable
message delivery is one of the key issues to be addressed if there is to be
widespread adoption of Web services, particularly in business-to-business
scenarios," said Neil Macehiter, research
director at Ovum. "Communications using Internet-based protocols, such as
HTTP and SMTP, are inherently unreliable and do not support
the assured or ordered delivery demanded by the applications on which
businesses depend. WS-Reliability, being an approved OASIS Standard developed
in open forum that addresses these limitations, is an important step on the
path to realizing the promise of Web services." WS-Reliability
supports guaranteed delivery, which ensures the message is delivered at least
once, duplication elimination, which certifies that the message is delivered at
most once, and message delivery ordering, which guarantees messages in a
sequence are delivered in the order sent. "Financial
transactions are just one example of the kind of applications that need
WS-Reliability to meet quality-of-service standards. A message requesting a
money withdrawal, for instance, must be received by an application once and
only once," noted Tom Rutt, chair of the OASIS
Web Services Reliable Messaging (WSRM) Technical Committee. "With the
WS-Reliability OASIS Standard, information can be shared between software
programs over the Internet as reliably as within a single application on a
laptop." Patrick Gannon,
president and CEO of OASIS, applauded the efforts of the technical committee
members who produced the new standard, recalling, "The genesis for
WS-Reliability was submitted to OASIS in March 2003 by Fujitsu, Participation in
the OASIS WSRM Technical Committee remains open to all organizations and
individuals. OASIS hosts an open mail list for public comment and the ws-reliability-dev mailing list for exchanging information
on implementing the standard. WS-Reliability is provided on a royalty-free
basis. Industry Support
for WS-Reliability OASIS Standard: <INSERT
SPONSOR QUOTES> Additional
information: OASIS WSRM
Technical Committee http://www.oasis-open.org/committees/wsrm About OASIS: OASIS (Organization
for the Advancement of Structured Information Standards) is a not-for-profit,
international consortium that drives the development, convergence, and adoption
of e-business standards. Members themselves set the OASIS technical agenda,
using a lightweight, open process expressly designed to promote industry
consensus and unite disparate efforts. The consortium produces open standards
for Web services, security, e-business, and standardization efforts in the
public sector and for application-specific markets. Founded in 1993, OASIS has
more than 3,500 participants representing over 600 organizations and individual
members in 100 countries. Approved OASIS Standards include AVDL, CAP, DocBook, DSML, ebXML, SAML, SPML,
UBL, UDDI, WS-Reliability, WSRP, WSS, XACML, and XCBF. http://www.oasis-open.org Press contact: Carol Geyer OASIS Director of
Communications carol.geyer@oasis-open.org +1.978.667.5115
x290 6.1 Discussion of Draft Press ReleaseThe group made some minor edits to the draft press release. 6.2 Discussion of Talking Points for Press InterviewsThe group discussed some potential talking points, for use by members of the committee who have volunteered to be press contacts for the committee. 7
Discussion of
White Paper by Alan W
· Latest revised WS-R Whitepaper attached- to be
published in Grid Today The group provided feedback to Alan W. He will send a URL for the white paper to the list after it is published. 8
Discussion of
ongoing Errata Process
The Interop SC provided a set of feedback comments, as an input to the errata process. Some of these comments are pointing out needs for clarification, while others are requests for future enhancements to the specification. It was agreed to address these comments at the Thursday portion of the meeting. A set of errata can be published by the TC either informally or formally as a CD. Jacques: conformance to the previous spec is not affected by errata documents. Clarifications of Ambiguities, and editorial changes, which may help implementations, could be published informally. An Implementer’s guide could serve to document clarifications to aid implementers. It could be a living document, which is updated when required to add new clarifications on the WS-Reliability Specification. If we decide to progress a new version of the specification, we could include some of the responses to these items in that new version. 9
General
Discussion of Implementer’s Guide
One of the types of information this could hold is clarifications for implementer’s. Alan: WSRF has the concept of an application note, which serves the same purposed. Alan: WSN has several additional specs, like
primers. Some issues are resolved by
having best practices documented in a side spec. 10
General
Discussion of Composition with other Web Services Standards
· RE: [wsrm] Input for FAQ question Title:
RE: [wsrm] Input for FAQ question A
way to approach the composability with other WS-*
specs is that they are likely to fall under these (fuzzy) categories : (a)-
"Under WS-R": Add-ons to SOAP transport like routing, addressing, that WS-R may need to accommodate or profile. Status:
nothing in the open space yet... (b)-
"Supporting WS-R" specifications (policies, WSDL annotation), that
support some function assumed by WS-R but not central to its deployment: Status:
not finalized or not open. (c)-
"Complementary to WS-R" specifications (Security, transactions,
Context...) that support other business requirements requirements
likely to be used in conjunction with reliability, and share message footprint. Soap
headers composability and processing model make this
possible. Apparent redundancy (message ID, reply address..)
should not be an issue. Appropriate
profiling and guidelines may apply. (d)-
"Over WS-R", Higher level specifications (BPEL, Choreography, CAF,
ASAP...) would use/profile reliability, not the reverse. That
may help a bit I hope. Our focus would be on (c) this time. Jacques We should ask for input to this discussion. WS-Security has already been signaled out as an important spec to compose with. WS-Context is one candidate for composition. In the Future, WS-addressing might be a candidate for composition (e.g., specify a reference mechanism URI to use in the Reply-To element. Jacques:
One aspect of composibility is fault handling. If another WS protocol generates a soap
fault, due to a protocol error, the sender may not want to resending
in such cases. 11
Specific
Discussion of Composition with Web Services Security
Once we have this work done, we could decide to publish it as a CD, without public review. We could also have it go thru the formal standards process at OASIS. The TC could decide how to best progress such a document, after the work is almost completed. Question: which header elements from WS-Reliability are sensitive enough to warrant protection by WS-Security:
The ws-reliability headers, in some cases, need to be protected. We may need to identify and potential constraints on how to use ws security with ws-relibility (e.g., Sender needs to process security after WS- reliability, receiver needs to process security before WS-Reliability). Members
are invited to post contributions on this topic. We can decide on how to publish any outputs
after the work is underway. 12
Discussion of
Future Enhancements for Version 2
12.1Reliability for Response
message
Jacques led a discussion on the nature of the problem for providing reliability assurances for the response message of a request/response exchange. This requires a refinement of the definition of guaranteed delivery: the request must be resent if the response is not received by the sender. The receiver is not notified that the response is not delivered unless the sender does something special (i.e., no three way handshake). The sender could send a special ack to the receiver that it got the ack with the response to the original request. With synch request/response, the rm-ack is bundled with the response payload, this gives the proper behavior for guaranteed delivery. However, the response is not acked, so there is no way for the original sender to return a fault on the response. Jacques: we need to redefine the definition of reliability for the response, it cannot be defined the same way as for reliability of the request message. Question: can a receiver of a request response operation place a wsrm:request header (with a callback reply pattern) in the response to the original request? It is unclear why anyone would want to do this, since the response guarantee comes for free, given the lack of resend. Questions for duplicate elimination for the response: one way is duplicate elimination or ordered deliver of response could be tied to the same requirement level as the request. Questions for Ordered delivery for the response. For
one way, the same message must be resent, in its entirety. 12.2Wrapper Element for
WS-Reliability Soap Headers
12.3Other Capabilities Deferred
to Next Version
13
Report of Interop SC with possible demo
14
Review of
Homework Assignments
15
Continuation of
Future Work Items Discussion
16
Continued
Discussion of Press Release Talking Points
17
Future meeting
planning
In general, it was agreed to have every other week meetings in general. When there is a conflict with another F2F meeting (e.g., WS-Addressing on Dec 7) we can agree to change the specific week for our meetings. 1.5
hours per conference call, on Tuesdays, Next agreed call dates: Nov 30 and Dec 14. It
was agreed to decide on the next meeting cycles at the Dec 14 meeting. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]