[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] [REL-XX]Proposal for POLL RM-Reply Pattern
All, Attached is my document with my comments and requirements list. -SunilTitle: 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:
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:
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:
Other issues with Body:
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]:
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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]