RE: Draft of Requirements for Intermediary Support for discussion.

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

Some comments embedded below.

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



Dale Moberg <dmoberg@cyclonecommerce.com> on 08/02/2001 04:10:15 PM

To:   ebxml-cppa@lists.oasis-open.org
cc:   "Burdett, David" <david.burdett@commerceone.com>
Subject:  RE: Draft of Requirements for Intermediary Support for
      discussion.




           DavidBurdett>
           >> Here is my first cut of the requirements for CPPA  that are
needed to support
           >>   intermediaries. It suggests the development of several
           >> different types of CPA/CPP  ...

Before getting into the details of your  proposed new partitioning of
information,
I am  interested in understanding the need for new  functionality.

Let me start  with an intermediary that serves to
re-send ebXML messages. A  minimalist
intermediary could be represented within  a CPA by the Endpoint elements
within the Transports used by two  participants in a collaboration. In
other  words,
for A to send to B via C, A would look  at the Endpoint URL for B, and find
http://intermediary.net/pathForMsgRouter
while B would find the Endpoint URL for  A, which perhaps is the same,
http://intermediary.net/pathForMsgRouter.

MWS:  If we use this approach, we need some words of explanation in the
spec covering the intermediary case.

In  this case, the URL needed by the intermediary to forward its arriving
messages
would occur nowhere in the CPA of the two  participants. It would be
privately
maintained in the intermediary's "routing table."  This is the current
state
of  "support" for intermediaries, and it is admittedly very meagre and
really
abstracts an intermediary down to the URL Endpoints  it presents to  the
non-intermediary participants.(I recall that the  above is
basically how the POC handled  CPAs
for  scenarios involving  "hubs")

MWS:  The intermediary's routing table could be populated using CPAs
between
individual parties and the intermediary or it could be populated by private
means
defined by the intermediary.  I believe that there have been discussions of
the
CPA option over the past year or so.

Given that the CPA is  to provide some configuration information needed by
MSHes,
one step beyond what  we now have would be to consider how the CPP and
CPAs
could be extended to  support participants using the Via element within
ebXML  messages.
In other words, we  could add something to transport Endpoint notation so
that
the participants would  be able to populate the Via field in their messages
that
they send.

MWS:  Sounds like a good idea.

Beyond this, we could  begin to explicitly represent the intermediary as a
participant,
along with the other  parties. To do so, we first could consider
the representations
within the BPSS for a  BP involving an intermediary. Will the BPSS for
an intermediary be a  multiparty BPSS or will it in fact be the same as for
the
2 party case? In other  words, does the presence of the intermediary make
the BP a different  business process somehow? If so, how? If not, why  not?
Presumably the Request  and Response documents will stay the same. Will
any other aspects of  the message change-- packaging, signals, security
parameters, and so  on? If none of these elements are modified,
is  it then  safe to assume that the presence
of an intermediary  does not make any difference for the BPSS?

MWS:  I believe that the existing BPSS can handle the intermediary case
using
the coupled binary collaboration approach that it uses for multiparty.

I suspect that the  main impact of having an intermediary will be on
the reliable messaging  apparatus, possibly some impact on security
(though this has  possibly been confined and dealt with under the
XPath transforms used  for signing messages), and possibly some
impact on the synch  and asynch modes. Are there other impact
points when an  intermediary is present in the process? These  specifics
need to be inventoried  first, IMO, before we launch off with new flavors
of CPPs and CPAs.

MWS:  Absolutely, we need to start with a detailed requirements analysis
of the intermediary case.

For the most part, it  seems to be that your requirements jump straight
to some proposed  solutions, while I had hoped to have requirements, use
cases,
special situations,  and related information that would help us  understand
the problem better.  Then we can consider potential solutions, and
evaluate
their comparative  strengths. We do now have more time to analyze  whether
to assimilate the  intermediary CPA to be a special case of multiparty,  or
to rather add  intermediaries in through special modifications or
qualifications  under
transport, packaging, synch/asynch, and so  on.