[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [ebxml-msg] MS v1.05
OK, I understand (except the Cancel order would have a PO number on it so it would never be "cancel last order"). However, unless you had the foresight to have Message Ordering on the first PO, none of this matters. The only way this works is if Message Order is turned on all the time -- unlikely. Since the two POs have two different PO numbers on them, the order of the POs is not important. the only (semi)important thing is that the Cancel PO comes after the first PO. Again, Message Ordering does not help unless you had the foresight to have Message Ordering on the first PO. It think in this case, you would use a ChangePO rather than cancel and reissue. Regards, David Fischer Drummond Group. -----Original Message----- From: Lund, Brad [mailto:brad.lund@intel.com] Sent: Tuesday, October 16, 2001 8:53 AM To: 'David Fischer'; SHIMAMURA Masayoshi; ebXML Msg Cc: ebxml-cppa@lists.oasis-open.org; Michael DeNicola; IWASA Kazunori Subject: RE: [ebxml-msg] MS v1.05 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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC