[ebxml-msg] ConversationId's status attribute

[SHIMAMURA Masayoshi <shima.masa@jp.fujitsu.com>]

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