OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [ebxml-msg] Re: Comments on the 1.09 about ConversationId


>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>





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC