RE: MEP in SOAP1.2

Hi Naresh,

> -----Original Message-----
> From: Naresh Agarwal []
> Sent: 01 July 2002 14:56
> To:
> Subject: MEP in SOAP1.2
> Hi
> SOAP essentially represents one-way message and hence is stateless.

SOAP 1.2 introduces the concept of message exchange patterns (MEPs). During
the life-time of a message exchange (in accordance with a specified MEP)
there may be transcient state. Whether that state remains accessible in the
long term beyond the completion of a message exchange or not is a
implementation choice (ie. the point when local resources (buffers,control
blocks etc) are reclaimed and all trace that the exchange ever happened is
an implementation choice).

> Now in order to implement various message-exchange patterns 
> in SOAP (request-response, one way request, request-multiple 
> response etc.), sender need to PASS the INFORMATION regarding 
> the type of exchange, whether request-response, one way 
> request, request-multiple response etc to the receiver in some way.  
> As far as i have understood (i may be wrong), SOAP 1.2 says 
> that this can be achieved by using the features provided by 
> an underlying protocol and/or application-specific information.

You might find [1] helpful. It describes some conventions used in the
description of MEPs, features and bindings in Part 2. Simply the idea is
that for each message exchange (that is the instantiation of an MEP - NB. a
message exchange may involve the exchange of more than one SOAP message) a
message exchange context is brought into existence. Various properties are
instantiated in the message exchange context - including a property that
names the MEP to be used for that message exchange. Features 'provided' by
underlying protocols (eg. authentication) are abstracted as a collection of
related properties (eg.username, security token, realm...) which, if used in
the message exchange context, engage the operation of the relevant feature
*provided* that that feature is supported by the underlying protocol and its
binding specification. A feature specification describes the properties
associated with a given feature and their semantics when used in conjunction
with particular MEPs (the operation of some features may be completely
orthogonal to the operation of MEPs, others may not be so). A binding
specification details how the underlying protocol is used to provide the
binding supported MEPs and feature. Not all bindings are expected to support
all features or MEPs.

Bear in mind that this is an abstract model for describing behaviour.
Implementations are not required to directly implement message exchange
contexts and feature properties literally as described in the spec.

> 1)Does application-specific information means that SOAP 
> headers would be used to pass such information? Also does 
> SOAP 1.2 says anything about the syntax and semantics of 
> information passed in SOAP headers?

If the functionality of a given feature is being provided by an underlying
protocol, then the information passed between the SOAP-Node and the binding
would flow (in the abstract) in properties contained in a message exchange

OTOH, for functionality that the SOAP node chooses *not* to delegate to the
underlying protocol, either because the underlying protocol does not support
that feature, or because the SOAP node has chosen to use a SOAP extension
that provides 'equivalent' functionality then the SOAP headers are used in
accordance with the specification of the relevant SOAP extension.

The current documents specify a core framework which provides for the
specification of SOAP extensions, features and bindings in other
specifications yet to be created.

> 2)Features probvided by underlying protocols mean using MEP. 
> If we talk about HTTP, then do we use some HTTP header to 
> pass this information? else how does we pass this information 
> (type of exchange) using HTTP.

Information is exchanged between the local binding and the local SOAP
Node/processor. This is an internal exchange and is 'modelled' using message
exchange contexts, properties and features. 

Information that passes between peer instances of a given binding (HTTP in
this case) express the information within the operation of the underlying
protocol. For example, the reqresp:ImmediateDestination property (which has
a URI value) is transferred as the HTTP request URI in an HTTP request, or
in the  To: field of a email message header in the experimental email
binding at [2].

> Any help would be greatly appreciated!

I hope that this is more help than hinderance :-)

> thanks,
> regards,
> Naresh Agarwal

Best regards

Stuart Williams

Received on Monday, 1 July 2002 11:11:57 UTC