Re: TBTF: A distillation of sorts

Hi Mark!

Comments inline:

----- Original Message -----
From: "Mark Nottingham" <mnot@mnot.net>
To: "Glen Daniels" <gdaniels@macromedia.com>
Cc: "XML Distributed Applications List" <xml-dist-app@w3.org>
Sent: Thursday, July 26, 2001 6:11 PM
Subject: Re: TBTF: A distillation of sorts


> Glen,
>
> This looks good. Some initial thoughts;
>
> I'm primarily interested in the intermediary scenerios (of course).
> It may be helpful to think in terms of the SOAP endpoints vs. the
> underlying protocol endpoints; for example,
>
>   +------------------------------*  <--- SOAP transaction between
endpoints
        (^^ this layer might be "application transaction between endpoints")

>   SOAP1 ----------> SOAP2 -> SOAP3  <--- SOAP nodes and hops
>   +-----------------*   +--------*  <--- HTTP transactions and endpoints
>   HTTP1 -> HTTP2 -> HTTP3 -> HTTP4  <--- HTTP nodes and hops
>
> Some endpoints (*) might have a URI associated with them. The SOAP
> endpoints always correlate to corresponding underlying endpoints,
> which is nice, but the SOAP hops and the underlying hops and/or
> transactions aren't, neccessarily.
>
> 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.

I'm not sure about this.  My intuition here is to say that an underlying
protocol provides hop-to-hop transport from SOAP node to SOAP node, and
anything else it does under the covers is its business.  So the HTTP binding
contract about, for instance, the correlation ID, would be from SOAP1 to
SOAP2 without regard for the fact that HTTP2 is involved.

Some notion of the "transport path" is probably needed though, since you
really do want to know if you're sending a message through a multi-hop path
that involves other protocols/bindings - it may influence the decisions
which are made about how/what to serialize across each hop.  This gets
pretty hairy, I think, but I'd love to attack it with a whiteboard for an
hour or so to see how it might work.

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

Agreed that they're important, but I wonder if we really need to tackle them
fully now.  Again, it would certainly be worth playing with some scenarios
and diagrams to see how thick things get.

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

The fact that we can pretty easily imagine extensions (i.e. SOAP-RP) that
can help with this is heartenting, I think.  So the question (as per usual)
comes down to "how much of this do we want to tackle in our work".  For
instance, it seems to me that if we want to handle RPC across essentially
asynchronous protocols like SMTP, we need to handle some kind of
correlation.  I don't yet have a solid sense if we need to handle generic
endpoint mapping / routing.

> These problems only insert themselves when you use intermediaries
> (either SOAP or some kinds of transport intermediaries). Correlation
> is somewhat straightforward; it would probably be good to think about
> how this model would work with other things like routing, endpoint
> identification, security, etc.

+1.  I'm offline Friday, but will try and do some more thinking on this over
the weekend.  Thanks for the comments!

--Glen

Received on Friday, 27 July 2001 07:58:18 UTC