RE: TBTF: SOAP MEP vs TMEP

Hi Marc,

I find myself regarding the primary purpose of a SOAP protocol binding is to
(faithfully) transfer the infoset of a SOAP Envelope (and its  contents)
between adjacent SOAP nodes along a SOAP message path. 

In addition the binding may also convey the value of various properties
associated with features that the binding supports between adjacent SOAP
nodes in a compliance with the requirements of the relevant feature spec.
and in a manner specified in the binding specification.

As a consequence I find it difficult to usefully conceive a specification
that describes how a SOAP protocol binding provides (implements) what you
call a SOAP MEP (presumably intended to cover multi-hop cases in general)
except for two special cases:

1) The end-2-end message exchange occurs over a single hop on a single
binding.

2) An end-2-end message exchange that occurs over multipe hops using
multiple binding instances conforming to the same binding specification.

I conceived of Transport-MEPs as patterns of exchange of SOAP messages over
a single binding instance between adjacent SOAP nodes. I think these are
exactly what bindings implement.

SOAP Message exchanges have larger scope (in the presense of intermediaries)
and can occur over multiple different protocol bindings.

I think that SOAP-MEPs (as you name them) can be defined by extension of
Transport-MEPs... eg. a SOAP Request-Response MEP over multiple hops arises
by extension of Request-Response Transport-MEP. However, simple extension of
a TMEP is not the only way to provide a semantically equivalent SOAP-MEP.
So, to take your split binding example, a SOAP Request-Response MEP could be
provided by the use of an underlying one-way transport MEP in conjunction
with a request/response corelation module defined for use inconjunction with
a two one-way transport message exchanges.

A way out of this 'fix' may be to regard MEP's as SOAP MEPs (as you describe
them) which include a description of the MEP is relayed through an
intermediary... and to regard the role of a SOAP binding to describe the
operation of that MEP over a single hop between adjacent SOAP nodes.... I
think I almost like this :-) It would leave all the intermediary behaviour
specified as part of the MEP description, and not the binding... which would
focus on the transfer of message infoset and feature properties between
adjacent SOAP nodes.

Maybe I come full circle and contradicted myself... comments?

Stuart

> -----Original Message-----
> From: Marc Hadley [mailto:marc.hadley@sun.com]
> Sent: 29 January 2002 17:55
> To: XML Protocol Discussion
> Subject: TBTF: SOAP MEP vs TMEP
> 
> 
> Following on from our discussion on the TBTF call today I would like to 
> raise a point that I alluded to in a previous message [1]. I think that 
> current text does not draw enough distinction between SOAP message 
> exchange patterns and transport message exchange patterns and as a 
> result is rather confusing.
> 
> In order to address the confusion I would propose that when we refer to 
> MEPs in the specification we refer to SOAP MEPs, i.e. patterns of 
> exchange of SOAP messages rather than underlying protocol exchanges. We 
> would define an open ended set of such MEPs: outbound one-way, inbound 
> one-way, request-response, ... The purpose of a binding specification 
> would be to describe how an underlying protocol is used to support a set 
> of these SOAP MEPs plus any other features desired. Our HTTP binding 
> specification would describe how HTTP is used to provided the SOAP MEPs 
> that we decide we want to support.
> 
> We also need to decide a number of issues including:
> 
> (i) Can a SOAP MEP be split over multiple bindings ? E.g. request 
> response with request via HTTP, response via SMTP.
> (ii) Are SOAP MEPs single hop or multi-hop in nature ?
> 
> and what bearing the answers to these questions have on bindings 
> "supporting" a given MEP.
> 
> Regards,
> Marc.
> 
> [1] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jan/0194.html

Received on Tuesday, 29 January 2002 14:22:53 UTC