CORBA 2.0 mechanisms and services define how today's desktop objects and components can ride on tomorrow's intergalactic software bus
Robert Orfali and Dan Harkey
When Microsoft and CI Labs talk about OLE components and OpenDoc objects, they focus on the benefits of document-centric (as opposed to today's mostly application-centric) desktop computing. But these objects and components won't live only on the desktop. They're destined to become the currency of the intergalactic client/server era. How will OLE and OpenDoc talk to servers? How will object servers deliver the mission-critical support for transactions, concurrency, and scalability that today is the province of TP (transaction processing) monitors? The OMG (Object Management Group) has long a
nticipated these problems. Version 2.0 of the CORBA (Common Object Request Broker Architecture ) aims to solve them by defining key object services, including transactions, concurrency, relationships, and externalization. Microsoft, with help from Digital Equipment, has a rival solution called COM (Common Object Model), and Novell's AppWare Distributed Bus may be yet another contender. All this enables us to say that we have seen the future, and it is distributed objects.
What's a distributed object? A C++ or Smalltalk object encapsulates code and data, and can be specialized by means of inheritance, but can't reach across compiled-language or address-space boundaries. In contrast, distributed objects are packaged as binary components accessible to remote clients by means of method invocations. Clients don't know which language or compiler built a server object, or where on the intergalactic network the object physically resides. They need to know only its name and the interface it publishes.
Ul
timately we want supersmart client/server components that can not only interoperate but collaborate. For example, agents roaming the intergalactic network should be able to negotiate with other agents. In a homogenous programming environment, such as Telescript, that's easy. But the emerging world of software components is heterogeneous, and we need standards that set the rules of engagement among different types of components.
OMG's Object Management Architecture
The OMG envisions a common interconnection bus (see the figure "
CORBA Standards for Component Evolution
") that hosts client components, core services needed by all components (including naming, persistence, events, and transactions), and common facilities for component collaboration. These may be horizontal in the case of user-interface or system management facilities that interconnect components from different application domains, or vertical when specific to particular domains--say, car rental or
hotel management. In these vertical domains, users will manipulate suites of business objects on the desktop, and tap into underlying client/server webs.
In the fall of 1990, OMG first published the Object Management Architecture Guide. It was revised in September 1992, and the details of the common facilities were added in January 1995. The four key elements of the OMG's architecture are:
--
The ORB (Object Request Broker):
It's the object interconnection bus. Clients are insulated from the mechanisms used to communicate with, activate, or store server objects. CORBA 1.1, introduced in 1991, defined the IDL (interface definition language) and APIs that enable client/server object interaction within a specific implementation of an ORB. CORBA 2.0 specifies how ORBs from different vendors can interoperate.
--
Object services:
Packaged as components with IDL-specified interfaces, these services extend the capabilities of the ORB. OMG has adopted the following o
bject services: naming, event notification, persistence, life-cycle management, transactions, concurrency control, relationships, and externalization. Five new services are expected by mid-1995: query, licensing, properties, security, and time. These object services should be bundled with every ORB.
--
Common facilities:
These collections of IDL-defined components define the rules of engagement for application objects. They're categorized as horizontal and vertical. The horizontal ones address four disciplines: user interface, information management, systems management, and task management. The user-interface services, like OLE and OpenDoc, govern on-screen activities such as in-place editing. The information-management services resemble the OLE and OpenDoc mechanisms for compound document storage and data interchange. Systems management services define interfaces used to manage, instrument, install, configure, operate, and repair distributed objects. Task management services include thin
gs like work flow, long transactions, agents, scripting, and rules. In the realm of vertical facilities, IDL-defined interfaces will support suites of interacting objects specialized for health, retail, finance, and other domains.
--
Application objects:
These are components specific to end-user applications. To participate in ORB-mediated exchanges, they too must be defined using IDL. Application objects, of course, build on top of services provided by the ORB, common facilities, and object services.
The CORBA 2.0 ORB and object services should be incorporated into commercial ORBs starting in mid-1995. The application objects and common facilities, however, are works in progress. When the common facilities are ready for prime time, perhaps by the end of 1996, CORBA will provide IDL interfaces for virtually every distributed service we know today. Note that it is not the OMG's goal to reinvent all of these services, but rather in many cases to provide IDL wrappers for existing st
andards. The ambitious goal of CORBA is to turn everything into nails, and give everyone a hammer. The nails are the IDLized services, and the hammer is the IDL interface to these services.
The ORB Client
A CORBA ORB looks more complex (see the figure "
Structure of a CORBA 2.0 ORB
") than it really is. The key is to understand that CORBA, like SQL, provides both static and dynamic interfaces. Let's first review how CORBA works on the client side.
Client IDL stubs provide the static interfaces to object services. These precompiled stubs, generated by the IDL compiler, define how clients invoke corresponding services on the servers. With dynamic invocation APIs, on the other hand, you can (at run time) discover a service that you want to invoke, obtain a definition of it, issue a parameterized call to it, and receive a reply from it.
Interface repository APIs allow you to obtain and modify the descriptions of all the registered component interface
s, the methods they support, and the parameters they require. CORBA calls these descriptions method signatures. The interface repository stores, updates, and manages object interface definitions, and your programs use its APIs to access and update this information.
With CORBA 2.0, ORBs provide global identifiers called repository IDs that uniquely and globally identify a component and its interface across multiple ORBs and repositories. The repository IDs are system-generated unique strings that enforce naming consistency across repositories--no name collisions are allowed. They're generated by means of DCE (Distributed Computing Environment) UUIDs (universally unique IDs) or a user-supplied unique prefix attached to IDL-scoped names.
The ORB interface (used by clients and servers alike) supplies miscellaneous useful APIs. For example, there are APIs to convert between object references and strings. These calls are handy if you need to store or communicate object references.
With support
for both static and dynamic client/server invocations and an interface repository, CORBA is more powerful and flexible than first-generation middleware, such as RPC (remote procedure call) (see "ORB vs. RPC"). Static invocations are easy to program, fast, and self-documenting. Dynamic invocations, while harder to program, offer maximum flexibility and are essential when applications must discover services at run time.
The ORB Server
Servers can't tell the difference between static and dynamic invocations. The same message semantics apply in both cases. The ORB locates an object adapter, transmits the parameters, and transfers control to the object implementation through the server IDL stub (also called a skeleton).
Static skeletons provide interfaces to each service exported by the server. These stubs, like the ones on the client, are created using an IDL compiler. A static skeleton provides hardwired support for the IDL-defined methods of a particular object class.
The dynamic skeleton interface, introduced in CORBA 2.0, provides a run-time binding mechanism for servers. The dynamic skeleton inspects the parameters of an incoming message to determine a target object and method. This technique is handy for building bridges between ORBs. It can also be used by interpreters and scripting languages that have to fabricate object implementations on the fly. Dynamic skeletons can receive either dynamic or static invocations from clients.
The object adapter sits atop the ORB's core communication services, accepting requests for service on behalf of the server's objects. It provides the run-time environment for instantiating server objects, passing requests to them, and assigning object IDs (object references) to them. The object adapter also registers the classes it supports and their run-time instances (i.e., objects) with the implementation repository. CORBA specifies that each ORB must support a standard adapter called the basic object adapter. Servers may, however,
support more than one object adapter (see "Is an Object Adapter a TP Monitor?").
The implementation repository lists the classes a server supports, the objects that are instantiated, and their IDs. It also serves as a common place to store trace information, audit trails, security, and other administrative data.
CORBA 2.0's Intergalactic ORB
CORBA 1.1 was only concerned with creating portable object applications; the implementation of the ORB core was left as an exercise for the vendors. The result was components that were portable but not interoperable. CORBA 2.0 tackled interoperability by specifying the IIOP (Internet inter-ORB protocol)--a scary name for TCP/IP with some CORBA-defined message exchanges that serve as a common backbone protocol. The messaging part of the backbone supports common data representations for all the OMG IDL types, interoperable object references, and common message formats and semantics optimized for ORB exchanges. Every ORB that calls itself
CORBA-compliant must either speak IIOP natively or be able to bridge to it.
CORBA 2.0 specifies DCE as the first of many optional inter-ORB protocols, called ESIOPs (Environment-Specific Inter-ORB Protocols). At a semantic level, the DCE and Internet ORB implementations use the same messaging protocols. The IIOP is designed to enable out-of-the-box ORB interoperability over TCP/IP. The DCE ESIOP provides a more robust environment for mission-critical ORBs requiring advanced features, such as Kerberos security, cell and global directories, distributed time, and authenticated RPC.
CORBA 2.0 also defines how to build ORB-to-ORB bridges (see the figure "
Generic ORB-to-ORB Bridging Using CORBA 2.0's Dynamic Facilities
"). When a client on one ORB calls a server on another ORB, the new DSI (dynamic skeleton interface) transmits the request to the target ORB, and then the dynamic invocation interface invokes the target object on that ORB. This dynamic technology is also well-suited
for building gateways to non-CORBA object busses, such as COM (see "COM: The Other Object Bus") and the Distributed AppWare Bus.
The CORBA 2.0 Object Services
The CORBA object services provide a unique way to build custom middleware. It's unlike anything today's conventional client/server systems offer. Component providers can use mix-in multiple inheritance to integrate their own code with the CORBA object services. Components gain persistence or transactional capability by inheriting these things through IDL interfaces.
OMG currently defines standards for eight object services:
--
The life-cycle service
defines how to create, copy, move, and delete components.
--
The persistence service
provides a single interface for storing components in a variety of containers, including object databases, relational databases, and simple files.
--
The naming service
enables components to locate other components. The serv
ice allows objects to be bound to existing network directories or naming contexts, including ISO's X.500, OSF's (Open Software Foundation's) DCE, and Sun's NIS (Network Information Service).
--
The event service
allows components on the bus to dynamically register (or unregister) interest in specific events. The service defines a well-known object called an event channel that collects and distributes events among components.
--
The concurrency service
provides a lock manager that can obtain locks on behalf of either transactions or threads.
--
The transaction service
provides two-phase commit coordination among recoverable components using either flat or nested transactions (see "CORBA's Object Transaction Service").
--
The relationship service
provides a way to create associations (or links) between components. It also provides mechanisms for traversing the links that group these components. The service can be used to enforce
referential integrity constraints, and to track containment relationships and any other kind of linkages among components.
--
The externalization service
provides a standard way to stream data into and out of an object.
These services, and the five additional services OMG is currently working to define, empower components and provide a robust environment in which they can safely live and play.
Intergalactic client/server requires a common interconnection bus and an environment in which smart components can collaborate. CORBA 2.0 provides both and, with 440 member organizations backing the standard, we may finally get the universal plumbing we need to sustain the next client/server revolution.
illustration_link (35 Kbytes)
A common interconnection bus, the ORB (Object Request Broker) hosts syst
emwide object services, such as naming, persistence, and transactions; application-specific services, including user-interface technologies similar to OLE and OpenDoc; and application objects that wield all these other services.
illustration_link (16 Kbytes)
CORBA clients invoke services statically by way of compiled IDL (interface definition language) stubs or on the fly using of dynamic invocation APIs. CORBA servers route client requests to object implementations analogously by means of static skeletons or at run time using the new dynamic skeleton interface. Clients and servers share the utility APIs of the ORB (object request broker) interface.
illustration_link (12 Kbytes)
Logically, a client in communication with one ORB (Object Request Broker) just requests a service from a server associated with another ORB. Under the covers, ORB A uses the new DSI (dynamic skeleton interface) to route the client's request across an inter-ORB bridge, and then ORB B issues a dynamic invocation to the server.
Bob Orfali and Dan Harkey are (along with Jeri Edwards) the authors of Essential Client/Server Survival Guide (VNR, 1994). They currently work on the application of distributed object technology at IBM. You can reach them on the Internet at
harkey@vnet.ibm.com
.
Client/Server with Distributed Objects
