[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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/>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC