IIOP: Internet Inter-ORB Protocol
Make your code accessible even in future, with the next universal protocol
We are witnessing paramount changes in the last four or five years - changes that effect us in our everyday life - the way we live, the way we communicate and the way we do business. The Internet or the web technologies are giving us new powerful tools, everyday, to make our life easier and better. We still need to constantly overcome the hurdles or stumbling blocks inherent in any technology to gain a better living-style. Internet Inter-ORB Protocol (IIOP) is a paradigm-shift that promises to unite distributed objects and applications with no language or platform barriers, and overcomes all the limitations of the current web technologies.
IIOP is an object-based protocol and has the potential to massively enhance the types of applications or services or databases that are built and communicate on the web. IIOP provides a comprehensive system through which live objects can request services from one another across the corporate networks over the internet or intranet. IIOP is expected to become the next standard communication protocol on the Internet, replacing, or coexisting with, HTTP/CGI.
IIOP is a critical part of a strategic industry standard, the Common Object Request Broker Architecture (CORBA) and is defined by Object Management Group (OMG, a consortium of over 800 companies world-wide). Using CORBA's IIOP and related protocols, a company can write programs that will be able to communicate with their own or other company's existing or future programs wherever they are located, without having to understand anything about the program other than its service and a name.
IIOP offers several advantages like better architecture neutrality, communication transparency, scalability and code reuse. This is not a concept just on paper, but is already happening and working successfully in the most diversified organizations across the globe. IIOP is the communication protocol across the 50 different organizations at American Automobile Association (AAA) and the hundreds of cell-sample centers at European Bioinformatics Institute to exchange information.
Before diving into IIOP, let me first explain some of the terminology
used in this article.
CORBA is a distributed technology that supports access to remote objects developed in multiple languages across a variety of platforms. The core of the CORBA architecture is the Object Request Broker (ORB), which is the object bus. The ORB allows client applications to find objects and invoke methods on them locally or across a network. It handles passing requests, responses and exceptions between a client object and a server object. When the client applications uses an object, it doesn’t need to know the object’s location, programming language or type of platform because the ORB masks these details. The ORB handles the location of server objects in a repository that keeps this level of detail from the client.
Each ORB must define a standard representation for the objects it transmits, the so-called on-the-wire format. In an ideal world, all ORBs would use the same on-the-wire format, but this is not how CORBA implementations have evolved. To cope with this problem, CORBA 2.0 defines a standard format that ORBs can use to exchange objects: the General Inter-ORB Protocol (GIOP). The Internet Inter-ORB Protocol (IIOP) in turn specifies how GIOP maps to TCP.
To present things in a different way,
IIOP is a high-level protocol that takes care of many of the services
associated with the levels above the transport layer, including data translation,
memory buffer management, dead-locks and communication management. It is
also responsible for directing requests to the correct object instance within
CORBA and IIOP assume the client-server model of computing in which a client program always makes requests and a server program waits to receive requests from clients. For a client to make a request of a program somewhere in a network, it must have an address for the program (object instance). This address is known as the Interoperable Object Reference (IOR). Part of the address is based on the server's IP address and port number. In the client's computer, a table can be created to map IORs to proxy names that are easier to use. A Common Data Representation (CDR) provides a way to encode and decode data so that it can be exchanged in a standard way. The client application can access the object using the IOR, which masks the client application’s ORB implementation from the ORB implementation used to host the CORBA object.
|At the lowest level, you have the physical device (an Ethernet card) which gives you a MAC address. From there, you move up into the Ethernet protocol, which gives you a connection-based, broadcast, bus-network topology, where messages are encoded and collisions resolved. Next, you get into the Internet Protocol (IP), which specifies the format of packets that traverse the Internet and gives a hostname, specified in four octets (192.168.222.152). This hostname, along with additional information, allows IP to be routed. Above IP is the Transport Control Protocol (TCP), which adds the functionality of port number and control directives such as packet segmentation and time to live. IIOP is built on TCP. This gives us reliable, stream-based delivery and TCP is responsible for ensuring that the right application on a machine receives the message. Above IIOP is the ORB level, which marshals and unmarshals the IIOP requests. Last is the application level, which includes object implementations and other ORB objects such as the Naming and other services. IIOP doesn’t have a default port to listen at.
IIOP is designed to allow two distributed applications written in any
language to communicate. It assumes that neither party speaks any particular
language, and it therefore automatically translates information as it is
Though IIOP cannot be compared with DCE directly, we can compare CORBA’s IDL with DCE’s IDL. In CORBA, one can introduce a new interface class as an extension of another, whereas the same is not possible in DCE. CORBA’s IDL allows polymorphism (invoking the same method on different types of objects) whereas DCE"s IDL does not.
Remote method invocation (RMI) is the action of invoking a method of a remote interface on a remote object. RMI allows for the creation of distributed Java-to-Java applications, in which the methods of remote Java objects can be invoked from other Java virtual machines - even possibly on different hosts. Once a Java program obtains a reference to a remote object, it can make a call on the remote object either by looking up the remote object in the bootstrap-naming service provided by RMI, or by receiving the reference as an argument or a return value. Also, a client can call a remote object in a server, and that server can be a client of other remote objects.
RMI is designed to allow two distributed Java applications to communicate. It assumes that both parties speak Java, and therefore it can rely on the Java language for increased efficiency and a more native programming interface.
The Java remote method invocation system has been specifically designed to operate in the Java environment. The Java language's RMI system assumes the homogeneous environment of the Java Virtual Machine, and the system can therefore take advantage of the Java object model whenever possible. Sun and IBM have jointly developed RMI-IIOP, a new version of RMI that runs over IIOP and interoperate with CORBA ORBs and CORBA objects programmed in other languages.
The RMI protocol makes use of two other protocols:
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.
Problems with HTTP, are that HTTP can only communicate with a web server, which introduces problems with collaboration, commercial interests as well as performance issues. HTTP is based on TCP sockets and is a simple, text-based protocol.
The combination of interoperability and portability means that customers can invest knowing that they are not locked in to the products of a single vendor.
The traditional HTTP/CGI which is being used in current day’s web applications
is a slow, stateless protocol and suits only simple applications like storing/retrieving
information with/without filters. IIOP is designed to support objects and
state rather than content, making it a natural protocol on which any application
can be built, and works over TCP/IP, making it the right fit in internet
and intranet environments.
IIOP solves several of the limitations inherent in HTTP/CGI and has the given below advantages,
With IIOP, web applications are not locked into a single machine that
must manage both requests of HTML files and executions of server programs,
either through CGI or Java. A Web server can now be installed on a dedicated
Internet host that is free to serve only incoming HTTP requests, while all
the other client/server applications are run on different machines.
IIOP provides a standard & robust protocol and, when coupled with the portability of the Java language, provides the best model for building more complex and operational web applications.
Some of the products available in the market that would help you if you
are developing products based on IIOP technology.
IIOP Protocol Analyser
IIOP Protocol Analyser by Ciarán Treanor extends the tcpdump packet analyser from the Lawrence Berkeley National Laboratory to analyse IIOP packets
Orbix Wonderwall by IONA Technologies is a server-side firewall proxy for IIOP. The Wonderwall runs on the bastion host, and it allows to filter, control and log IIOP traffic between clients on the exterior (the Internet), and IIOP servers on the interior (the internal network). It requires no changes to code on the client side, and minimal changes, if any, on the server side. It also does not require any special support in the client side ORB layer.
SunSoft provides the source code of it's portable implementation of the CORBA 2.0 mandatory "IIOP" interoperability protocol for networked ORBs. It is composed of four parts: a CDR marshalling engine, a TypeCode interpreter, the engine framework (includes a partial ORB implementation) and IIOP-specific modules.
DataBroker is a CORBA application object based on providing universal access for the CORBA-capable application to record-oriented data and applicYations which generate record-oriented data. DataBroker supports native access to Oracle and Sybase, ODBC drivers, multi-threading, MPP architectures. It is plug and play ready for IONA's Orbix, Netscape's Open Network Environment (ONE), Oracle's Network Computing Architecture (NCA), Visigenic's VisiBroker and via CORBA's IIOP (Internet InterORB Protocol).
Open Network Environment
The Q system provides interoperability support for multilingual, heterogeneous component-based software systems. Q/CORBA by the University of Colorado is a software bus system and provides both remote procedure call (RPC) and message-passing semantics as a layer above Unix sockets. It can provide both the Open Network Computing (ONC) industrial standard (the one underlying NFS) as well as CORBA2 IIOP.
Tcliop by George Almási extends the popular TCL/Tk scripting language by enabling it to call CORBA services using the CORBA 2.0/IIOP (Internet Inter-Operability Protocol). There is exactly one new TCL command to learn before making calls to CORBA services. There is no code generation phase nor any compilation to be run before calling a CORBA service.
With the introduction of IIOP into the CORBA 2.0 specification interoperability
between different commercial ORBs is possible. ORBs can still support their
own proprietary protocols as they did with their previous versions of non-CORBA
2.0-complaint ORBs. Bridges allows ORBs to interoperate between different
protocols while using IIOP as the backbone protocol. This makes CORBA very
CORBA is not the only architecture that uses IIOP. Other architectures can also use and take full advantage of IIOP. IIOP is a well-proven communication transport and by implementing IIOP, other architectures can interoperate with ORBs. Architectures like Netscape’s Open Network Environment (ONE) and Sun Microsystems’s Java uses IIOP to communicate with ORBs. Sun has provided a mechanism to map Java RMI into IIOP. Nowadays Java is widely used for developing applications that inter-operate with CORBA applications.
IIOP has proved to be very efficient and cost effective which explains its wide acceptance. It’s flexibility, scalability and simplicity makes it easy to use and implement.