wsrm issues

[John Fuller <jfuller@wernervas.com>]

Enclosed are excerpts from WS Reliability: the most recent schema,
a suggestion I made concerning using ASAP to implement a polling reply 
pattern
and a proposal from others in the group for a reliability namespace 
status request.

My argument is basically that ASAP was designed to deal with the Aspect
of determining the status of a service instance and could be used in 
place of
adding special reliability headers for this purpose.

Again, they expect 1000s of messages a second
and want to piggyback acknowledgements.  I worry the term "service 
instance"
(while also used this way in the Grid Service community) may have
scared people away imagining how it would be implemented.
It seems to me ASAP's treatment of Keys and Context Data are opaque 
enough
to handle it semantically.

What are opinions here about the application of ASAP for this purpose?
I don't want to misapply or stray from the intent of ASAP...


***

WS-Reliability has gone through some changes since the precommittee 
document,
a recent schema writeup is shown below

rev_schema.xsd

***

From: John Fuller <jfuller@wernervas.com>
Date: Fri Sep 26, 2003  4:09:00 PM US/Central
To: tom@coastin.com
Cc: wsrm <wsrm@lists.oasis-open.org>
Subject: Re: [wsrm] Poll Operation

In the invoice message if they added an ASAP header for a 
create-instance-request
(perhaps providing the observerkey uri) with no response requested
(our one way scenario),
it seems like an observer could find the status by the ASAP RequestId
or alternately ContextData: both of which are opaque enough they could
use RM header inforrmation or not.
Admittedly reliability was originally to be out of scope for ASAP,
but it is a case of a query for service instance status information...


On Friday, September 26, 2003, at 03:39 PM, Tom Rutt wrote:

> I have expressed concerns that the Poll operation should be expressed 
> as part of the WSRM protocol using a soap header element.   Doug has 
> stated a preference to treat the poll operation
> as a separate WSDL operation.
>
> I think the question boils down to what we consider as parts of the 
> contract for the web service instance that the client is accessing.  
> If one considers the entire description for a particular web service 
> instance (e.g.,  an Invoice delivery service with a oneway WSDL 
> operation) to include its ability to use WSRM defined
> soap headers and protocol, and if the poll request message part will 
> never be piggybacked with an invoice message part,  I can see Doug's 
> point.  In this case, the adversised web
> service instance includes the ability to receive the invoice oneway 
> operation, as well as to
> be able to deal with the WSRM soap headers and act in accordance to 
> the protocol.  So it does not matter if the service description 
> includes the poll info as a message part bound to the soap body, vs 
> binding it to the soap header.
>
> However, if the client wants to piggyback the poll request with another
> reliable invoice request, the wsdl description might be complicated if 
> both are
> defined as message parts (for the same wsdl operation) bound to the 
> body. If there is no need for this "Piggybacked poll" use case, then 
> that is another concern which is removed..
>
> I was concerned about supporting use cases where someone would 
> consider the invoice oneway
> operation as the definitive specification of the web service instance, 
> with WSRM protocol usage
> negotiated in some other agreement, outside of the wsdl spec .  If 
> this use case
> is not in anybody's mind as an alternative, I guess my other concerns 
> do not apply,
>
> Tom Rutt
>
> -- ----------------------------------------------------
> Tom Rutt		email: tom@coastin.com; trutt@fsw.fujitsu.com
> Tel: +1 732 801 5744          Fax: +1 732 774 5133

***

From: Sunil Kunisetty <Sunil.Kunisetty@oracle.com>
Date: Tue Sep 16, 2003  1:51:15 PM US/Central
To: wsrm@lists.oasis-open.org
Subject: [wsrm] [REL-XX]Proposal for POLL RM-Reply Pattern


  All -

  I had an AI @ the last F2F for coming up with a proposal for POLL 
pattern.

  Mark/Doug:

  Could you create a Spec. Issue for Requirement Issues 3.6 & 3.7?

  <ProposalBegin/>

   I'd like to propose to have 2 new Headers:

      StatusRequest
      StatusResponse

   StatusRequest will be the Header used by the Sender to send a 
poll/status
   inquiry to the Receiver. It will have 2 sub-elements. A mandatory 
GroupId
   and an optional SequenceNo. The types for these are the same as the 
ones
   in MessageHeader element.

   StatusRequest
       - GroupId  - Mid URI type - Mandatory
       - SequenceNo - UnsignedLong - Optional

   StatusRequest can be sent without a MessageHeader and hence can be
   piggy-backed on another Request or can be batched with other status 
requests.

   StatusResponse Header will be used by a Receiver to send the status 
back
   to Sender. It will have the following sub-elements:
         - RefToGroupId      -  mid URI type - Mandatory
         - RefToSequenceNo - unsigned long  - Optional
         - Status                    - QNAME        - Mandatory

   Possible Status Values are:
         - InvalidGroupId -  When the GroupId is invalid or un-recognized
         - InvalidSequenceNo  - When the SequenceNo is invalid or 
un-recognized
         - MsgExpired - When the message was expired (based on 
ExpiryTime)
         - MsgReceived - When the message was received and ack-ed by the 
RMP/

   Since all our Header elements are extensible, Implementations can 
extend with a
   new element called 'sub-status' and send more implementation specific 
details
   if desired. But I prefer that Spec. level requirements for Status be 
simple.

   Multiple StatusResponse(s)  can be batched or can be piggy-backed on 
Response.

   We should be able to share the above Status values with Fault Codes. 
Note both
   are QNAME types and hence shareable.

   Error due to StatusRequest processing will result in a Fault with 
error code
   InvalidStatusRequest.

   <ProposalEnd/>

  Comments ???

  -Sunil

***