[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: PIP IDs
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC