CPP/CPA enhancement suggestions

["Pim van der Eijk" <pvde@sonnenglanz.net>]

Here are some brief descriptions of potential enhancement requests for
ebXML CPP/CPA, for tomorrow's meeting. Depending on interest from the
TC, these could be developed further.

Warning: these are rough ideas, hopefully the description conveys the
general ideas.

1) Supporting end-to-end agreements in multihop: abstracting from
 hop-specific parameters

In the current CPP/CPA schema, a <DeliveryChannel> defines both
quality of service (security, reliability) that applies "end-to-end" and
settings that are different from hop to hop.  The transport
<Endpoint>, SSL settings and MEP binding (pull or push) are between
the initiator and the first hop, and between the responder and the last
hop. They are not end-to-end agreement features.

Requirement: allow partner agreements that abstract from the per-hop
settings and express only the end-to-end settings.  This hides the
local parameters and allows both partners to use the exact same
agreement.

A simple option is to make @transportId in <DeliveryChannel>
optional. The CPA is then the same for sender and recipient and can be
digitally signed. The transport configuration is declared out of scope
for the agreement.

Analogy to email: our ebMS header and WS-A routing parameter are
structures for end-to-end routing, like the RFC 2822 email address
"user@domain". The sender has its private settings for SMTP and
recipient for IMAP/POP3 servers, and both can reconfigure them
independently and without the other party knowing, as long as the edge
hops can establish a message forwarding path. 

In this case a CPA no longer is sufficient to fully configure an ebMS
MSH, like CPA 2.0 XML documents are today. The missing information
needs to be added to each deliveryChannel so that the MSH can function
properly. We could leave how this is done to products or define a
standard XML format for it. The missing information plus the
end-to-end agreements can be merged to generate a classic, complete
CPA. But that "CPA" could be different for sender and recipient,
especially if there is more than one intermediary.

Note that this is already the case with ebMS 2.0 if e.g. one party
uses an SSL terminator and the other does not: the <Transport>
elements in the CPA are already different.

(Note: this mapping from channels or messages to "local" transport
configurations is like the unspecified "routing function" that
intermediaries must implement. See an earlier proposal in
http://lists.oasis-open.org/archives/ebxml-cppa/200811/msg00000.html. )

2) Extending <DocExchange> and using WS-Addressing

In Part 2 we are using WS-Addressing. The <ebXMLSenderBinding> and
<ebXMLReceiverBinding> elements now have sections for (end-to-end)
security and reliability. The <DocExchange> element should contain
information that expresses whether the exhange is point-to-point
(default) or multihop.  If multihop, we could use some defined
attribute value to express that the forward EPR reference parameter is
constructed using the default algorithm (which constructs an EPR that
mirros an ebMS UserMessage).  The DocExchange group would then be
reusable for many different service/action combinations. 

We could also allow explicitly setting other WSA fields like Reply-To.

3) Delivery channels for "response" signals

With some delivery channels there are associated signals: pull
requests, errors, acknowledgements, receipts.  These can all use EPRs
in a multihop context. If one of these EPRs does not use the default
values mentioned in the spec, the DeliveryChannel should specify this
EPR explicitly and therefore becomes less reusable.

The CPA 3.0 draft XSD has an Endpoint type that can express whether an
endpoint is used for various uses (e.g. errors). It may be more
flexible to have separate explicit delivery channels for these signals
and have a reference from the <DeliveryChannel> that is used for the
business message to e.g. an @errorChannel, @initiatingChannel (for
Pull or Sync), @receiptChannel, @errorChannel. That way, for each
signal associated with a channel you can set security, addressing and
other parameters explicitly. (Using @defaultMshChannelId and
OverrideMshActionBinding, you can set global defaults for all signal
channels, or channels of some type, but there is a need to be able to
set this per delivery channel).

4) Configuring PullRequest

We now support the ebMS 3.0 "pull" feature in CPA 3.0 draft by having
an <Endpoint> element on the <TransportSender> element.  (Section
4.3.8 of the latest CPA 3.0 draft). This expresses that the sender
acts as the HTTP server, unlike in CPPA 2.0 where the HTTP server
endpoint is always associated with the receiver.  This is not enough
to fully configure the ebMS 3.0 PullRequest.  The pull request may be
secured using WS-Security, it may or may not be sent reliably, and may
or may not have WS-Addressing configuration (routing parameters).  I
think the PullRequest should have its own DeliveryChannel (even in
regular point-to-point ebMS) and there could be a reference
@initiatingSignalChannel from the business message <DeliveryChannel>
element to the channel that the pull request uses.

In multihop, we have distinguished two cases:
- Local pulling: only an edge intermediary needs to be aware of, and
configured for, the pulling.  Pull requests are not reliable:
end-to-end retransmission; authorisation with intermediary locally.
- End-to-end pulling: here we have subcases based on routing based on
the @mpc (no reference parameter needed) or routing using a reference
parameters. Global authorisation:  receiver has authorisation
agreement with sender. 

So the proposed @pullRequest parameter (that links a delivery channel
for a business message to the delivery channel for the pull request
signal) is either an end-to-end configuration, agreed between sender
and recipient, or a local configuration. 

5) Synchronous responses

The CPA 2.0 used nesting of CanReceive in CanSend (or vice versa) to
indicate synchronous responses. The new ActionBinding elements can
also be nested.  I would like to have a way of expressing that a
message on some channel is using the transport backchannel, other than
nesting but by just using a different DeliveryChannel.  This way,
whether or not a CanReceive is a synchronous response to a CanSend, is
expressed in the channel, not by nesting.  

Motivation: in a CPP, you could have say 3 CanSends and 5 CanReceives.
These are associated with one or more DeliveryChannels.  In CPP
intersection those channels are matched against another CPP that
should have 3 CanReceives and 5 CanSends. If synchronous response is
expressed as nesting, a partner that supports synchronous and
asynchronous will have a duplicate ActionBinding, one with a nested
ActionBinding and the other without one.  It is simpler if there is
just a single mechanism (multiple alternative <DeliveryChannel>
elements) to express this. CPP intersection is must simpler.

There already is a @syncReplyMode parameter in the CPP/CPA, but it is
in MessagingCharacteristics which is optional.  We could have an
attribute @usesTransportBackChannel with default value false. If true,
there could be an @initiatingDeliveryChannelId parameter that
identifies the other delivery channel that a particular channel uses
the backchannel from.

These two parameters could also be used for PullRequest as in (4) to
reference the pull request delivery channel that the message uses the
backchannel of.