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: [ebxml-msg] Re: Comments on the 1.09 about ConversationId



Shimamura-san,

See my comments below.

I have not yet seen Dan Weinreb's posting quoted below so I am responding
to it at the same time.

Regard,
Martin Sachs
*************************************************************************************

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



SHIMAMURA Masayoshi <shima.masa@jp.fujitsu.com> on 11/30/2001 03:12:25 AM

To:    Martin W Sachs/Watson/IBM@IBMUS, ebxml-msg@lists.oasis-open.org
cc:
Subject:    Re: Comments on the 1.09 about ConversationId



Martin,

Thank you for sending your comments. However I don't understand why From
Party's internal ConversationId *value* should be propagated to To Party.

MWS:  The total of my argument is that there is no reason for the MSH to
manage the conversationId or to create its own internal form of the
conversationId.  The conversation is a construct of the application and
higher level middleware and the MSH only has to place the conversationId in
the header of the outgoing message. See my response below.

My proposal means that From Party's internal ConversationId value is
converted to MSH's ConversationId value through the indications of start
and end timing of the conversation, and then the MSH's ConversationId
value is propagated to To Party. Is there any problem?

>    MWS:  It is not at all clear to me that message order is a
>    responsibility of
>    the MSH.  I understand that the MS architecture has the MSH
>    guaranteeing order.  However in every conversation use case I have
>    seen, there is only one message outstanding in the conversation at
>    any time.  Hence the conversation semantics guarantee ordering without
>    assistance from the MSH.

Please remember Dan Weinreb's comments below. BPSS needs guarantee of
message order in messaging layer.

MWS:  Since the conversation semantics ensure that messages stay in order,
BPSS does not need that guarantee. In general, a collaboration protocol
defined by BPSS has only one message outstanding at any time, so there
is nothing for the MSH  to keep in order.

> Date: Tue, 16 Oct 2001 09:04:28 -0400 (EDT)
> From: Dan Weinreb <dlw@exceloncorp.com>
> Subject: Re: [ebxml-msg] Comments on ebMS_v1.04c
>
>    Date: Sun, 14 Oct 2001 22:37:02 -0400
>    From: Martin W Sachs <mwsachs@us.ibm.com>
>
>    New MWS comment:  I have never understood the value of
>    messageOrderSemantics, especially since ordering is performed
separately
>    for each conversation.
>
> I understand what you're saying here and you have an interesting point.
> I checked this out with my colleague Mike Rowley, who says:
>
>    Not quite.  Within a single collaboration, it is sometimes important
that the
>    messaging system not reverse the order of messages.  The BPSS may
require, for
>    example, that an Invoice be sent and then an Advanced Shipment Notice
(ASN),
>    in that order.  Neither of these have response messages so they may be
sent
>    one right after the other.  The code on the other side will be written
on the
>    assumption that the ASN will never arrive before the Invoice, so if
the
>    messaging system gets them out of order, it will break the
collaboration.

MWS:  The above is a very dangerous practice.  It seems to me that if the
invoice and
the ASN must appear in the order sent, the invoice should require an
acknowledgment
so that the collaboration protocol (conversation) can keep them in order.
Actually,
I believe that unless UDP or SMTP is being used, the ordering will be
maintained by TCP or
HTTP if both messages are sent on the same channel.  However, if we must
support use
case like this, I guess we are stuck with messageOrderSemantics.
>
> That is, the BPSS can specify a BinaryCollaboration that has two
> BusinessTransactionActivities, one after the other in a particular
> order, each one of them a BusinessTransaction specifying a document
> flow consisting only of a "request".

In addition, existing B2B applications also need guarantee of message
order in lower layer. Please remember Colleen Evans's comments:
<http://lists.oasis-open.org/archives/ebxml-msg/200110/msg00102.html>

I think there is no such rule that "only one message outstanding in the
conversation at any time" in the ebXML architecture and general business
process.

MWS:  No, there is no global set of rules for conversations.  I was
describing
the usual case.  I would not design a use case such as Dan described above.


By the way, I don't understand ConversationId enough. Because
ConversationId does not appear in ebXML's higher level specifications
such as BPSS or Core component at all. The ConversationId somehow appears
in only CPPA and Message Service. I'd like to understand details of
ConversationId. Can I have your answers to following questions?

MWS:  ConversationId is basically an implementation construct but it
must label each message belonging to the same conversation.

  - Why ConversationId is needed?

  MWS: A pair of trading partners may have multiple conversations.  The
  conversationId is necessary so that a received message can be routed
  to the correct conversation.

  - What kind of good effect is there in B2B?

  MWS: Use of ultiple concurrent conversations is essential for performance
  of B2B.
  Suppose, for example, that Fujitsu makes a single order for 100,000
  power supplies.  That conversation continues until the advance shipping
  notice is sent.  Without multiple concurrent conversations, the power
  supply manufacturer could not accept another order on the same CPA until
  it had
  shipped the first order to Fujitsu.  That could be a very long time.
  Consider
  that with just-in-time delivery, a company may want to pipeline its
  orders
  so that it issues another order before the first shipment arrives. That
  requires multiple concurrent conversations with the same CPA.


  - What layer does use ConversationId? Business application? Or any
    middleware? What kind of middleware?

    MWS:  Typically, the middleware that supports conversations creates
    the conversationId and the related state information for the
    conversation such as the software entry points for that conversation.
    The middleware that receives the message from the MSH uses the
    conversationId to find the state information for that conversation and
    thus to find the correct software entry point.


  - Why does ConversationId not appear in ebXML specifications except
    for CPPA and Message Service?

    MWS:  Mainly because ebXML has not defined the middleware
    that exists between the
    MSH and the application. BPSS essentially defines one conversation.
    The conversationId is created by middleware that manages the concurrent
    conversations.

  - Would you show use case of ConversationId?

    MWS:  I believe that my above explanations are the use case.


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



> Date: Thu, 29 Nov 2001 09:43:14 -0500
> From: Martin W Sachs <mwsachs@us.ibm.com>
> Subject: Re: [ebxml-msg] Comments on the 1.09 about ConversationId
> To: SHIMAMURA Masayoshi <shima.masa@jp.fujitsu.com>
> Message-id: <OF77C7AA5A.6C5D2F36-ON85256B13.004FA39D@pok.ibm.com>
>
>
> Shimamura-san,
>
> Please see below for some responses (MWS:)
>
> Regards,
> Martin Sachs
>
>
*************************************************************************************

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

>
>
>
> SHIMAMURA Masayoshi <shima.masa@jp.fujitsu.com> on 11/29/2001 05:39:33 AM
>
> To:    ebxml-msg@lists.oasis-open.org
> cc:
> Subject:    [ebxml-msg] Comments on the 1.09 about ConversationId
>
>
>
> 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:
>
>    MWS:  I disagree. The MSH is a messaging agent.  Management of the
>    conversation
>    is at a higher level, either in other middleware or in the application
>    or both.
>    The conversationId has to be supplied to the MSH by the higher levels
>    when the
>    higher levels request that a message be sent. I understand that the MS
>    specification provides for ordering the messages in a conversation but
>    that
>    is function which is not needed.  See comments below.
>
>    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.
>
>      MWS:  I agree that the Party (i.e. the application or appropriate
>      middleware)
>      has to indicate start and end of a conversation to the MSH.  I do
not
>      agree that the MSH should generate the conversationId or otherwise
>      manage it.  The conversationId is passed between Parties in the
>      message
>      header. The party sending the first message of theconversation
>      generates
>      the conversationId.  The other party may map that conversationId to
>      its own
>      internal conversation identifier.
>
> 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.
>
>    MWS:  It is not at all clear to me that message order is a
>    responsibility of
>    the MSH.  I understand that the MS architecture has the MSH
>    guaranteeing order.  However in every conversation use case I have
>    seen, there is only one message outstanding in the conversation at
>    any time.  Hence the conversation semantics guarantee ordering without
>    assistance from the MSH.
>
>    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.
>
>    MWS:  If it is agreed that conversations are really managed at a
higher
>    level in the middleware, then this attribute is not needed at all.
>    At each Party, the middleware component that manages the conversation
>    must notify the MSH when that conversation has ended.
>
>    MWS (soapbox here):  This discussion is another example of how the
>    MSG team has done itself a great disservice by not defining the
>    functions that an API to the MSH must provide.
>
>
>
>
> 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>
>
>
>






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


Powered by eList eXpress LLC