RE: Layering, to allow alternative protocols between particular h ops

["Burdett, David" <david.burdett@commerceone.com>]

Dan

You make a good argument for a two layer approach to ebxml (hop-to-hop and
end-to-end) and a clearly defined interface between them. However, I think
this is a version 2.0 rather than a 1.1 issue.

David

-----Original Message-----
From: Dan Weinreb [mailto:dlw@exceloncorp.com]
Sent: Saturday, September 15, 2001 1:23 AM
To: mwsachs@us.ibm.com
Cc: ebxml-msg@lists.oasis-open.org
Subject: Layering, to allow alternative protocols between particular
hops


   Date: Fri, 14 Sep 2001 10:19:28 -0400
   From: "Martin W Sachs" <mwsachs@us.ibm.com>

Let me address your points in a different order than the order in which
you presented them.

   Also, as the Arpanet evolved (into the Internet), 

OK, I promise, no more Arpanet.  From now on I'll use Internet analogies.

						     everything in the cloud
   speaks IP.  There is no free-for-all choosing of unique protocols between
   different nodes.

Sure there is: you have to keep in mind the layers of the protocol
stack.  A TCP implementation is a software module running at layer 4
(ISO OSI terminology).  It runs the TCP algorithms and finally calls
into layer 3.  The layer-4-to-layer-3 API specifies that layer 4
passes an Internet Protocol packet, which specifies a destination in
the form of a 32-bit Internet address, and layer 3 promises to make an
effort to deliver the packet.  The software module running at layer 3
now has, precisely, a free-for-all choosing of unique protocols at
layer 2.  It might decide, for example, to use Ethernet, or it might
decide to use token ring.

Now, there seems to be lack of universal agreement about whether we're
trying to put together the kind of architecture in which there can be
an A-B-C-D link in which B talks to C using some protocol that we
didn't define.  I think the mail of the last few days shows that some
people think this is within our charter and some have not thought of
it as being in our charter.  Somewhere along the line, I would think
that a decision has to be made about this.  For purposes of exploring
the former alternative I will assume that this is what we're trying to
do.

If we're trying to do this, I think it's cleanest to adopt a layered
approach analogous to the Internet example.  In this analogy,
hop-to-hop communication is analogous to ISO layer 2.  Each hop-to-hop
link can make its own choice about whether to use one or another layer
2 protocol.  And note that there would be nothing special about the
*first* hop!

   Re:  "Is there some special rule about hops to which the endspoints are
   parties, that makes those hops different from IM-to-IM hops?"

   Of course, there is such a rule.  If A and D want to communicate via
ebXML,
   each one has to be using an ebXML interface (MSH) and therefore both A
and
   D have to use ebXML to get to their adjacent intermediaries.

I've tried, above, to explain why I think that in a clean
architecture, if B and C are allowed to pick an appropriate protocol,
then A and B should be treated exactly the same way.

If B and C can pick their own protocol, then we need to split the
concept of "protocol" as we've been using it into two layers.  The
higher layer is the "protocol" by which A talks to D (analogous to
layer 3, the Internet Protocol).  The lower level are the protocols by
which A talks to B or B talks to C (analogous to layer 2, which ISO
calls the Data Link layer).

Having done that, we clearly want to define the higher layer.  It's
also completely clear that we want to define the official API between
the higher layer and the lower layer.  Do we want to specify any
particular lower layer protocol?  You (Marty) said earlier that B
should be allowed to talk to C however it wants to, including using
protocols that were not defined by the ebXML MS group.  So, B and C
have a menu of alternatives, some of which are not from us.  Do we
want to provide one of those alternatives, or do we want to consider
that to not be in our charter and say that *all* of them are not from
us?  I suspect the former, but as I mentioned earlier, there doesn't
seem to be unanimity about our charter here.

   Re: "far clearer to portray ebXML as two protocol layers".  We have that
   right now, one is defined by the MS spec and the other is defined by the
   BPSS spec.  I don't think that there is much inside the MSH that can be
   split into to layers that may be in different boxes.

By my reckoning, the BPSS spec is more like layer 4.  If you want to
count the BPSS as a layer, then I'm saying that we need to have
*three* layers instead of two, if we want a clean implementation that
lets B and C pick their own protocol.

One of the main reasons for using layering in protocol designs is to
control sharing: what is common and what is not common.  On the
Internet, we all do TCP and IP in common, but we can pick and choose
among Ethernet, token ring, and whatever Data Link implementations are
being used over the backbone fibre nets these days.  In your model of
multi-top ebXML, we all adopt a common concept of how A and D talk to
each other, and yet we are free to allow B and C to pick their own way
to talk to each other.

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>