CORBA
CASE STUDY
CPSC 550
Juan C. Navarro
March 2006
1
TABLE OF CONTENTS
INTRODUCTION............................................................................................................. 3
WHAT IS CORBA ........................................................................................................... 3
GOALS OF CORBA ....................................................................................................... 4
CORBA APPLICATIONS ............................................................................................... 5
CORBA DEFINITIONS ................................................................................................... 6
FEATURES OF CORBA ................................................................................................. 7
CORBA SERVICES .................................................................................................... 7
STRUCTURE OF CORBA .............................................................................................. 9
BASIC CONCEPT ....................................................................................................... 9
HOW TO USE CORBA ................................................................................................. 12
CORBA PRODUCTS .................................................................................................... 15
SIGNIFICANCE OF POINTS ........................................................................................ 16
SUMMARY ................................................................................................................... 17
REFERENCES ............................................................................................................. 18
2
INTRODUCTION
The explosive growth of the web, the increasing popularity of PCs, the advances in highspeed network access and the user demands for more powerful systems brought
distributed system and distributed object computing to the main stream. Three of the
most popular distributed object technologies are OMG’s Common Object Request
Broker Architecture (CORBA), Microsoft’s Distributed Component Object Model
(DCOM), and Sun’s Java/Remote Method Invocation (Java/MRI). This case study
focuses on the OMS’s CORBA.
WHAT IS CORBA
CORBA stands for Common Object Request Broker Architecture. It is a Standard
Architecture for Distributed Object System. It is language independent object model and
specification for a distributed applications development environment. It was developed
with the purpose of allowing application to communicate with one another no matter
where they are located or who has designed them. The standard also defines the
Interface Definition Language (IDL) and the Application Programming Interface (API).
CORBA was created by The Object Management Group (OMG), which is an open
membership, not-for-profit consortium that produces and maintains computer industry
specifications for interoperable enterprise applications. The OMG was created in 1989
and has about 700 hundred members in the Organization:
Some of OMG Actual Members:
Adobe Systems
GE Transportation
Motorola (Platform)
NASA (Government)
Massachusetts Institute of Technology (University)
3
CORBA SPECIFICATION
The CORBA specification describes how to develop an implementation of CORBA. It
also describes programming language bindings that developers use to develop
applications. In addition, the CORBA specification provides a broad and consistent
model for building distributed applications by defining:




An object model for building distributed applications
A common set of application programming objects to be used by the client and
server applications
A syntax for describing the interfaces of objects used in the development of
distributed applications
Support for use by applications written in multiple programming languages
GOALS OF CORBA
The Goals of CORBA is to support distributed heterogeneous objects request in a way
that is transparent to the user and application programmers and to allow distributed
objects to be implemented in any programming language and to communicate with one
another. Another goal of CORBA is to promote an object-oriented approach to building
and integrating distributed software applications. Allow to build systems on
heterogeneous hardware, networks, operating systems and programming languages.
Object Reuse: CORBA allows wide-spread use of existing components
Flexibility:
CORBA allows developers to choose:




Operating System
Execution Environment
Programming Language
Hardware
4
CORBA APPLICATIONS
CORBA is useful in many situations. Because of the way that CORBA integrates
machines from so many vendors, with sizes ranging from mainframes through minis and
desktops to hand-helds and embedded systems, it is the middleware of choice for large
(and even not-so-large) enterprises. One of its most important, as well most frequent,
uses is in servers that must handle large number of clients, at high hit rates, with high
reliability. CORBA works behind the scenes in the computer rooms of many of the
world's largest websites. Specializations for scalability and fault-tolerance support these
systems. But it's not used just for large applications; specialized versions of CORBA run
real-time systems, and small embedded systems.
CORBA applications support the enterprise: The compute engine behind a website could
be a huge CORBA server, running load-balanced on a roomful of machines and
supported by OMG's standard fault tolerant architecture. In addition, smaller servers can
run on a single machine, or even a handheld or small embedded device, and still
interoperate with all other CORBA clients and servers over OMG's standard protocol,
IIOP.








Telephone Networks worldwide
Banking Application on every continent
Utilities
Manufacturing
Government
Industrial
Car dashboards to mainframes
Controlling Telephone switches
5
CORBA DEFINITIONS
OMG:
Object Management Group.
CORBA:
Common Object Request Broker Architecture
CORBA Specification: The CORBA specification describes how to develop an
implementation of CORBA. It also describes programming language bindings
that developers use to develop applications.
ORB:
Object Request Broker architecture specification for distributed object
systems. This is the middleware that establishes the client/server
relationship:





Intercept a call from the client
Find the correct object
Pass it the parameter
Invoke its method
Return the results to the client
GIOP:
General Inter-ORB Protocol: CORBA 2.0 standard that enables different
developer implementations to communicate with each other.
IDL:
Interface Definition Language: An interfacing programming language that that
allow communication across a heterogeneous distributed system.
IIOP:
Internet Inter-ORB Protocol: Internet version of GIOP that use the TCP/IP
protocol.
API:
Application Programming interface
Middleware: A software layer that provides a programming abstraction as well as
masking the heterogeneity of the underlying networks, hardware, operating
systems, and programming languages.
6
FEATURES OF CORBA
.
CORBA supports many existing languages. CORBA also supports mixing these
languages within a single distributed application.
CORBA supports both distribution and Object Orientation.
CORBA is an industry standard. This creates competition among vendors and ensures
that quality implementations exist. The use of the CORBA standard also provides the
developer with a certain degree of portability between implementations. Note: application
source is not 100% portable between different CORBA products.
CORBA provides a high degree of interoperability. This insures that distributed objects
built on top of different CORBA products can communicate. Large companies do not
need to mandate a single CORBA product for all development.
Over 700 companies back CORBA, including hardware companies, software companies,
and cable companies, phone companies, banks, etc.
CORBA SERVICES
CORBA provides a definition for the following set of distributed services to support the
integration and interoperation of distributed objects:
Naming Services: It allows names to be bound to the remote object references of
CORBA objects within naming context.
Event Service: Defines interfaces allowing objects of interest, called suppliers, to
communicate notifications to subscribers, called consumers.
Notification Service: Extends the Event service, retaining all of its features including
event channels, event consumers and event suppliers



Notifications may be defines as Data Structures
Event consumers may use filters that specify exactly which events
they are interested in.
Event suppliers are provided with a means of discovering the
events the consumers are interested in/
7



Event consumers can discover the event types offered by the
supplier on a channel, which enables them to subs cribe to new
events as they become available.
It is possible to configure the properties of a channel, a proxy, or a
particular event.
An event type repository is an optional extra. It will provide a data
structure of events, making it convenient to define filtering
constrain.
Security Service: The CORBA security service includes the following:




Authentication
Access control can be applied to CORBA objects when they
receive remote method invocations. Access rights may for
example be specified in access control.
Auditing by servers of remote method invocations
Facilities for non-repudiation. When an object carries out a remote
invocation on behalf of a principal, the server creates and stores
credentials that prove that the invocation was done by that server
on behalf of the requesting principal.
Trading Service: Allows the objects to be located by attributes. It is a directory service.
Its database contains a mapping from service types and their
associated attributes onto remote object references of CORBA
objects.
Transaction Service and Concurrency Control Service: The object transaction service
allows distributed CORBA objects to participate in either flat or nested
transactions
Persistent Object Service: An object that is guaranteed to live between activation of
processes is called a persistent object. Persistent objects are
generally managed by persistent object stores, which store their state
in a marshaled form on disk.
8
STRUCTURE OF CORBA
BASIC CONCEPT
One program calls upon another for its services no matter where it is located.
CORBA provides a complete messaging environment for executing remote
objects written in multiple languages and running on different platforms.
9
Object: This is a CORBA programming entity that consists of an identity, an interface,
and an implementation, which is known as a Servant.
Servant: This is an implementation programming language entity that defines the
operations that support a CORBA IDL interface. Servants can be written in a
variety of languages, including C, C++, Java, Smalltalk, and Ada.
Client: This is the program entity that invokes an operation on an object implementation.
Accessing the services of a remote object should be transparent to the caller.
Ideally, it should be as simple as calling a method on an object, i.e., obj>op(args). The remaining components in Figure 2 help to support this level of
transparency.
Object Request Broker (ORB): The ORB provides a mechanism for transparently
communicating client requests to target object implementations. The ORB
simplifies distributed programming by decoupling the client from the details of
the method invocations. This makes client requests appear to be local
procedure calls. When a client invokes an operation, the ORB is responsible for
finding the object implementation, transparently activating it if necessary,
delivering the request to the object, and returning any response to the caller.
ORB Interface: An ORB is a logical entity that may be implemented in various ways
(such as one or more processes or a set of libraries). To decouple applications
from implementation details, the CORBA specification defines an abstract
interface for an ORB. This interface provides various helper functions such as
converting object references to strings and vice versa, and creating argument
10
lists for requests made through the dynamic invocation interface described
below.
CORBA IDL stubs and skeletons: CORBA IDL stubs and skeletons serve as the “glue”
between the client and server applications, respectively, and the ORB. The
transformation between CORBA IDL definitions and the target programming
language is automated by a CORBA IDL compiler. The use of a compiler
reduces the potential for inconsistencies between client stubs and server
skeletons and increases opportunities for automated compiler optimizations.
Dynamic Invocation Interface (DII): This interface allows a client to directly access the
underlying request mechanisms provided by an ORB. Applications use the DII
to dynamically issue requests to objects without requiring IDL interface-specific
stubs to be linked in. Unlike IDL stubs (which only allow RPC-style requests),
the DII also allows clients to make non-blocking deferred synchronous
(separate send and receive operations) and one way (send-only) calls.
Dynamic Skeleton Interface (DSI): This is the server side's analogue to the client side's
DII. The DSI allows an ORB to deliver requests to an object implementation that
does not have compile-time knowledge of the type of the object it is
implementing. The client making the request has no idea whether the
implementation is using the type-specific IDL skeletons or is using the dynamic
skeletons.
Object Adapter: This assists the ORB with delivering requests to the object and with
activating the object. More importantly, an object adapter associates object
implementations with the ORB. Object adapters can be specialized to provide
support for certain object implementation styles (such as OODB object adapters
for persistence and library object adapters for non-remote objects).
11
HOW TO USE CORBA
The Interface Definition Language (IDL)
CORBA objects are defined by an Interface Definition Language (IDL) that describes the
processing (methods) and the data sent and returned. IDL compilers for languages such
as C, C++, Java, Smalltalk and COBOL let programmers use familiar constructs. IDL
definitions stored in an Interface Repository can be queried by a client application to
determine which objects are available on the bus.
Note When implementing a client for an existing CORBA service, or a server for
an existing client, you would get the IDL interfaces from the implementer--such
as a service provider or vendor. You would then run the idlj compiler over those
interfaces and follow these steps.
Steps for creating a CORBA development based on Java IDL
The following example uses J2SE 1.4. The J2SE v.1.4 provides the Application
Programming Interface (API) and Object Request Broker (ORB) needed to enable
CORBA-based distributed object interaction, as well as the idlj compiler. The idlj
compiler uses the IDL-to-Java language mapping to convert IDL interface definitions to
corresponding Java interfaces, classes, and methods, which can then be used to
implement the client and server code.
1. Define the remote interface
You define the interface for the remote object using the OMG's Interface
Definition Langauge (IDL). The IDL is used instead of the Java language
because the idlj compiler automatically maps from IDL, generating all Java
language stub and skeleton source files, along with the infrastructure code for
connecting to the ORB. Also, by using IDL, you make it possible for developers
to implement clients and servers in any other CORBA-compliant language.
Example
Hello.idl:
module HelloApp
{
interface Hello
{
string sayHello();
oneway void shutdown();
};
};
* Copyright (c) 1996-2002 Sun Microsystems, Inc. All Rights Reserved.
12
2. Compile the remote interface
The java IDL compiler generates the Java version of the interface, as well as the
class code files for the stubs and skeletons that enable the applications to hook
into the ORB. Different IDL compilers and compiler options may generate
additional files:
HelloPOA.java: This abstract class is the stream-based server
skeleton, providing basic CORBA functionality for the server. It extends
org.omg.PortableServer.Servant, and implements the InvokeHandler
interface and the HelloOperations interface. The server class,
HelloServant, extends HelloPOA.
HelloStub.java: This class is the client stub, providing CORBA
functionality for the client. It extends rg.omg.CORBA.portable.ObjectImpl
and implements the Hello.java interface.
Hello.java: This interface contains the Java version of the IDL
interface. The Hello.java interface extends org.omg.CORBA.Object,
providing standard CORBA object functionality. It also extends the
HelloOperations interface and org.omg.CORBA.portable.IDLEntity.
//Hello.java
package HelloApp;
/**
* HelloApp/Hello.java
* Generated by the IDL-to-Java compiler (portable),
version "3.0"
* from Hello.idl
*/
public interface Hello extends HelloOperations,
org.omg.CORBA.Object,
org.omg.CORBA.portable.IDLEntity
{
} // interface Hello
* Copyright (c) 1996-2002 Sun Microsystems, Inc. All Rights Reserved.
HelloHelper.java: This class provides auxiliary functionality,
notably the narrow() method required to cast CORBA object references to
their proper types. The Helper class is responsible for reading and writing
the data type to CORBA streams, and inserting and extracting the data
type from Anys. The Holder class delegates to the methods in the Helper
class for reading and writing.
13
HelloHolder.java: This final class holds a public instance member
of type Hello. Whenever the IDL type is an out or an inout parameter, the
Holder class is used. It provides operations for
org.omg.CORBA.portable.OutputStream and
org.omg.CORBA.portable.InputStream arguments, which CORBA allows,
but which do not map easily to Java's semantics. The Holder class
delegates to the methods in the Helper class for reading and writing. It
implements org.omg.CORBA.portable.Streamable.
HelloOperations.java:This interface contains the methods sayHello() and
shutdown(). The IDL-to-Java mapping puts all of the operations defined
on the IDL interface into this file, which is shared by both the stubs and
skeletons.
3. Implement the server
After running the idlj compiler, it is possible to use the skeletons it generates to
put together the server application. In addition to implementing the methods of
the remote interface, your server code includes a mechanism to start the ORB
and wait for invocation from a remote client.
4. Implement the client
Similarly, it is possible to use the stubs generated by the idlj compiler as the
basis of your client application. The client code builds on the stubs to start its
ORB, look up the server using the name service provided with Java IDL, obtain a
reference for the remote object, and call its method.
5. Start the applications
Once a server and a client have been implemented, you can start the name
service, then start the server, then run the client.
* Copyright (c) 1996-2002 Sun Microsystems, Inc. All Rights Reserved.
14
CORBA PRODUCTS
CORBA is a specification; it is a guide for implementing products. Several vendors
provide CORBA products for various programming languages.
The Java 2 ORB : The Java 2 ORB comes with Sun's Java 2 SDK. It is missing several
features.
VisiBroker for Java: A popular Java ORB from Inprise Corporation. VisiBroker is also
embedded in other products. For example, it is the ORB that is embedded in the
Netscape Communicator browser.
OrbixWeb: A popular Java ORB from Iona Technologies.
WebSphere: A popular application server with an ORB from IBM.
Netscape Communicator: Netscape browsers have a version of VisiBroker embedded
in them. Applets can issue request on CORBA objects without downloading ORB
classes into the browser. They are already there.
Various free or shareware ORBs: CORBA implementations for various languages are
available for download on the web from various sources.
MICO: MICO implements the CORBA standard relying on C++. It is an open source
implementation.
omniORB: A CORBA ORB for C++ and Python. It is freely available under the terms of
the GNU Lesser General Public License (for the libraries), and GNU General Public
License (for the tools). omniORB is largely CORBA 2.6 compliant.
15
SIGNIFICANCE OF POINTS
The Object Management Group comprises 700 companies and Organizations dedicated
to maintain compatibility and standardization of the CORBA system.
The architecture and specifications of CORBA are vendor neutral.
CORBA Specifications are available to everyone
Three of the most popular distributed object technologies are OMG’s Common Object
Request Broker Architecture (CORBA), Microsoft’s Distributed Component Object Model
(DCOM), and Sun’s Java/Remote Method Invocation (Java/MRI). This case study
focuses on the OMS’s CORBA.
CORBA’s interface definition language is the crucial part because it permits
communication on a heterogeneous distributed system.
CORBA’s versatility makes it ideal for distributed object systems, such as across the
Internet, because the different portions of the distributed system are managed by
different organizations.
CORBA software from different vendors may not always interoperate at all levels, and
Microsoft’s DCOM is a Windows-based solution only.
16
SUMMARY
CORBA is a specification for creating distributed object-based applications. The
CORBA architecture and specification were developed by the Object Management
Group (OMG). The OMG is a consortium of several hundred information systems
vendors. The goal of CORBA is to promote an object-oriented approach to building and
integrating distributed software applications.
The CORBA specification describes how to develop an implementation of
CORBA. It also describes programming language bindings that developers use to
develop applications. The specification defines:




An object model for building distributed applications
A common set of application programming objects to be used by the client and
server applications
A syntax for describing the interfaces of objects used in the development of
distributed applications
Support for use by applications written in multiple programming languages, such
as C, C++, java, Smalltalk, Ada, COBOL, Lisp.
A CORBA objects implements the operations in an IDL interface. All that the
clients need to know to access CORBA objects is the operations available in its
interface.
The OMG maintains its constant vision regarding CORBA since its creation in
1989, providing upgrades for the specifications in order to satisfy developers current
service demands, the latest CORBA version is 3.03.
The architecture and individual specifications are vendor neutral, and the
direction and definition are public processes, including a broad cross-industry
consensus. In addition, the specifications are available to everyone with free rights to
implement software using the specification.
Three of the most popular distributed object technologies are OMG’s Common
Object Request Broker Architecture (CORBA), Microsoft’s Distributed Component Object
Model (DCOM), and Sun’s Java/Remote Method Invocation (Java/MRI). This case study
focuses on the OMS’s CORBA.
17
REFERENCES
CORBA Technology http://www.answer.com
CORBA. <http://www.corba.org/>
Coulouris, Dollimore, Kindberg. Distributed Systems Concepts and Design. Harlow,
England: Addison-Wesley, 2001.
Introduction to CORBA http://java.sun.com
OMG. Home page. http://www.omg.org. OMG, 2003
OMG. ”About The Object Management Group™ (OMG™)”.
http://www.omg.org/gettingstarted/gettingstartedindex.htm. OMG, 2003
18