OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: Draft of Requirements for Intermediary Support for discussion.

Title: RE: PIP IDs
          >> 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
while B would find the Endpoint URL for A, which perhaps is the same,
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")
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.
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?
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.
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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC