|
|||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
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
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 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:
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.
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
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.
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.
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.
![[HOME]](../images/homepage.gif){kind=small}
Article dated: July' 1998