RE: MEP in SOAP1.2

Hi Williams

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 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].
>

HTTP implements just one MEP-request/response. 

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 SOAP 
headers or underlying protocol?

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?

thanks,
regards,
Naresh Agarwal







> -----Original Message-----
> From: Williams, Stuart [mailto:skw@hplb.hpl.hp.com]
> Sent: Monday, July 01, 2002 8:42 PM
> To: Naresh Agarwal
> Cc: xml-dist-app@w3.org
> Subject: RE: MEP in SOAP1.2
> 
> 
> Hi Naresh,
> 
> > -----Original Message-----
> > From: Naresh Agarwal [mailto:nagarwal@in.firstrain.com]
> > Sent: 01 July 2002 14:56
> > To: xml-dist-app@w3.org
> > 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
> context.
> 
> 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
> --
> [1] http://www.w3.org/TR/2002/WD-soap12-part2-20020626/#soapfeatspec
> [2] http://www.w3.org/2000/xp/Group/2/02/emailbinding.html
>

Received on Tuesday, 2 July 2002 10:51:17 UTC