Re: TBTF: A distillation of sorts

> > So, a service provided by HTTP is available from HTTP end-to-end,
> > not SOAP end-to-end. As such, it seems like the processing model
> > would need to know about the underlying protocol's endpoints in
> > order to process these correctly.
> 
> not sure I follow what you're saying here... 

Glen was suggesting that an implementation could make choices about
when to actually serialize the blocks on the wire depending on the
nature of the next-hop transport. One way to express this might be a
modification or special case of the general processing model; it
seems to have implications for the PM, since we have the possibility
of block insertion. The PM is currently modeled around SOAP
communications, not underlying transport communications, so it might
need to be changed to reflect that.


> > In TB call before today's, there was talk of the 'core' services
> > that we need to accommodate in our framework. Correlation is one
> > which we've covered, but endpoint identification *and* routing is
> > also important.
> 
> yes, certainly, it would seem to me that at the very least,
> endpoint identification is common to all transport protocol
> bindings. routing on the other hand is not required by all, only
> those where intermediary SOAP nodes are involved. What isn't clear
> to me is whether the application code "knows" about these SOAP
> intermediaries...

I think we're making two different points - I was trying to say that
just as RPC requires correlation to be portable across transports,
it also requires routing to get the response message back. In HTTP,
this is implicit, because of the nature of the connection and the
MEP, but it would not be across some other transports.

This poses a more serious problem than correlation, which has a
nature that is complementary to the SOAP message path (Correlation is
fairly passive; it's a cookie that's used at the SOAP endpoints.
Endpoint ID and Routing have effects in message handling itself).


> > HTTP provides implicit endpoint identification for the client by
> > virtue of the fact that it's the one that made the request. The
> > routing of the response message is determined by the routing of
> > the request message, in reverse order. Other protocols may not
> > provide this, especially non-transactional or unconnected
> > protocols. For example, SMTP could provide for response endpoint
> > identification through the From: header, but the routing to that
> > endpoint will probably be much different.
> 
> Ahhh, but if a SOAP intermediary node is involved, the implicit
> client identification is lost because the perceived client from the
> perspective of the ultimate recipient of the message is the last
> intermediary, not the originating client...

Again, perhaps. If the SOAP intermediary is co-located with a
lower-layer intermediary (on an SMTP relay, for example), routing on
the message takes place in SMTP, without interference by SOAP.

For example, this is a SOAP intermediary that is a mail destination
as well as sender:
  +---------------------------*
  SOAP1 ----> SOAP2 ----> SOAP3
  +-----------*   +-----------*
  SMTP1 ----> SMTP2 ----> SMTP3

Whereas this is a SOAP intermediary deployed on a SMTP relay:
  +---------------------------*
  SOAP1 ----> SOAP2 ----> SOAP3
  +---------------------------*
  SMTP1 ----> SMTP2 ----> SMTP3

(hmm, perhaps it would be useful to expand these illustrations to
depict other MEPs as well as one-way...)

-- 
Mark Nottingham
http://www.mnot.net/

Received on Thursday, 26 July 2001 20:37:12 UTC