[ebxml-iic] [Fwd: Re: deployment template]

[Pete Wenzel <pete@seebeyond.com>]

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>