[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-msg] MS v1.05
I have a travel industry background, and we definitely had a requirement for message ordering in protocols - some of the same scenario issues Brad outlines below. If your flight booking, commit and cancellation message ordering in a session got mixed up, the result was a passenger showing up at the gate with no booking (something I'm sure some of you have had the pleasure of experiencing). Also, the JMS spec provides for message ordering (section 4.4.10 if you're interested http://java.sun.com/products/jms/docs.html): "JMS defines that messages sent by a session to a destination must be received in the order in which they were sent (see Section 4.4.10.2, “Order of Message Sends,” for a few qualifications). This defines a partial ordering constraint on a session’s input message stream. JMS does not define order of message receipt across destinations or across a destination’s messages sent from multiple sessions." and further down in the spec: "A client may use a transacted session to group its sent messages into atomic units (the producer component of a JMS transaction). A transaction’s order of messages to a particular destination is significant. The order of sent messages across destinations is not significant. See Section 4.4.7,“Transactions,” for more information." Colleen "Lund, Brad" wrote: > In-order messaging is important because say you send a message to order 100 > widgets, then you send an order to cancel that last order and you then send > a final message to order 10000 widgets, all in a very short amount of time. > If that is the way it is suppose to be BUT it arrives like this Order > 10000, cancel last order, order 100 widgets, it is very different and maybe > not what you intended. > > Brad > > -----Original Message----- > From: David Fischer [mailto:david@drummondgroup.com] > Sent: Tuesday, October 16, 2001 6:10 AM > To: SHIMAMURA Masayoshi; ebXML Msg > Cc: ebxml-cppa@lists.oasis-open.org; Michael DeNicola; IWASA Kazunori > Subject: RE: [ebxml-msg] MS v1.05 > > What is Message Ordering needed for? I know of several developing > implementations and I don't believe they are implementing Message Ordering? > Why > is it essential? > > As for backward compatibility, Chris' proposal to create a new element > called > AckRequested makes this all non-compatible. We could change > duplicateElimination=True|False back to > deliverySemantics=OnceAndOnlyOnce|BestEffort. They mean essentially the > same > thing. The change was for clarity but if this is a problem, let's change it > back? > > Regards, > > David Fischer > Drummond Group. > > -----Original Message----- > From: SHIMAMURA Masayoshi [mailto:shima.masa@jp.fujitsu.com] > Sent: Tuesday, October 16, 2001 4:45 AM > To: ebXML Msg > Cc: ebxml-cppa@lists.oasis-open.org; Michael DeNicola; IWASA Kazunori > Subject: Re: [ebxml-msg] MS v1.05 > > Folks, > > Splitting the document is good idea for easy to read the specification. > However I don't understand why "Reliable Messaging" and "Message Order" > sections are included in Optional part. These are essential functions > for actual business on the Internet. > > I propose that we choice one from following ideas: > > 1. Move "Reliable Messaging Module" and "Message Order Module" > sections to the end of Part 1. > > 2. Add more one part "Advanced Functionality" and place "Reliable > Messaging Module" and "Message Order Module" sections in the > Advanced Functionality part as following: > > Part I. Core Functionality > [same contents as V1.05] > Part II. Advanced Functionality > 6. Reliable Messaging Module > 7. MessageOrder Module > Part III. Optional Futures > 8. Delivery Receipts > 9. Message Status Service > 10. Message Service Handler Ping Service > 11. Multi-Hop Module > Part IV. Appendices > [same contents as V1.05] > > On Fri, 12 Oct 2001 17:57:31 -0500 > David Fischer <david@drummondgroup.com> wrote: > > This is v1.04 of the Messaging Document. This is a combined effort from > David > > Burdett (T2 lead), Chris Ferris, and David Fischer. > > > > We voted at the F2F to split the document into pieces or modules. Rather > than > > put those modules in a second document, we decided to split the document > into > > three parts. > > > > Part I > > Core Extension Elements and Modules > > MessageHeader element > > Manifest element > > Security Module > > Error Module > > Part II > > Optional Modules > > Delivery Receipts > > Reliable Messaging > > Message Status > > Message Service Ping/Pong > > Message Order > > Multi-Hop > > Part III > > Appendices > > > > Three new elements have been created: > > DeliveryReceiptRequested > > AckRequested > > MessageOrder > > > > The main difference for other elements is TraceHeaderList is under Via and > > QualityOfServiceInfo has new children. The other main difference is a new > actor > > for Acknowledgment so it can be targeted at the NextMSH or the ToPartyMSH. > There > > can now be 0, 1 or 2 instances of AckRequested and 0, 1 or 2 instances > > Acknowledgment. DeliveryReceipt is still in the spec but it is no longer > part > > of Reliable Messaging. > > > > OK, Let the comments begin! > > > > Regards, > > > > David Fischer > > Drummond Group > > 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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC