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.
But…
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
|