[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebcore-cppa] CPP/CPA 3.0
Hello Dale,
Thanks for your comments.
I think cost of keeping this compabitibility in added
complexity to schema and documentation outweighs any potential benefits.
There may be other ways to migrate/convert existing CPAs,or to help existing
ebMS 2.0/CPA 2.0 user communities, that do not require the new schema to
retain constructs for which we have better options. And if this project is to be
feasible at all, we may want to leave out some functionality of the old
CPA. But perhaps the elements and types for ebMS 2.0 could stay close to
the CPA 2.0 ones, and that we use newer types for ebMS 3.0 and EDIINT, for which
there is no legacy CPA 2.0
JSON an interesting idea, though we would need to define
a JSON schema too, and JSON schema is still a draft and does not have all
features that XML schema has, some of which the draft v3.0 schema
uses.
Templates are indeed widely used with CPA 2.0 and should also
be supported in CPA 3.0. But we may also be able to define the schema and
matching to avoid the problems with v2.0 CPP matching, so that a party A could
send a CPP to a party B, referencing a CPP of B, and B returning the matching
CPA as a response. This is one way the BDX "Connect" could work.
Pim From: Dale Moberg [mailto:dmoberg@axway.com] Sent: 24 January 2013 16:15 To: Pim van der Eijk; ebcore-cppa@lists.oasis-open.org Subject: RE: [ebcore-cppa] CPP/CPA 3.0 I
think one requirement from the old days that needs to be revisited if this work
is to be undertaken is that compatibility be maintained between CPPA 2.0 and the
next version. A
second possibly related issue is whether there should be a lighter exchange
format, such as JSON. A
third is whether Templates be given a status that merges the work done on
Negotiation with the Template. [Then
the template becomes an offer with the acceptable ranges of values to be chosen
by the responder indicated clearly in the template (as in Negotiation] This
would result in a single round trip, offer-answer setup, without need for
Negotiation or complicated CPA formation. The responder’s answer, if any, would
in effect be the agreement. The
CPPA initiative was also overly burdened by seeking an approach that could
straddle _any b2b protocol setup with any business process model. This was an
irrational exuberance of ebXML and possibly something that needs to be
revisited. So
my proposal would be to reconsider the resources that exist that might be worth
salvaging after a clarified and adjusted set of requirements is settled.
The amount of work involved here should also not be underestimated. I think a
call for new participants might also be in order. Not sure how that would work.
From:
ebcore-cppa@lists.oasis-open.org [mailto:ebcore-cppa@lists.oasis-open.org] On
Behalf Of Pim van der Eijk 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. The draft v3.0 schema
(attached to email https://lists.oasis-open.org/archives/ebcore-cppa/201009/msg00002.html)
and specification (https://www.oasis-open.org/apps/org/workgroup/ebcore-cppa/download.php/34606/ebcppa-v3.0-Spec-wd-r01-en-pete4.odt)
today are incomplete and not easy to use. Below are
some issues that (in my opinion) would need to be addressed, some new
functional requirements and a list of detailed comments on the draft spec.
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
. 7. Detailed
Comments Here are some
detailed comments on parts of the spec.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]