RE: [ebxml-cppa] ebXML CPPA Override for alternative asynchronouse ebMS signals (orebBP signals as well)

["Pim van der Eijk" <pim.vandereijk@oasis-open.org>]

Hello Sacha,

Yes, I think it would solve our problem. Just a few quick notes:

[1] Perhaps the element should be called "SignalChannelId" instead of
"AsyncDeliveryChannel", to indicate it would only be used for signals, not
for business documents.  
As you say, its absence would mean that, if the syncReplyMode of the
business channel (see note [2] below) is "none" or "responseOnly", the
Default Msh Channel would be used for MSH signals (see note [3] below). I'm
not sure what channel would be used for standalone ebBP signals (see note
[4] below). 

[2] Along that line, the "ChannelId" could be renamed to
"BusinessChannelId"? 
Perhaps more clear, although it would break backward compatibility with
existing CPAs.

[3] There currently is a  "defaultMshChannelId", shouldn't there be a
"defaultBusinessChannelId" too? 
Just a thought.  It would make editing CPAs a bit more user-friendly ..

[4] I note there is a "defaultMshChannelId".  What is the default channel
for standalone ebBP signals (as different from ebMS signals), which would be
used with a value of "none" or "responseOnly"?  Perhaps the
"defaultMshChannelId" should be renamed to "defaultSignalChannelId" and also
used to cover ebBP signals. Or, you could define a separate default channel
for them.  

[5] Would there ever be a need to send asynchronous Msh Signals using a
different channel from ebBP signals? If yes, there could be a separate
"MshSignalId" and "?BpSignalId" element in a Party Action Binding.
Defaulted as per [4].

[6] There is still a remaining question when the "ackSignatureRequested"
attribute has a value of "perMessage". If an acknowledgment is requested,
and the syncReplyMode is "none" or "responseOnly", the asynchronous channel
to use would have to be set on a per-message basis (since signed and
unsigned acknowledgments have different channels).  I am not sure what the
signalling MSH should do in this case.

Pim

-----Original Message-----
From: Sacha Schlegel [mailto:sschlegel@cyclonecommerce.com] 
Sent: 13 January 2006 00:03
To: ebxml-cppa
Cc: Pim van der Eijk
Subject: [ebxml-cppa] ebXML CPPA Override for alternative asynchronouse ebMS
signals (orebBP signals as well)

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


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php