2.2.2 Calling in-process components

Invoking operations of components that run in-process can be realized in two primary ways. One approach is to lay down a binary standard that covers all components written for the component model, regardless of what programming language they are implemented in. At its core, this approach is similar to how procedural libraries work. A procedural library can be used by a program written in a programming language different from that of the library, as long as the program and library are both compiled for the same architecture and the program is aware of how to call procedures contained in the library. Procedural invocations are covered by standards known as calling conventions that standardize the mundane technical means used when one procedure calls another. This includes the order in which arguments are transferred, which arguments are transferred on the call stack and which are transferred in CPU registers (if any), handling of return values and stack clean-up.

Object-oriented programming languages need to handle all of the above, but also need to take objects into account. Specifically, the instance data of the receiving object (its state) must be passed, and there must be a way to realize dynamic dispatch (that is, to look up the implementation at runtime as opposed to at compile-time). Second-generation component models target architectures that are not, in themselves, object-aware, and thus must standardize object invocations (they also act as object models). These issues are explored in Chapter 3 and Chapter 4. COM is likely the best-known component model that is a binary standard.

The alternative approach, exemplified by CORBA, is to standardize on the IDL dialect in conjunction with formalized language bindings. This approach requires clients to rely on runtime software to make calls to objects. This software is supplied with the component model implementation and, at least partly, runs in the same process as the client. Vendors of different component model implementations may use different means to realize component calls. In order to ensure that a client can use any conforming component model implementation with components tested with a different implementation, different language bindings must be carefully standardized. A client written in one programming language can communicate with a component written in another language as long as the component model implementation supports both languages. The runtime software supplied with the component model implementation is responsible for translating calls from one language to another.