[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: The DOM and the victim, the iconoclast and the believer
Hi Ray, Ray said: 1. The CORBA IDL interface of DOM is not intended to be functional, but rather only a language-neutral way of expressing the interfaces. It is not clear to me whether a functional CORBA binding is useful given that if the objects are independently remote, the efficiency problems may be too difficult, and if they are local, you probably wanted a more-local implementation. CORBA has not done a great job of hosting local objects. IIOP is more robust than a local invocation. The spec is silent on the topic, so you apparently cannot expect local objects to interoperate between ORBs. Didier reply: Why then also include exceptions? If this where simply a template then why having so much detail. So much details that the interface can be compiled and mapped to a particular language. This is more than a template. This is a fuly fonctional OMG IDL. If the intent was to provide just a template, then it is easy to write an abstract interface without having to use OMG IDL no? And yes, you are right the OMG spec do not mention anything about in process usage. Only inter-operability between object through sockets and IIOP is properly defined. Then, why use an interface definition that is not adapted to in-process processing? Most of DOM processing will happen in process no? Then why use an interface definition with a specification specialized for remote invocation? Ray said: 2. Such an interwoven model as the DOM needs version covariance, which if you are limited to fixed interfaces produces extreme fragmentation and loses the real type identity of objects when you try to covary them in a graph, as is required for DOM level 2, not to mention that invariant interfaces would force the simplest navigation operations in loops to involve typecasting for operations as every-day as checking the namespace. Fixed interfaces work fine in large services, but not in fine-grained object models. The DOM level is hierarchy-by-hierarchy, not node by node. Discovering a level 1 node in the middle of a level 2 hierarchy would be catastrophic, yet that's all the navigation methods guarantee if you stick with fixed interfaces without duplicating most methods. The so-called interface contract simply isn't adequate in this type of setting which requires covariance. A node is still a node within a level 2 hierarchy, even with a namespace attribute added. A node would not be a node within a level 2 hierarchy with no namespaceURI attribute, even though it was a node in a level 1 hierarchy with no namespaceURI attribute. Intermixed success and failure of level 2 methods within a hierarchy would be intolerable in many cases. You check the level before you start to perform operations, not by querying each node. Didier reply: Yes this is what I proposed in an other posting. To have an interface that a client can query to obtain the right DOM version before requiring anything else from the provider. Ray said: 3. Inflexible languages may wish to supply a seperate implementation for distinct levels to solve the covariance problem. But a good number of bindings including IIOP, Java, Javascript, and so on can easily expand existing interfaces. This turns out to be a very useful balance between splintering interfaces and objects without type. Objects have type, but the type is guaranteed as a complete hierarchy. Level 1 and level 2 clients can coexist with level 1 and 2 implementations in languages with enough flexibility. It would be strange, for example, to force Javascript to query different interfaces for core features clearly part of the same object just because of other languages that must do it that way. Didier reply: What you mention here is late binding languages as found in most interpreted languages. With these languages there is no big problems with interface compatibility. But, as you know, the world is more diverse than than and early binding language need a clear contract not a piece of soap. So for early binding languages, you have to know the contract, you have to know the interface and this latter has to be conformant to a certain specification. Ray said: 4. C++ by itself lacks enough mechanism to be binary-compatible with more than one version at a time. Environments which expect reusability of binary objects between shared libraries define something beyond the standard C++ language to prevent shifts in the binary protocols. Some fix the fundamental fragility of C++ vtables, and some do not. Some allow the interfaces to grow, and some do not. Raw C++ expects no migration of objects, so it is natural that a C++ binding would never expect to be compatible with more than one level at a time. Didier reply: Ray, for your information, there is some middleware interfacing models up there such as XPCOM for instance that allows C++ languages or anything else to provide a certain binary signature. This means that the different components within the same address space have the same binary signature and therefore can be binded properly. So, forget about using C++ binding which obviously will not lead you anywhere. You need a binary signature convention, so that objects in the same address space can communicate together. Please, consult the very small doc available at Mozilla.org for more info on this. And if you are incredulous about how a small bunch of people did better on this facet than a whole consortium (i.e. OMG), then, I can only say that talent is not necessarily proportional to the wallet size :-) Ray said: 5. The common-yet-unstandardized CORBA approach of just handing C++ servants from a separately-compiled library to a C++ client is the least-robust C++ model I have seen. Certain CORBA C++ implementations are more robust, such as SOM-based ones, I believe. The language bindings of the DOM are not auto-generated from the CORBA IDL -- each binding is permitted to do what is appropriate to the language to expand the interface. In COM, for example, an extension interface is added to an object to add methods. Since C++ lacks any standard solution to the problem you will find a variety of solutions depending upon the hosting object model's binding capability, and how flexible it is. I have raised the issue and called for robustness in the CORBA spec (in addition to what is already present in the IIOP spec). But so many really are only using CORBA for remote objects, so it isn't clear if it is a useful pursuit. It is not hard to do in C++ if the spec were to call for it, and it could be standardized so that local objects would be interoperable between ORBs. Didier reply: I agree that OMG never fully addressed the problem of inter-operability within a single address space. You are right to mention that the actual solution is not fulfilling this kind of need actually. In fact, the actual OMG specs are well adapted for remote invication not for in-process usage. Therefore, funny to see that a specification not well adapted to intra-address space usage was used to define the DOM. Probably some political presure within the DOM WG I presume. Ray said: I am working on my own C++ binding for DOM right now that has none of the traditional C++ fragility problems, again, by introducing a more-robust object model, which I call CROS (C++ Runtime Object Standard)... Didier reply: OK Ray, in fact, you are proposing a new middleware. Its OK. So now the question is: is your spec resolving the problem of intr-address space usage? can I develop a component in, let's say, Python and have it used by an other one developed in C++? If yes, you probably defined a binary signature and if this is the case, please let us know what is your solution. This may be interesting to learn and probably to use if you provide tool to make it a reality. Since then, XPCOM is freely available. Or when the WINE project will have made some progress, their DCOM implementation may be interesting (but actually lack an IDL compiler). Cheers 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
|