CORBA

Celsina Bignoli bignolic@smccd.net

Enterprise Computing
Corporation have similar computing environments:
mixed set of HW platforms a mixed set of SW components programmers with very different skill sets need to maintain legacy code desire to avoid vendor lock-in

What is CORBA
CORBA (Common Object Request Broker Architecture) cross-platform, cross-language, vendorindependent specification for object-based distributed computing Introduced by the Object Management Group (OMG) in 1989

OMG
The OMG is a consortium that comprises over 700 companies and organizations
almost all the major vendors and developers of distributed object technology
platforms databases software tools

corporate application developers

CORBA
CORBA can be thought as a languageindependent version of RMI
similar lifecycle including definition of interfaces, generation of stubs and skeletons

glues together application written in different languages on different platforms

interfaces must be specified in a languageindependent format

CORBA Architecture
Client Invokes methods implemented by the server Server

Network
Stub Marshalls invocation and sends data to skeleton Skeleton Un-marshalls data and invokes method on server

CORBA Components
Interface Definition Language (IDL) Wire Protocol (IIOP) Language Mappings

CORBA Architecture
Client Invokes methods generated from IDL (implemented by the server) Server

Stub

Marshalls invocation and sends data to skeleton Automatically generated from IDL

Skeleton

Un-marshalls data and invokes method on server Automatically generated from IDL

ORB

IIOP

ORB

ORB
The ORB is the distributed service that implements the request to the remote object.
It locates the remote object on the network communicates the request to the object waits for the results and when available communicates those results back to the client.

The ORB implements location transparency.

Exactly the same request mechanism is used by the client and the CORBA object regardless of where the object is located.

The ORB implements programming language independence for the request.

The client issuing the request can be written in a different programming language from the implementation of the CORBA object

CORBA Products
ORB
Java 2 ORB VisisBroker for Java

Description
comes with Sun's Java 2 SDK A popular Java ORB from Inprise Corporation. VisiBroker is also embedded in other products
A popular Java ORB from Iona Technologies A popular application server with an ORB from IBM has a version of VisiBroker embedded in it Available from various websites

OrbixWeb WebSphere Netscape Communicator Shareware ORBs

Interface Definition Language (IDL)

Used to specify an object interface, i.e. the contract between code using the object and the code implementing the object indicates the operations the object supports, but not how they are implemented
the implementation of a CORBA object is provided in a standard programming language, such as the Java or C++

clients only depend on the interface IDL interfaces are programming language neutral

Interface Definition Language(2)

OMG IDL allows you to define the following :
Modularized object interfaces Operations and attributes that an object supports Exceptions raised by an operation Data types of an operation return value, its parameters, and an object's attributes

IDL Data Types

Basic data types (long, short, string, float...) Constructed data types (struct, union, enum, sequence) Typed object references The any type, a dynamically typed value

Bindings
IDL defines language bindings for many different programming languages
OMG has standardized on language bindings for: C, C++, Java, Ada, COBOL, Smalltalk, Objective C, and Lisp

Developers can choose the appropriate programming language for the object implementation and a possibly different programming language for the client. IDL declarations are compiled with an IDL compiler and converted to their associated representations in the target programming languages according to the standard language binding

IDL to Java Bindings

IDL
module interface

Java
package interface

C++
namespace abstract class

operation
attribute exception

method
pair of methods exception

member function
pair of methods exception

IDL to Java Data Type Mappings

IDL Type boolean char octet short long long long float double string Java Type boolean char byte short int long float double String

HelloWorld Example

Hello Client
Object Reference sayHello Hello World!

Hello Server
Hello Servant sayHello

Stub
ORB IIOP TCP/IP (network)

Skeleton
ORB

Defining the Remote Interface

create a file Hello.idl with the following content:
module HelloApp { interface Hello

{
string sayHello(); oneway void shutdown(); }; };

Mapping Hello.idl to Java

idlj -fall Hello.idl The tool idlj reads OMG IDL files and creates the required Java files. The idlj compiler defaults to generating only the clientside bindings. If you need both client-side bindings and server-side skeletons you must use the -fall option A directory called HelloApp has been created containing a number of files

Generated Files
Hello.java
This interface contains the Java version of our IDL interface. The Hello.java interface extends org.omg.CORBA.Object, providing standard CORBA object functionality.

HelloPOA.java
This abstract class is the stream-based server skeleton provides basic CORBA functionality for the server The server class, HelloServant, extends HelloPOA.

_HelloStub.java
This class is the client stub, providing CORBA functionality for the client. Implements the Hello.java interface.

Generated Files
HelloOperations.java
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

HelloHelper.java
This class provides auxiliary functionality. responsible for reading and writing the data types to CORBA streams

HelloHolder.java

Developing the Server

Create the servant class HelloImpl
implements of the Hello IDL interface; each Hello instance is implemented by a HelloImpl instance
contains one method for each IDL operation, in this example, the sayHello() and shutdown() methods

its a subclass of HelloPOA, which is generated by the idlj compiler from the example IDL.
Servant methods are just like ordinary Java methods; the extra code to deal with the ORB, with marshaling arguments and results, and so on, is provided by the skeleton

Portable Object Adapter (POA)

Abstract layer between the wire and the skeleton responsible for
pull data from the wire de-marshalling data forward requests to skeletons

Naming Services
The two options for Naming Services shipped with J2SE 1.5 are: orbd, which includes both a Transient Naming Service and a Persistent Naming Service. tnameserv - a Transient Naming Service.
The example uses orbd.

Developing the Client

needs to look up the server

obtain a reference of the object on which it makes remote method calls

unaware the object is
remotely located written in a different language

serviced by a different vendor ORB

CORBA vs. RMI

both frameworks for building distributed systems

similar architectural principles

CORBA supports components written in different programming languages

RMI assumes client/server written in Java

RMI easier to learn and use
code is smaller and simpler serialization makes it easier to maintain an application

CORBA unlike RMI has no notion of distributed garbage collection

Choosing CORBA vs. RMI

Depends on how you can answer some questions
will the application need to communicate with components that are NOT written in Java?

would the extra CORBA infrastructure be useful?

Will all future code that needs to communicate with the application always be written in Java?

RMI/IIOP

JRMP the native protocol of RMI is replaced with IIOP, the CORBA protocol

RMI/IIOP Applications
Steps
1. Remote interface like in RMI

extends Remote
methods throw RemoteException

2. Server extends PortableRemoteObject instead of UnicatsRemoteObject 3. stubs and scheleton are generated using rmic with the iiop flag 4. CORBA naming service used instead of RMI registry 5. IDL can be generated from Step 1 and used to develop non-Java components