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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

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


Subject: Fujitsu proposal for Potential WSRM TC l Work Items


We (after an informal meeting between Jacques, Hamid, and Alan 
Weisberger) now propose 2 important work items for the WSRM TC going 
forward and one bonus benefit:
 
*1.  Clarify and unambiguously define the reliability of the response 
message.  *
 
We should not assume that this is equivalent to the reliability of the 
request message, but should define it separately and independently.  We 
propose to include this in WS-R 1.2 - a small incremental addition to 
the existing spec.
 
While the reliability of the response should be defined in different 
terms than the reliability of the request (see proposal), /it should not 
have a major impact on WS-R 1.1 standard or implementations.  /If the 
WS-R 1.1  implementation supports the option to cache the response and 
resend it, then all the functionality to support reliability of a 
synchronous response message is already present. 
-->*The WS-R specification should make that clear by defining the 
criteria for the reliability of the response message.*
 
*2.  Develop a high level specification for delivery assurance/QoS of a 
reliable message*.   We need to define the notion of reliable message 
delivery assurance in the context of QoS by describing the precise 
semantics (but not the syntax or protocol).  *The standardization of the 
expression of delivery assurance could be used to support either WS-R or 
WS-RMg (WS-RX).* 
 
We believe that a "mark-up" of the standard representation of delivery 
assurance would be very valuable for the WS industry and would be more 
expediently developed, generated and approved in the WSRM TC (vs WSRX 
TC) due to its proposed sharper focus.
 
For example, we recommend distinguishing between an acknowledgement from 
the receiving RMg entity (e.g. in WS-RX spec) vs an acknowledgement that 
confirms that the layer above the receiving RMg entity (perhaps a WS 
control protocol or application layer) has correctly received the 
message from the RMg entity.
 
Also, there may be different notions of the various forms of reliable 
message delivery: at least once, atmost once (AKA duplicate 
elimination), guaranteed delivery, sequential delivery, etc.  What do 
these notions really mean to the layer above?  They need to be precisely 
defined and illustrated.
--------------------------------------------------------------------------------------------------------------------------
*Side benefit:*
 
By keeping the WSRM TC actively engaged by working on these two 
subjects, we also reserve one or more placeholder work items that could 
be initiated when other Web Services specs are more mature and able to 
be used with WS-R:
 
-Defining a minimal level of interoperability between WS-R and WS-RMg.  
For example, defining a common set of functionality or lowest common 
denominator between the two specs and a corresponding (run time) syntax 
translation mechanism for equivalent message types.
 
-Composing WS-R with WS-Addressing (for the SOAP binding case).
 
-Composability with other specs TBD (i.e. WS Resource Framework or 
WS-Notification family of standards)
 
-Consistency with ebXML version 3, which currently references WS-R.

-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133




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