RE: TBTF: SOAP MEP vs TMEP

Hi Noah,

I had been hoping that the tail of my message to Mark [1] was pretty much
where we would want to be.

<quote>
A way out of this 'fix' may be to regard MEP's as SOAP MEPs (as you
[Marc]describe
them) which include a description of [how]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.
</quote>

Personnally, I think I would be strongly against trying to distinguish
between "originator-to-intermediary" and "intermediary-to-intermediary" hops
on the basis that there may be an arbitrary number of intermediaries between
message sender and message recipient and the sender generally will not know
whether its talking to an intermediary or not... indeed the intermediary may
not know its an intermediary until its started to match actor URIs against
the set of roles it is capable of playing.

I think I am reconciled to abandon the term TMEP, in part at least because I
think it at least leads you to mis-interpret it, I think. I really have no
wish to expose the gorry detail of what goes on beneath the hood of a
transport in order for a binding to provide given single-hop MEP to adjacent
peer SOAP nodes. Binding-provided MEP might more accurately label the
concept that I have been labelling as TMEP.

The MEP we have described so far expresses the behaviour over a single hop
of a single-request/response message exchange. It sets the expectation that
all can end in failure, but that if successful only one instance of the
request will be received and only one instance of the response. Informally
the MEP (ie with narrative rather than statemachines) describes how the
exchange pattern is relayed across intermediaries - one of the things we
have to address is how we present that more formally - I have some ideas on
that. The description also discusses what happens to faults generated during
a message exchange.

I actually think that we have it pretty much covered... and I think Marc
agrees.

In terms of end-2-end MEPs, I think things are as 'simple as the thread
would indicate' for the case where the hop-by-hop pattern echos the
end-2-end pattern. I think it is less straight forward for the cases where
you want messages for flow in one direction over protocol A and the other
direction over protocol B or some more complex mixture. I think that the
only way that I can reconcile this is that view this as a single hybrid
binding to the set of protocols involved in the exchange, so that the
binding continues to be responsible for that operation of the MEP between
adjacent peer SOAP Nodes.

I think we do have a coherent picture, but I think that the term
Transport-MEP has been conjouring up a different image for you than it has
at least for me... which is indicative of it perhaps not being the right
term. I think that I am now happy to think in terms, solely of SOAP MEPs
where the MEP description details:

- The operation of the MEP in terms of an exchange of SOAP messages 
  (cf. the requester/responder FSMs in the current draft)
		
- How the MEP is relayed across intermediaries.
  (Currently just narrative in the current draft)

- The disposition of faults generated during the operation of the MEP.
  (This is covered for SRR in the current draft... but the detail is
   open to discussion particularly faults due to the response message).

A binding description then has to 'fit' the usage of the underlying protocol
into the FSMs that describe operations of the MEP. However, the binding
description is fundementally single-hop... the required *relaying* behaviour
is decribed in the MEP and feature specifications and not the binding
specifications.

So... does this add clarity or confusion? Mostly I think its elaboration of
the quoted piece from [1].

Regards

Stuart

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2002Jan/0402.html


> -----Original Message-----
> From: Noah Mendelsohn [mailto:noah_mendelsohn@us.ibm.com]
> Sent: 01 February 2002 23:08
> To: skw@hplb.hpl.hp.com
> Cc: 'Marc Hadley'; XML Protocol Discussion
> Subject: RE: TBTF: SOAP MEP vs TMEP
> 
> 
> I don't think it's quite as simple as this thread would indicate.  I think

> that MEP specifications will often be end-to-end.  For example, I want 
> request/response to work through SOAP intermediaries!  I expect such a 
> specification to call out hop-to-hop responsibilities as appropriate.  For

> example, it could discuss "originator-to-intermediary", 
> "intermediary-to-intermediary", etc.  Things like fault delivery, 
> responsibility for duplicate detection and suppression in case of retries,

> etc.  must be discussed in this broader context, I think.
> 
> I would expect binding specifications to conform to one or more of such 
> MEP responsibilities.  Such conformance may or may not reflect the natural

> patterns of the transport, which is why I don't much like the term 
> "transport MEP".  For example, I should be able to do a UDP binding that 
> participates as, for example, the first hop of a multi-hop SOAP 
> request/response.  Request/response is certainly not a "transport" MEP for

> UDP, which is inherently one-way.
> 
> Does this make sense?  Thanks.
> 
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
> 
> 
> 
> 
> 
> 
> 
> "Williams, Stuart" <skw@hplb.hpl.hp.com>
> Sent by: xml-dist-app-request@w3.org
> 01/30/2002 07:22 AM
> 
>  
>         To:     "'Marc Hadley'" <marc.hadley@sun.com>
>         cc:     XML Protocol Discussion <xml-dist-app@w3.org>
>         Subject:        RE: TBTF: SOAP MEP vs TMEP
> 
> 
> Hi Marc,
> 
> > I think that maybe we just agreed all along :-)
> >
> > Marc.
> 
> yep... probably loud agreement ;-)
> 
> Stuart
> 
> 
>

Received on Friday, 1 February 2002 19:38:18 UTC