OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebcore-cppa message

[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
Sent: Sunday, January 20, 2013 3:03 PM
To: ebcore-cppa@lists.oasis-open.org
Subject: [ebcore-cppa] CPP/CPA 3.0

 

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

 

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]