OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [ebxml-msg] FW: [members] OASIS TC Call for Participation: OASIS Web Services Reliable Exchange (WS-RX) TC

Title: RE: [ebxml-msg] FW: [members] OASIS TC Call for Participation: OASIS Web Services Reliable Exchange (WS-RX) TC

I have not seen any information about the call. Looks like it will be May 13 when we can take this up




From: Jacques Durand [mailto:JDurand@us.fujitsu.com]
Sent: Wednesday, May 04, 2005 11:22 AM
To: 'Matthew MacKenzie'; Dale Moberg
Cc: ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] FW: [members] OASIS TC Call for Participation: OASIS Web Services Reliable Exchange (WS-RX) TC


I have not heard of any call scheduled today.

> It would be interesting to discuss what would be required in ebms to
>enable pluggability of rm processors.

Reliability has been designed from the start as a modular feature in V3 (meaning rather independent from the processing of ebMS headers), so that should not be too hard to realize. So far, the definition of QoS reliability features, and the abstract operations involved are rather similar between the two reliability specs. I see two things that can be done and an issue to resolve:

- the core body of V3 specification should only address the common reliability model, and related abstract operations (which/how they are used to make various MEPs reliable), but not mention any specific to WS-Reliability. The parts of the RM agreement that are common (top level QoS features) can also be profiled here.

- WS-Reliability specifics (e.g. lower level RM agreement parameters) can be moved to a binding section in appendix. The other module based on WS-ReliableMessaging would be treated the same when it is ready (could take a year, maybe two...)

- issues: reliability of synchronous responses is not addressed by either spec... although it is on the WS-Reliability roadmap and has been anticipated in current V3 draft, we don't know about WS-ReliableMessaging. Also, WS-ReliableMessaging is a bit fuzzy regarding the notification of delivery failure. It may need to be profiled further so we can have a clear contract at MSH level.

For now I'd rather concentrate on the other features beside reliability: still a lot to do there...


-----Original Message-----
From: Matthew MacKenzie [mailto:mattm@adobe.com]
Sent: Wednesday, May 04, 2005 7:03 AM
To: Dale Moberg
Cc: ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] FW: [members] OASIS TC Call for Participation: OASIS Web Services Reliable Exchange (WS-RX) TC

It would be interesting to discuss what would be required in ebms to
enable pluggability of rm processors.

Dale Moberg wrote:

>If we are meeting today, could we add the following item to our agenda
>and try to figure out what convergence involves for the reliability
>functionality in 3.0?
>Dale Moberg
>-----Original Message-----
>From: James Bryce Clark [mailto:jamie.clark@oasis-open.org]
>Sent: Tuesday, May 03, 2005 8:01 PM
>To: members@lists.oasis-open.org; tc-announce@lists.oasis-open.org
>Subject: [members] OASIS TC Call for Participation: OASIS Web Services
>Reliable Exchange (WS-RX) TC
>     A new OASIS technical committee is being formed. The OASIS Web
>Services Reliable Exchange (WS-RX) Technical Committee has been proposed
>the members of OASIS listed below.  The proposal (below) meets the
>requirements of the OASIS TC Process [1].  The TC name, statement of
>purpose, scope, list of deliverables, audience, and language specified
>the proposal will constitute the TC's official charter. Submissions of
>technology for consideration by the TC, and the beginning of technical
>discussions, may occur no sooner than the TC's first meeting.
>     This TC will operate under our 2005 IPR Policy.[2]  The eligibility
>requirements for becoming a participant in the TC at the first meeting
>details below) are that:
>     (a) you must be an employee of an OASIS member organization or an
>individual member of OASIS;
>     (b) the OASIS member must sign the OASIS membership agreement (see
>     (c) you must notify the TC chair of your intent to participate at
>least 15 days prior to the first meeting, which members may do by using
>"Join this TC" button on the TC's public page at [4]; and
>     (d) you must attend the first meeting of the TC, at the time and
>fixed below.
>     Of course, it also will be possible to join the TC at a later time.
>     Standards always are improved by broad participation.  Non-OASIS
>members who wish to participate may contact us about joining OASIS
>[3].  Our rules and structure are designed to promote inclusiveness. We
>look forward to assisting parties interested in joining the community of
>implementers, technologists, academics and end-users working on OASIS
>standardization projects.  All also are welcome to take advantage of the
>public resources maintained for each TC: a mail list archive, document
>repository and public comments facility, all of which will be available
>the TC's public home page at [4]. Archives of the TC's mail list and
>comment lists, as with all OASIS TCs, will be visible at [5].
>     Further information generally related to the topic may be found on
>Cover Pages at http://xml.coverpages.org/reliableMessaging.html.
>     Please feel free to forward this announcement to any other
>lists.  OASIS is an open standards organization; we encourage your
>feedback. JBC
>~ James Bryce Clark
>~ Director, Standards Development, OASIS
>~ jamie.clark@oasis-open.org
>[1] http://oasis-open.org/committees/process.shtml
>[2] http://www.oasis-open.org/who/intellectualproperty.php
>[3] See http://www.oasis-open.org/join/
>[4] http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-rx
>[5] http://lists.oasis-open.org/archives/
>1.  TC Charter:
>     OASIS Web Services Reliable Exchange Technical Committee (WS-RX)
>     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
>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
>the TC.
>     The TC will accept as input the February 2005 Version 1.0 of the
>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
>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
>of the input documents to produce as output modular specifications that
>standardize the concepts, WSDL documents and XML schema renderings
>to provide reliability assurances to message exchanges between two
>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
>behalf of the Application Destination. Message Transfer is the function
>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
>failures. There can be multiple, concurrent and independent reliable
>exchanges between two parties. Reliability assurances make statements
>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
>The specifications will render these concepts as a specific set of
>restrictions over SOAP messages including XML schemas and WSDL
>     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
>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
>messages are not transferred.
>     --  Exactly Once:  Messages are transferred at least one time and
>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
>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
>     The specifications developed by the WS-RX TC will define elements
>relationships among elements that enable the implementation of the
>following functions which support the reliability assurances in the
>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
>is the condition resulting from catastrophic failure in which a
>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
>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
>Framework [9] and binding of that policy to a WSDL port.
>     --  A binding of the reliable messaging protocol elements to SOAP
>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
>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
>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
>Web services architecture.
>     If an above specification is outside of a standardization process
>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
>TC output will be expressed in an abstract manner, and the incarnation
>be left at that time as an exercise in interoperability.
>     While composition with other specifications is a goal of the TC, it
>also a goal to leave the specifics of how that composition is achieved
>outside the scope of the RM specifications.
>     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
>only for the sake of clarity. If some function, mechanism or feature is
>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
>issues and considerations that do not affect an interoperable reliable
>messaging protocol.
>    Specifically: the TC is not concerned with binding the
>to specific underlying transports.
>     The TC and the specifications that it produces do not address
>considerations, such as durability related to Sources' and/or
>ability to satisfy reliability assurances.
>     Except for the elements directly related to the functions in the
>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
>    The TC will not attempt to define concepts or renderings for
>that are of wider applicability including but not limited to:
>     --  Security (Encryption, Integrity and Authentication)
>     --  Addressing
>     --  Policy languages and frameworks
>     --  Routing
>     --  Transactions and Compensation
>     Where required these functions are achieved by composition with
>Web services specifications.
>     The TC will not attempt to define functionality duplicating that of
>any normatively referenced specification in the input
>or WS-RM Policy specifications. If the referenced specification is
>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.
>     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.
>     These specifications will reflect refinements, corrections or
>technological improvements with respect to the input documents and in
>accordance with this charter.
>     Ratification of the above specifications as OASIS Standards,
>a brief period to address any errata, will mark the end of the TC's
>     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"
>mode as defined in the OASIS Intellectual Property Rights (IPR) Policy,
>effective 15 April 2005.
>     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; and
>     --  End users implementing Web services-based solutions that
>an interoperable, composable reliable messaging solution.
>     TC business will be conducted in English.
>2. Non-normative information regarding the TC:
>Similar or applicable work
>     The following work may be relevant to this WS-RX TC:
>     Similar Work:
>     --  OASIS Web Services Reliable Messaging TC.  The WSRM TC has a
>similar goal to that of WS-RX; to specify reliable message delivery for
>services.   However, the WSRM TC has a fundamentally different view with
>regard to scope of the specification, required functions, policy, and
>services architecture
>     --  OASIS ebMS TC.  The ebMS TC has as part of its scope a similar
>goal to that of WS-RX.  However, it has a fundamentally different view
>regard to scope, QoS, required functions and Web services composability.
>     The proposers of this TC recognize there are different reliability
>approaches in the industry and believe that the defined Scope of Work of
>this TC addresses many functional use cases of these parallel efforts.
>proposers of this TC seek involvement from the authors of WS-Reliability
>particular, and the contribution of their expertise and experience, and
>intend to work in harmony with them in the creation of the product of
>technical committee.
>     Applicable Work:
>     --  OASIS Web Services Security TC.  WS-RX will ensure that its
>specifications compose with the WSS TC specifications.
>     --  W3C Web Services Addressing WG.  WS-RX will utilize the
>WS-Addressing functions where appropriate and avoid creating overlapping
>     The TC may decide to establish liaisons with other groups as
>Responsibilities for such liaison will be defined by the TC at that
>     Anticipated contributions:
>     --  The current WS-Reliable Messaging [1] and WS-RM Policy [2]
>specifications, as published February 2005 by BEA, IBM, Microsoft, and
>TIBCO Software are expected to be contributed to this TC.
>First meeting
>     The first meeting of the WS-RX TC will be a face to face meeting
>in Palo Alto, California, USA 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
>will be sponsored by SAP.
>On-going meeting schedule
>     It is anticipated the WS-RX Technical Committee will meet via
>teleconference every week at a time determined by the TC members during
>TC's first meeting.  It is anticipated that the WS-RX Technical
>will meet in face to face every quarter at a time and location to be
>determined by the TC members.  Actual pace of face to face and
>teleconference meetings will be determined by TC members.
>     One of the proposers, as listed below, will sponsor the
>teleconferences unless other TC members offer to donate their own
>facilities. If no other TC proposers offer to sponsor teleconference
>facilities, Microsoft will donate their facilities.
>     The following eligible individuals are in support of this proposal:
>Atsushi Atarashi, NEC, atarashi@sv.nec-labs.com
>Anto Budiardjo, Individual Member, antob@clasma.com
>Abbie Barbir, Nortel, abbieb@nortel.com
>Doug Bunting, Sun Microsystems, doug.bunting@sun.com
>Lloyd Burch, Novell, lburch@novell.com
>Serge Cayron, ACORD, scayron@acord.org
>Steve Carter, Novell, srcarter@novell.com
>David Chappell, Sonic Software, dchappell@sonicsoftware.com
>Alan Clark, Novell, aclark@novell.com
>Lloyd Chumbley, ACORD, lchumbley@acord.org
>David Connelly, OAGI, dconnelly@openapplications.org
>Toby Considine, The University of North Carolina at Chapel Hill,
>Paul Cotton, Microsoft Corporation, pcotton@microsoft.com
>Glen Daniels, Sonic Software, gdaniels@sonicsoftware.com
>Chris Ferris, IBM, chrisfer@us.ibm.com
>Dan Foody, Actional, dan.foody@actional.com
>Paul Fremantle, IBM, pzf@uk.ibm.com
>Robert Freund, Hitachi, Ltd., bob.freund@hitachisoftware.com
>Peter Furniss, Choreology, peter.furniss@choreology.com
>Alastair Green, Choreology, alastair.green@choreology.com
>Anish Karmarkar, Oracle, Anish.Karmarkar@oracle.com
>Chris Kurt, Microsoft Corporation, ckurt@microsoft.com
>Dan Leshchiner, TIBCO, dleshc@tibco.com
>Mark Little, Arjuna, mark.little@arjuna.com
>Matt Mackenzie, Adobe, mattm@adobe.com
>Matt Mihic, Blue Titan, mmihic@bluetitan.com
>Jeff Mischkinsky, Oracle, jeff.mischkinsky@oracle.com
>Nilo Mitra, Ericsson, nilo.mitra@ericsson.com
>Tim Moses, Entrust, tim.moses@entrust.com
>Eric Newcomer, IONA, eric.newcomer@iona.com
>David Orchard, BEA Systems, dorchard@bea.com
>Sanjay Patil, SAP, sanjay.patil@sap.com
>Jim Purves, United Kingdom e-Government Unit,
>Andrew Nash, Reactivity, anash@reactivity.com
>Shivajee Samdarshi, TIBCO, shivajee@tibco.com
>Jiri Tejkl, Systinet, jiri.tejkl@systinet.com
>Claus von Riegen, SAP, claus.von.riegen@sap.com
>Pete Wenzel, SeeBeyond, pete@seebeyond.com
>Steve Winkler, SAP, steve.winkler@sap.com
>Prasad Yendluri, webMethods, prasad.yendluri@webmethods.com
>Matsuki Yoshino, Hitachi, Ltd., yoshinom@itg.hitachi.co.jp
>     Paul Cotton, Microsoft Corporation, pcotton@microsoft.com
>Proposed TC Chairs
>     Paul Fremantle, IBM, pzf@uk.ibm.com
>     Sanjay Patil, SAP, sanjay.patil@sap.com
>[1] WS-ReliableMessaging
>[2] WS-RM Policy
>[3] WS-Security
>[4] WS-Trust
>[5] WS-SecureConversation
>[6] WS-Addressing
>[7] SOAP 1.1
>[8] SOAP 1.2
>[9] WS-Policy
>[10] WSDL 1.1
>[11] WSDL 2.0
>[12] WS-I Basic Profile
>[13] Secure, Reliable, Transacted Web Services: Architecture &
>[14] XML Schema
>To unsubscribe, e-mail: members-unsubscribe@lists.oasis-open.org
>For additional commands, e-mail: members-help@lists.oasis-open.org
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail.  You may a link to this group and all your TCs in OASIS



To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]