[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ebxml-msg] RE: Public usage scenario documents
David, You are repeating an age-old argument, that a good implementer will know what to do. - Except that there are plenty of well-publicized disasters that were clearly a result of under-specification and the implementers didn't make the right choices. - Except that in this case, there is a small matter of interoperability between arms-length implementations, so merely relying on implementers to know what to do won't get us there unless the specification is precise and complete. As for the disasters, here are two that, in my opinion, clearly result from underspecification: - The Mars orbiter that failed because someone mixed English and Metric units. - The Ariane 5 disaster. The rocket crashed because of an arithmetic overflow. A software component that calculated with the horizontal component of the rocket's acceleration was lifted from Ariane 4. But Ariane 5 accelerated much faster and the computation overflowed, flooding the system bus with error messages, killing the on-board systems. Worse, the component that failed should not have been on Ariane 5 at all because its computation wasn't needed. The point is that today's systems are far too complex to leave it to each implementer to get it right and interoperable with every other implementer. Each one is left to interpret the spec and do "the right thing". Even if everyone is top notch, the interpretations should not be expected to match. Regards, Marty ************************************************************************************* Martin W. Sachs IBM T. J. Watson Research Center P. O. B. 704 Yorktown Hts, NY 10598 914-784-7287; IBM tie line 863-7287 Notes address: Martin W Sachs/Watson/IBM Internet address: mwsachs @ us.ibm.com ************************************************************************************* David RR Webber - XMLGlobal To: Martin W Sachs/Watson/IBM@IBMUS <Gnosis_@compuser cc: "Cutler, Roger (RogerCutler)" <RogerCutler@chevrontexaco.com>, ve.com> ebxml-msg@lists.oasis-open.org, Randy Clark <Randy.Clark@bakerhughes.com>, "'bhaugen'" <linkage@interaccess.com>, eBTWG List <ebtwg@lists.ebtwg.org>, 05/28/2002 12:14 "'Duane Nickull'" <duane@xmlglobal.com>, Christopher Ferris AM <chris.ferris@sun.com> Subject: RE: Public usage scenario documents Message text written by Martin W Sachs > Both parties to the message exchange MUST persist enough state to allow recovery and getting back in sync. Specific state variables must be prescribed. They are at least those variables needed to restore the state of the transaction and conversation after system recovery, such as the conversation ID, CPA Id, service, action, and perhaps other parts of the message header. Timeouts and retries, as prescribed in the MSG spec, are not sufficient to cover system failures since the failure could last a very long time. <<<<<<<<<<<<<<<<<<<<<<< Marty, There appears to me to be no big surprise there. I would say this was EDI 101 - and that we hardly need things in the spec' which teach people how to build applications systems. People who know how to build product will include these feature sets and augment them according to their customer base requirements. So we do not need to teach this - and worse - it potentially forces people to build this in - even if their use case / customer model can use a lesser level of functionality quite happily. We have avoided this with Registry for example. If you are building a reliable messaging product - you are going to have a all manner of features in it over and above - like being able to check that the confirmation was signed by someone with a wristwatch on their left arm, et al/ Or worse - what about hardware level verification of tamperproof retention for authentication in a five year time frame? At some point you have to quit and know - this is outside our scope. Let's not confuse functional level detail - with technical specifications. Cheers, DW.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC