W3C home > Mailing lists > Public > xml-dist-app@w3.org > July 2002

RE: MEP in SOAP1.2

From: Williams, Stuart <skw@hplb.hpl.hp.com>
Date: Tue, 2 Jul 2002 16:24:41 +0100
Message-ID: <5E13A1874524D411A876006008CD059F04A06EED@0-mail-1.hpl.hp.com>
To: "'Naresh Agarwal'" <nagarwal@in.firstrain.com>
Cc: xml-dist-app@w3.org

Hi Naresh,

> -----Original Message-----
> From: Naresh Agarwal [mailto:nagarwal@in.firstrain.com]
> Sent: 02 July 2002 16:08
> To: Williams, Stuart
> Cc: xml-dist-app@w3.org
> Subject: RE: MEP in SOAP1.2
> Hi Williams

Actually it's Stuart... our dumb site mailer insists on encanting our names
backward :-(

> thanks for the reply.
> > Information is exchanged between the local binding and the local SOAP
> > Node/processor. This is an internal exchange and is 'modelled' using
> > exchange contexts, properties and features. 
> > 
> > Information that passes between peer instances of a given binding (HTTP
> > this case) express the information within the operation of the
> > protocol. For example, the reqresp:ImmediateDestination property (which
> > a URI value) is transferred as the HTTP request URI in an HTTP request,
> > in the  To: field of a email message header in the experimental email
> > binding at [2].
> >
> HTTP implements just one MEP-request/response. 

No... the HTTP binding described in SOAP 1.2 Part 2 supports two MEPs [1]:

1) The Request-Response MEP [2] exchanges two SOAP messages, one in each
direction between a requesting/initiating SOAP node and a responding SOAP

2) The SOAP-Response MEP [3] where the initiating node solicits (in binding
specific manner) the exchange of a single SOAP message from responding SOAP
node to initiating SOAP node. 

> If we take some protocol, which may implement more than one MEP, then the
> reciever need to identify the MEP, that the sender might have initiated. 
> In such a scenerio, we need to have the *type of MEP* (request/response, 
> one way message, request/n-response etc.) in the *message* 
> (SOAP envelope + underlying protocol specific data) so that 
> receiver is able to identify the type of MEP and can act accordingly.
> What is preferred mechanism of sending the MEP information - either use
> headers or underlying protocol?

Yes... the binding needs to provide a means by which a SOAP node receiving a
SOAP message can determine which MEP is in operation.

In the case if the HTTP binding described in part 2, the HTTP request method
can be used to discriminate MEP in use in nearly all cases (unfortnately,
not all cases :-(). I have raised a couple of comments related to this [4].

> Also does the SOAP1.2 specs covers the syntax and semantics of this
*information*, if
> at all it is transferred or it is implementation dependent?

The short answer is 'yes' the SOAP 1.2 spec does cover the syntax of this
information in the particular case of the MEPs and features supported by the
HTTP binding contained there in. The semantics are/or should be covered in
the relevant feature/MEP descriptions. 

Other binding specifications (TBD) SHOULD even MUST specify means for
communicating the "this *information*" between peer binding instances.

A longer answer is that the general expectation is that a Feature
Description will described an abstract set of properties (name, value space
and semantics) and the semantics of the feature when used inconjunction with
other features (typically MEPs). Some features may be completely orthogonal,
others may interact with another.

A binding specification declares support for some set of features (inc.
MEPs) and describes how to make use of the underlying protocol being bound
to honor the semantics of the supported features (inc. MEPs) as specified in
the relevant feature and MEP descriptions.

> thanks,
> regards,
> Naresh Agarwal

Again, I hope this is proving helpful.

Best regards

Stuart Williams
[1] http://www.w3.org/TR/2002/WD-soap12-part2-20020626/#http-suptransmep
[2] http://www.w3.org/TR/2002/WD-soap12-part2-20020626/#singlereqrespmep
[3] http://www.w3.org/TR/2002/WD-soap12-part2-20020626/#soapresmep
[4] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jul/0000.html
Received on Tuesday, 2 July 2002 11:26:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:20 UTC