[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-msg] MS v1.05
Sometimes you have to live with a system you haven't designed and can't re-design
for whatever reason :-)
In the travel example I mentioned, the context for each action in a booking
scenario is based on the conversation ID. From the time the booking is
initiatied, until it is committed, there is no unique in-system reference for each
action (like a unique purchase order ID) that can be used.. Consequently, the
actions are tied together and referenced with a conversation ID. If the sequence
of messages within that conversation gets out of order, the way the booking is
finalized may not be in sync with the user's intent, with unpredictable results.
That's the current reality of about every big travel system out there (Sabre,
Worldspan, Galileo, Apollo, Travelocity, etc.). If there are ways to prevent
things going awry by provisioning sequencing within a protocol spec, why is that a
problem?
Colleen
Christopher Ferris wrote:
> 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>
> >
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
--
Colleen Evans
Principal Product Manager
Sonic Software Corporation
phone: 720 480-3919 or 303 791-3090
email: cevans@sonicsoftware.com
website: http://www.sonicsoftware.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC