W3C home > Mailing lists > Public > www-ws-desc@w3.org > March 2003

SOAP Response pattern and our MEPs

From: Jacek Kopecky <jacek@systinet.com>
Date: 20 Mar 2003 18:35:54 +0100
To: WS-Description WG <www-ws-desc@w3.org>
Message-Id: <1048181752.26384.120.camel@krava.in.idoox.com>

Hi all,

I'm trying here to start fulfilling my action item on relating the SOAP
Response MEP with WSDL MEPs (I think this is what the MEP work has
transformed my action item into.)

"The SOAP Response MEP defines a pattern for the exchange of a non-SOAP
message acting as a request followed by a SOAP message acting as a
response. In the absence of failure in the underlying protocol, this MEP
consists of exactly two messages, only one of which is a SOAP message." 
[http://www.w3.org/TR/soap12-part2/#soapresmep]

So at the first look, this MEP can be used by operations following the
WSDL Request/Response (I think we agreed to add that MEP) pattern.

Let's now look at the primary intended usage of this SOAP MEP - it's an
HTTP GET request with a response containing a SOAP Envelope. From this
point of view, there is only the target URI and the request message as
such is empty. Therefore, in the cases where there are no parameters
marshaled in the URI, the SOAP Response MEP could also be used by
operations following the output-only WSDL MEP.

I suggest that our SOAP binding support mapping request/response
operations onto the SOAP Response MEP (probably using some way of
marshaling the request message into the request URI for HTTP GET -
I think the URI replacement algorithm should fit here); and I also
suggest that our SOAP binding support mapping output-only operations
onto the SOAP Response MEP, thus enriching the current capabilities of
our SOAP binding. 8-)

Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet Corporation
                   http://www.systinet.com/
Received on Thursday, 20 March 2003 12:36:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:23 GMT