CORBA - Steve Vinoski, 1997 ============================= Summary: This article presents a high-level overview of CORBA, its key features, current state and future directions. Motivation ---------- To provide a common software development platform to accomodate heterogeneity in physical networks, protocols, hardware, OS, programming languages, etc. etc. Key features ------------ - Distributed objects: Pretty much like those in the "Network Objects" paper. CORBA is the layer that enables interaction between clients and servers who implement object functionality. The following are made invisible to the client: object location, object implementation, object execution state, network protocols for communication. Essentially, a software developer is freed from low-level distributed system programming details. She can focus on issues pertaining to her own application domain. - Interface Definition Language (IDL): Key feature is language independance. Consists of types, structs, exceptions, modules and inheritance. "Language mappings" define how these features are mapped to facilities of specific programming languages. For example, there are language mappings for C, C++, Smalltalk, etc. - Language compilers, stubs, skeletons: A language compiler takes an IDL and translates it into client-side 'stubs' and server-side 'skeletons'. They are analogous to the stubs and upcall mechanism in DEC RPC. Dispatching using stubs and skeletons is 'static invocation'. Stubs are also called 'proxies'. - Interface Repository (IR) and Dynamic Despatch: CORBA defines an IR that is simply a directory of all interfaces registered with it. A client can either bind to interfaces statically or browse through IR and select interfaces at run time. Functions from such interfaces need be dispatched dynamically, a mechanism that CORBA supports. - Function call invocation: CORBA allows three kinds of invocations: Synchronous, Deferred Synchronous ("asynchronous") and One-Way Invocation ("fire and forget"). The last two are not supported by DEC RPC, i believe [correct?]. - Extensive libraries: For specific application domains. Caveats ------- CORBA designers made one gross error: They didn't define the data representation and exchange format for ORB. Therefore, two implementations could be non-interoperable, something that indeed happened as different companies chose their own data formats. This error was later corrected, as CORBA became popular. Discussion ---------- - What's DCOM and how is it different from CORBA? - Proxy objects have evolved over the years from being dumb stubs to intelligent modules providing caching, replication etc. Any comments? - Recently, there has been work in sharing objects in DSM style, using object-specific consistency protocols. What applications motivate this approach, as against CORBA?