Title: RE: PIP IDs
I
may state the obvious here, in which case I apologies.
But,
in my opinion:
if
the intermediary is a "transparent" gateway, i.e. if it is
NOT ACCOUNTABLE
for any problem that may happen
between the parties, then it may be simply
a redirected
URL (in some way, when A wants to talk to B, instead
of
specifying http://ebXML.B.com/port it
could
specify http://ebXML.C.com/port )
From A's
perspective, the intermediary C is almost
invisible, it is a "technical
issue".
if
the intermediary is ACCOUNTABLE for any issue that
may happen during the
execution of the agreement, then
I think it becomes an ACTOR in the
choreography and
should be modelled as such.
I am not sure if it needs
to be included in the BPSS or
if it may simply "mirror" the original CPA
(I mean,
C will play B's role in the CPA with A and it will play
A's
role in the CPA with B).
Does
this make any sense?
/stefano
-----Original Message-----
From: Dale Moberg
[mailto:]
Sent: 02 August 2001
22:10
To:
Cc: Burdett,
David
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.
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.
