[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: ebBP 11/14/2005: Conformance and Loose Coupling
In Tuesday's call, we discussed whether or not to re-evaluate the
parameters around language on ebXML conformance (broader than ebBP).
I've taken the relevant language from the working specification and
proposed text based on the conceptual agreement we reached in a quorate
vote 8 November 2005. I will also take this question to the ebxml-jc as
requested. I would also ask if we prefer any other conformance
verbiage, or normative or non-normative language (See final note in this
email).
Section 2.3:
Change from: The ebBP technical specification SHOULD be used wherever
ebXML conformant software components are being specified to execute
Business Collaborations. This specification MAY be used when several
conformant software components are composed and are being specified to
execute Business Collaborations, such as the use of web services mapped
to business transactions.
The ebBP technical specification is used to specify the business process
related configuration parameters for configuring a BSI to execute and
monitor these collaborations.
This section discusses:
* How the ebBP technical specification fits in with other ebXML
specifications and may be used with other emerging technologies
(such as WSDL) An ebBP process definition does not preclude
composition with other process related technologies.
* How to use the ebBP artifacts at design time, either for
specifying brand new collaborations and transactions, or for
re-using existing ones.
* How to specify core transaction semantics and parameters needed
for a Collaboration-Protocol Profile (CPP) or Collaboration
Protocol Agreement (CPA).
* Run-time transaction and collaboration semantics that the ebBP
schema specifies and the BSI is expected to manage. [1]
Change to:
Change from: As with other specifications in the ebXML framework, an
ebBP process definition may be composed and used with other
technologies. That flexibility and composability are important aspects
not only to the adoption of these standards but their effective use and
successful deployment into heterogeneous environments and across
domains. In the context of this technical specification, Business
Collaborations may be executed using the ebBP process definition and/or
composed with other technologies. As it relates to the other
specifications in the ebXML framework, an ebBP process definition
supports the loose coupling and alignment needed to execute Business
Collaborations. This specification may also be used when several other
software components are composed and being specified to execute Business
Collaborations, such as the use of web services mapped to business
transactions.
The ebBP technical specification is used to specify the business process
related configuration parameters for configuring a BSI to execute and
monitor these collaborations.
This section discusses:
* How the ebBP technical specification fits in with other ebXML
specifications and may be used with other emerging technologies
(such as WSDL) An ebBP process definition does not preclude
composition with other process related technologies.
* How to use the ebBP artifacts at design time, either for
specifying brand new collaborations and transactions, or for
re-using existing ones.
* How to specify core transaction semantics and parameters needed
for a Collaboration-Protocol Profile (CPP) or Collaboration
Protocol Agreement (CPA).
* Run-time transaction and collaboration semantics that the ebBP
schema specifies and the BSI is expected to manage.
As this technology matures and relevant profiles emerge, more
compatibility points will be specified or conformance information
defined in the context of heterogeneous technology integration. For
example, an ebBP profile is under development in OASIS ebXML
Implementation, Interoperability Conformance TC.
Section 2.4
Change from: If one or more parties wish to participate on the basis of
one or more web service definitions the corresponding WSDL file(s)
associated to the BTA(s) that is(are) representing the ebXML conformant
party MAY be generated and MAY be referenced in the CPA if necessary.
Change to: If one or more parties wish to participate on the basis of
one or more web service definitions the corresponding WSDL file(s)
associated to the BTA(s) that is(are) representing the party MAY be
generated and MAY be referenced in the CPA if necessary.
Section 3
1. Change from: The ebBP technical specification/ /defines a standard
language for business process specification. An ebBP definition works
with the ebXML Collaboration Protocol Profile (CPP) and Agreement (CPA)
specification to bridge the gap between Business Process Modeling and
the configuration of ebXML conformant eBusiness software (See following
figure).
Change to: The ebBP technical specification/ /defines a standard
language for business process specification. For example, an ebBP
definition works with the ebXML Collaboration Protocol Profile (CPP) and
Agreement (CPA) specification to bridge the gap between Business Process
Modeling and the configuration of eBusiness software (See following
figure).
2. Change from: The ebXML BSI represents any ebXML conformant
component. The BSI MAY be configured from an ebBP definition and a CPA.
Change to: The ebXML BSI represents an important component in realizing
eBusiness automation and deployment. The BSI MAY be configured from an
ebBP definition and a CPA.
Please also note that I have also updated the Status section of the main
body of the technical specification related to normative capabilities.
This is indirectly related to the discussion and as a result of our
decision on separating the examples.
Updated Status in technical specification (at the front):
This set of ebBP documents are compatible with the ebXML Business
Process Specification Schema v1.01 technical specification and schema,
and a migration path is possible from v1.01, v1.04 and v1.05 documents
to v2.0.1. The technical specification supersedes the v2.0 Committee
Draft / Committee Specification. [1 footnote]
Six packages are provided for ebBP:
1. Normative: A package for the technical specification and
appendices (Artifact Type: Spec, and Artifact Type: Spec and Descriptive
Name: Appendices)
2. Normative: A package for the core schema (Artifact Type: Schema)
3. Normative: A package for the Business Signal schema (Artifact
Type: Schema, Descriptive Name: SignalSchema)
4. Non-normative: A package that includes the BT patterns
matrices, Public Review comments list, files for an exemplary XSLT
transform to assist the user community to begin to migrate v1.01, v1.04
and v1.05 ebBP instances (for information and reference only) [Artifact
Type: Document, Descriptive Name: Supplements],
5. Normative: A package of ebBP schema-generated documentation for
ebBP schema (Artifact Type: Document, Descriptive Name: Schema)
6. Normative: A package of ebBP signal schema-generated
documentation (Artifact Type: Document, Descriptive Name: SignalSchema).
These documents are updated periodically. Send comments to the editor.
Exemplary process definition and signal instances and illustrations are
also provided in publicly available package on the OASIS site. This
final package is non-normative and outside the review and TC process
cycle of this technical specification.
footnote [1] The preceding OASIS TC process indicates Committee
Specification while the new TC process indicates Committee Draft
followed by a Committee Specification. The v2.0 packages were applicable
under the old TC process as the quorate TC vote was initiated prior to
the effective date of the new TC process (although the vote concluded
after 15 April 2005). Under the new TC process, this document is a
Committee Draft.
========
[1] Previously proposed text as specified in:
http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/email/archives/200511/msg00018.html
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]