Not true!
The fact that no more messages for a conversation are left in the
persistent store does not mean that the conversation is ended. The time to
complete a conversation may far exceed persistDuration. In addition to
network delay and MSH response time, it may involve long processing delays
by the application. Just consider the case where you order a custom-built
PC from a company with just-in-time inventory policy. It may have to place
orders with multiple subcontractors and wait for responses to all of them
before it replies to you.
The MSH can only conclude that a conversation is ended when it is told that
it is ended, preferably by the software/middleware above it.
Most useful conversations eventually end. Yes, there are some that go on
forever. An application may open a conversation and use it for a
continuing flow of individual interactions. In my experience that happens
when some of the needed identifiers are in payload where they are hidden
from the middleware. OBI is probably one such case. Applications
supporting ebXML messaging probably do not need infinite length
conversations. In any case if this is done right, the MSH need not care,
i.e. if conversation management is above the level of the MSH.
Regards,
Marty
*************************************************************************************
Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287; IBM tie line 863-7287
Notes address: Martin W Sachs/Watson/IBM
Internet address: mwsachs @ us.ibm.com
*************************************************************************************
David Fischer <david@drummondgroup.com> on 12/03/2001 09:30:08 PM
To: Ralph Berwanger <rberwanger@bTrade.com>,
ebxml-msg@lists.oasis-open.org
cc:
Subject: RE: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
Ralph, Chris, I agree. What I was trying to point out is that (purely for
the
purposes of Message Order) the ConversationId need not be stored separately
in
persistent store from the messages pertaining to the ConversationId. If
there
are no messages in the persistent store pertaining to a conversation, then
there
is no need to store it any longer for the purposes of maintaining message
order.
You are of course correct, a ConversationId may be used again later. IMO,
a
Conversation may never actually end.
Regards,
David Fischer
Drummond Group.
-----Original Message-----
From: Ralph Berwanger [mailto:rberwanger@bTrade.com]
Sent: Monday, December 03, 2001 3:27 PM
To: ebxml-msg@lists.oasis-open.org
Subject: RE: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
David,
I am not sure that I agree with this. I thought that
persistentDuration was related to a specific message. I am thinking
about the case when the intermediate message may be a price quote and
the price quote is only valid for a few hours. The persistDuration
would be set to expire after the termination of the validity period for
the quote. However, the conversation would still be open. I can think
of several business cases where the persistDuration makes sense on a per
message basis (not to be confused with perMessage) and not based on the
conversation.
Ralph Berwanger
David Fischer wrote:
> I seem to be missing something. The end of a conversation is
controlled by
> persistDuration, isn't it? I think the ConversationId is held in
persistent
> store with the MessageId (at least in the case of MessageOrdering).
Along with,
> or in, the MessageId record, there must be a persistDuration field.
When the
> last message in that conversation is deleted from the persistent store
> (persistDuration has passed), wouldn't the ConversationId
automatically go with
> it? If there are still messages waiting because they are out of
order, would
> they not also be deleted when persistDuration expires? If you are
concerned
> with messages going away too quickly, then make persistDuration long.
>
> There is nothing forbidding another later message to be sent with the
original
> ConversationId but the message order would not be of concern since all
the
> previous messages have expired anyway.
>
> Or, are you saying ConversationId is held somewhere else?
>
> Regards,
>
> David Fischer
> Drummond Group.
>
> -----Original Message-----
> From: SHIMAMURA Masayoshi [mailto:shima.masa@jp.fujitsu.com]
> Sent: Monday, December 03, 2001 3:54 AM
> To: Dan Weinreb; mwsachs@us.ibm.com
> Cc: ebxml-msg@lists.oasis-open.org
> Subject: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
>
>
> Dan and Martin,
>
> My proposal's purpose is not management of ConversationId by MSH
itself.
> Its purpose is prevention of invalid ConversationId and acquisition of
> timing information of the end of conversation in MSH. Because message
> order is guaranteed per conversation. If higher layer (application or
> middleware) gives MSH invalid ConversationId, MSH will fail in
guarantee
> of message order. And also if MSH can't know when the conversation
> finishes, MSH can't decide that when the conversation's sequence
number
> information can be released from MSH's resource.
>
> So I can withdraw (1) in my proposals below, but I'd like to keep (2)
as
> my proposal. Because if higher layer gives MSH the status information
> (Start, Middle, End or Alone), sending MSH and receiving MSH can check
> invalid ConversationId and can know when the conversation finishes.
>
>
> On Thu, 29 Nov 2001 19:39:33 +0900
> SHIMAMURA Masayoshi <shima.masa@jp.fujitsu.com> wrote:
>
>>The specification of ConversationId element on page 20 has two
problems:
>>
>>1) The value of the ConversationId element is determined by the Party.
>>
>> ConversationId is very important for guarantee of message order.
>> Because message order is guaranteed per each conversation. Thus MSH
>> instead of Party should determines and manages the value of the
>> ConversationId to prevent invalid ConversationId value. I propose
>> following change:
>>
>> Line 823-825
>> ... The Party initiating a conversation determines the value of
the
>> ConversationId element that SHALL be reflected in all messages
>> pertaining to that conversation.
>> |
>> V
>> ... The Party indicates start and end of conversation to MSH. The
>> value of the ConversationId element is generated and managed by
the
>> MSH.
>>
>>2) Receiving MSH can't know the end of conversation.
>>
>> Receiving MSH holds received conversation's ConversationId in its
>> persistent storage for guarantee of message order. However
receiving
>> MSH has not any way to know the end of conversation. Thus receiving
>> MSH don't know when ConversationId's information can be removed
from
>> its persistent storage.
>>
>> To resolve the problem, I propose to add status attribute to
>> ConversationId element. The status attribute takes one of following
>> three 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.
>>
>
>
> 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
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>