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.