ebXML CPPA Override for alternative asynchronouse ebMS signals (orebBP signals as well)

[Sacha Schlegel <sschlegel@cyclonecommerce.com>]

Hi everyone

A sample use case:

<tp:CanSend>
  <tp:ThisPartyActionBinding tp:action="testOneAction" ... >
    <tp:BusinessTransactionCharacteristics ...  />
    <tp:ChannelId>coronationTrunk_Channel</tp:ChannelId>
  </tp:ThisPartyActionBinding>
  <tp:OtherPartyActionBinding>
    gnaraloo_Receive
  </tp:OtherPartyActionBinding>
</tp:CanSend>

<tp:DeliveryChannel tp:channelId="coronationTrunk_Channel" ... >
  <tp:MessagingCharacteristics tp:syncReplyMode="none"
tp:ackRequested="always" tp:ackSignatureRequested="never"
tp:duplicateElimination="always"/>
</tp:DeliveryChannel>

The CanSend with action "testOneAction" uses the Delivery Channel named
coronationTrunk_Channel. Following the reference the actually
DeliveryChannel element can be found. In the DeliveryChannel we see by
looking at the syncReplyMode that all a ebMS technical acknowledgement
signal will be sent back asynchronously. There are other values such as
"responseOnly", "signalsAndResponse" or "signalsOnly". "response only"
would indicate to me that the repsonding business document is sent back
synchronously and all associated signals asynchronously. The
ackRequested in the Messaging Characteristics indicate that an ebMS
technical acknowledgement is expected.

The delivery channel that is used for the asynchronous ebMS technical
acknowledgement is the delivery channel that the party has selected as
"defaultMSHChannel".

Problem description:

This is fine as long the defaultMSHChannel is suitable for all actions
that use async ebMS technical acknowledgements.

But if one action will go over a different delivery channel (high volume
top secret channel), one would like to have the corresponding async ebMS
technical acknowledgement go get back over the same delivery channel
(high volume top secret channel).

This is not possible as all async ebMS signals will be sent over
defaultMSHChannel

Possible solution 1:

Adding an optional element to the ThisPartyActionBinding called
something along the line: "AsyncDeliveryChannel". The following rule
could be added:

o If the element is not present, the defaultMSHChannel will be used.
o If the element is present but the syncReplyMode of the delivery
channel referenced in "ChannelId" indicates synchronous transport the
element will be neglected.
o If the element is present, and syncReplyMode indicates asynchronous
transport and there is an OverrideMSHChannelId the new element
"AsyncDeliveryChannel" has presedence.


Possible solution 2:

Extended use of OverrideMshActionBinding. As Pim interpreted the value
of the OverrideMshActionBinding can "redirect" MSH signals such as
"Acknowledgement", "Error", "Status Request".

Also it generalises all "Acknowledgement" and that is not what we want
either. It should be possible for only one specific "Acknowledgement".

For advanced asynchronous replies, such as business signals, and even
business reposes the OverrideMshActionBinding is not suitable either.

So the OverrideMshActionBinding would need to be extended so that people
can set the CollaborationRole/ProcessSpecification and
ThisPartyActionBinding Id attribute to unanimously select the action.
Potentially the Role would also need to be specify in case the party
place different roles in the same Business Collaboration and the same
action happens for both roles. 

So I opt for solution suggestion 1, to add a new optional element to the
ThisPartyActionBinding element (actually ActionBinding type).

Pim, would these solutions solve your problem?

Regards

Sacha