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

Since there does not seem to be consensus, I am going with Chris on this one and
not make any changes.


-----Original Message-----
From: SHIMAMURA Masayoshi [mailto:shima.masa@jp.fujitsu.com]
Sent: Thursday, December 06, 2001 11:36 PM
To: Christopher Ferris; David Fischer
Cc: Ralph Berwanger; ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] Re: Comments on the 1.09 about ConversationId


On Thu, 06 Dec 2001 11:25:49 -0500
Christopher Ferris <chris.ferris@sun.com> wrote:
> I don't think that we need to say anything about
> this at all. As Marty has indicated, control over
> the conversation is within the application/process management
> domain, not the MSH. If anything, this would be something
> in the realm of the infamous Service Interface layer
> and not part of this spec.
> We're writing a protocol spec, not an implementation design
> specification.

As Martin showed, two ways are suggested to notify MSH conversation's
status in this list.

> Date: Thu, 06 Dec 2001 10:04:33 -0500
> From: Martin W Sachs <mwsachs@us.ibm.com>
> Subject: RE: [ebxml-msg] Re: Comments on the 1.09 about ConversationId
> To: David Fischer <david@drummondgroup.com>
> Cc: Christopher Ferris <chris.ferris@sun.com>,
>  Dan Weinreb <dlw@exceloncorp.com>,
>  ebxml-msg@lists.oasis-open.org
> The application does that but you have to be notified that the conversation
> is ended
> precisely so you can purge obsolete stuff from the persistent store.  Two
> approaches
> have already been suggested on this list:
>    1. Software at each party notifies its MSH
>    2. Software on the side the sends the last message notifies its MSH and
>    the
>    message header contains a flag that notifies the To MSH.

The second one needs to add status attribute to ConversationId element,
but I suggest that we adopt the second one.

In the second one, only the Sending Application has to notify MSH the
conversation's status. But in the first one, the Receiving Application
also has to notify MSH the conversation's status in addition to the
Sending Application. I believe the first one is not good way. Why same
information should be notified from two paths separately? If the status
information from Sending Application is not same as the status
information from Receiving Application, which is correct?

A conversation is initiated by the Sending Application and
ConversationId value is also determined by the Sending Application. Thus
the conversation's status should be specified by the Sending Application.
It is the natural way.

Please see for more detail of the second one:


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>

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

Powered by eList eXpress LLC