Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] The DOM and the victim, the iconoclast and the believer
 Hi, After an hour of jogging (too bad, we do not have enough snow this week for skate skiing), and a week struggling with the DOM I discovered something interesting. He decided to interview my three fellow in this story: the victim, the iconoclast and the believer. The victim point of view: Suppose that you developed an application based on the OMG IDL, to be more precise a C++ application. So, when the DOM 1 recommendations where published you wrote a DOM 1 set of interfaces in the OMG IDL format, used the IDL compiler to translate the interface into C++ code, Got even the zeal to compile a Java code version, let it cook in the oven for 5 minutes, waited a couple hours until it is cool enough, implemented the code, and finally got a DOM level 1 component. You where proud of your accomplishment. Then, you started to make some experiment, plugged your DOM level 1 component with some DOM level 1 consumers, got surprised that it works, and thought gee what a beautiful day...until DOM 2 came.... You then discovered something funny, they expended several interfaces with new members. Bang W3C caused a mini version of the Y2K bug in your own garden. You didn't got the time to fill your cellar with enough provision to go through it. This is it! DOM 2 made it, the millennium catastrophe, you where simply clueless on how briliant people can bring you so much trouble....a courtesy of W3G (please maestro, can you play for the circumstances "Also Spreach Zaratoustra" or maybe the Mozart Reqiem would more appropriate - what are you recommending me :-). Why did we ended there? a) the C++ DOM level 1 client that you where using understood the DOM1 interface. the IDL compiler that you used translated the interface into a virtual table. To make things simple a virtual table is a table of pointer to functions. In C++, this virtual table is fixed and not expandable. Thus, if you change the vTable, then the client will not be able to interface to your component. Moreover, the new java client version that you just bought do not work with your DOM level 1 component even if the manufacturer said that it was compatible with your object broker (they said that they improved it, made bug fixes, made it faster, you simply just could resist to get it) b) Then to correct things, you simply write the DOM 2 interface as recommended (even with a bit of zeal), compile it, let it cook...and bang this time the is the other components that not work any more. Because you changed the vtable, itself the result of the IDL compilation, and because nothing is said in the OMG specs on how to implement an interface, then, using this freedom, the object broker manufacturer used a vtable, thinking that it makes sense. But, the end result being that now you have an impedance mismatch between two components, one that can only understand the DOM1 interface and the other the DOM2 interface. the iconoclast point of view now: If W3C made its work properly, they would have first defined the DOM1 interface, and thought seriously about legacy maintenance, backward compatibility, component robustness, etc... In simple words did a good software engineering job. What we would expect from the recommendations? a) that a component implementing only the DOM 1 interface would be able to work with a client that understand either the DOM1 or the DOM2 interface. And vise versa. What this means? That the object would allow evolution and backward compatibility by providing the possibility to query the interface. For example, if the client can understand only a DOM1 node interface, then it can query for a DOM1 node interface and do its work even if the provider supports the DOM1 and DOM2 interfaces. I do not get it, he said, a bit puzzled that W3C made such a big mistake. Ok let's recap a) we define all interfaces as contracts something that is stable throughout the time. A contract that can be fulfilled even if the components evolve. A contract that can be fulfilled in spite of the component evolution. If we change the contract we simply create a new one. If we change the interface, we simply create a new one. b) to do so, we have a mechanism to query the interface and get the right one. What? they say that your object broker should deal with that? Then how the object broker can differentiate between two interfaces having the same name but not the same specification? This is not mentionned in the OMG specs, so, how can we expect that they would do it in a standard way? What? they say, just recompile the code. but what do we do if we do not have the source code? What? they say, you're not suppose to have backward compatibility, manufacturers should make some money and therefore you have to buy again all the components each time a new recommendation is out. So, fine, please, include this as a note to the recommendations please :-) The believer point of view: OK, the humans are born with good intentions, only the society corrupts them (who said that? Jean Jacques Rousseau?). The WG didn't thought about backward compatibility and good software engineering practices. But the next recommendation will probably address these concerns. After all, these people listen to our concerns. Or probably they got the following problem, they wanted that the object to be called a node even if the interface evolves. If we would have a backward compatibility process, then the interface would have to be renamed and thus we would end up with an interface having the name "node124" in the year 2020. Yes indeed this is a weakness of the OMG model. But waht if we call the node "node_l1" or node_l2" OK "node_l124" is not as esthetically appealing as simply "node" but at least, we know to whom with interface and you know these days, it is preferable to know to whom you interface :-). Seriously, they will address this concern, after all, I am a believer. And you, what are you? Have you given some thought about this issue. Is the DOM a never ending prototype or a component definition with support for backward compatibility and evolution (able to balance both). Also, did someone experimented a DOM 1 or DOM 2 component compiled with a certain manufacturer IDL and then tried to interface with a fully compliant OMG component compiled with a different manufacturer IDL. Where you able to make both work together? Especially in the same address space. Personally I was able to do it if both where communicating on a socket using IIOP. Each one running in a different address space. Didier PH Martin ---------------------------------------------- Email: martind@n... Conferences: Web New York (http://www.mfweb.com) Book to come soon: XML Pro published by Wrox Press Products: http://www.netfolder.com xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ or CD-ROM/ISBN 981-02-3594-1 Please note: New list subscriptions now closed in preparation for transfer to OASIS. 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
