[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Preliminary Minutes WSRX Formation F2F for review
The preliminary minutes from the wsrx formation face to face are attached. Please review these preliminary minutes and post any required corrections to the list before the end of this week. At the end of the week I will post the corrected minutes on the document server. Tom Rutt Fujitsu -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133Title: Preliminary Minutes OASIS (WS-RX) TC formation meeting
|
Preliminary Minutes OASIS (WS-RX) TC formation meeting The first F2F meeting of the OASIS Web Services Reliable Exchange (WS-RX) TC was held on Thursday, June 23 from 9:00 am to 5:30 local time and Friday June 24 from 9am to 12pm local time. This meeting was hosted by SAP and was held at the following location: 4290 El Camino Real CA 94306 1 Welcome, Convener and meeting hostPaul Cotton, opened the meeting as Convenor, by reviewing the agenda. A teleconference Bridge was set up for remote access to the meeting. Minutes Style Conventions Motion text § Motion Resolution text Ψ Action item text Ψ Potential new issue Text: 2 Introductions and roll call, Convenera) WS-RX TC roster http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/roster.php Paul stated that applicant status means that either: the OASIS primary rep has not yet approved the person, or the company has not yet assigned the new member agreement. Attendance:
The above list was extracted from the roll, which includes the assignment of voting rights, which was posted by Paul Cotton as: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200506/msg00030.html . b) OASIS Web Services Reliable Exchange (WS-RX) TC home page: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-rx 3 Appointment of Note taker(s), ConvenerTom Rutt volunteered to take minutes. 4 Selection of TC chairs, ConvenerPaul stated that the charter suggested Paul Fremantle from IBM and Sanjay Patil from SAP as co-chairs. Jeff M moved, Umit seconded the nomination of Paul and Sanjay as Co-chairs. Paul and Sanjay gave short introductions of themselves to the group. § No opposition to motion, Paul and Sanjay are co-chairs.. Jeff moved, seconded by Chris F, to thank the convenor Paul Cotton. § No opposition to motion, Paul Cotton is duly thanked by TC. 5 Approval of meeting agenda, Chairs Draft
Agenda circulated by Paul Cotton. 1. Welcome, Convener and meeting host 2. Introductions and roll call, Convener a) WS-RX TC
roster http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/roster.php
b) OASIS Web Services Reliable Exchange (WS-RX) TC
home page: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-rx 3. Appointment of Note taker(s), Convener 4. Selection of TC chairs, Convener BREAK 5. Approval of meeting agenda, Chairs 6. Introduction to OASIS process, OASIS staff LUNCH 7. Review of TC charter, Chairs a) Original Call for Participation http://lists.oasis-open.org/archives/tc-announce/200505/msg00004.html
b) WS-RX TC charter http://www.oasis-open.org/committees/ws-rx/charter.php
BREAK 8. Contributed works a) WS-ReliableMessaging and
WS-RM Policy, Chris Ferris http://schemas.xmlsoap.org/ws/2005/02/rm http://schemas.xmlsoap.org/ws/2005/02/rm/policy b) ReliableMessaging interop scenarios, Jorgen Thelin FRIDAY 9. TC administration, Chairs a) Distributed meeting schedule (day of week and time
of day) b) TC and meetings aids such as TC website, document
repository, IRC, etc. i) Email
archive: http://lists.oasis-open.org/archives/ws-rx/ ii) Document repository http://www.oasis-open.org/committees/documents.php?wg_abbrev=ws-rx
iii) Minutes http://www.oasis-open.org/committees/ws-rx/minutes.php
iv) FAQ http://www.oasis-open.org/committees/ws-rx/faq.php BREAK c) Future F2F meeting schedule http://www.oasis-open.org/committees/calendar.php?wg_abbrev=ws-rx d) TC roles (secretary, issues list editor,
specification authors, etc.) 10. Any other business 11. Adjournment No opposition to approval of agenda. 6 Introduction to OASIS process, OASIS staffJamie Clark Described the OASIS Process, which is defined in the policy and procedures page: http://www.oasis-open.org/who/policies_procedures.php Under TC process, voting rights are toggled based on attendance. OASIS TCs can set their own policy on frequency of Teleconferences, Face To Face, and criteria fo Web ballots. The TC Charter is a crucial component of the OASIS process for a TC. The charter is a basis for the activities of the TC. Any changes to the scope of work should be reflected in updates to the Charter. Jamie switched to explaining the Intellectual Properties Rights. The licensing class for this TC is Royalty Free on Royalty free is a separate concept from licensing. Royalty Free on Committee Drafts, which are voted, place obligations upon members of the TC. At any time a member can give a notification to the chair to withdraw from the committee. This truncates that persons future obligations. OASIS has a special majority criteria of 2/3 + 1 for some specific milestone actions. There is a public TC web page, which allows access to the email list and public documents. There is a private TC web page, for all members, which has access to all documents in a more organized form, and meeting announcements. 7 Review of TC charter, Chairsa) Original Call for Participation http://lists.oasis-open.org/archives/tc-announce/200505/msg00004.html b) WS-RX TC charter http://www.oasis-open.org/committees/ws-rx/charter.php Co-chair Paul F reviewed the charter posted as: http://www.oasis-open.org/committees/ws-rx/charter.php. Comments from TC meeting discussion are inserted inline. The
charter for this TC is as follows. Name
and abbreviation OASIS
Web Services Reliable Exchange Technical Committee (WS-RX) Purpose The
purpose of the OASIS Web Services Reliable Exchange (WS-RX) Technical Committee
(TC) is to define a protocol for reliable message exchanges between two Web
services, through continued development of the Web Services Reliable Messaging
specification [1] submitted to the TC as referenced in this charter and to
define a mechanism by which Web services express support for reliable messaging
as well as other related useful parameters. This mechanism will be based upon
the Web Services Reliable Messaging Policy Assertion ("WS-RM Policy")
specification [2] submitted to the TC. Scope The
TC will accept as input the February 2005 Version 1.0 of the WS-ReliableMessaging [1] and WS-RM Policy [2] specifications
(the Input Documents) from BEA Systems, IBM, Microsoft, and TIBCO Software.
Other contributions and changes to the input documents will be accepted for
consideration without any prejudice or restrictions and evaluated based on
technical merit in so far as they conform to this charter. OASIS members with
extensive experience and knowledge in these areas are particularly invited to
participate. The
scope of the TC's work is to continue development and
refinement of the input documents to produce as output modular specifications
that standardize the concepts, WSDL documents and XML schema renderings
required to provide reliability assurances to message exchanges between two
parties that conform to the specifications. Reliable
messaging systems can generally be described using a four agent model. In this
model there is an Application Source, a Reliable Messaging Source that acts on
behalf of the Application Source, an Application Destination and a Reliable
Messaging Destination that acts on behalf of the Application Destination.
Message Transfer is the function of moving messages from a Reliable Message
Source to a Reliable Messaging Destination. This TC will provide protocols for
the reliable message transfers that occur between Reliable Messaging Sources
and Reliable Messaging Destinations. The TC will not develop additional
mechanisms by which a Reliable Messaging Source captures messages from an
Application Source or mechanisms by which a Reliable Messaging Destination
delivers messages to an Application Destination. A
reliable message transfer is one in which certain reliability assurances exist
between two parties even in the presence of a variety of failures. There can be
multiple, concurrent and independent reliable exchanges between two parties.
Reliability assurances make statements about the type of reliability provided
to a message exchange. The
specifications will define a set of basic concepts required for the correct
functioning of message exchanges with reliability assurances. The
specifications will render these concepts as a specific set of restrictions
over SOAP messages including XML schemas and WSDL documents. The
specific reliability assurances in the scope of the TC are: * At Least Once: Messages are transferred
at least one time or an error is raised on at least one of the endpoints. It is
possible that some messages are transferred more than once. * At Most Once: Messages are transferred at
most one time or an error is raised on at least one of the endpoints. It is
possible that some messages are not transferred. * Exactly Once: Messages are transferred at
least one time and at most one time or an error is raised on at least one of
the endpoints. * Ordered: Messages are transferred in the
order in which they are sent. These
reliability assurances can be combined and certain combinations are of
particular interest due to their widespread application: Exactly Once and
Ordered (also referred to as Exactly Once Ordered). The
specifications developed by the WS-RX TC will define mechanisms that support
and allow the implementation and expression of reliability assurances, at most
once, at least once, exactly once, ordered, and will not define mechanisms for
applications to manifest reliability assurances. The
specifications developed by the WS-RX TC will define elements and relationships
among elements that enable the implementation of the following functions which
support the reliability assurances in the scope of the TC: * Reliable establishment and teardown of
one or more independent shared contexts between two parties within which
reliability assurances apply to one-way or two-way messaging. * A mechanism which two parties can use to
perform one-way or two-way reliable messaging within a reliable context. * Ensures timely destination amnesia
detection. Destination amnesia is the condition resulting from catastrophic
failure in which a Destination loses the shared context required by reliability
assurances. * At Most Once reliability assurances even
in the case of Destination amnesia. * Efficient message retransmission and
acknowledgment. * Duplicate message detection. * Detection of out-of-order messages and discovery
of the correct order of messages. * Unique identification of messages within
a reliable context * Acknowledgement of all messages within a
reliable context * RM protocol violation detection and the
raising and transmission of related fault information. * Efficient preservation of the integrity
of reliable contexts by composition with WS-Security or other SOAP security
mechanisms. * Expression of support for the
specifications using the WS-Policy Framework [9] and binding of that policy to
a WSDL port. * A binding of the reliable messaging
protocol elements to SOAP 1.1 and SOAP 1.2. The
specifications will uphold the basic principles of other Web services
specifications of independence and composition and must be composable
with the other specifications in the Web services architecture, such as
WS-Security [3], WS-Trust [4], WS-SecureConversation
[5], WS-Addressing [6], SOAP 1.1 [7], SOAP 1.2 [8], bindings of SOAP 1.1/1.2 to
HTTP, WS-Policy [9], WSDL 1.1 [10] and WSDL 2.0 [11]. The TC will also take into consideration
applicable work, such as the WS-I Basic Profile [12]. The "Secure, Reliable, Transacted Web
Services: Architecture & Composition" white paper [13] published in
2003 provides information on the Web services architecture. Jeff M stated he wanted to propose some clarifications to the above paragraph. Paul H stated that any charter clarifications must be voted with special majority. Jamie stated that charter clarification changes must be a special majority vote, taken place through a remote ballot.. Any proposed changes agreed by the TC at a F2F must be subjected to a special majority vote. Martin C stated that the TC administrator can set up a TC ballot. Jamie stated that it is better to have such a vote in a remote ballot, since the voting list will be formalized only at the end of the meeting. Jeff M: moved (Martin C seconded) to add the IBM Basic B2B Profile [16] published in April 2005, WS-Context [17], and WS-Reliabilty 1.1, an OASIS International Standard, published in November, 200 [18]. to the take into consideration sentence, and to add and the Web Services Architecture published by the W3C as a Working Group Note [15] to the provides information sentence. The new references are to be inserted as: [15] Web Services
Architecture [16] IBM Basic B2B
Profile [17] WS-Context [18]
WS-Reliability 1.1 Chris Kurt stated that this motion is out of order, since is not a charter clarification (remove ambiguity or clarify scope), because it broadens the scope of the charter. Jeff M responded that this does not expand the scope of the charter, since these are merely documents cited as being taken into consideration by the work of the TC. Chris K stated that expanding this list of documents does not help the TC. This could lead to a much larger set of documents. Martin C stated these document may restrict the scope of the TC. Umit: it is not clear what take into consideration means in the charter statement. Jacques D: the term of scope applies to nature of work, not the quantity of what must be done to get there. Chris F: I do not see this as expanding the scope. The term such as in the charter already implies that this is not a closed list. Colleen: I think this proposed change does increase what must be done by the TC. Martin C: I suggest that Jamie put the clarification resulting from this motion out for formal ballot. Chris K retracted his point of order, to allow continuation of discussion of the motion. Jonathan asked what purpose this clarification of the charter serves. These documents are already available for members of the TC to read while doing their work. Lloyd B: adding these documents will increase the work of the group. Paul H: while this may not increase the actual work of the group, it will change the public perception of this group. There were several questions on how this motion can be resolved. It was clarified that we operate under the existing charter until the vote is completed and the motion is accepted. Paul C suggested that the correction of references is an editorial matter to be put in the ballot. § The TC agreed that this motion to clarify the charter should be put out for a formal ballot, in accordance with the OASIS Procedures. Ψ Action: Jamie Clark will put the proposed charter clarification from the Jeff M motion out for formal Ballot, in accordance with OASIS Procedures. If
an above specification is outside of a standardization process at the time this
TC moves to ratify its deliverables, or is not far enough along in the
standardization process, any normative references to it in the TC output will
be expressed in an abstract manner, and the incarnation will be left at that
time as an exercise in interoperability. There was discussion on the meaning of Far enough along. Tom Rutt stated that the current wording allows any member to propose that a spec is not far enough along to include as normative reference, and then TC can decide by vote. Paul C: I think the current text is fine. Some groups (e.g. ISO) have rules that only things which are 1 step behind formal ratification can be cited in a normative reference. However, OASIS has no such formal rules. Doug B: I agree with Paul C on this one. I prefer we leave it flexible in the charter. When we have to discuss specific cases we should argue them each on their own. Jeff: for example Soap 1.1 and WSDL 1.1 have no official standard status, but have been granted special consideration by several groups due to their wide implementation. Paul C: the WS-I profiles gave interoperability over important use cases for Soap 1.1 and WSDL 1.1. However, I see OASIS standards as being broader in their specification. No changes required for the above paragraph. -------------- Break for Lunch While
composition with other specifications is a goal of the TC, it is also a goal to
leave the specifics of how that composition is achieved outside the scope of
the RM specifications. Martin suggested that we
change RM to WS-RX Specifications Doug B suggested outside the
scope of the WS-RX TC. Doug B moved, Anish Seconded to change outside scope of the RM Specifications to outside the scope of this TC. § This proposed clarification will be put out for formal Ballot. Ψ
Jamie
Clark will put out a web ballot on the Doug B motion. Each
of the protocol elements will use implementation and language neutral XML
formats defined in XML Schema [14]. Out
of Scope: The following is a non-exhaustive list. It is provided only for the
sake of clarity. If some function, mechanism or feature is not mentioned here,
and it is not mentioned in the Scope of Work section either, then it will be
deemed to be out of scope. The
TC will not define a mapping of the functions and elements described in the
specifications to any programming language, to any particular messaging
middleware, nor to specific network transports. The
elements and/or mechanisms the TC defines must be independent of issues and
considerations that do not affect an interoperable reliable messaging protocol. There was some discussion of the wording and/or mechanisms the TC defines. It was clarified that usage of elements defined in another spec is different than defining a new mechanism. No change was suggested. Specifically:
the TC is not concerned with binding the specifications to specific underlying
transports. The
TC and the specifications that it producesdo not
address considerations, such as durability related to Sources' and/or
Destinations' ability to satisfy reliability assurances. Typographical error noted in above paragraph. Ψ Action OASIS Staff should fix typographical error in charter of missing space between produces and to the next time the charter is updated. Except
for the elements directly related to the functions in the scope of the
specifications, the TC will not prescribe the format of messages that are
transferred reliably according to the specifications. The
TC will make no assumptions about the location of Application Sources relative
to RM Sources and Application Destinations relative to RM Destinations. The
TC will not attempt to define concepts or renderings for functions that are of
wider applicability including but not limited to: * Security (Encryption, Integrity and
Authentication) * Addressing * Policy languages and frameworks * Routing * Transactions and Compensation Anish asked if an authenticated session setup for ws-reliable messaging would be out of scope. He can envision an authenticated session in the RM headers themselves, and wants to know if this is out of scope. The current input spec has a security token in the create sequence response body. Anish: I do not agree that Security is part of Reliability. Chris F: If I can ack messages from someone else, that is not reliable. Colleen: this spec must compose with ws-security. Thus we cannot define things that are already in WS-Security. Gilbert: we might consider adding statements that this spec does not depend on other specs. Tom R: the input spec uses EPR for Ack To. However there is no requirement for ws-addressing run time. We should not use wsa:messageId however, since this is part of the WS-addressing run time headers. Chris F: the security context is optional in the Create Sequence response, thus we do not depend on ws-security. Paul C: making the security context optional, allows another group to profile it to change this to not used, or as required. Doug D : We need revised text to get to conclusion on this discussion Chris F: we could tweek this to make clear that re-use of an EPR is not out of scope. Martin C: we are going to have to make some of these decisions on re-use in a case by case basis. Gilbert: I do not see good definitions of Composability. Paul F- are there any proposed changes to the charter in this area. No changes were proposed. Where
required these functions are achieved by composition with other Web services
specifications. The
TC will not attempt to define functionality duplicating that of any normatively
referenced specification in the input WS-ReliableMessaging
or WS-RM Policy specifications. If the referenced specification is outside of a
standardization process at the time this TC moves to ratify its deliverables,
or is not far along enough in the standardization process, any normative
references to it in the TC output will be expressed in an abstract manner, and
the incarnation will be left at that time as an exercise in interoperability. Deliverables The
TC has the following set of deliverables. * A revised Web Services Reliable Messaging
Protocol specification. Committee
Specifications are scheduled for completion within one year of the first TC
meeting. * A revised Web Services Reliable Messaging
Policy Assertion specification.
Committee Specifications are scheduled for completion within one year of
the first TC meeting. Anish: I assume the first bullet would include Schemas. However could the TC also have output white papers on subjects, such as composability with WS-Security. Paul F: there is no wording in the charter precluding additional
documents to be published. These
specifications will reflect refinements, corrections or material technological
improvements with respect to the input documents and in accordance with this
charter. Ratification
of the above specifications as OASIS Standards, including a brief period to
address any errata, will mark the end of the TC's
lifecycle. The
TC may choose to vary the number of the specification documents and their
titles. IPR
Mode This
TC will operate under the "RF (Royalty Free) on RAND Terms" IPR mode
as defined in the OASIS Intellectual Property Rights (IPR) Policy, effective 15
April 2005. Audience The
anticipated audience for this work includes: * Vendors offering Web services products; * Other specification authors that need
reliable message delivery for Web services * Software architects and programmers, who
design, write or integrate applications for Web services * End users implementing Web services-based
solutions that require an interoperable, composable
reliable messaging solution. Language TC
business will be conducted in English. References [1]
WS-ReliableMessaging http://schemas.xmlsoap.org/ws/2005/02/rm [2]
WS-RM Policy http://schemas.xmlsoap.org/ws/2005/02/rm/policy [3]
WS-Security http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf [4]
WS-Trust http://schemas.xmlsoap.org/ws/2005/02/trust [5]
WS-SecureConversation http://schemas.xmlsoap.org.ws/2005/02/sc [6]
WS-Addressing http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/ [7]
SOAP 1.1 http://www.w3.org/TR/2000/NOTE-SOAP-20000508/ [8]
SOAP 1.2 http://www.w3.org/TR/soap12-part1/ http://www.w3.org/TR/soap12-part2/ [9]
WS-Policy http://schemas.xmlsoap.org/ws/2004/09/policy [10]
WSDL 1.1 http://www.w3.org/TR/2001/NOTE-wsdl-20010315 [11]
WSDL 2.0 http://www.w3.org/TR/wsdl20-extensions http://www.w3.org/TR/2004/WD-wsdl20-bindings-20040803 [12]
WS-I Basic Profile http://www.ws-i.org/deliverables/workinggroup.aspx?wg=basicprofile [13]
Secure, Reliable, Transacted Web Services: Architecture & Composition http://msdn.microsoft.com/webservices/understanding/advancedwebservices/default.aspx?pull=/library/en-us/dnwebsrv/html/wsoverview.asp http://www-128.ibm.com/developerworks/webservices/library/ws-securtrans/index.html [14]
XML Schema http://www.w3.org/TR/xmlschema-1/ http://www.w3.org/TR/xmlschema-2/ Bob F: I have a question about the intent of the Chairs and the group in pursuing the work to arrive at the output specifications. How do we deal with things such as requirement definition document, or issues lists, which are not official deliverables, Paul C: I have a concern that we would not be finished within a year if we take on too many new output documents. Of course an Issues list would be useful. Steve C: I would think that such documents as a use case document would be helpful. Tom R: another example might be some state chart diagrams or sequence charts to aid in the validation of the specification. However these might not be appropriate to include as formal output specifications. Paul F: I would think that non-output documents which help the work of the group are a useful thing. However we should avoid formal outputs which will prolong the work of the TC. Bob F: A running working document on requirements, for the internal use of the TC, could help record fundamental reasons some decisions are made. I have seen some other groups spend more time because they are missing such a standing requirements document. Bob: I move that the TC operations include the existence of a working document on requirements to aid its work. Seconded by Jacques. Paul C: I believe that there is already a formal set of requirements in the charter. We have an input spec that members have already implemented Trying to write a requirements document or a used case will slow the TC work down. Jorgen: I would like to clarify whether this motion is to have the charter change. Bob F: my intent was to have the motion pertain to the workings of the TC, rather than an explicit charter change. Anish: I believe taking the charter and the input spec and writing a requirements document will aid the TC Gilbert: It would help to know which use cases or requirements are in or out of scope of the TC. Paul F: Are requirements and use cases meant to be separted. Bob F: I move to amend my motion for TC operation to change requirements to requirements and/or use cases. Steve C seconded. Colleen: I feel that adding another deliverable adds to the scope of the TC. Paul C: Adding another deliverable will increase the time for the TC to finish. Gilbert: Deriving requirements from existing charter and specs is much simpler than starting from a blank slate to arrive at requirements. Anish: I do not see how the charter as it stands disallows a working internal requirements/use Case document. Paul F: I feel that changing the charter to add a Requrements/UseCase document is increasing the scope of the TC. I would like to close off the charter discussion. Jeff: if there is a general agreement that we could have such a working document for requirements/useCases then we would not need to change the charter. As long as people cannot say such a document is out of scope of the Charter. Chris F: if the charter does not preclude such a document, someone could produce such a document as a contribution for use in the TC work. Gilbert § No objection to Amendment, resulting motion Text The TC operations include the existence of a working document on requirements and/or Uses cases to aid the operations of the group. Doug D: I would prefer that the word include be changed to allow. Jeff: since this is a sense of the meeting motion, it does not matter whether the word include or allow is used. Chris K: This discussion is a discussion about creating a new deliverable, and is adding new work to the TC. This I believe we should not talk about this outside the charter. If this was included in the charter it would be an increase in the scope of the TC. Paul F: The motion positions this as a working document, not a deliverable. Chris K: I believe that such a new document will add to the work to be done by the TC. Chris F: I feel that anyone could produce such a document to help the TC do its work, and the TC could decide to use that document to aid its work. Paul F: I would like to propose that we amend to motion to determine if TC members feel that such a document would be useful and feasible within the time frame.. Seconded by Bob F. § No opposition to amendment. Amended sense of committee motion: This TC believes that a working document on requirements and/or use cases will be valuable to the operations of the TC and feasible within the time frame of the TC. Vote 25 yes in room , 16 against. § Amended Motion on Sense of committee for Requirments/UseCase document Passed. Steve C:: I would like to amend the motion from Jeff: Paul F: this is out
of order, the motion from Jeff has been queued for
formal ballot. 8 Contributed worksThe following contributions were posted to the email exploder: BEA Systems WS-RM and WS-RMPolicy contribution to WS-RX TC Dave Orchard 23 Jun 2005 18:09:05 TIBCO WS-RM and WS-RMPolicy contribution to WS-RX TC@tibco.com Shivajee Samdarshi 23 Jun 2005 17:57:45 IBM WS-RM and WS-RMPolicy contribution to WS-RX TC Christopher Ferris 23 Jun 2005 17:56:13 Microsoft WS-RM and WS-RMPolicy contribution to WS-RX TC Paul Cotton 23 Jun 2005 17:47:20
a) WS-ReliableMessaging and WS-RM Policy, Chris Ferris http://schemas.xmlsoap.org/ws/2005/02/rm http://schemas.xmlsoap.org/ws/2005/02/rm/policy Chris Ferris presented an overview of the input document to the TC posted as: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200506/msg00014.html There was a question on why a message with sequence number 1 cannot serve as the start of sequence indication. Chris F stated that the first message could be lost or received twice. Tom Rutt stated that the explicit sequence creation exchange establishes the AckTo epr. Anish asked why the last message indication in a sequence cannot automatically terminate the sequence. Chris F stated that the explicit sequence destroy is a signal that the sender has received acks for every message it cares about in that sequence. Question: Is bilateral sequence merely an optimization or is it a mandatory feature. Chris F: Different people think differently. I believe this is an optimization Ψ Potential New ISSUE: Is Bilateral Sequence Negotiation an optimization or a mandatory feature? RM policy assertion seems to force it to occur, in the case of a wsdl request response reliable in both directions. Hamid asked if the purpose of this presentation is to just give an overview, or is it to allow TC members to raise potential Issues. Chris F: If people want to raise potential issues now, they can do it as I speak. Anish asked if the ackTo can change during the lifetime of a sequence. Chris F: the input spec does not allow the ackTo to change during a sequence. Ψ Potential New ISSUE: Should the AckTo EPR be allowed to change during the lifetime of a sequence. Chris F stated that the WS-RM protocol is only concerned with where the ack goes to. It does not deal with application responses to that message. WS-addressing ReplyTo deals with a possible application response to the message. Anish: WS-RM is a protocol which can guarantee the delivery of a single message. Request response semantics at the application level is not part of RM. Chris F: there is a way to use WS-RM for assuring both a request message and the later response message. But the wsrm:acks pertain only to a single direction of message. Chris F: What is identifier of endpoint which establishes the binary relationship between two endpoints which are engaged in a sequence. Anish: it is possible that the wsa:reply to for the request message may have the same address as the wsrm:ackTo for the sequence the message is sent on. In such a case both the application reply and the wsrm:ack could be piggybacked. Doug D: The wsa:replyTo for a create sequence message does not have any specified relationship specified in the input RM spec to wsa:ReplyTo values for individual messages sent using the resulting sequenceId. Ψ Potential New ISSUE: Which pair of EPRs define the scope of a sequence. Tom R: can the sequenceAck to an AckRequested be carried on the http response to that ack requested request. Chris F: if both wsa:replyTo and the wsrm:AckTo eprs both use the anonymous address this could occur. Steve W: WS addressing is discussion the a uniqueness requirements for messages using the same wsa:messageID. In the case of retransmission for reliability reasons, is there a relationship between the uniqueness of the wsa MessageID for a retransmitted message, and the wsrm:SequenceID,sequenceNo used for that message. Ψ Potential New ISSUE: What are the uniqueness requirements for the wsa:messageID values used for messages retransmitted with the same wsrm:{sequenceID, MessageNumber} pair as a prior transmission of the same reliable message. Martin: The last message indication is not that it is the last message, since it may be retransmitted. Tom: The answer to this question depends on whether a retransmitted message at the soap layer is considered to be the same message as the prior transmission with that same sequenceID and messageNumber. This is closely related to the potential new issue above from Steve W. Chris F clarified that the wsrm:nack , when sent from receiver to sender, only states that the sender needs to retransmit a particular message number in a sequence. Lloyd: is id valid to send a nack for the same message number for a message that has been successfully acked already. Chris F: the order that the ack or nack messages are received by the original message source is not necessarily the same as the order they were send by the original message receiver. Steve W: is the sender required to resend a message if it has already received an ack for that messageNumber. Chris F: while the sender is allowed to resend in such a case, it is not required to resend if it has received an ack. However, the spec does not say this now. Paul C: we could add a clarification such as sender MAY resend the message in such a case. Chris F: there might be some cases where the receiver really does require a resend. Ψ Potential New ISSUE: Is the sender required to resend a message identified in a Nack, if it has already received an ack for that same messageNumber. The following slide triggered a discussion: Effecting Reliability assurance § WS-RM protocol is an AtLeastOnce protocol as manifested on the wire § Responsibility of the RM Source to ensure successful transmission of each message AtLeastOnce or else fail the Sequence § Responsibility of the RM Destination to effect the appropriate reliability assurance as a contract with the Application Destination § Enables asymmetric implementation capabilities without changing the protocol 4 Provides for broader reach (e.g. pervasive device -> high-end server) 4 Simplifies the protocol Martin C: reliability assurance, in some cases, may need to be asserted separately by the sender for each sequence. Paul C: this additional functionality could be is built on the protocol that exists. Tom R: I have an example case where there is a wsdl port type with two operation types, one which the sender requires duplicate elimination, while the other the sender does not require duplicate elimination. This could be handled by having two different sequences established between the same two sender and receiver endpoints, one for each required assurance level. Chris F: The current spec puts the determination of reliability assurance beyond at least once as an aspect of the receiving implementation. The protocol assures at least once. Any additional assurance negotiation between sender and receiver is outside the scope of the RM spec. Ψ Potential new ISSUE: Is there a requirement that the sender can assert that the receiver must deliver a particular reliability assurance on a given sequence. Chris presented the following slide,: Efficient preservation of the integrity of reliable contexts by composition with WS-Security or other SOAP security mechanisms. 4
CreateSequence
can carry SecurityTokenReference to secure the
Sequence 4
When used, messages belonging to a Sequence
MUST provide proof of possession of the Security Token referenced in the CreateSequence Chris stated that several people have asked him why this security token is in the WSRM create sequence message of the current spec. He presented a rationale stating that it is to disallow hijacking a sequence number. Claus: how do you indicate that a particular security context is supported. Chris F: that is out of scope of this spec. Paul C: we need to add an issue that the spec needs to Support tokens by both ws security 1.0 and ws security 1.1. Ψ Potential new ISSUE: Must the ws-reliable messaging spec support tokens produced for both ws-security 1.0 and ws-security 1.1. Meeting recessed at 5:40 PM. Chris continued on Friday morning with the review of the WS-RM Policy Assertion Spec. Chris stated that this is not necessary (E.g, such negotiation could be done out of band via configuration etc), but its intent is to provide a standard mechanism for policy assertions. There are four child elements of RMAssertion
In the current spec policy Assertions apply to endpoints Ψ Potential New ISSUE: Is there a need to attach policy assertion to something other than an endpoint. In WSDL binding, policy can be associated with binding, service, or portType. In wsdl an endpoint is associated with a Port. Hamid: Not all services have wsdl, is attaching policy to wsdl the only way to negotiated agreements. Chris F: This spec is optional, so other ways to negotiate such policies are allowed. Martin C: what assurance to we have that WS-Policy will be far enough along on the standards track to have our TC spec completed within the one year timeline. Paul F: If policy is not ready, we need to define an abstract model for these policy assertions for WS-Reliable messaging. Martin C: why not do the abstract model first. Paul F: I do not see it as a big problem to do the abstraction later. Jorgen: there is a good chance that policy will be far enough along. Doug B: a lot of these parameters only matter on one side of the exchange. Chris F: if we made some for the client, others for the server, there is no way to guarantee consistency. b) ReliableMessaging interop scenarios,, Jorgen Thelin Jorgen gave a presentation on the interop experience the submitters of WS-Reliable Messaging have experienced: posted as: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200506/ppt00000.ppt He stressed that this is a historical presentation, based on earlier versions of Reliable Messaging Spec from that submitted to the TC. He stated 7 companies are shipping product based on earlier versions of the Spec. He described scenarios used in three interop workshops involving 7 implementations. WS-RM Spec refinements suggested from Interop workshops NACK Resource reclamation points Extensibility points Absolute URI (vs. relative) Sequence expiration Last Message and ACK usage Clarified SOAP mustUnderstand usage Clarified FAULT handling RM Policy assertions The last slide presented the following links to workshop summaries
WS-RM Interop
Workshop #1 Meeting Summary http://msdn.microsoft.com/webservices/community/workshops/rminteropwsOct2003.aspx http://www-106.ibm.com/developerworks/offers/WS-Specworkshops/ws-pwrmfest1.html Interop Scenarios: http://groups.yahoo.com/group/WS-RM-Workshops/files/Scenarios.doc
WS-RM Interop
Workshop #2
WS-RM Feedback Workshop Meeting summary: http://msdn.microsoft.com/webservices/community/workshops/rmspecwsjul2003.aspx http://www-106.ibm.com/developerworks/offers/WS-Specworkshops/ws-rm1.html Presentation Decks http://download.microsoft.com/download/6/d/4/6d48120a-878e-4f0d-af20-3e900b004c3d/presentations-july2003-ws-wkshp.zip ftp://www6.software.ibm.com/software/developer/library/WS-specworkshopspwrm1.zip Meeting Summary: http://msdn.microsoft.com/webservices/community/workshops/rminterop052004.aspx http://www-106.ibm.com/developerworks/offers/WS-Specworkshops/ws-rm200405post.html Interop Scenarios: http://groups.yahoo.com/group/WS-RM-Workshops/files/Interop2-Scenarios.doc
WS-RM Interop
Workshop #3 Meeting Summary http://msdn.microsoft.com/webservices/community/workshops/composability042005.aspx http://www-106.ibm.com/developerworks/offers/WS-Specworkshops/ws-rmsecon200504post.html Interop Scenarios: http://groups.yahoo.com/group/WS-RM-Workshops/files/RM%2BSC%26T%20Composition%20Scenario-2005-02-25.doc Doug B suggested they post these documents on the TC document server. Jorgen stated that there are no further plans for RM workshops. However they do have public interop endpoints available for on-going testing. Vadim expressed a concern expressed that the scenarios did not cover failure of the source or destination. He stated that such scenarios should be included in interops for the OASIS spec. Jorgen stated that the interops were intended just to test the protocol. Paul C: He stated he could help anyone who wants to interact with the Microsoft endpoints. Doug D: He stated he could help with the IBM endpoints. 9 TC administration, Chairs
9.1 Distributed meeting schedule (day of week and time of day)The chairs are proposing a bi-weekly 90minute set of Teleconferences. Paul C: I recall that the call for participation calls for weekly meetings. Jeff M: We should let the TC decide. Chris F: I think we should, at least initially, meet weekly to progress the work along. Bi-weekly will tend to lead to much less happening in the in-between weeks. We can always scale back. Paul C: 90 minutes every two weeks is not enough. I think we should meet for 90 minutes every week. The meeting can always adjourn early. Martin moved to have weekly 90 minute meetings, seconded by Toufic. § No opposition, motion for weekly 90 minute meetings passed. Time 1) Pacific 8:30 AM: 11:30 Eastern, 5:30 PM CET, Japen 12:30 AM Time 1a) Pac 8 am, Eastern 11 AM , CET 5 PM, Japan 12 AM Time 2) 1 PM Pacific, 4:PM Eastern, 10 PM CET, 7:AM Japan Time zone poll Pacific -27 Eastern - 12 CET - 4 Pacific - 3 Cant live with poll of face to face attendees
First choice is 1 PM Pacific on Thursday (overlap with ws-I BSP group)
One of the chairs cannot make the wed slot every week. Martin moved that weekly 90 min calls at 1 PM Pacific time Thursdays, Gilbert seconded. In favor 33 Opposed 2 Abstain - 2 . § Motion Passes, meetings will be 90 minutes at 1 PM every Thursday. Martin moved to start 7 July, Paul C seconded. § No objections, Motion passed. Microsoft will supply the bridge for the first group of calls. 9.2 TC and meetings aids such as TC website, document repository, IRC, etc.i) Email archive: http://lists.oasis-open.org/archives/ws-rx/ ii) Document repository http://www.oasis-open.org/committees/documents.php?wg_abbrev=ws-rx iii) Minutes http://www.oasis-open.org/committees/ws-rx/minutes.php iv) FAQ http://www.oasis-open.org/committees/ws-rx/faq.php Sanjip stated that a TC process is a subject which will be formalized in the early calls. Sanjip put up a set of slides for a formal discussion.: TC process · Log and track progress of issues · Structure TC discussions and record TC decisions o Minutes o AI list o Issues List · Spec Naming and Versioning Schemes Issue status · Open o Anyone can raise issue o TC discusses issue to understand and insure in scope and not duplicate o Issues editor clarifies wording and logs it · Open approach agreed o May involve changes in spec o Agreed approach documented and provides guidelines to editors · Resolved o Editors incorporated changes that are reviewed by one or more TC members · Closed o TC Votes on a committee draft that includes the changes Paul C: I think we need a status between pending (approach agreed), and Resolved. The move to resolved should be driven by a vote on the proposed issue resolution. General agreement that each issue resolution should be voted.
9.3 Future F2F meeting schedulehttp://www.oasis-open.org/committees/calendar.php?wg_abbrev=ws-rx Microsoft volunteers F2F in Date Choices:
Preference Counts: a) 11 b) 19
Cannot do: a) 3 b) 2 Wed-Thu Sept 21-22 was chosen for second face to face. 9.4 TC roles (secretary, issues list editor, specification authors, etc.)Position nominations: TC Secretary (minute taker, and document page organizer) Volunteer Tom Rutt Issues Editor: (formulate, log and maintain issues list) - Volunteer Mark Goodner Spec Editors Volunteers (Chris F, Anish K, Umit, Gilbert, Steve W) Paul C: how do you have four people edit two documents. Paul F: we are taking volunteers for an editing team, but we need to sort this thing out. Martin C: the editing team can work amongst themselves to determine how to divide work. Jeff M: have the chairs determined how the editing team will be selected. Paul F: We now have to work that out. Ψ Action: the editing team should produce an editors draft in OASIS format with line numbers. Ψ Action: chairs will give Tom Rutt Secretary status for Kavi so he can organize the Document page Jeff M: it would be good to have a web master. For now the Chairs should fulfill web masters role. 10 Any other businessThe chairs will work on an IRC channel for use in the meetings. Paul C: I believe we need to be careful, we should have a web access. I do not like something which requires installation of special software. Tom R: As note taker, I would be careful to jump on using IRC for note taking, especially if it has a significant hit on the workload for producing minutes. Martin: I would prefer that we have some IRC type of channel available for meetings. Someone else asked about a collaborative meeting process tool. Tom R stated he will set up a contributions section of the document server, and members should post to , sending the url in the email notice. Jorgen asked if we have a clear sense of milestones. Ψ Action: Chairs will provide a set of milestones for the TC. Jeff M: I would like to thank SAP for fine hosting job, and the chairs for their fine job. 11 AdjournmentMeeting adjourned at 12:15 PM. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]