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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

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

Subject: Re: PIP IDs


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.



"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

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

Powered by eList eXpress LLC