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

[Sunil Kunisetty <Sunil.Kunisetty@oracle.com>]

 Marc,

 My comments with  <sk> tags.
"Goodner, Marc Andrue" wrote:

> First, I really do not see why it is inconsistent to define both header and body operations. Both are

 <sk> It is inconsistent because while all other RM operations are defined using SOAP Header,
         only this one is using Body. </sk>

> mechanisms available to us and I believe that the usage of the poll request is more consistent with being

 <sk> I disagree. I believe in that SOAP body is meant for application payload and the extensible
         Headers are meant to do QoS stuff like the RM stuff. So we don't have both, we just have
         one </sk>/

> 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

 <sk> Ideally yes, but nothing wrong  with an empty Body </sk>.

> 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 t

 <sk> There is an action, and the action is to ack. a message </sk>

> he actual web service there seems very unintuitive. I understand that it may be syntactically legal but I don't

 <sk> I agree that it is some what unintuitive. So on one hand, we have some what unintuitive solution with
         no technical issues and other hand we have some what (less) unintuitive (bcoz we are using
         SOAP Body which is meant for an application payload  to send a RM request) with technical/design/
         implementation constraints. Go Figure!</sk>

> 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

 <sk> Our Spec. doesn't define the API/Application interface. So we can't assume whether this action
         will be performed directly or in-directly by some User action. I assume most implementations
         will support both modes. </sk>

> 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

<sk> How? If it is Headers, RMP implementations can add this Header to the wire even if the
        WSDL doesn't define so or WSDL can mandate this Header by defining that in the SOAP
        Binding (with mU=1) or can also define the Header optionally in the SOAP Binding part (with mU=0).
        How can you do this with Headers? </sk>.

> 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.

 <sk> It does. How does the client be aware of the WSDL for the RMP service?</sk>

>
>
> 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>

<sk> In my proposal, the same sender who sent the initial message to the same receiver (read endpoint)
        will be sending the Poll request to the same endpoint. Where as in the revised proposal, anyone
        can send the Poll request to this endpoint. It's more vulnerable. </sk>

>
>
> 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>

 <sk> It is an implementation issue and my point is we (the Spec.) are imposing new implementation
         restrictions which are not needed in the first place. </sk>


>
>
> 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>

<sk> In the revised proposal, RM poll ack. request is sent on a different endpoint/service. If this
        philosophy is extended, i.e., secure key requests are sent to different endpoint/service, transaction
        commit calls are sent to a different endpoint, how can you have a secure, transactional, reliable
        messaging on a single endpoint? </sk>

>
>
> 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>

<sk> Yes, it's a design restriction... so essentially we are imposing new design restrictions which are
         not needed in the first place. </sk>

>
>
> 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>

<sk> RMP is not a service or application. RMP is QoS provider to an existing service. </sk>

>
>
> 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

<sk> Because all (atleast every RMP impl. I know) RMP implementations are based on Handlers. </sk>

> 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>

<sk> As I said above we cannot assume that this will be invoked directly or in-directly as it is out of scope.
        I see a need for piggy-backing. </sk>

>
>
> 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>

<sk> See all the problems I've mentioned above.</sk>

>
>
> 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>

<sk> There is a message and that message is empty. Note, ws-i  bp 1.0 also acks. that empty
         Body is empty message and it is unique in it's own. </sk>

>
>
>                   [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>

<sk> Poll is also a disconnected response to an early request in the reverse direction. Poll and Callback
        always go together semantically. If you call it a 'Status' request, then some of your concerns are
        valid. But I'm just polling for an ack. for an earlier request. </sk>

>
>
>  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>

<sk> As I've been saying form beginning, the issue here seems to be conceptual concerns...
        But what the revised proposal is doing is not addressing the technical issues with it or
        rather skirting  them.

        I really wanted to see a complete concrete alternate proposal. How is the wsdl defined? How
       does the client get hold of the RMP's WSDL etc.... </sk>/

>
>
> 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>

 <sk> How is sending the request in a Header affects application developers especially when this is
         done transparently?  </sk>

 Thanks for your comments!
 -Sunil