[Fwd: Returned mail: see transcript for details]

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

--- Begin Message ---

• From: Mail Delivery Subsystem <MAILER-DAEMON@oracle.com>
• To: <Anish.Karmarkar@oracle.com>
• Date: Tue, 4 May 2004 13:46:02 -0700 (PDT)

The original message was received at Tue, 4 May 2004 13:45:56 -0700 (PDT)
from localhost [127.0.0.1]

   ----- The following addresses had permanent fatal errors -----
<wsrm@list.oasis-open.org>
    (reason: 550 Host unknown)

   ----- Transcript of session follows -----
550 5.1.2 <wsrm@list.oasis-open.org>... Host unknown (Name server: list.oasis-open.org: host not found)

Reporting-MTA: dns; inet-mail1.oracle.com
Received-From-MTA: DNS; localhost
Arrival-Date: Tue, 4 May 2004 13:45:56 -0700 (PDT)

Final-Recipient: RFC822; wsrm@list.oasis-open.org
Action: failed
Status: 5.1.2
Remote-MTA: DNS; list.oasis-open.org
Diagnostic-Code: SMTP; 550 Host unknown
Last-Attempt-Date: Tue, 4 May 2004 13:46:02 -0700 (PDT)

--- Begin Message ---

• From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
• To: wsrm@list.oasis-open.org
• Date: Tue, 04 May 2004 13:44:51 -0700

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

--- End Message ---

--- End Message ---