Deployment Profile Template
v1.1
For OASIS ebXML Business Process Specification Schema v2.0.X
Public Review Draft 01, 04
December 2006
Artifact identifier:
ebXML_DPT-v1.1-ebBP20x-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>
Editor:
Monica Martin, Sun Microsystems <monica.martin@sun.com>
Contributors:
Stephen Green, Individual Member <stephengreenubl@gmail.com>
Dale Moberg, Axway Software <dmoberg@us.axway.com>
Sacha Schlegel, Cyclone Commerce <sschlegel@cyclonecommerce.com>
Pete Wenzel, Sun Microsystems <pete.wenzel@sun.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 2006. 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 ebBP 2.0.x
3 Profile
Requirements Details
3.2 Defining a Business Transaction
Profile
3.2.1 Process Diagram of the
Business Transaction
3.2.2 Properties and Parameters of
the Business Transaction Pattern
3.2.3 Customization of the Business
Transaction Pattern
3.2.4 Common Characteristics for a
Business Transaction Pattern
3.2.5 Composing Complex Business
Collaboration Activities
3.3 Defining a Standard or
User-Defined Business Signal
3.3.1 Business Signal General
Profile
3.3.2 Common Characteristics for a
Business Signals
3.4 Defining the Business Document
Profiles
3.4.1 Profiling Table for Business
Documents
3.4.2 Profiling Table for
Attachments.
3.4.3 Common Characteristics for
Business Documents
3.5 Defining a Business
Collaboration Profile
3.5.1 Process Diagram of the
Business Collaboration
3.5.2 Properties and Parameters of
the Business Collaboration
3.5.3 Composing Complex Business
Collaboration Activities
3.5.4 Common Characteristics for
Business Collaboration
4.2 Deployment and Processing
Requirements for Business Documents
4.3 Deployment and Processing
Requirements for Business Transactions and/or Collaborations
4.4 Additional Aspects beyond
Business Transaction Specification
4.5 Additional Deployment or
Operational Requirements
1.1 Purpose
The ebXML ebBP 2.0 [ebBP2] contains several configurable features and options. Any use of ebBP 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 ebBP process definitions and business content, and (2) define ebBP templates that may be partially filled-in, from which the user community can (or should) derive complete definitions. This profile template includes an initial set of modules to provide the capability to support these goals. More experience is being sought by relevant user communities and domains to continue to expand this profile template.
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. Note, section references may exist in this document that are not for a source specification (such as to another section in this document). These are clearly differentiated.
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 Deployment 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 conform to, 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 |
<references to related test
requirements or test cases, that would verify |
|
Notes |
<Profile-specific comments. This is left for a Deployment Profile to fill in.> |
When no recommendation is made for a profile requirement
item of the template, one of the following values MUST be used in the
“profiling” and “alignment” fields of
the table:
Not Applicable: for items that are not relevant to
the community.
No Recommendation: will indicate that there is no recommendation
or requirement for this feature item.
Pending: for items that are still under study for a recommendation, and for which some recommendation is likely to be specified in future versions of the Deployment Profile (yet, the user community did not want to wait for these to be specified before publishing a current version of the Profile or Guide.)
For items that specify text values, it should also be noted
whether or not the values are case-sensitive.
Two classes of users would be expected to collaborate in the instantiation of this Template to produce a Deployment Guide (or Profile):
Business Process Designers would detail the business-process specific requirements of the Message Service.
Technical Architects in user communities or vertical industries would make the technical decisions necessary to implement the business processes most effectively.
Consumers of a Deployment Guide include:
Business process implementers (IT departments), to deploy a Message Service solution according to the requirements of specific trading communities.
Software solution vendors, to identify all areas in which business process specification bodies require software flexibility, and what specific configurations are necessary to support such standards.
In this section, users will only specify which modules of the source specification are used in this profile (i.e. modules that business partners need to use or support in order to conform to the profile and communicate with others who do conform). For each used module, users also specify whether the module has been profiled or not. If yes, some profiling details should be given for this module in section 3 or 4. It is important and relevant to the development of all of these modules to reference and use the Business Transaction pattern matrices and well-formedness rules that exist in the technical specification. The pattern matrices provide guidance on the operational semantics surrounding the patterns. The well-formedness rules also further ensure consistency in the development of ebBP process definitions.
2.1 Modules
|
Module Name and Reference |
Business Transactions |
|
Profiling Status |