>The persistDuration would be set to expire after the termination of the
validity period for
the quote.
Not that an MSH should not have message-persistence-duration for logging
purposes or whatever,
but I would view this as a business function to be modeled in a business
flow language such as
WSFL, XLANG, BPSS, etc.
Another Example at that level: On an airline GDS to book a flight there are
3 basic steps:
Availablility query -> price quote -> book.
The price quote is a specialization of a Business Offer that expires. (In
fact, this is exactly
what happens on AA.COM.).
I would expect that function to be enforced within the business logic, not
using the ebXML MSH
persistentDuration.
Scott
______________
Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
512-823-8097 (TL 793-8097) (Cell: 512-415-8490)
srh@us.ibm.com, Fax: 512-838-1074
Ralph
Berwanger To: ebxml-msg@lists.oasis-open.org
<rberwanger@bT cc:
rade.com> Subject: RE: [ebxml-msg] Re: Comments on the 1.09 about
ConversationId
12/03/2001
03:26 PM
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>