ConversationId, MessageOrder and Multiparty Collaborations

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

Hello,

 

In an ongoing ebXML project, we are looking at a number of issues, on which I could use some advice.

 

Our scenario involves three organizations A, B and C.  

- A initiaties a new conversation by sending an ebXML message to B.  

- In the course of this conversation, B may hand over the interaction to C.

- C then sends a message to A. 

 

We want A to be able to correlate this incoming message from C with the internal processes, destinations etc. involved in the ongoing conversation with B without requiring A's MSH to process any payloads. This is because:

(i)  this is much more efficient and generic, and A's MSH needs to process large amounts of messages; and

(ii) the payload may be encrypted, with decryption taking place in another (internal) application, not in A's MSH.  

 

The easiest way to allow correlation of messages between A-B and C-A seems to be to reuse the ConversationId used between A and B in the messages exchanged (between B and C and) between C and A. 

 

The ebMS specification (section 3.1.3) states that ConversationId MUST be unique within the context of the CPAId. This seems to imply that sharing of ConversationId between messages that have different CPAIds is undefined but not disallowed.  This would then allow organizations or applications to mutually agree on additional conventions for and interpretations of values for ConversationId across CPAId (perhaps in specific contexts only, e.g. constrained by Service/Action context).

 

Q1:  Is this interpretation of the ebMS specification correct? 

 

The specifications for ebXML BPSS and CPPA do not constrain reuse of ConversationId in any way. EbMS leaves ConversationId values "implementation dependent", CPPA states that ConversationId "SHOULD be generated by the layer above the MSI", and BPSS (1.05, haven't looked at ebBP yet) doesn't mention it at all.

 

Q2:  Is this intentional?  Will it change with upcoming revisions of these specifications?

 

The ebMS specification also defines an optional MessageOrder module which we are being asked to support. This interacts with the ConversationId reuse issue. The specification states (section 9.1.1) that "[the] From Party and the To Party each set an independent SequenceNumber as the Sending MSH within the ConversationId."  As stated, if A is exchanging messages with both B and C that happen to share a ConversationId, MessageOrdering cannot be used as SequenceNumber is unique per <Party Sending MSH, ConversationId> pair, and some messages in the sequence go to another To Party MSH. 

 

However, I understand this as implicitly assuming a CPAId scope or even a To Party scope. A more precise formulation would then be that SequenceNumber has to be unique for a triple <Party Sending MSH, CPAId, ConversationId> or even per <Party Sending MSH, To Party MSH, CPAId, ConversationId>, if <From PartyId, CPAId> pairs for some reason do not uniquely identify a single To Party.

 

Q3:  Is this correct?

 

If yes, A's MSH would maintain separate SequenceNumber counter for its conversations with B and C even if the ConversationId is identical. If no, we cannot reuse ConversationId between different Party MSH pairs (or even between message sets with different CPAIds) if MessageOrder is used somewhere.

 

Pim van der Eijk