Corba

A Real World Problem

WHAT IS CORBA? - the Common ORB architecture

Distributed objects are the next wave in Internet innovation. CORBA, the Common Object Request Broker Architecture defined by the Object Management Group (OMG), specifies how software objects distributed over a network can work together without regard to client and server operating systems and programming languages.

CORBA is a complete distributed object platform. It extends applications across networks, languages, component boundaries, and operating systems. A CORBA Object Request Broker (ORB) connects a client application with the objects it wishes to use. The client application does not need to know whether the object resides on the same computer or on a remote computer elsewhere on the network. The client application needs to know only two pieces of information: the object's name and how to use the object's interface. The ORB takes care of the details of locating the object, routing the request, and returning the result

CORBA fits the component-based and Internet-based approaches to building and using software. It defines a way to divide application logic among objects distributed over a network, some on clients, others on a variety of servers. It also defines a way for those objects to communicate and use each others' services. CORBA supplements Java with a rich set of services that includes introspection, dynamic discovery, transactions, security, naming, and more. CORBA links the Java mobile code environment and the world of interoperable objects.

CORBA ORB Architecture

The following figure illustrates the primary components in the CORBA ORB architecture. Descriptions of these components are available below the figure.

CORBA ORB Architecture

Object Implementation (Server) -- This defines operations that implement a CORBA IDL interface. Object implementations can be written in a variety of languages including C, C++, Java, Smalltalk, and Ada.
Client -- This is the program entity that invokes an operation on an object implementation. Accessing the services of a remote object should be transparent to the caller.
Object Request Broker (ORB) -- The ORB provides a mechanism for transparently communicating client requests to target object implementations. The ORB simplifies distributed programming by decoupling the client from the details of the method invocations. This makes client requests appear to be local procedure calls. When a client invokes an operation, the ORB is responsible for finding the object implementation, transparently activating it if necessary, delivering the request to the object, and returning any response to the caller.
ORB Interface -- An ORB is a logical entity that may be implemented in various ways (such as one or more processes or a set of libraries). To decouple applications from implementation details, the CORBA specification defines an abstract interface for an ORB. This interface provides various helper functions such as converting object references to strings and vice versa, and creating argument lists for requests made through the dynamic invocation interface described below.
CORBA IDL stubs and skeletons -- CORBA IDL stubs and skeletons serve as the ``glue'' between the client and server applications, respectively, and the ORB. The transformation between CORBA IDL definitions and the target programming language is automated by a CORBA IDL compiler. The use of a compiler reduces the potential for inconsistencies between client stubs and server skeletons and increases opportunities for automated compiler optimizations.
Dynamic Invocation Interface (DII) -- This interface allows a client to directly access the underlying request mechanisms provided by an ORB. Applications use the DII to dynamically issue requests to objects without requiring IDL interface-specific stubs to be linked in. Unlike IDL stubs (which only allow RPC-style requests), the DII also allows clients to make non-blocking deferred synchronous (separate send and receive operations) and oneway (send-only) calls.
Dynamic Skeleton Interface (DSI) -- This is the server side's analogue to the client side's DII. The DSI allows an ORB to deliver requests to an object implementation that does not have compile-time knowledge of the type of the object it is implementing. The client making the request has no idea whether the implementation is using the type-specific IDL skeletons or is using the dynamic skeletons.
Object Adapter -- This assists the ORB with delivering requests to the object and with activating the object. More importantly, an object adapter associates object implementations with the ORB. Object adapters can be specialized to provide support for certain object implementation styles (such as OODB object adapters for persistence and library object adapters for non-remote objects).
IIOP/GIOP -- The IIOP specification defines a set of data formatting rules, called CDR (Common Data Representation), which is tailored to the data types supported in the CORBA Interface Definition Language (IDL). Using the CDR data formatting rules, the IIOP specification also defines a set of message types that support all of the ORB semantics defined in the CORBA core specification (http://www.omg.org/corba/corbiiop.htm). Together, the CDR formatting rules and the message formats constitute an abstract protocol called GIOP, which stands for General Inter-ORB Protocol. GIOP messages can be sent over virtually any data transport protocol, such as TCP/IP, Novell SPX, SNA protocols, etc. To ensure "out-of-the-box" interoperability between ORB products, the IIOP specification requires that ORBs send GIOP messages over TCP/IP connections because TCP/IP is the standard connection-oriented transport protocol for the Internet. To put it very simply, GIOP + TCP/IP = IIOP.
Objects publish their identities and locations in the form of object references. The CORBA 2.0 specification dictates a common format for object references exchanged over IIOP, called IOR (Interoperable Object Reference) format. An IOR contains one or more profiles. Each profile describes how a client can contact and send requests to the object using a particular protocol. All legal IORs must have at least one IIOP profile, thus ensuring that wherever that reference goes, any CORBA-compliant ORB will be able to locate the object and send requests to it. The IIOP profile contains the Internet address of the object's server and a key value used by the server to find the specific object described by the reference.

Object references can be converted into character strings, which can be published arbitrarily, like URLs, in email messages, files, databases, directories, and so on. Any CORBA-compliant application can convert the string into an IOR and use it to locate and invoke the object.
Interface Repository -- The Interface Repository is a service that provides persistent objects that represent the IDL information in a form available at runtime. The Interface Repository information may be used by the ORB to perform requests. Moreover, using the information in the Interface Repository, it is possible for a program to encounter an object whose interface was not known when the program was compiled, yet, be able to determine what operations are valid on the object and make an invocation on it.
In addition to its role in the functioning of the ORB, the Interface Repository is a common place to store additional information associated with interfaces to ORB objects. For example, debugging information, libraries of stubs or skeletons, routines that can format or browse particular kinds of objects, etc., might be associated with the Interface Repository.
Implementation Repository -- The Implementation Repository contains information that allows the ORB to locate and activate implementations of objects. Although most of the information in the Implementation Repository is specific to an ORB or operating environment, the Implementation Repository is the conventional place for recording such information. Ordinarily, installation of implementations and control of policies related to the activation and execution of object implementations is done through operations on the Implementation Repository.

OMG Reference Model Architecture

Object Services -- These are domain-independent interfaces that are used by many distributed object programs. For example, a service providing for the discovery of other available services is almost always necessary regardless of the application domain. Two examples of Object Services that fulfill this role are:
- The Naming Service -- which allows clients to find objects based on names;
- The Trading Service -- which allows clients to find objects based on their properties.
There are also Object Service specifications for lifecycle management, security, transactions, and event notification, as well as many others [OMG:95b].
Common Facilities -- Like Object Service interfaces, these interfaces are also horizontally-oriented, but unlike Object Services they are oriented towards end-user applications. An example of such a facility is the Distributed Document Component Facility (DDCF), a compound document Common Facility based on OpenDoc. DDCF allows for the presentation and interchange of objects based on a document model, for example, facilitating the linking of a spreadsheet object into a report document.
Domain Interfaces -- These interfaces fill roles similar to Object Services and Common Facilities but are oriented towards specific application domains. For example, one of the first OMG RFPs issued for Domain Interfaces is for Product Data Management (PDM) Enablers for the manufacturing domain. Other OMG RFPs will soon be issued in the telecommunications, medical, and financial domains.
Application Interfaces - These are interfaces developed specifically for a given application. Because they are application-specific, and because the OMG does not develop applications (only specifications), these interfaces are not standardized. However, if over time it appears that certain broadly useful services emerge out of a particular application domain, they might become candidates for future OMG standardization.

CREATING CORBA OBJECTS

You can create CORBA objects in one of two general ways:

Write and compile an interface definition language (IDL) specification.
Use java2iiop (also called Caffeine), provided with Netscape's Enterprise Server and the most recent version of Visigenic's Vbroker. This utility processes Java bytecode and generates files for CORBA objects.

USING IDL

CORBA defines an interface definition language (IDL) that provides a language-neutral way to describe a CORBA object and the services it provides. IDL lets components written in different languages communicate with each other using IIOP and the rest of the CORBA architecture. CORBA objects can reside on different types of systems, including Windows or UNIX servers and IBM 3090 or DEC VAX mainframes. They can be written in different languages. As long as interfaces to their services are written in IDL, the objects can communicate and use each others' services through ORBs on clients, servers, database systems, mainframes, and other systems on the network.

Developing Applications

To develop distributed applications with IDL, you must first identify the objects required by the application. You will then usually follow these steps:

Write a specification for each object using the Interface Definition Language (IDL).
Use idl2java to generate the client stub code and service skeleton code.
Implement the service interface.
Write an application (often called a server application or object server) to create, activate, and register an instance of the service.
Write the client application (or applet) code.
Use javac to compile the service interface, server application, and client application (or applet).
Start the server application.
Run the client application (or applet). When the client invokes a service method, the call goes through the client-side stubs to the ORB, which uses the server-side skeletons and information from the server application to locate the service implementation and call the method.

Caffeine: CORBA WITHOUT IDL

Netscape's Enterprise Server 3.0 includes a java2iiop compiler (also called Caffeine) for defining CORBA-compliant interfaces using Java instead of IDL. By using java2iiop, you can generate the necessary container classes, client stubs, and server skeletons from Java bytecode. Caffeine makes it easy for Java programmers to write objects that interoperate across Java VMs using Java language semantics. You don't have to learn CORBA IDL to make Java objects remotable and accessible via a CORBA IIOP ORB. Caffeine also lets you pass objects by value. Finally, it provides a naming service that maps CORBA object references to URLs. The following figure shows the development process.

Other Examples

Hello World with Java IDL

"Ping" Client with Vbroker

ORBs Tested for this Class

OOC Omnibroker OOC's CORBA-2 compliant Object Request Broker. It offers a complete C++ and Java mapping, comes with complete source and is free for non-commerical use.
Visigenic Vbroker
Sun's Java IDL

COMPETITION

This section presents competing technologies, that is, technologies developed to do what CORBA does.

HTTP and CGI The CGI/HTTP protocol is clumsy, stateless, and extremely slow-much slower than CORBA IIOP. Programming Internet client-server applications with CGI is a very poor choice. The bad news is that CGI is the premier three-tier client-server application model for the Internet today. The good news is that the leading Internet architects, well aware of CGI's shortcomings, are migrating to alternative technologies. Netscape will do its part by bundling a CORBA ORB with every browser.

RMI First, RMI does not provide language-neutral messaging services. In other words, RMI objects can talk only to other RMI objects. With RMI, you cannot invoke objects written in other languages or vice versa. Second, RMI does not support dynamic invocations and interface repositories. Third, RMI does not provide a wire protocol for security and transactions. RMI is both proprietary and lightweight. It was not designed to interoperate with other ORBs or languages. Unlike CORBA's IIOP, RMI is not a suitable backbone for the Internet or intranets; it lacks services IIOP provides.

DCOM A DCOM object is not an object in the object-oriented programming sense; a DCOM object does not have a persistent object reference that lets you reconnect to the same object at a later time. In other words, DCOM objects do not maintain state between connections. This can be a big problem in environments where you have faulty connections - for example, the Internet. The current implementation of DCOM does not support distributed naming services; it is based on the NT registry. Configuring DCOM and installing type libraries is tedious and labor-intensive. DCOM is also Windows-centric. Very few implementations of DCOM run on non-Windows platforms. Finally, for DCOM to scale on the server side, it requires the Microsoft Transaction Server (MTS). Microsoft has no immediate plans to port MTS to non-NT platforms.

RPC With an RPC, you call a specific function (the data is separate). In contrast, with an ORB, you call a method within a specific object. Different object classes may respond to the same method call differently. Because each object manages its own private instance data, the method is implemented on that specific instance data. ORB method invocations are precise. The call gets to a specific object that controls specific data and then implements the function in its own class-specific way. In contrast, RPC classes have no specificity: all the functions with the same name are implemented the same way.

What about RMI?

Though RMI is an ORB in the generic sense that it supports making method invocations on remote objects, it's not a CORBA-compliant ORB. RMI is native to Java. It is, in essence, an extension to the core language. RMI depends on many of the other features of Java-object serialization, portable, down-loadable object implementations, and Java interface definitions, among others. The resulting mechanism is very natural for Java programmers to use. They never have to leave the Java programming environment or learn any new "foreign" technology. On the other hand, RMI has some limitations, principle among which is a consequence of its greatest strength-its tight integration with Java makes it impractical for use with objects or applications written in any other language.

Java, RMI and CORBA

A white paper prepared by David Curtis, Director of Platform Technology Object Management Group


HTTP and CGI	The CGI/HTTP protocol is clumsy, stateless, and extremely slow-much slower than CORBA IIOP. Programming Internet client-server applications with CGI is a very poor choice. The bad news is that CGI is the premier three-tier client-server application model for the Internet today. The good news is that the leading Internet architects, well aware of CGI's shortcomings, are migrating to alternative technologies. Netscape will do its part by bundling a CORBA ORB with every browser.

RMI	First, RMI does not provide language-neutral messaging services. In other words, RMI objects can talk only to other RMI objects. With RMI, you cannot invoke objects written in other languages or vice versa. Second, RMI does not support dynamic invocations and interface repositories. Third, RMI does not provide a wire protocol for security and transactions. RMI is both proprietary and lightweight. It was not designed to interoperate with other ORBs or languages. Unlike CORBA's IIOP, RMI is not a suitable backbone for the Internet or intranets; it lacks services IIOP provides.

DCOM	A DCOM object is not an object in the object-oriented programming sense; a DCOM object does not have a persistent object reference that lets you reconnect to the same object at a later time. In other words, DCOM objects do not maintain state between connections. This can be a big problem in environments where you have faulty connections - for example, the Internet. The current implementation of DCOM does not support distributed naming services; it is based on the NT registry. Configuring DCOM and installing type libraries is tedious and labor-intensive. DCOM is also Windows-centric. Very few implementations of DCOM run on non-Windows platforms. Finally, for DCOM to scale on the server side, it requires the Microsoft Transaction Server (MTS). Microsoft has no immediate plans to port MTS to non-NT platforms.

RPC	With an RPC, you call a specific function (the data is separate). In contrast, with an ORB, you call a method within a specific object. Different object classes may respond to the same method call differently. Because each object manages its own private instance data, the method is implemented on that specific instance data. ORB method invocations are precise. The call gets to a specific object that controls specific data and then implements the function in its own class-specific way. In contrast, RPC classes have no specificity: all the functions with the same name are implemented the same way.