CPPA3: A CPPA that supports PModes
In OASIS, there has historically been a division
of labour between the
various ebXML Technical Committees, with the ebXML Messaging Services
specification being responsible for the protocol and message format,
and the ebXML Collaboration Protocols and Agreement TC responsible for
the CPPA (Collaboration Protocol Profile/Agreement) configuration
formats. The version 2.0 of CPPA supported ebMS 2.0 since 2004.
The CPPA TC merged with another ebXML TC to become the ebCore Technical
Committee.
The development of the version 3.0 of CPPA started many years
ago, then put on hold, partly in anticipation of related
specifications (such as AS4 and the ebMS3 Advanced Features) to be
completed. One part of CPPA3 covering party identification was spun
off and became the ebCore Party ID Type specification in 2010. The full
CPPA3 specification is now available in draft form at https://www.oasis-open.org/committees/document.php?document_id=56327.
All feedback is welcome. Furthermore, representatives of OASIS member
companies can join the ebCore
TC at OASIS to contribute to its deliverables.
The ebMS3 concept of PMode is about parameters and parameter values that control the processing of ebMS3 messaging and does not have an XML representation. The specification uses a dotted string format to identify parameters. There is no XML schema for PModes. One goal of CPPA3 is to serve as such a schema.
The draft schema of CPPA3 includes full documentation on how it
represents AS4 PModes. The distribution also has a number of examples,
including examples for AS4 profiles developed for large scale cross-border data
exchange in Europe. On the question how it represents PMode
information, here is a brief discussion.
First, in many cases, CPPA directly reuses the name of PMode parameters,
e.g. the following are two parameters for error handling:
<cppa:DeliveryFailuresNotifyProducer>true</cppa:DeliveryFailuresNotifyProducer>
<cppa:ProcessErrorNotifyProducer>true</cppa:ProcessErrorNotifyProducer>
In other cases there are minor differences. For example, in
cppa:Signature it prefers the names from the W3C Recommendations rather
than the AS4 names (e.g. DigestAlgorithm instead of HashFunction).
A bigger difference relates to structuring configuration information for
multiple messaging configurations. In realistic situations, each AS4
gateway will have multiple PModes with other gateways it connects to,
for different services and actions (e.g. actions "SubmitOrder",
"AcceptOrder", "RejectOrder" in a "OrderingBilling" service). A
typical use case for a configuration interchange format is to encode, in
a single XML document, a set of PModes for a new partner gateway, or
to deploy a new service with an existing partner. By loading the file, the new partner, or the new service, are automatically deployed on the gateway.
The notation for
PModes in ebMS3 covers only a single PMode so a direct representation of
the parameters in XML format would lead to massive redundancy.
Some AS4 products have proprietary "PMode XML" schemas and most of the ones
I've seen address this, though the approaches taken are quite diffent.
Likewise, CPPA also attempts to minimize redundancy and provide structure. It uses both XML tree
hierarchies (nesting of elements) and cross references (ID/IDREF). In
CPPA, there is a cppa:PartyInfo group that defines party identifiers
and certificates, so these are defined only once for all exchanges.
Within that group there can be cppa:ServiceBinding elements that define
the Service value once, and which in turn includes list of protocol
bindings for the Actions in the Service. Apart from being less redundant,
the document becomes much easier to read for developers or administrators.
Actions need bindings to a specific message protocol configuration.
Since multiple actions may use the same binding, in CPPA these are
cross-referenced rather than nested in the action tree. A binding
connects an action to a channel. CPPA is not just covering ebMS3 but
also other protocols, so it defines multiple types of channels, of
which cppa:ebMS3Channel is one.
The type of ebMS3Channel is a subtype of a generic WSChannel type, from which it inherits a.o. a WSSecurityBinding group and an abstract ReliableMessagingBinding element, which AS4ReceptionAwareness substitutes for. It adds groups for the handling of errors and receipts. The structure largely follows the grouping of the PMode parameter set.
A channel can be linked to transport definitions, e.g. an HTTPTransport
for AS4. Since different PModes/ebMS3Channels may use the same
transport, this is again done as a cross-reference. There may be only
one HTTP listener for all AS4 messages, which infers the PMode to use
from headers relating to parameters. However, a transport is not
required. A channel may use the backchannel of another channel, which
does have a transport defined. An ebMS3Channel may also require use of a
PullRequest, and then the HTTP transport is specified with the channel
of that PullRequest.
The use of a reference from one channel (the channel used by an action
binding, i.e. a user message) to another (the one used by the
pullrequest) is an instance of a more general pattern: user messages,
pull requests, receipts, and errors all have their (possibly the same,
possibly different) channels, as suggested (but in very underspecified way) in
section D.2.1. of EBMS3CORE.
Furthermore, in CPPA, for reuse, channels
can reference other channels. The channel referenced from an action
binding is the regular channel used by the user message. That channel
may specify that another channel is to be used to exchange receiver
errors generated for messages using that channel. This has the
advantage that questions such as whether or not receipts or errors are
signed can be enforced using the configuration parameters. Today for
AS4 this is (just) specified in the OASIS specification proze or in
community profiles, and hard to configure in products so often hard-coded.
This sounds complicated, but it really means that for possibly dozens
of PModes between two gateways A and B, there may only be a need for
four channels: one for user messages from A to B, one for signals
(errors or receipts) for those messages, one for user messages from B
to A, and one for signals (errors or receipts) for those messages. If
there is a need for different channels for errors and receipts (e.g. one
synchronous and the other asynchronous, or one signed and the other
unsigned), two additional ones are needed. And if the user messages
are pulled, then two additional channels may be needed for the pull
requests. Yes, a bit more configuration, but at least it becomes
possible to
specify the gateway's behaviour in a very fine-grained way, if desired, using the
same mechanisms consistently.
In addition to these Channels, there will be two HTTP transports: one for A to B and one for B to A, convering all exchanges.
As a result of the generalization of channels and XML schema structuring, several PMode parameters seem redundant.
A parameter like
PMode[1].ErrorHandling.Report.ReceiverErrorsTo is not actually needed.
It is simply the Endpoint of the HTTPTransport of an error channel
referenced from the channel referenced from an ActionBinding. The address for Receipts can be determined similarly.
In CPPA3, we list the Actions for each Service, which relate either to
incoming messages (received from the partner) or outgoing ones (sent to
partner). By default, all these actions are standalone, i.e. they don't
have a response action. But there is an optional "replyTo" attribute
on an ActionBinding to express that an action is a business response to another action.
There may be several such actions (e.g. "AcceptOrder", "RejectOrder").
In a protocol like ebMS3/AS4, presence of this attribute expresses that
the actions are part of a Two Way Exchange and therefore a
RefToMessageId header is expected in the second leg actions. A separate
MEP parameter would be redundant in this situation.
Note: an alternative to
"replyTo" could be to not have a flat list of ActionBindings but to
explicitly group the actions for Two Way MEPs. The current approach is
simpler, but (like everything) this is a proposal that can be re-considered before we finalize the CPPA
specification.
The "MEP Binding" parameter expresses whether legs are Push, Pull or (for
Two Way) Sync. In the draft CPPA schema, each Action is bound to a
Channel. If the Channel has its own transport, the MEP Binding is Push
for One Way MEPs or for asynchronous Two Way MEPs. If the Channel
does not have a transport and specifies the use of a PullRequest using a
particular Channel, the Action is Pull. If the Channel for a response
Action does not have a transport specified and states it uses the
backchannel of another channel used by the request action, the
communication is synchronous. So this classification in three types of
bindings seems to fully follow from other information already modelled
in the schema.
Finally, the schema allows for the use of multiple WSSecurityBinding in
an ebMS3Channel, to reference different SOAP
Actor/Role. A PullRequest references its own channel. That channel can
specify a WSSecurityBinding targeting the "ebms" Actor/Role. This
security binding can contain a UserAuthentication element to specify a
Username token to be used. This existing mechanism covers the
functionality of the PMode.*.Authorization.* parameters. By reusing the common UserAuthentication structure, we can fully configure the token (e.g. whether digest authentication is used, of a timestamp is to be included).
While the CPPA3 XSD does not have an element called "PMode", the central claim of this blog post is that it is not fundamentally different from other (so far only proprietary) XML schemas for PModes (at least for the schemas I've seen). Since it is a further development of an existing standard that has been used for years (and which has known limitations for which we now think we've found solutions), it is based on a lot of experience. For ebMS3 and AS4, the structure and semantics of CPPA3 is based on names, definitions and grouping of ebMS3 PMode parameters, or of elements in other referenced schemes (like XML Signature and XML Encryption).
When creating the schema, the design focussed on creating an easy to use, consistent and coherent schema.
The hierarchical organization of cppa:PartyInfo is
easier to read than having an unordered bag of redundant PMode
definitions. The introduction of the concept of Channels, typed
cross-references among Channels, and references to Transports,
simplifies the schema, reduces redundancy, enhances its expressivity,
and greatly increases reuse.
Another design goal for CPPA3 was to support not only ebMS3/AS4, but also to support legacy protocols like ebMS2 and AS2, and to allow extensibility for future protocols. Using XML schema techniques (types, substition groups), the schema can be further extended to future protocols. Its support for multiple protocols means that a multi-protocol gateway can use a single format to configure multiple protocols. Even within a single CPPA document it is possible to configure some exchanges to use different protocols than others. This is useful in a transition from one protocol to another.
Another feature of CPPA is that it does not just allow configuration of communication between two parties (the "Agreement" part), it also allows a party to specify its parameters as a "Profile" in a way that allows it to be "unified" automatically with the corresponding parameters from a communication partner. The Profile can specify multiple alternative options, from which the the most preferable compatible options can be selected in the unification process. CPPA3 is being designed in parallel to an implementation (to be open sourced), and all test sample CPAs in the current draft were generated using this implementation to validate its functionality and implementatibility.
Finally, CPPA also supports a much simpler way of configuring messaging based on a concept of named protocols, or "templates". The template name could identify a particular community profile (which predefines many parameter values) by name. Rather than implementing the (fairly complex) CPPA3 schema, a product could then implement the template using its own configuration mechanism, and map a CPP or CPA that references the template on import to these predefinined settings.
More on these other topics in future posts ..
- Pim's blog
- Login or register to post comments
- 5425 reads