RE: Additional use case: 7 "Reversed HTTP binding for SOAP".

The basic constraint is the service is on a device that can not run an HTTP server.  Mobile might be one reason, but more the problem is that the service is on a device that can not be addressed, but does have an HTTP client.  Sure there are many ways to solve this problem, as there are to solve many of the use cases we are looking at, but HTTP is one way that has advantages (and disadvantages) over the other protocols you mention.
 
 
-----Original Message-----
From: public-ws-async-tf-request@w3.org [mailto:public-ws-async-tf-request@w3.org]On Behalf Of ext David Hull
Sent: February 16, 2005 02:11 PM
To: public-ws-async-tf@w3.org
Subject: Re: Additional use case: 7 "Reversed HTTP binding for SOAP".


It seems the basic constraints of this situation are that the service is mobile or otherwise hard to address.  This doesn't seem like a good fit for HTTP.  Rather, it seems like a better fit for store-and-forward protocols like email or messaging.

The basic pattern of request reply (as I understand it) is


*	requestor sends a request 

*	service sends a correlated reply or fault 

So take your pick between


*	Reverse HTTP is in fact request/reply, but with a funky way of "sending" the request message. 

*	Reverse HTTP is some other pattern, e.g. perhaps the infamous solicit/response. 

*	Reverse HTTP attempts to handle a problem best handled by other means



michael.eder@nokia.com wrote: 

Additional use case:  7  "Reversed HTTP binding for SOAP".



I would like to raise an additional use case for consideration.   Because this 

is new I will give a bit of background.



Overview:



A large and growing number of devices, such as mobile terminals, personal 

computers, and appliances are nowadays equipped with HTTP clients. At the same 

time most of these devices do not operate a HTTP server because of memory 

limitations, power limitations, or because these devices are not generally 

addressable or reachable from the Internet (e.g. behind NAT, Firewall, Turned 

off, or out of service). Yet in many cases these devices could offer valuable 

services. For example they could host a number of services such as a profile 

service, a calendar service, or a location service. Such services could be 

especially valuable when such devices interact with an HTTP-based server (or 

service) that might need some specific information from one or more of the 

services hosted by the device.   



The use case presents a new binding for SOAP to HTTP with primary difference 

from the normal HTTP binding for SOAP is that here a SOAP request is bound to 

a HTTP response and vice versa. Hence the name "Reversed HTTP binding for 

SOAP".



1.	Description of the scenario



The client contacts a HTTP Server and sends a normal HTTP request. This 

initial contact informs the HTTP server that the device is available, and 

could also indicate one or more services the client supports.  



The HTTP server responds with a SOAP request message in the body of the HTTP 

response.  



At some point the client sends a HTTP message to the HTTP server. The body of 

the HTTP request contains a SOAP response message.



The HTTP server responds.  This response could be a SOAP response message, 

HTTP content, or HTTP/1.1 202 Accepted



2.	Can we achieve this use case now with the current specs? 



For SOAP 1.1 over HTTP



No we cannot achieve this using the current binding.



For SOAP 1.2 over HTTP



No we cannot achieve this using the current binding.



3. What is the minimal change that would be necessary to what spec(s) in

    order to achieve this case?



A new (SOAP Reverse HTTP) binding is needed to support this.



For WSDL 1.1 and 2.0



I suspect the answer is also no but further study is needed.





Kind regards,





Michael Eder



====================================

Michael Eder

NRC Boston

5 Wayside Road

Burlington,  MA  01803

Phone:  781 993 3636

Mobile: 617 834 1485

Fax:    781 993 1907