Re: Seeking clarification about the use of the HTTP binding

Mark Baker:

>> I don't know how the MEP model would deal with this, 
>> but I'm not a big fan of it anyhow, so I'll let WSD 
>> worry about that. 8-)

Well, I'm afraid I bear some of the blame if not the credit for the MEP 
model.  Without defending or critiquing it, I think the way it would deal 
with this is:  define an MEP that has some optionality in where the 
messages go.  So, you could define an MEP that is along the lines of:

One Way or Request Response MEP

* An outbound SOAP message is mandatory
* A binding implementing the MEP is responsible for either carrying a 
response SOAP message or indicating that none is being sent.
* Whatever rules for fault delivery invarious places.

The HTTP binding of the MEP would either send a 200 and a SOAP response, 
or a 202 and no SOAP response.  Other transports could easily match that, 
and many applications would not need to know which transport was being 
used.

Another way to deal with this would be an MEP designed pretty much only 
for HTTP:

* An outbound SOAP message addressed to a URI and carrying pretty much any 
HTTP headers, a method selection (GET/POST, etc)  or other HTTP parameters 
that you care to allow. 
* A response carrying any information legal in a response, indicating 
situations in which a SOAP message is carried.

Of course, you wouldn't invent MEP's unless you wanted a degree of 
transport independence.  The HTTP MEP above is just to show that it can be 
done if you want to really integrate HTTP into SOAP.  I think the MEP 
could be spec'd quite easily by pointing to the HTTP RFC and listing the 
information from it carried in each direction.

I think we do want transport-independent MEPs.  IBM, for example, finds 
value in sending SOAP messages over WebSphere MQ (the artist formerly 
known as MQSeries.)  I think that, with care, we could have a 
Request/Response that took a first hop over HTTP, was relayed through 
someone's internal network using WebSphere MQ to an application which 
generates a response, and sends it back over the reverse path.   The 
WebMethod SOAP feature even gives an organized way for conveying 
GET/PUT/POST through the MQ hop, should you chose to do so (not sure 
whether our binding supports it, but in principle we could.)  I think 
that's all a quite sensible sue of HTTP, quite appropriately exposing a 
Web resource to the Internet using HTTP.

Noah

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------