OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[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

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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]