[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: WSRM uses URIs to refer to endpoints for callback and poll patterns-- new issue
Resending (as the previous send bounced -- I had the wrong address :-( ). ------------------------------------------------------------------- For the poll and callback pattern WS-R has an attribute 'replyTo' of type xs:anyURI. The value of this attribute in the request message specifies the poll/callback location. This is problematic for the following reasons: 1) A URI does not represent a Web service -- a WS is much more than a URI and a reference to a WS has to be more than a URI. A URI is certainly part of the WS reference. URI is necessary but not complete. For example, the URI does not say what the operation/interfaces/binding/policy/f&P/capability/etc are. One cannot even specify the value for the "SOAPAction" HTTP header (which is part of the binding). Although WS-R is not WSDL-centric (and the callback location and poll location does not necessarily have an associated WSDL), the replyTo attribute makes the scope of WS-R very limited. 2) As corollary to (1) above, the binding/interface of the URI has to be known before hand and cannot be changed. I.e., the SOAP node which is being polled or called-back on has to be assumed to use SOAP HTTP binding. One of the big reasons for using callback/poll is the underlying protocol itself is asynchronous (HTTP is synchronous) -- other reason is that the operation takes a looong time. Effectively, WS-R cannot be used with non-HTTP/non-SOAP-binding. For example, one cannot use SMTP/MOM-proprietary asynch protocols. 3) Another corollary to (1) is that one cannot send a message using protocol A and poll/callback using protocol B. E.g., a node which is behind a firewall sends a message using HTTP (so that it knows that the message has been received but not necessarily delivered) and have the receiving node send an ack using SMTP. 4) An attribute of type URI is not enuf to represent all kinds of protocol bindings (such as queuing systems). This means that newer versions of WS-R spec (which hopefully will support various protocols) cannot use an attribute of type URI -- for two reasons -- the type is restricted to URI and it is an attribute (which means it can only be simple type). I.e., the current schema for WS-R lacks extensibility for the addressing feature of callback/poll. Not very friendly for future versioning. I do realize that this issue is being brought up at the 11th hour, but did not realize that there was an issue till now. Thanks. -Anish --
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]