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