[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [ebxml-iic] [Fwd: Re: deployment template]
Following is my correspondence with Doug Bunting regarding the Deployment Template. A few of his comments were echoed by Matthew MacKenzie last week and addressed in the current ("for vote") version, while others deserve consideration for future work on the Template. If anyone wishes to discuss these points, please CC Doug, as he does not subscribe to the IIC list. --Pete -------- Original Message -------- Subject: Re: deployment template Date: Fri, 21 Feb 2003 16:14:38 -0800 From: Pete Wenzel <pete@seebeyond.com> To: Doug Bunting <Doug.Bunting@Sun.COM> CC: Jacques Durand <JDurand@fsw.fujitsu.com>, "'Bikeev@ean-int.org'" <Bikeev@ean-int.org>, Monica Martin <Monica.Martin@Sun.COM>, Steve Yung <Steven.Yung@Sun.COM>, Keith Babo <Keith.Babo@Sun.COM> Thus spoke Doug Bunting (Doug.Bunting@Sun.COM) on Fri, Feb 21, 2003 at 02:28:13PM -0800: > Pete, > > My apologies for not getting back to you sooner. > > My concerns are relatively general and pervasive for the > specification. I doubt you'll be able to do more than note the > concerns in your current round of edits, which may be fine. > > My concerns: > The Template document and any Deployment Guide instance have clear > overlap with information provided in a CPA document. Since any CPA > instance may be presented in a human readable fashion for users and > also provides machine readable interoperability, why would this > information be duplicated in a Deployment Guide? Ah, good question. A trading community may wish to place constraints on the contents of CPAs, to meet various specific business requirements or to increase the likelihood of interoperability. These filter down to become actual Messaging requirements. So really a Deployment Guide is not only a specification of ebMS requirements, but also of CPA reqs. I have noted the CPA overlaps explicitly, as suggested by Jacques, but have not actually gone through the CPP/A spec to make sure it is covered in its entirety. If I go this extra step, I would rename the document "Message Service and CPP/A Deployment Guide Template". In addition, I was adhering to the concept of specification independence, so the Deployment Guide would be complete either with or without CPP/A usage. > The EAN*UCC Deployment Guide example may indicate over > specification in the Template. All of the "no recommendation made" > items might not need to be in the Template if this becomes a trend. Probably true in many cases, but for now I wanted to identify optional areas completely, before eliminating any possibilities. This deserves some analysis that will come with experience, as a few orgs use it and determine what is and is not useful. > The Template document includes a number of low level policy items > many companies will never describe for external parties. For > example, my policy for ignoring requests (even those containing > errors, as mentioned in 4.2.4.2) is not something I'd tell even my > most trusted trading partners. The question is how to authenticate > a request as coming from one of those known trading partners, not how > (or if) I'd reject something else. > > The Template document requests disclosure of low level technical > details that have no effect upon interoperability between systems. It > doesn't matter, for example, how Content-id (2.1.2), Content-type > (2.1.3.1), CPAId (3.1.2), ConversationId (3.1.3), Service (3.1.4) or > Error reporting URI (4.2.4.2) values are constructed on one side as > long as they meet the general uniqueness (and other) requirements of > the relevant specifications and are recognized or retrievable (for > CPAId and Service) on the other side. I'd remove most of the > "constructed" / formatting questions from the Template. Let me think about these two for a bit, to make sure a community wouldn't want to standardize such policies and values for some reason. > Generally, the Template may indicate a set of requirements not > presently met in the CPP/A specification or some historical tenacity, > dragging Implementation Guides and Deployment Guides (as separate > human readable documents) along into ebXML. I hope the former and > suspect this document could easily become a Requirements document for > future CPP/A specifications. Yes, options that have been identified and which cannot be captured by the current CPA should be fed into the CPP/A 3.0 process. But I still think there is room for a Deployment Guide that places community- specified restrictions on the contents of a CPA. Too much optionality and too many arbitrary choices having to be made by each user is, in general, not a good thing. Thanks much for your thoughtful comments. --Pete Pete Wenzel <pete@seebeyond.com> SeeBeyond Standards & Product Strategy +1-626-471-6311 (US-Pacific) ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]