RE: [wsrm] [REL-94]Proposal for POLL RM-Reply Pattern

["Goodner, Marc Andrue" <marc.andrue.goodner@sap.com>]

First, I really do not see why it is inconsistent to define both header and body operations. Both are mechanisms available to us and I believe that the usage of the poll request is more consistent with being represented in the SOAP Body. 

I do understand that there is nothing wrong with sending an operation in a SOAP Header. However I think that is only consistent when used in conjunction with the SOAP Body as the context of the operation expressed in the header is usually expected or understood to have some relation to the operation request or content in the body. To send a message with only a header to an endpoint with no action to be taken by the actual web service there seems very unintuitive. I understand that it may be syntactically legal but I don't like it and I don't think most application developers would either.

The idea that not describing the operation being requested in the header anywhere is somehow a benefit does not agree with me. It only sounds like a benefit to implementers, not to end users of this specification who I believe will think of the poll request as an operation that they will want to invoke directly and not as part of some other request to a web service, especially if they aren't making a request of that service. Expressing that as an operation of the RMP in the SOAP Body will be the best experience for developers using WS-Reliability in my opinion.

I think many of the issues with respect to how and where the client gets the WSDL apply whether or not we are using headers. I agree that the headers should be specified in the WSDL to facilitate interoperability and schema validation. So I don't think it makes much sense to debate the WSDL issues to much especially as I only agree with one mechanism which is the different endpoint/uri example which does not seem to have many WSDL problems unique to itself.

So below as <mag/> are a few comments on the document.

Regards,
Marc g


Different endpoint different URI: The other option is to treat a RMP as a Service  and hosted on a different endpoint/WSDL. Issues in this case:
1. How does the client get hold of the WSDL? 
2. How is the Service implemented? Rpc/doc, literal/encoded etc. 
3. Security/DOS issues 
<mag>These issues apply regardless of whether it is a header or not with the exception of rpc/doc. I would support requiring support for both actually. With respect to encoding we should require doc and stay silent on encoding as we require BP support</mag>

4. If a RMP implementation uses different (persistence) cache for different endpoints (for different applications), how does this centralized RMP endpoint get hold of all these caches? 
<mag>That sounds like an implementation problem. Even with all of those caches the groupid/seqno should must still be unique so it will need to return any acknowledgements it finds. How it finds those when it is implemented in this way is not an issue for the specification</mag>

5. If every QoS is treated as a different Service and has a different endpoint, how can we achieve Secure, Transactional and Reliable stuff on the SAME endpoint?
<mag>I don't understand this point. What do you mean with every QoS as a different service?</mag>

6. No mechanisms to prohibit other (non RM) Headers on this request to this special port. 
<mag>I don't see any issue with that, that is by design. That way you can add WSS or other headers particularly to address point 3.</mag>

Other issues with Body:
1. Looks odd. All other RM operations are expressed in Headers. 
<mag>Purely subjective. I think it looks more odd to send a SOAP message with only a header</mag>

2. Generally speaking Body contents are meant for end applications. Headers are the extensibility mechanism for Web Services and are a double edge sword. If required, they can be defined statically in the WSDL or can be added dynamically on wire without being defined in the WSDL. 
<mag>I agree. But in this case we are treating the RMP as an application.</mag>

3. Most of us (at least all the Interop participants used some sort of Handlers) will be using Handlers for the RMP implementation. JAX-RPC Handlers are meant to be triggered based on certain Headers, i.e., a Handler definition has a  set of Headers (QNames) that are mapped to it and it is meant to be invoked only when those Headers appear on wire. So if we send this RM operation as a SOAP Body without any Headers, how will the Handler be invoked? We end up peeking into every message if this new implementation requirement is imposed. 
<mag>This is actually why I support leaving the callback in the header as in that case it would mean that you would be looking for the same type of information in the body and the header. In this context though you client application is making a request of the RMP directly. Why would the handlers have to look into every method if you provide a service from your implementation to support this operation type?</mag>

4. Piggybacking will be prohibited. 
<mag>I don't see the need to piggyback the poll request. It seems to me that this operation would be invoked directly and not indirectly as part of some other process.</mag>

So sending in Body is still possible, but have lot of issues as mentioned above. It should be the last resort. I don't see any problem using Headers for sending this Poll request except for few conceptual worries, so I don't see a need for a change. Here are the advantages using the Header:
1.      Consistent with other RM operations.
2.      Extensible.
3.      Easy to define WSDL Bindings if required.
<mag>I don't think using a body operation is inconsistent or somehow not extensible. Defining the WSDL bindings for the operation as a different endpoint/uri should not be hard</mag>

4.      There is nothing wrong in sending operations in SOAP Headers.
a.       It won't be re-inventing a new MEP, as MEPs deal with Senders & Receivers and not Body or Header. The current proposal still constitutes the R-R MEP.
b.      SOAP spec. doesn't say that Headers shouldn't  be used for operations. Infact, it's perfectly valid to use Headers for Platform (non application) operations. Here are some snippets from SOAP Specs.
 i.      SOAP provides a flexible mechanism for extending a message in a decentralized and modular way without prior knowledge between the communicating parties. Typical examples of extensions that can be implemented as header entries are authentication, transaction management, payment etc.[5]
<mag>I don't disagree with these points</mag>

 ii.      A SOAP header is an extension mechanism that provides a way to pass information in SOAP messages that is not application payload. Such "control" information includes, for example, passing directives or contextual information related to the processing of the message. [6]
<mag>This is exactly what I have issue with, "related to processing of the message", there is no message! I understand that technically there is but to an application developer that is what this looks like</mag>

                  [ps: I also discussed this in length with our rep. on XMLP W3C WG 
                  and he echoed my thoughts that it is nothing wrong in sending in 
                  Headers.]
 iii.      I don't think this is anything different from the Callback thing we are doing.
<mag>I think it is different. For one the callback is a disconnected response to an early request that did include a message. Secondly I can envision scenarios in which those callback acknowledgements will be sent piggybacked on a request of some other related operation</mag>

 iv.      Many specifications already send QoS-like operations in Headers. The only difference is that they are sent with some associated payload, where as in this case, there is no such payload.
<mag>That's what I have a problem with, no payload</mag>

5.      Batch multiple Poll requests
<mag>It is not clear to me that this could not still be supported when using the body</mag>

6.      Piggy backing with other requests to the same endpoint.
<mag>I don't see the poll operation as being as useful in this case, I would be fine with not supporting piggybacking the poll.</mag>

7.      No new implementation restrictions. Consistent with the current approach.
<mag>My concern is the application developers. Easy to implement but difficult or uncomfortable to use and no one will.</mag>


-----Original Message-----
From: Sunil Kunisetty [mailto:sunil.kunisetty@oracle.com] 
Sent: DTue, Oct 07, 2003 10:34 AM
To: wsrm@lists.oasis-open.org
Subject: Re: [wsrm] [REL-XX]Proposal for POLL RM-Reply Pattern



 All,

 Attached is my document with my comments and requirements list.

 -Sunil