Title: RE: PIP IDs
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.
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.
