All
I hope you all understand and realize that I was using a simplified example,
I certainly did not intend for it to be a model to design from :-) that
said, I can think of several applications where in-order delivery would be
useful and if I had it available to me I would certainly use it, that's just
me.
Regards,
Brad
-----Original Message-----
From: Christopher Ferris [mailto:]
Sent: Wednesday, October 17, 2001 5:26 AM
To: ebXML Msg
Cc:
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:]
> Sent: Tuesday, October 16, 2001 6:10 AM
> To: SHIMAMURA Masayoshi; ebXML Msg
> Cc: ; 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:]
> Sent: Tuesday, October 16, 2001 4:45 AM
> To: ebXML Msg
> Cc: ; 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 <> 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 <>
> 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>
