David,
No need to appologize.
Chris,
I agree. I would further add to your comments that exploring what exactly
*is* an IM vrs a TP is in order
for moving forward in CPPA TC. Is an IM a specialized TP?, Would an IM be
represented in a
Collaboration?, etc. Clarifying this model is critical to moving forward.
I my mind, it is easier to seperate these issues between
1) Dynamic/Static Config
A CPA file is a static configuration deployed before runtime. Transporting
equiv data in a header
represents a dynamic configuration. [not unlike RPC static stubs/skels vrs
DII].
2) Collaboration knowledge
Binary configuration (static/dynamic) vrs multi-party configuration
(static/dynamic).
I believe that these 4 way options can be accomodated --at least at the
specification level.
Implementation and robust interoperability testing, etc, is another
question.
Dynamic config with Multi-party collaboration knowledge is the most complex
and flexible.
Perhaps this may help moving forward.
Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074
christopher ferris <chris.ferris@east.sun.com>@Sun.COM on 07/31/2001
03:33:34 PM
Sent by: Chris.Ferris@Sun.COM
To: ebXML Msg <ebxml-msg@lists.oasis-open.org>
cc: ebxml-cppa@lists.oasis-open.org
Subject: Re: PIP IDs
David,
I think that everyone is in agreement that the currently specified
CPP/A doesn't address intermediaries. This is certainly unfortunate
but given the resources we had in the original CPP/A project team
(mostly Marty!) and the fact that the CPP/A team had a mere 6 months
as compared to the 18 months that all of the other project teams
had to complete their work, the team made a conscious decision to
defer consideration of intermediaries and multi-party agreements
until "phase 2".
Well, we're now in "phase 2" (woo hoo!). As I wasn't present at the
kick-off for the CPP/A TC, I can't speak as to what the team's plans are
for going forward. I would certainly support any decision to
address intermediaries. Multi-party agreements probably represent
a slightly more complicated undertaking. It isn't clear to
me (yet) whether a processing intermediary such as C1 or Ariba
constitutes part of a multi-party collaboration or something else.
That said, "I feel your pain";-) However, please let's not confuse
any implementation issues that you have as an intermediary provider with
any potential issues associated with "single-hop" MSH processing involving
a CPA.
Cheers,
Chris
"Burdett, David" wrote:
>
> Chris/Scott
>
> It really was not my intention to make "inflamatory" statements. If they
> were, I absolutely apologise.
>
> I also agree that having a configuration file is a good idea and can make
> implementation easier. The problem with current "end-point to end-point"
> CPAs is that they don't work when there is an intermediary. Consider this
> example ...
>
> TP1<------------ CPA 1 ------------>TP2
>
> In this example CPA 1 specifies the entire agreement between TP1 and TP2
and
> there are no problems with a single configuration file (CPA).
>
> However in this example:
>
> TP1<------------ CPA 2 ----------->TP2
> TP1<--- CPA 3 --->IM<--- CPA 4 --->TP2
>
> CPA2 agrees defines how TP1 and TP2 will carry out business in terms of
> business processes and business transactions *only*.
> CPA3 defines how TP1 sends messages to the intermediary (IM) and CPA 4 is
> the equivalent for the IM and TP2. These agreements define the format and
> structure of the messages but not the business process/transactions being
> followed. The value add of the intermediary is that if TP1 and TP2 do use
> different protocols or standards or different versions of documents then
> they translate between the different protocols/versions.
>
> I don't think the current CPA documents easily support this use case.
>
> David
>
<snip/>
------------------------------------------------------------------
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-msg-request@lists.oasis-open.org