Re: T2 Behavior of IM and non IM MSH,was RE: T2 PLEAE READ - Sugges ted solution to RM Issues

[Martin W Sachs <mwsachs@us.ibm.com>]

Dan,

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.

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.

Also, as the Arpanet evolved (into the Internet), everything in the cloud
speaks IP.  There is no free-for-all choosing of unique protocols between
different nodes.

The problem with the CPA is only that it is limited to two parties.
Attempting to fold intermediaries in gets dangerously close to multiparty,
which is far in the future.  Yes, if there were such a thing as a
completely dumb intermediary, one might be able to do a few things but as I
already pointed out, I don't believe that there is such a thing.

Regards,
Marty

Regards,
Marty

*************************************************************************************

Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



Dan Weinreb <dlw@exceloncorp.com> on 09/14/2001 09:43:09 AM

Please respond to Dan Weinreb <dlw@exceloncorp.com>

To:   david.burdett@commerceone.com
cc:   Martin W Sachs/Watson/IBM@IBMUS, chris.ferris@east.sun.com,
      arvola@tibco.com, ebxml-msg@lists.oasis-open.org
Subject:  Re: T2 Behavior of  IM and non IM MSH, was RE: T2 PLEAE READ -
      Sugges   ted solution to RM Issues



   Date: Tue, 11 Sep 2001 21:39:51 -0700
   From: "Burdett, David" <david.burdett@commerceone.com>

   Dan

   You said ...

   >>>It is thus even moreimportant that the spec clearly state its
assumptions
   about the intermediary functions above the level of the MSH including
some
   words about the case where there is a non-ebXML link in the path between
two
   intermediaries.<<<

Just for the record: Marty said that.  I replied to that paragraph saying

   I agree strongly about "clearly state its assumptions".

There seems to be some disagreement as to what the spec is proposing
to describe about intermediaries.

I think that someone reading the current ebXML MS spec, as it is
currently worded, could easily be forgiven for thinking that there is
no such concept as a "non-ebXML link in the path between two
intermediaries".  I don't think the existing spec, as currently
worded, gives the reader any warning that such a thing is being
contemplated.

And here's a question I don't think we've asked before.  Marty said:


   Consider this:

      A----B----C----D

   Clearly, A and D have to communicate end to end via ebXML messaging, CPA
   (virtual or real), and BPSS (virtual or real).

   The problem is that there is nothing requiring that the link between B
and
   C be an ebXML path.  Therefore both of our previous comments that all IM
   nodes must have two MSHs are not correct.

OK, let's say there's nothing requiring that the link between B and C
be an ebXML path.  Is there anything requiring that the link between A
and B be an ebXML path?  Clearly A and D have to communicate using
ebXML, but if B and C are free to do their own thing, why not A and B?
Is there some special rule about hops to which the endspoints are
parties, that makes those hops different from IM-to-IM hops?

This is why I brought up the Arpanet analogy.  If you like (a) the
idea that B and C can use whatever protocol between them that they
want to, and (b) the idea that communication between A and B really
has to be defined by the ebXML MS spec, then I think it would make
things far clearer to portray ebXML as two protocol layers: a higher
layer that talks about how A interacts with D (analogous to Arpanet
host-to-host), and a lower layer that talks about how A interacts with
B (analogous to Arpanet host-to-imp).  Then we can say that the
hop-to-hop communications (analogous to Arpanet imp-to-imp) can be
whatever the hops want them to be: not just B-C hops but even A-B
hops.  We would specify (a) all about the A-D communication, and (b)
what the application on A tells the MSH on A, including such things
as "use B as the first hop, and here are some hop-level parameter
values".

We have said that in the A-B-C-D example, A would have "two CPA's",
one being a CPA between A and B, and the other being a CPA between A
and D.  But think about what's actually in the CPA.  Some of the
information in the CPA is meaningful for the A - D communication, but
entirely meaningless for the A - B communication (e.g. the Process
Specification and Packaging elements), whereas other information in
the CPA is meaningful for A - B but meaningless for A - D (e.g. the
Transport element).

To me this seems like a clear sign that something is wrong.  The CPA
does not seem to be intended for use between two entities (A and B, in
this case) that are only talking to each other about hops, and not
talking to each other about business processes at all.  It would be
clearer and more elegant if an explicit distinction were made between
the two layers, i.e. separating the subject material suitable for the
A - B discourse from the material suitable for the A - D discourse,
both in the MS spec and in the CPA spec.  I realize that we can't do
that as part of a 1.1 release, but maybe it should be considered for 2.0.

-- Dan

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