I heard from Ralph Berwanger that you discussed my suggestion regarding ConversationId in previous teleconference on Monday 10, but did not reach conclusion. So I'd like to show my suggestion and its rationale again. Suggestion: Add status attribute to ConversationId element. The status attribute takes one of following four values: Start: First message in messages belong with the conversation. Middle: A message except for first and last message in messages belong with the conversation. End: Last message in messages belong with the conversation. Alone: First and last message in the conversation which consist of only one message. It MUST be specified when the conversation have only one message. Rationale: The Receiving MSH needs to know when conversation ends. Because the Receiving MSH has to hold the last message's SequenceNumber of the conversation in persistent storage for guarantee of message order until the conversation ends. If the Receiving MSH misses the end of conversation, the SequencNumber information remains in persistent storage forever. If we add the status attribute to ConversationId element, the Receiving MSH can know the end of conversation and can remove the SequencNumber information of conversation at correct time. As Marty mentions, even if we don't add the status attribute to ConversationId element, the Receiving Application can notify the Receiving MSH of the status of conversation (Start, End, etc.) instead. But I think it is not good idea. Because, - If the Sending Application also notifies the Sending MSH of the status of conversation, why same information should be notified from the Receiving Application too? If the status information from the Sending Application is not same as the status information from the Receiving Application, which is correct? - How and when the Receiving Application notifies the Receiving MSH of the status of conversation? The Receiving MSH will passes received message to the Receiving Application through the application's callback routine asynchronously. Thus if we force the Receiving Application to notify the Receiving MSH of the end of conversation, the Receiving Application has to call the Receiving MSH's API to notify the end of conversation after the last message in the conversation was passed. It makes complex of MSH's API and add extra work to the Receiving Application. - If unexpected error occurs in business process and the Sending Application decides to terminate the conversation emergency at unexpected time in the business process definition, how do the Receiving Application know the termination of the conversation without the status attribute of the ConversationId element? Adding status attribute to ConversationId element can resolve the problems above. A conversation is initiated by the Sending Application and the ConversationId value is also determined by the Sending Application and then propagated to the Receiving Application. Thus the conversation's status should also be specified by the Sending Application and then propagated to the Receiving Application. I think it is the natural way. Regards, -- SHIMAMURA Masayoshi <
shima.masa@jp.fujitsu.com> TEL:+81-45-476-4590(ext.7128-4241) FAX:+81-45-476-4726(ext.7128-6783) Planning Dep., Strategic Planning Div., Software Group, FUJITSU LIMITED