IIOP: Internet Inter-ORB Protocol Make your code accessible even in future, with the next universal protocol My Articles: Home Networking Wearable Computing IIOP Meet My Friend Intelligent Agents 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. [Articles Home] [Home] 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. What is IIOP 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, CORBA is to object oriented computing what the WWW is to documents IDL is to CORBA what HTML is to the web IIOP is to CORBA what HTTP is to the www IOR is to CORBA what URL is to the www The working of IIOP 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 an ORB. 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 helps CORBA achieve language, site and platform independence but CORBA is not the only architecture that uses IIOP. Because a TCP/IP-based proxy is usable on almost any machine that runs today, more parties now use IIOP. When another architecture is IIOP-compliant, it not only establishes a well-proven communication transport for its use, but it also can communicate with any ORB implementation that is IIOP-compliant. The possibilities are endless. Comparision with DCE, RMI and HTTP 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 transferred. DCE 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. RMI 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: Java Object Serialization protocol, used to marshal call and return data. HTTP, used to "POST" a remote method invocation and obtain return data. HTTP 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. Is IIOP a replacement for CGI? 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, supports more robust arguments data types than just strings doesn t require to spawn a new process for each request provides persistence of state between calls provides the ability to obtain any object reference on the Internet separates interface from implementation which enables easy version upgrades and support to multiple programming languages supports dynamic function invocation, load balancing, transaction services can handle more than one request/response per connection can handle more than one object per request 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. Products for IIOP Development 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 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. Inter-ORB Engine 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 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). Netscape Open Network Environment Netscape ONE is an open network environment based on publicly defined standards, which lets developers and enterprises quickly and easily create robust, dynamic, cross-platform Inter/Intranet applications. It supports HTML, Java, JavaScript, the Netscape Internet Foundation Classes (IFC), the Internet Inter-ORB Protocol (IIOP), communication and collaboration protocols (HTTP, NNTP, SMTP, POP3), and a broad set of standard, scalable security services. Q/CORBA 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 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. What next 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 flexible.
IIOP: Internet Inter-ORB Protocol 7 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. Article dated: July' 1998 A word of appreication to the author?