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 MessageOrder


OK, I will make this change since there does not seem to be any dissension.

David.

-----Original Message-----
From: SHIMAMURA Masayoshi [mailto:shima.masa@jp.fujitsu.com]
Sent: Wednesday, December 05, 2001 1:09 AM
To: David Fischer; ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] Re: Comments on the 1.09 about MessageOrder


David, 

On Tue, 04 Dec 2001 23:09:57 -0600
David Fischer <david@drummondgroup.com> wrote:
> Has this been decided?  Are we going to allow only ebXML RM for MessageOrder?
> 
> David.

I believe it was decided in the specification V1.0 already. The V1.0
says:

  8.4.7.2 messageOrderSemantics attribute
  ...
  If deliverySemantics is not OnceAndOnlyOnce and messageOrderSemantics
  is set to Guaranteed then report the error to the From Party with an
  errorCode of Inconsistent and a severity of Error (see 871 sections 10
  and 11).
                                                    [Line 870-872, P.23]


I re-send my proposals for MessageOrder for your convenience. Because I
revised a part of my proposals in 
<http://lists.oasis-open.org/archives/ebxml-msg/200111/msg00325.html>
and
<http://lists.oasis-open.org/archives/ebxml-msg/200112/msg00004.html>.
Following includes the revisions.

--------
Please change section 10 as following:

  P. 49, Line 1993-1994.
    It is highly RECOMMENDED that Reliable Messaging be used when a
    MessageOrder element is present.
      |
      V
    Reliable Messaging MUST be used when a MessageOrder element is
    present.

  P. 49, Line 1997.
    SHOULD
      |
      V
    MUST

  P. 49, Line 2009
    This line should be deleted, and insert following sentences after
    line 2016.

        When the value of the messageOrderSemantics attribute is set to
        "guaranteed", delivery behavior Once-and-Only-Once MUST be used.
        In the specification, the Once-and-Only-Once delivery behavior
        means that two conditions below are satisfied at same time:

        1) No lost message by one of following two mechanisms
            - Reliable messaging described in "7.5 ebXML Reliable
              Messaging Protocol". It means that the messages includes
              AckRequested element or Acknowledgment element.
            - Reliable communication protocol
        2) No duplicate message by the mechanism described in "7.5.6
           Duplicate Message Handling". It means that
           duplicateElimination attribute is set to true.

  P. 49, Line 2021.
    only when duplicateElimination is true. 
      |
      V
    only when delivery behavior is Once-and-Only-Once.

  P. 49, Line 2023.
    If duplicateElimination is not true
      |
      V
    If delivery behavior is not Once-and-Only-Once

  P. 49, 2025-2026
    that have a duplicateElimination attribute with a value of true 
      |
      V
    that have delivery behavior is Once-and-Only-Once

  P. 50, Line 2044 and 2046.
    when duplicateElimination has a value of true 
      |
      V
    when delivery behavior is Once-and-Only-Once

  P. 50, Line 2050 and 2052.
    When duplicateElimination is true 
      |
      V
    When delivery behavior is Once-and-Only-Once


Because guarantee of message order can be realized only when delivery
behavior is Once-and-Only-Once. Actually in the Message Service
specification V1.0, guarantee of message order can be specified only
when delivery behavior is Once-and-Only-Once.

Please consider following case:

    MessageOrderSemantics: Guarantee
    Delivery behavior: At-Most-Once (duplicateElimination is true and
                                     AckRequired is not used).

                            +----------+
    ---- Message (SN=1)---> |receiving |
    ---- Message (SN=2)---> |    MSH   |
    ---- Message (SN=4)---> |          |
                            +----------+

In this case, receiving MSH is not sure that the Message of SN 3
will reach after that. It might never reach forever. It means that
receiving MSH can't decide that when the Message of SN 4 should be
passed to application.
--------


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