ebcore-cppa message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: CPP/CPA 3.0
- From: "Pim van der Eijk" <pvde@sonnenglanz.net>
- To: <ebcore-cppa@lists.oasis-open.org>
- Date: Sun, 20 Jan 2013 23:02:56 +0100
Hello,
Now that the
AS4 ballot is completed, the main related component of ebXML that has
not been finished is the CPP/CPA 3.0 specification. This email presents an
overview of the status of this and some thoughts on its potential future, for
discussion. If you have an interest or any views, please respond by
email. Depending on response and feedback, we could discuss this at a
future conference call.
Pim
0.
Background and Status
The CPP/CPA
specification was part of the ebXML set of standards. The last formal standard
version of the specification is version 2.0, which was an OASIS standard since
2002 and an ISO standard since 2004. Work was continued on maintenance and
extension in the ebXML CPP/CPA Committee, which later transitioned into
ebCore. A draft version 3.0 was developed, the last draft version of which
is from 2009. A CPPA subgroup of ebCore was set up in 2009 and has a
workspace at https://www.oasis-open.org/apps/org/workgroup/ebcore-cppa/index.php.
Work was done in this committee until 2010, but no progress has been made since
for various reasons: lack of resources, and a desire of the
team to first finish other dependent components, such as the ebMS3 Part 2
and AS4 specifications.
A section on party
identification was extracted in 2010, updated and was adopted as an OASIS
Committee Specification: the ebCore Party ID. That specification is
now widely used in user communities at least three continents. This
indicates that at least one part of the CPP/A specification serves a need,
so if there are any other valuable parts in the specification, it would be a
shame if they weren't finished and published.
The v3.0 draft
includes numerous enhancements, such as: alignment with the ebBP standard,
support for message protocols other than ebMS 2.0, such as EDIINT, Web
Services and ebMS 3.0 Core, and an extension mechanism for other
protocols. There has also been a start with simplification of the
schema, such as a flattened structure for action bindings.
In the
ebCore CPPA subcommittee, we developed more enhancements, such as support
for WS-Addressing and for the new features in ebMS 3.0 Part 2, such as multihop,
bundling and splitting. The multihop feature support is provided by a
mechanism that could also handle many different types of SOAP intermediaries.
There is
also a better way of handling messages that use backchannels and the concept of
"related channels" provides precise, fine-grained configuration of message
protocol signals. Many of these features are innovations that are not in any other Web
Services or other specifications. Now that AS4 is finished,
we could review the AS4 specification and add any necessary parameters, but I
think we have most already. So at this stage a question to discuss is whether it
would make sense to attempt to resume work on the specification and attempt to
finalize it in 2013. We would then need to make an inventory of activities
and issues to be addressed.
As a first question,
we need to determine whether there (still) is a need for CPP/CPA in the market
and how well the draft CPP/CPA v3.0 addresses the needs of implementers.
The main
application area for v3.0 seems to be to support ebMS 3.0
implementations. After a slow start, some large deployments of ebMS 3.0 are
starting in 2013 and more
vendors are planning ebMS 3.0/AS4 implementations. The ebMS 3.0 specification uses
an abstract concept called processing modes with their parameters but leaves the
implementation of this concept to specific products. A pmode
covers information on sender and recipient, so it is more similar to CPA than to
CPP. In the absence of a standardized exchange format
communities looking to adopt ebMS 3.0 have the kind of setup and configuration
issues that
CPA solved a decade ago. I'm seeing some of this
in ebMS 3.0 pilots. A
standardized product-independent format would add value for ebMS 3.0 users.
Some ebMS 3.0 products/prototypes have configuration
mechanisms using XML or other notations. The ones I have
seen seem mostly pragmatic/proprietary formats, tied to particular
assumptions or to supported feature sets that don't pretend to be candidate
standard formats. The draft CPP/CPA v3.0 overall has more complete coverage and (in my
personal opinion) a better overall structure, but can be simplified and improved a
lot.
Outside ebMS, some recent initiatives use concepts similar to
CPP (but not with ebMS) and could have adopted CPP v3 if it were finished and
more widely known.
1. Backward
Compatibility
The CPP/CPA v3.0 was
set out to be backward compatible (except for minor changes), so while
some new structures have been defined (e.g. the ActionBinding is a
big improvement over the old CanSend/CanReceive elements), the old
structures are preserved, so the complexity increases. There are other
opportunities for simplification that have not been taken advantage
of. I think the backward compatibility requirement should be
dropped. A semi-automatic migration of old v2.0 CPAs may still be possible
in some cases. Anyhow, compatibility is most likely an issues for users
that have many v2.0 CPAs in production. Many users with many CPAs typically
use toolkits to manage their CPAs and/or derive CPAs from templates.
It could be much easier to update those toolkits and generate
(non-backward-compatible) v3.0 CPAs than to try to migrate the old CPAs.
2. Schema
Documentation
Chapters 4 and 5 of
the draft specification explain the v3.0 schema using a pseudo-syntax.
Much of the explanation is also redundantly present as
xsd:annotation/xsd:documentation in the separate schema. Using
an XML schema tool like oXygen, it is possible to generate schema
documentation, in DocBook, HTML and PDF formats. The generated
documentation has much nicer hyperlinked diagram representations of the
schema structures, so the resulting product would also be easier to use. If
acceptable to OASIS TC Admin, we could move all schema documentation to the XSD
and generate the (future equivalents of) these chapters from there. This would
also make it easier to maintain the schema and documentation. The current
specification could be limited to an introduction and specific aspects such
as support for business process and conformance profiles for supported messaging
protocols.
3. Business
Process
An important aspect
of CPP/CPA is its link to the business process, and the draft specification
discusses this in detail (in particular section 4.3). While I'm a big fan
of ebBP, a main audience for CPP/CPA v3.0 are system architects of B2B messaging
products who may not be interested in the links to business process, but just
want to understand how to map the specification to the capabilities of their
product. We could create a separate chapter that combines these and appendix F
and G into a separate standalone chapter. Also, some mandatory elements in
the schema could be made optional.
4.
Conformance Profiles
OASIS specifications
need a conformance section. We could define sections for different messaging
protocols. Or a separate one for sub-profiles of ebMS, such as
AS4?
Or could we leave
those outside a "CPP/CPA 3.0 Core" specification?
5. Size of
Specification
It was already the case with
the earlier CPP/CPA 2.0 standard that the specification was a larger document
than the ebMS 2.0 standard it complements (156 pages versus 70 pages) and
the latest draft of CPP/CPA 3.0 is also a large document. By
separating the schema documentation from the main document and moving to a
hyperlinked generated format for schema documentation, the spec would become
easier to use. But if we can make the spec shorter by removing or
shortening sections, that would help too.
6. New
Functional Ideas
Here are some ideas for extensions that I
noted in the past two years. Based on user requests and
discussions
Standalone CPPs |
In ebMS v3.0 it is no longer required to
include agreement references in messages. With limitations (e.g. only
synchronous receipts and errors and CA-based trust assumptions), a CPP
could then be used as a complete functional description. Perhaps there should be an
element in the CPP that indicates whether it can be used in such a
way, or only serves as input
to CPA formation |
Start and End in
CPPs |
It is possible to set the lifetime of a CPA, but not of a CPP. |
More granular Start and
End |
Allow these to be set for individual
actions |
Certificate
Management |
A CPP or CPA could reference a
certificate as the result of an XKMS query, or as an HTTPS hyperlink. This would support CPP/CPAs with
an expected update semantics (to avoid having to issue a new CPP/CPA just
for a certificate update).
Alternatively, specify
that certificates can be updated using CEM messages
|
Delegation Concept |
This is a proposed extension mentioned
in a posting to the BDXR mailing list. See the attachment to
https://lists.oasis-open.org/archives/bdxr/201210/msg00009.html.
|
Linking CPA to CPPs |
Norwegian requirement to link a CPA to
the CPPs that were input to its formation. (So that, if the CPP changes, the
related CPAs can be found and updated
too) |
.
7. Detailed
Comments
Here are some detailed comments on parts of the spec.
4.3.3.1 |
ProcessSpecification |
make this optional |
4.3.3.3 |
ApplicationCertificateRef |
remove this? Or better
define how it would be used. |
4.3.3.4 |
ApplicationSecurityDetailsRef |
Idem |
4.3.3.5.2.1 |
CanSend and
CanReceive |
Remove; replaced by flat
structure |
4.3.3.5.2.4 |
BusinessTransactionCharacteristics |
make this optional. For
definitions, can we just reference ebBP rather than repeat the
definitions? |
4.3.4 |
MessagingCharacteristics |
Can be replaced by related channels and new way of
representing backchannel |
4.3.5 |
Certificate |
More discussion needed.
|
4.3.6 |
SecurityDetails |
More discussion needed.
Candidate enhancement: allow
reference to Trust Service Lists |
4.3.7 |
DeliveryChannel |
Updates in latest draft
schema for multihop, related channels etc. |
To be discussed: can we make channels
unidirectional? Also applies to
transport, docexchange. Would simplify the schema.
Directionality follows from whether the referencing action is send or
receive.
Add support
for splitting and bundling as in latest schema drafts.
|
4.3.7.1. |
MessagingCharacteristics |
See above |
4.3.8 |
Transport |
Could we have unidirectional
transports? Direction would follow from use. |
4.3.9.3 |
FTP transport |
Could we drop this (AS3 would
be the only user) |
4.3.10 |
DocExchange |
Latest schema has
enhancements for multihop |
For subelements,
could we make them unidirectional? |
To be discussed:
some generalization of SOAP bindings |
4.3.10.1.4 |
ReliableMessaging |
Add AS4 support here, and allow specification of
protocol to use. More
parameters |
4.3.10.1.5 |
WSDLOperation |
It may be easier to allow actionbindings to
reference into (external) WSDLs. |
4.3.10.1.7 |
Compression |
If this is payload
compression, could we define this in packaging? |
|
|
|
4.5. |
Packaging |
Working on some ideas
here. |
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]