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

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

 All,

 Attached is my document with my comments and requirements list.

 -Sunil

Title: Tom has requested me to re-list

 

Tom has requested me to re-list the requirements for Poll RM Reply pattern [1] and also list the concerns I’ve mentioned in the con. call. I already listed few issues briefly before [2].

 

Use Cases:

 

1.      For a client behind a firewall using one-way MEPs. It can’t use the Response RM Reply pattern as the application is using one-way MEPs. It also can’t use the Callback RM Reply pattern as it is behind the firewall. So essentially there is no easy way out. I believe this is very prominent use case and should have an efficient solution. Poll RM Reply pattern solution would be solving this problem efficiently.

2.      Retry is not always an alternate if the payload is huge. Retry-on-demand is an alternative. And one way to achieve is to poll the message before retrying.

3.      Thin Client: Currently for applications using one-way MEPs and Callback patterns, they need to have a listener on the client side. This may be acceptable to fat/thick clients. This requirement may be too heavy weight for (very) thin clients especially if not all messages have to be reliable (say only 5 out 100 msgs. sent are critical for an application). So instead of having a listener, the Sender can only poll for acks. for those critical messages).

 

While the TC has unanimously accepted the requirement, and the syntax was agreed in-principle, the main concern seems to be more conceptual. Whether this request should be  sent in the SOAP Body or SOAP Header? I foresee many issues with sending the request in SOAP Body.

 

Issues sending in SOAP Body:

 

If this Poll request has to be sent in the SOAP Body, then it has to be defined in the WSDL unlike in the Header case. In the latter case, it is not a must rather could.  If not, interoperability is not guaranteed, schema/payload validation won’t happen etc.

 

So, if it has to be defined in WSDL, where?

 

Same as application’s WSDL: WSDL 2.0 (was WSDL 1.2) does have support for Interface (was PortType) inheritance. Provided with this, we could have required that all application interfaces that require RM Poll could inherit the RM Poll Pattern PortType. But WSDL 2.0 is not expected to be in community draft before we are. Even if so, we still has to solve the WSDL 1.1 cases. So for WSDL 1.1, this would require mucking around the Application’s WSDL – which is not acceptable. Mucking around problem will exist whether we are changing the same PortType/Port or whether adding new PortType/Port to the same <wsdl:service> element or adding a new <wsdl:service> to the same WSDL. Mucking around has lot of problems:

1. Versioning.
2. How is the updated WSDL available to the user?
3. It is no longer application’s WSDL, rather a combo version.
4. If QoS module has to update the application’s WSDL, who does when & how?

 

Different endpoint same URI as application endpoint URI in a different WSDL: Other option is to create another WSDL with one operation (Poll RM Reply Pattern) and endpoint address will be the same as the application endpoint address. However, the concern/issues here are:

1. How does the platform (RMP) get hold of this WSDL?
2. If the platform (RMP) hosts 1000 applications, do we have to create 1000 WSDLs with the same portType/Port with different URIs (basically one each for each application service endpoint)?
3. WS-I BP 1.0 discourages URI overloading though doesn’t prohibit it.
4. If the name of the operation is “poll”, then we will have a restriction that user shouldn’t have any operation with the same name. [This is not an issue if it is a DOC service as it would be namespace qualified. This will be an issue if it is a RPC service].

                                                              

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
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?
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?
6. No mechanisms to prohibit other (non RM) Headers on this request to this special port.

 

Other issues with Body:

1. Looks odd. All other RM operations are expressed in Headers.
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.
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.
4. Piggybacking will be prohibited.

 

 

 

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.

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]

                                                             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]

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

                                                           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.

5.      Batch multiple Poll requests

6.      Piggy backing with other requests to the same endpoint.

7.      No new implementation restrictions. Consistent with the current approach.

 

Let me also address Mark’s concerns raised in his mail [3][4]:

1. Security is bit different when compared to Reliability, Transactions, Lifecycle etc. The former has tight dependency with payload, while the latter ones are loosely coupled and generally have a out-of-band contract.
2. XKMS didn’t define WSDL SOAP Bindings and hence they don’t have the problems I mentioned above.
3. XKMS didn’t define any Header operations and ALL of them are in Body. So at least it is consistent in that respect.

 

 

Summary:

So in short, there are no technical issues as far as I can see with sending this request in SOAP Header except for conceptual concerns.

 

References:

[1] - http://www.oasis-open.org/archives/wsrm/200309/msg00034.html

[2] – http://www.oasis-open.org/archives/wsrm/200309/msg00063.html

[3] - http://www.oasis-open.org/archives/wsrm/200310/msg00009.html

[4] - http://www.oasis-open.org/archives/wsrm/200310/msg00008.html

[5] - http://www.w3.org/TR/SOAP/#_Toc478383497

[6] - http://www.w3.org/TR/2003/REC-soap12-part0-20030624/#L1161