A Report on CORBA and its Significance
written by Francis Chan (fchan@eecs.berkeley.edu)
Objective
Common Object Request Broker Architecture (CORBA) is
a system definition specification that allows applications to
communicate with one another regardless of their location, platform
and developer. We have conducted a research on its architecture,
impact and significance on the development of distributed applications.
This serves as an inspiration and background study on how we should
design our own architecture and protocols of the distributed design
system that we plan to build.
Detailed Description
CORBA 2.0, together with the Interface Definition
Language (IDL) and Application Programming Interfaces
(API) that were defined by the Object Management Group,
enables client/server object interaction and
interoperability by specifying how Object Request Brokers (ORB) from different
developers can interoperate.
Structure of the Object Request Broker Interfaces
The ORB is the middleware that establishes the
client-server relationships between objects. Using an ORB,
a client can transparently invoke a method on a server
object, which can be on the same machine or across a
network. The ORB intercepts the call and is responsible for
finding an object that can implement the request, pass it the
parameters, invoke its method, and return the results. The
client does not have to be aware of where the object is
located, its programming language, its operating system, or
any other system aspects that are not part of an object's
interface. In so doing, the ORB provides interoperability
between applications on different machines in
heterogeneous distributed environments and seamlessly
interconnects multiple object systems. With an ORB, the
protocol is defined through the application interfaces via a
single implementation language-dependent specification,
the IDL. In an ORB-based solution, developers simply
model the existing component using the same IDL they use
for creating new objects, then write "wrapper" code that
translates between the standardized bus and the existing
interfaces.
Significance of CORBA
Since the release of CORBA 1.0 in 1991, the promise to
provide out-of-the-box multi-vendor interoperability
among ORB implementations has yet been realized. The
CORBA 1.2 specifications had many vague areas to allow a
wide range of implementations, but caused problems with
interoperability. The problem was finally resolved by
CORBA 2.0 with the definition of a single wire-format
which specifies how detailed information representing a
CORBA request is laid out on a network transport. The
wire-format to be adopted was:
- CORBA 2.0 implementations provides out-of-the-box
interoperability by means of UNO GIOP (Universal
Networked Object, General Inter-ORB Protocol) hosted on
the TCP/IP networking transport, called IIOP (Internet
Inter-ORB Protocol).
- CORBA 2.0 implementations will have the option of
supporting an additional protocol, called the DCE CIOP
(Distributed Computing Environment Common Inter-ORB
Protocol) based on (Open Software Foundation) OSF's DCE
protocol.
CORBA also standardized:
- IDL-to-C++ language mapping
- Naming service, event service, lifecycle service
- ORB initialization service
However, until conformance becomes commonplace,
porting between different platforms, applications from
ORB to ORB will remain limited.
CORBA provides a distributed object-oriented approach to
integrating new as well as legacy applications and enables
the developers to write an object wrapper to encapsulate the
system. With CORBA, the developer needs only to write a description of
the service provided by the system using IDL, then write
code which invokes the appropriate set of actions in the
system when one of the object wrapper's method in invoked.
CORBA Limitations
While the interoperability issue has been tackled in CORBA
2.0, the security aspects have not been sufficiently
addressed, and this falls on the shoulders of the OMG
Object Security Service Specification. These have been the
major obstacles to serious and mission-critical applications
development, particularly those who still employ legacy
systems.
As a technology, CORBA is maturing rapidly and its
specifications has received broad industry support.
However, OMG technology has had only slow acceptance as
OMG/CORBA technology is an object-oriented technology
for distributed computing, an area where many users are not
technically ready to apply and deploy in real environments.
With the recent popularity of the Internet, the future of
CORBA lies greatly in its use in open distributed tools and
and services. This depends on both the publicity efforts on
the part of OMG in encouraging software and system
vendors to use CORBA and on CORBA's technical merits
in enabling true compatibility among different platforms
and other Internet programming languages and applications.
Status
We do not yet intend to fully integrate CORBA into our system but are
watching closely external research and industry efforts in developing
and using CORBA technology, especially those that provide the
compatibility between Java and CORBA.
These research include:
- JYLU[1] -- A CORBA Object Request Broker ILU developed
as part of Stanford Digital Library Testbed Development. It is an
implementation of Xerox PARC's ILU runtime kernel and Java language
binding completely in the Java language. It is already operable
both as clients and servers, but provide only limited capabilities support.
- JIDL[2] -- A CORBA IDL compiler developed at Sandia
National Laboratories. It is an IDL compiler with Java as the target
language. It enables Java applets running in Java-enabled Web
browsers to manipulate CORBA objects on remote servers as if they were
local Java objects. The current version of JIDL works
only with Orbix, a commercial CORBA implementation from
Iona. JIDL-generated code communicates with Orbix using
a generic (not object-specific) server-side script using
TclDii, an extension to the Tcl language.
References:
[1]
http://coho.stanford.edu/~hassan/Java/Jylu/
[2]
http://herzberg.ca.sandia.gov/jidl/