[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-msg] MS v1.05
I'd never design a system that depended upon order and certainly not something like this (cancel last order without explicitly referencing WHICH order I meant) but maybe that's just me. IMO, you have to expect things will go awry. You always need to be prepared for the unexpected ("no one expected the Spanish Inquisition!" ;-) Cheers, Chris 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