Deployment Profile Template
v1.1
For OASIS ebXML Collaboration-Protocol Profile and Agreement (CPP/A) 2.0 Standard
Public Review Draft 01, 04
December 2006
Artifact identifier:
ebXML_DPT-v1.1-ebCPPA2-template-pr-01
Location:
http://www.oasis-open.org/committees/documents.php?wg_abbrev=ebxml-iic
Artifact Type:
template
Technical Committee:
OASIS ebXML Implementation, Interoperability and Conformance (IIC) TC
Chair:
Jacques Durand, Fujitsu <jdurand@us.fujitsu.com>
Editors:
Jacques Durand, Fujitsu <jdurand@us.fujitsu.com>
Pete Wenzel, Sun Microsystems <pete.wenzel@sun.com>
Contributors:
Sacha Schlegel, Cyclone Commerce <sschlegel@cyclonecommerce.com>
Monica Martin, Sun Microsystems <Monica.Martin@sun.com>
Brian Hayes, Commerce One <brian.hayes@commerceone.com>
Abstract:
(Refer to Section 1.1, Purpose.)
Status:
This document was last revised or approved by the OASIS ebXML IIC TC on the above date. The level of approval is also listed above. Check the current location noted above for possible later revisions of this document. This document is updated periodically on no particular schedule.
Technical Committee members should send comments on this specification to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the “Send A Comment” button on the Technical Committee’s web page at http://www.oasis-open.org/committees/ebxml-iic.
For information on whether any patents have
been disclosed that may be essential to implementing this specification, and
any offers of patent licensing terms, please refer to the Intellectual Property
Rights section of the Technical Committee web page (http://www.oasis-open.org/committees/ebxml-iic/ipr.php).
Notices
OASIS takes no position regarding the validity or scope of
any intellectual property or other rights that might be claimed to pertain to
the implementation or use of the technology described in this document or the
extent to which any license under such rights might or might not be available;
neither does it represent that it has made any effort to identify any such
rights. Information on OASIS's procedures with respect to rights in OASIS
specifications can be found at the OASIS website. Copies of claims of rights
made available for publication and any assurances of licenses to be made
available, or the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers or users of
this specification, can be obtained from the OASIS Executive Director.
OASIS invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other proprietary rights
which may cover technology that may be required to implement this
specification. Please address the information to the OASIS Executive Director.
Copyright © OASIS Open 2005. All Rights Reserved.
This document and translations of it may be copied and
furnished to others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, provided
that the above copyright notice and this paragraph are included on all such
copies and derivative works. However, this document itself may not be modified
in any way, such as by removing the copyright notice or references to OASIS,
except as needed for the purpose of developing OASIS specifications, in which
case the procedures for copyrights defined in the OASIS Intellectual Property
Rights document must be followed, or as required to translate it into languages
other than English.
The limited permissions granted above are perpetual and will
not be revoked by OASIS or its successors or assigns.
This document and the information contained herein is
provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Table of Contents
1.3
How to Use the Deployment Profile Template
2 Profiling the Modules of CPPA 2.0
3 Profile Requirements Details
3.2
Defining the CPA Profile Meta-Data
3.2.2
Profile Requirement Item: [name of CPA element / attribute]
3.3.2
Profile Requirement Item: [name of CPA element / attribute]
3.4
Profiling the Collaboration Roles
3.4.2
Profile Requirement Item: [name of CPA element / attribute]
3.4.3
Profile Requirement Item: [name of CPA element / attribute]
3.5
Profiling the Delivery Channels
3.5.2
Profile Requirement Item: [name of CPA element / attribute]
3.6
Profiling the Document Exchanges
3.6.2
Profile Requirement Item: tp:ReceiverDigitalEnvelope /tp:EncryptionAlgorithm
3.6.3
Profile Requirement Item: tp:ReceiverNonRepudiation /tp:SignatureAlgorithm
3.6.4
Profile Requirement Item: [name of CPA element / attribute]
3.7
Profiling the Transport Protocol
3.7.2
Profile Requirement Item: [name of CPA element / attribute]
4.1
Management Authority for CPPs and CPAs.
4.2
Deployment and Processing requirements for CPPs
4.3
Deployment and Processing requirements for CPAs
4.4
CPA Interpretation Options
4.6
Additional Agreement Aspects beyond CPPA Specification
4.7
Additional Deployment or Operational Requirements
1.1 Purpose
The ebXML CPPA 2.0 [ebCPPA] contains several configurable features and options. Any use of CPPA requires a certain amount of standardization within a trading community. In order to foster interoperability on multiple levels between participants, these communities will want to (1) document additional conventions on CPPA elements format and content, (2) define CPP or CPA templates that may be partially filled-in, and that represent an agreement baseline in the user community.
This Deployment Profile Template for CPPA 2.0 is intended to
be filled or instantiated by one or more user communities. Once instantiated
and optionally extended with material that is specific to this community, it becomes
a Deployment Profile, or Guide. It is
the intention of the OASIS ebXML IIC Technical Committee to collect and archive
examples of Deployment Profiles created from this Template, as an aid to user
communities whose standardization efforts involve the creation of ebXML CPPA
documents.
Business partners may define CPP that represent their capabilities and
roles they can assume. Another approach is for a business party to directly
start by defining a CPA profile that this party will pre-fill with its own data,
and that it will communicate to its partners for them to complete. The
partially created CPA (or CPA profile) will narrow the options that a CPP would
offer, down to a very specific way under which this party wishes to
interoperate. This is the approach suggested here.
A party may define a few of such CPA profiles that express different modes
of connectivity, different roles and collaborations and different QoS
attributes. The reason for doing so is that its business partners may have
different profiles (e.g. large business, small business, etc.).
1.2 Terminology
The keywords must, must not, required, shall, shall not, should, should not, recommended, may, and optional in this document are to be interpreted as described in [RFC2119].
Source Specification: The specification or standard that is being profiled.
Deployment Profile Template:
Document that lists the options in the source specification that may be
selected by a user community, that identifies content elements (e.g. message
headers, XML values) the format and/or value of which may be further
standardized by a community, and that also identifies typical operating
conditions under which the source specification may be used, and selected by a
user community.
User Community: A group of users, e.g. within a supply-chain industry, the members of which decide to make a similar usage of the source specification in order to be able to interoperate.
Deployment Profile (or
Deplyment Guide): Document that is an instance of the Deployment Profile
Template. It defines which options should / should not be used by this
community, which format or value some content elements should comply with, and
under which operating conditions the standard must be used by this community.
1.3 How to Use the Deployment Profile Template
There are three parts in the Deployment Profile Template that need to
be instantiated in order to generate a Deployment Profile:
- The
section on the source specification modules (see section 2 below)
- The
section on the profiling requirement details (see section 3 below)
- The section on operating conditions associated with the profile (see section 4 below)
Every feature from the source specification that is candidate for profiling is listed in a profiling table. Each profiling table corresponds to a functional subset of a CPA. In case a CPA element requires a detailed profiling recommendation, this will be specified in another table called a “profile requirement item” table, which is of the form:
|
Specification Feature |
<Description of the source
specification item to be profiled. This is pre-filled in the Deployment
Profile Template.> |
|
Specification Reference |
<Identifies the item in the source
specification. This is pre-filled in the Deployment Profile Template > |
|
Profiling |
<how the item is profiled: option
narrowing/selection, content formatting, |
|
Alignment |
<dependency / alignment with other
data, e.g. binding, either with other |
|
Test References |