[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-msg] MS v1.05
I understand, but the conversationId is a form of
narrowing the scope of what needs to be ordered, and provides
the requisite context for the service that would be needed
for a "cancel this booking" message.
The sequencing of the messages within a conversation can
often be predetermined by virtue of the messages to be exchanged.
At the very least, it could be determined that before a "cancel
this order" message can be processed, a "request for order" message
needs to have been received and if a "cancel" message is received
without a corresponding "order" message then it is in error and this
fact would be reported as a fault.
While certain situations MAY require explicit ordering of the
messages to be enforced by means of the MessageOrderSemantics
not all will have such a requirement, especially when either the
application already has built-in enforcement by some other means
or when it really doesn't matter at all.
Cheers,
Chris
Colleen Evans wrote:
> 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
>
>
>
> ----------------------------------------------------------------
> 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