[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: CPA and overrides
We need to curtail this discussion in an attempt to move towards closure. The combined questions we should answer: * Do we need to be more general in our description of the CPAId and the CPA parameters discussed in the Reliable Messaging chapter? This would loosen our ties to a specific CPA format and move things to more explicitly encapsulate Chris' suggestion that a CPA is simply a configuration file stored by a MSH in whatever format is appropriate. (A ebXML CPA document is one way that configuration file could be negotiated and transported between MSH instances.) * Should we explicitly copy some of the configuration information from our (conceptual) CPA into the header of a TRP-compliant message? This is both a performance issue (avoiding lookups) and a security issue (allowing the sender to drive intermediaries and destination systems without prior agreement). I agree with the general sentiment that a negotiated agreement should not be overridden on a per document basis. My primary concern is around agreements that provide certain per message options to the sender. I'd rather have parameters often left up to the sender (a set that's unclear at this point) explicitly in the header. At the least, a specific set of parameters must be identified by the header. * Should the CPAId be optional in the message header? Alternatively, do we need to define a predetermined set of parameters identified by specific CPAId values? * Is the CPA's implicit binding of business process information and technical details appropriate for all uses within the MSH? Dave's issue about adding something like a CPAId to a "next actor" set of fields in the header goes right to this point. The next actor may be implementing a technical service that's somewhat orthogonal to the business process enabled by that service. Nonetheless, any intermediary is going to have a business relationship (even if it is a default, one time implicit agreement) with their immediate neighbours on the chain. thanx, doug -----Original Message----- From: Martin W Sachs [mailto:mwsachs@us.ibm.com] Sent: February 23, 2001 09:54 To: maw2@daimlerchrysler.com Cc: ebxml-transport@lists.ebxml.org Subject: Re: CPA and overrides Martha, First, whether you use the CPA or not (or it is optional) is entirely up to the middleware that you buy to support your system. Second, the override element is already optional. Regards, Marty **************************************************************************** ********* Martin W. Sachs IBM T. J. Watson Research Center P. O. B. 704 Yorktown Hts, NY 10598 914-784-7287; IBM tie line 863-7287 Notes address: Martin W Sachs/Watson/IBM Internet address: mwsachs @ us.ibm.com **************************************************************************** ********* maw2@daimlerchrysler.com on 02/23/2001 07:31:10 AM To: ebxml-transport@lists.ebxml.org cc: Subject: CPA and overrides Hi... Just wanted to comment on the conversation in yesterday's conference call relative to overriding the CPA. In the automotive industry, more companies *do not* engage in trading partner agreements than do. So with that, AIAG would like to see: 1. Optional link to the CPA. We would like to have the *option* to link to/use a CPA, but we would rather it not be mandatory. 2. Optional override of the CPA. Thanks, Martha ------------------------------------------------------------------ To unsubscribe from this elist send a message with the single word "unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org ------------------------------------------------------------------ To unsubscribe from this elist send a message with the single word "unsubscribe" in the body to: ebxml-transport-request@lists.ebxml.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC