I have not seen any information about the
call. Looks like it will be May 13 when we can take this up
Dale
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...
Jacques
-----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
>by
>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
>in
>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
>(see
>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
>[3]);
> (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
>the
>"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
>date
>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
>via
>the TC's public home page at
[4]. Archives of the TC's mail list and
>public
>comment lists, as with all
OASIS TCs, will be visible at [5].
>
>
Further information generally related to the topic may be found on
>the
>Cover Pages at http://xml.coverpages.org/reliableMessaging.html.
>
> Please
feel free to forward this announcement to any other
>appropriate
>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:
>
>Name
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
>
Specifically: the TC is not concerned with binding the
>specifications
>to specific underlying
transports.
>
> The TC
and the specifications that it produces do not address
>considerations, such as
durability related to Sources' and/or
>Destinations'
>ability to satisfy reliability
assurances.
>
> 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
>
> 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.
>
> 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; and
>
-- End users implementing Web services-based solutions that
>require
>an interoperable, composable
reliable messaging solution.
>
>Language
>
> 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
>Web
>services. However,
the WSRM TC has a fundamentally different view with
>
>regard to scope of the
specification, required functions, policy, and
>Web
>services architecture
>composability.
>
-- 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
>with
>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.
>The
>proposers of this TC seek
involvement from the authors of WS-Reliability
>in
>particular, and the
contribution of their expertise and experience, and
>intend to work in harmony with
them in the creation of the product of
>this
>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
>
>functions.
>
> The TC
may decide to establish liaisons with other groups as
>needed.
>Responsibilities for such
liaison will be defined by the TC at that
>time.
>
>
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
>held
>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
>the
>TC's first meeting. It is
anticipated that the WS-RX Technical
>Committee
>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.
>
>Proposers
>
> 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,
>toby.considine@fac.unc.edu
>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,
>jim.purves@cabinet-office.x.gsi.gov.uk
>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
>
>Convener
>
> Paul Cotton, Microsoft Corporation,
pcotton@microsoft.com
>
>Proposed TC Chairs
>
> Paul
Fremantle, IBM, pzf@uk.ibm.com
> Sanjay
Patil, SAP, sanjay.patil@sap.com
>
>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-sec
>urity-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/
>
>====
>
>
>---------------------------------------------------------------------
>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
>at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>
---------------------------------------------------------------------
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
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php