IIOP®: OMG's Internet Inter-ORB Protocol
A Brief Description

What is IIOP?

The Object Management Group exists to create standards for distributed object computing that are realistic, commercially available and usable. OMG does this through its Object Management Architecture (OMA) at the heart of which is the Common Object Request Broker Architecture (CORBA™). CORBA specifies the Object Request Broker (ORB) that allows applications to communicate with one another no matter where they reside on a network. The CORBA 2.0 specification, adopted in 1994, created true out-of-the-box interoperability in heterogeneous environments and delivers this interoperability over the Internet through IIOP -- the Internet Inter-ORB Protocol.

A common misconception about IIOP is that it is a "separate" specification that developers need to write to in order to allow CORBA to work over the Internet. This is not so. A properly constructed CORBA 2.0 ORB already incorporates IIOP. IIOP is an underlying mechanism of CORBA technology which is transparently managed by ORBs. So IIOP and CORBA are, essentially, inseparable. Therefore, programmers and users are never required to interact with IIOP in any way; it is invisible to them. IIOP allows their programs to interact transparently while executing, so one does not have to write "IIOP programs."

IIOP In a Nutshell

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/technology/documents/formal/corba_2.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.

When a client program built with ORB vendor B's product needs to talk to an object in a server built with ORB vendor A's product, the client program opens a TCP/IP connection to the server, and sends one or more IIOP request to the server. The ORB component linked into the server locates or activates the object specified in the request and invokes the appropriate method on the object. The fact that the object is not built with the same ORB product is invisible to the client.

Platform Independence

One of the most important aspects of CORBA/IIOP is its platform independence. CORBA ORBs interoperate without regard to vendor origin making CORBA/IIOP the truly ideal solution for the Internet, especially when one considers its vast size and the disparate hardware and software that is deployed there. This platform independence allows businesses to take advantage of the Internet without having to rebuild systems and networking hardware and software or forcing them to commit to a single vendor solution. CORBA/IIOP will allow most every system that is now in operation to be incorporated with comparitively minor modifications so that a business's installed base, even if it is made up of equipment and software packages from a variety of vendors, will be able to work together seamlessly.

CORBA/IIOP: Empowering the Web

As the Internet and network computing evolved, protocols were needed to allow applications to work over these networks. Unfortunately protocols (almost hand built) were developed on an application-by-application basis so that things like email, file transfer and now multimedia documents for the web all exist and function in parallel universes of functionality. HTTP was originally designed for the transmission of these multimedia documents across the World Wide Web. HTTP can transfer data and the data may be encoded for display (text, graphics) or playback (audio, video) but these encodings are not part of the HTTP standard. The protocol does not manage the information, it merely conveys it from the client to the server and back again. It is up to the applications themselves to break down and reassemble the information in order to transmit it and receive it.

As an application specific (actually display specific) protocol HTTP is fine but as web applications become more complex, they are running up against the limitations of HTTP. So as web-based applications become more complicated CORBA/IIOP becomes the natural solution for handling them. Using CORBA means that applications can communicate with each other over the Internet no matter where they are or who built them.

An Example

The programming model offered by HTML/HTTP suffices for simple problems that can be solved by presenting "fixed" documents -- collections of linked web pages written in HTML. Any problem that requires dynamic interaction with the user, such as an on-line reservation system, exposes some of the problems inherent in using HTTP to build non-trivial applications. The interface between the web server and the application program that actually manages the reservation database is, essentially, ad-hoc. The available mechanisms, such as CGI and NSAPI, are not object-oriented -- they do not enforce any type-safety. The interfaces can't be combined or extended (e.g. through inheritance or aggregation) and they don't inherently encapsulate any data that constitutes a particular object or instance. All data passed from the client take the form of character strings, and the application server is responsible for decoding them explicitly. There is no standard way of defining the service interfaces, so there is no repository of interfaces or self-description capability. Consequently, developers have to write more code with clumsier interfaces, the applications are more error-prone, they are harder to maintain, and are not likely to permit any meaningful re-use.

With CORBA and IIOP, almost all of the details of managing the interface and parameter passing mechanics are automated. The IDL interface describes the operations and parameters precisely and unambiguously. The code that manages encoding, passing, and decoding the parameters is generated automatically, not manually written as with HTML/HTTP. These interfaces also enforce type-safety, decreasing the possibility for errors and yielding more maintainable, re-usable application components. The on-line reservation system, for example, could easily be built to use the same reservation database component for several applications -- on-line Web reservations, more complex reservation applications for agents, applications using reservation data to plan resource allocation, and so on. Since more of the details of communication and interface management are automated, the developers can focus their efforts on solving the abstract problem -- managing reservations -- and not the details of how the web browser, the web server, and the application server all talk to each other.

Moving From HTTP to IIOP

For the most part, moving from HTTP to IIOP will be transparent to end-users, except for the fact that with IIOP the applications they use will become more sophisticated and have better performance. Initially, web applications that use IIOP will most likely take the form of Java applets downloaded via HTTP. Once the applet is downloaded, it takes over communication with remote objects using IIOP. The CORBA model and tools that support it allow programmers to build this kind of application more quickly, develop more functionality, and make use of existing components. The end result is more application bang for the buck.

As web-related CORBA standards progress, there will be standard URL formats for object references and requests, and scripting languages such as JavaScript and component models such as JavaBeans will be likely to have built-in support for IIOP. This step will give less sophisticated users access to powerful object-oriented services throughout the web, regardless of the specific object technology used to build them.

CORBA and IIOP also guarantee that objects can describe their interfaces at run-time. This offers powerful capabilities not available in other protocols, including HTTP. Web applications will be able to take an object reference, in the form of a URL beginning with something like "iiop://", and ask the object to describe itself. The ability to do this in object and component models is often called "introspection." The description takes a standard form, prescribed by the CORBA 2.0 specification. This capability allows users much more powerful browsing capabilities. Rather than just downloading documents, users can interactively discover and inquire about a wider range of more sophisticated object services.

IIOP Simply Works

The IIOP protocol supports an environment which lets programmers define and invoke any operation they need, with type-checked input and output parameters. As long as the application adheres to the CORBA standard, IIOP transparently allows communication to take place. It provides a single protocol for interoperability between the Enterprise and the Web. This approach is much more flexible and powerful than HTTP -- in fact, it extends the executing program environment across the network to the remote desktop creating a web of interconnected objects or ORBs. Coupled with Java for applet execution, IIOP is quickly becoming the preferred platform for distributed application development for the Web.

Summary

CORBA and IIOP are developments that are in the right place at the right time, and not a prototype churned out quickly in response to "web time" demands. From the beginning, CORBA/IIOP was intended to meet even the needs of the large, multinational enterprise where robustness, scalability, security, and value are critical elements of their information systems. CORBA/IIOP perfectly meets these criteria making it the architecture/protocol of choice for the future of World Wide Web.

To see some examples of CORBA/IIOP and how it is being used successfully by companies in a variety of industries, visit: http://www.corba.org.

David Curtis 
Christopher Stone 
Mike Bradley 

  Last updated on 08/24/2012