[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Prelim WSRX Minutes Monday AM
The prelim minutes from Monday AM are attached. 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. 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. Paul went through the roster to take the roll.
Roll call: 51 Voting members. 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 person’s 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]