5.4.1 Implications of not using a binary standard

The CORBA approach of standardizing on an IDL dialect and on formalized language bindings, instead of on the memory layout of interfaces as COM does, has a few implications. First, in-process object invocations are by necessity slower than had a binary standard been used. A CORBA object invocation is normally done indirectly through an ORB, which marshals all arguments before contacting the target object. In-process COM calls are identical to calling a C++ virtual member function, and thus entail no such performance penalty.

Some ORBs use the same stubs and skeletons for in-process calls as for remote calls, which means that in-process calls are marshalled, sent over the network loopback interface, and unmarshalled by the ORB before finally reaching the servant. The poor performance characteristics of this strategy can be mitigated using so-called collocation optimizations. Schmidt et al. (1999) describe two such optimization strategies implemented for the open-source TAO ORB, one of which routes calls through the object adapter, and one which forwards calls directly from the stub to the servant. The first strategy improves performance by several orders of magnitude, but is still twice as slow as a call through a dispatch table. The second strategy almost closes the performance gap, but is no longer CORBA-compliant (cutting the ORB out of the loop means that it can no longer perform any of its services, such as intercepting calls to enforce a threading or security policy). Also, it only works if the client and servant are known to be binary compatible, that is, if they have been written in the same language, or target the same binary object model. Despite primarily being designed for distributed systems, this research demonstrates that CORBA’s performance can be quite competitive with that of a binary standard.

A second implication of CORBA’s design is that making a solution compatible with CORBA is likely less onerous that making it compatible with COM, as a COM-compatible language must comply with the binary standard of COM, if native objects of that language are to be regarded as COM objects.¹ CORBA’s requirement that a runtime layer, in the form of an ORB, is used may entail a slight performance penalty, but it does free implementations from having to adopt a binary standard. Enabling a scripting language to be used for writing COM classes, for example, is possible, but requires script hosts to use internal data structures compatible with COM’s binary standard, or alternatively synthesize such structures at runtime. CORBA’s requirement that an ORB must be used to invoke operations successfully decouples the implementation structures used for objects from the ability to invoke operations on such objects. COM’s approach is effective from a performance point of view, though, and well-suited to environments where classes are expected to be written in a compiled object-oriented language such as C++, and accessed from a scripting language, such as older versions of Visual Basic.

A third implication of objects always communicating through an intermediary is that calls to objects can be trivially intercepted, which is more difficult if no such intermediary is present at all times. Some component models allow users to request the use of services in a declarative manner, which is realized by intercepting calls. This is the subject of Chapter 7.

Footnotes

1. A programming language with no native objects, or native objects that do not adhere to COM’s binary standard, may still make COM objects available if they, like C, support structures, pointers and calling functions through pointers. This approach can be used with a C++ compiler whose native objects are incompatible with COM, for instance.