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


Help: OASIS Mailing Lists Help | MarkMail Help

ebcore-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [ebcore] Groups - cppa3-specification uploaded

Hi Yngve,

Many thanks for your comments!   I know you've been working in this field and with the earlier CPPA2 for many years,  so you have a lot of experience and your feedback is valuable.
I've added some comments inline.  

On 03-05-17 08:55, Yngve Pettersen wrote:

Hi Pim!

Sorry for late feedback, and hope it's not too late J


Regarding the CPPA3, I have not be able to read the spec in detail but as far I can see there are some good things.

Ithink the new ServiceSpecification is fine. It's very nice to be able to build up the complete process in the CPP or CPA and show which message following the others. CPPA2 was difficult to follow with CanSend/CanReceive.

It's also good to see that we can state the counterpart role. This will really help.


Yes, this change was needed to automatically form CPAs from CPPs.  In CPPA2 it was not obvious which CanSend to pair with which CanReceive and vice versa, when there are more than two roles in a service.


Why changing the Packaging? In CPPA2 you could explain in detail how a file should be packed, encrypted and zipped, and also the which version of message that was used. This is a large step backwards I think.

There are a couple of aspects:
1)  MSH processing and the way it affects packaging.
2)  Packaging not determined by MSH processing.
3)  Expected data type, schema, cardinality etc. of payloads exchanged for a particular Service/Action.
4)  Packaging functionality verified by the MSH,  but applied by application or middleware.

On 1)
Re encryption and zipping.  Already CPPA2 described signing and encryption in DocExchange, e.g. the {Sender|Receiver}DigitalEnvelope and {Sender|Receiver}NonRepudiation. In CPPA3 this is not done differently. For ebMS2,  there is an ebMS2SecurityBinding element that contains Signature and Encryption sub-elements that would configure how the payloads are secured.   It is true that in CPPA2 compression was described in the Package group,  and one of the earlier draft schemas of CPPA3 did so too.  However,  I changed my mind on this. The reason is that compression is an MSH feature like the other two, and AS4 models it like this,  so treating it like a channel (messaging protocol) feature seemed a better design. There now is simply a Compression sub-element,  at the same level as the WSSecurityBinding etc. elements. Some protocols support compression and others don't, so configuring the feature for the protocol makes more sense than suggesting it can be configured independently as a packaging option.  The change also simplified the schema a bit and (for ebMS3/AS4) makes it easier to map from CPPA3 to "P-Modes" and the product-specific configuration formats of AS4 products.  

On 2)
There still is a Packaging element (and substitutions) and it can be used for aspects of packaging that are not (fully) determined by the MSH. For example, if there are two MIME parts,  the relative order of those parts. Or if there is an option to package a payload in one of multiple ways not otherwise controlled by the MSH, which option is used. For example, with ebMS3, a payload can be carried in the SOAP body, in a separate MIME part, or as an external payload.  CPPA3 Packaging supports configuring these options in the SOAPWithAttachmentsEnvelope package element.  Simple package elements have a PartName attribute that links the "physical" package element to the "logical" part element (see (3) below).  An ebMS3Channel element can reference a package specification using the package attribute. In CPPA3, the package element is not required, as often there is only a single package for a protocol, or at least a default one. CPPA2 had packaging completely separate from delivery channels, but in practice packaging is largely constrained by the messaging protocol used.

On 3)
Following ebMS3,  the CPPA3 schema separates PayloadProfile from Packaging.  A PayloadProfile is a "logical" specification of the payload parts that are exchanged, irrespective of messaging protocol and packaging used.  For example,  service S action A is linked to one XML payload named e-prescription and zero or more payloads of type application/pdf named attachment. A CPP may link an action to multiple different channels, each linked to a (possibly different) package, so the payload may for example be in a compressed MIME part if one channel option is chosen or in an uncompressed SOAP body if another option is chosen.   Each payload part has a name, and there are references from the package to the payload profile. So you could specify that the e-prescription is to be included in the body and the attachment in compressed MIME parts.   

The payload part definition allows references to document schemas,  e.g. the payload part e-prescription may be linked to element E in namespace N of an XML schema located at schema location L.  There is also an option to link a part to multiple schemas, for example an XSD and a Schematron document, against both of which it must be valid.

As for versioning, it seems to make most sense to define versions at the level of services, not of individual actions,  because typically if you for example send a V2 request, you expect a V2 response and not a V1 response, even if you support both V1 and V2.  So service S1 may be linked to a number of actions linked to payload profiles linking the exchanged payloads to version N of a schema whereas service S2 is linked to payloads of version N+1.   In a CPP, a party could have service specifications for V1 and/or V2.  Then in CPA formation,  it would be determined which version is used with a particular counterparty.  So at this level, versioning seems to be supported well.

Now it may be an idea to have some kind of additional structure in the set of service specifications of a party.  For example, an obsoletes/obsoleted-by relation. Then after CPA formation, all but the most recent formed service versions could be removed (assuming newer versions are preferred over others).   It would probably be an easy to add feature.
On 4)
Sometimes it is desirable to be able to state some constraints on payloads other than data type or schema that are not about the processing of the MSH, but constraints that submitted/delivered payloads must meet that are to have been addressed outside the MSH.  For example,  a service may require exchange of XML or PDF documents that are signed (by a business application or user).   In the definition of PayloadPart in a PayloadProfile, this can be expressed using the Signature and Encryption subelements.   I notice Compression is currently missing,  I'll fix that in the next update of the schema. 

So in all, I don't think any CPPA2 functionality is lost.  But if that's not true,  it should be corrected because CPPA3 intends to continue supporting ebMS2 and all the features that it and CPPA2 provided. 
If you have some (anonymized etc.) sample version 2 CPP and CPA documents representative of your current use,  I can offer to try to re-encode them in CPPA3?   It could be a useful double-check to see no functionality is lost.

And…why change almost all tags? It's will be more difficult to acquire CPPA3 if you are familiar with CPPA2 because of the new structure, look complete new and strange for me.

Yes it will take some time to get used to the new schema if you've used the old one.  When the TC started working on CPPA3 years ago,  the initial idea was to remain compatible with the earlier version,  but it was very difficult and unfinished.  Following the example of ebMS3, which was a new major incompatible schema, it seemed to make sense to make a clean start with a newer schema, also to appeal to new users who may have never seen the old v2 CPPA and may not be using ebMS2.  Even though the overall concepts are the same, sometimes two elements are combined in one, e.g. the new ebMS2Channel is a combination of a DeliveryChannel with a DocExchange (which in CPPA2 was always ebMS2) to simplify and flatten the structures, or to make CPA unification easier.   In some cases I think terminology has changed over the years, and the current naming aims to align with current practice.

The schema documentation does contain detailed explanation of how the new elements relate to the old.  I hope that helps ..

But if some of the name changes are really felt to be changes for the worse rather than for the better,  we can change them back of course.

I'm also concerned about the security and how we state the certificate details. But as I said, I have not read this spec in detail and had not time to compare with CPPA2 on this issue so it might be ok.

That functionality is still there.    You can still include a certificate as a KeyInfo in a Certificate element,  and define TrustAnchor elements.  You can reference certificates from transports (e.g. for TLS client authentication) or from channels (e.g. to define the signing and encryption certificates).   When creating a CPA from two CPPs, a presented certificate (chain) is to be matched against a set of root certificates.  This is an advantage of CPPA from the early days,  trust is fully integrated in overall CPP model and processing and not something separate.

Med vennlig hilsen / Best regards


Yngve Pettersen

Seniorrådgiver / Senior adviser

Mobile (+47) 950 85 477




Again, many thanks for taking the time to comment on the spec.   I hope more people will review it (and allow their reviews to be shared on the list),  so we can find and fix any issues.

Kind Regards,

Pim van der Eijk


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]