CORBA Overview

What is CORBA?
• Common Object Request Broker
Architecture
• Communication infrastructure for
distributed objects
• Allows a heterogeneous, distributed
collection of objects to collaborate
transparently
 What is CORBA good for?
• Developing distributed applications
• Locating remote objects on a network
• Sending messages and Receiving
response to / from those objects
 What is the OMG?
• Designers of CORBA
• Consortium of 700+ companies
– Not including Microsoft
• Members:
• platform vendors
• database vendors
• software tool developers
• corporate developers
• software application vendors
 Basic CORBA Architecture

Client Server

request response

ORB ORB
“Object Bus”
 ORB
• Object Request Broker
– “Object Bus”
• Handles all communication among objects
• Each host (machine) has its own ORB
• ORBs know how to talk to each other
• ORB also provides basic services to client
 ORB Responsibilities
• Find the object implementation for the
request
• Prepare the object implementation to
receive the request
• Communicate the data making up the
request
• Retrieve results of request
• There’s an ORB on the server too
• ORB receives request
 IIOP
• Internet Inter-Orb Protocol
• Network or “wire” protocol
• Works across TCP/IP (the Internet
protocol)
 Steps for Implementing CORBA
Objects
• Write Interface using IDL.
• Use IDL Compilers.
• Add Implementation code for server objects.
• Server prg to create and register the server
objects.
• Write server prg to create and register server
objects.
• Write client to locate and invoke services.
• Start the naming service and server prg on
server and client prg on client.
 IDL
• Interface Definition Language only express
interfaces.
• Defines protocol to access objects
• Like a contract
• Well-specified
• Language-independent
• Language bindings are std by OMG
 IDL Example
4. module HelloApp
5. {
6. interface Hello
7. {
8. string sayHello();
9. oneway void shutdown();
10. };
11. };

• Defines an interface called Hello with a method called sayHello.

• OMG specifies a mapping from IDL to several different programming

languages, including C, C++, Smalltalk, COBOL, Ada, Lisp, Python,
and Java. When mapped, each statement in OMG IDL is translated
to a corresponding statement in the programming language of
choice.
• E.g.omniORB (IDL to C++ omniidl) Vendors decision to generate
and pck code.
 Stubs and Skeletons
• Stub
– lives on client
– pretends to be remote object
• Skeleton
– lives on server
– receives requests from stub
– talks to true remote object
– delivers response to stub
 Stubs and Skeletons
Client Host Machine Server Host Machine
Client Remote
Object Object

Stub Skeleton

ORB IIOP ORB

 Client vs. Server
• in CORBA, a client is a client relative to a
particular object i.e. an object with a
reference to a “server” object
• A client may also act as a server
– If it has an IDL and stubs and skeletons
• Technically, a CORBA server contains one
or more CORBA objects
 Different Meanings of “Server”
• Host machine
• Program running on host machine
• CORBA object running inside program
– has IDL, stub, skeleton
– Sometimes called a Servant
Stubs and Skeletons -> Platform
Independence
– Client code has no knowledge of the
implementation of the object or which ORB is
used to access the implementation.
– Same for server
 CORBA Services
• Naming Service
– Register objects with a name
– Look up objects by name
– Another CORBA object
– CORBA2 provides method to locate services
by name.
– E.g. String [ ] services=
orb.list_initial_Services();
– Std name ‘NameService’ ,’RootPOA’ etc.
 Java CORBA Products

• The Java 2 ORB

• VisiBroker for Java
• OrbixWeb
• Netscape Communicator
• Various free or shareware ORBs
 IDL to Java Mapping
• Defined by OMG
• Translates IDL concepts into Java
language constructs
• Everything is accessible by writing normal-
looking Java code
 IDL to Java Type Mapping
IDL Type Java Type
boolean boolean
char / wchar char
octet byte
short / unsigned short short
long / unsigned long int
long long / unsigned long long long
float float
double double
string / wstring String
 IDL vs. Java vs. C++ concepts
IDL Java C++
module package namespace
interface interface abstract
class
operation method member
function
attribute pair of pair of
methods functions
 IDL Method Arguments
interface Warehouse{
boolean locate (in String descr ,out Product p); };
In,out,inout parameters simulated with Holder
class (Predefined for basic types).Public inst
variable called value.
boolean locate (in String descr , ProductHolder p);
ProductHolder p1=new ProductHolder();
w.locate(descr,p1);
Product p2=p1.value;

IDL does not support overloaded methods.

 Sequence and Exceptions in IDL
typedef sequence<Product> ProductSeq;
ProductSeq find (Customer c);
IDL translate sequence into array

exception BadCustomer {string reason;};

ProductSeq find (Customer c); raises BadCustomer;
IDL translate exception into a class, raises into throws

Interface can have const, attribute keyword for pair of methods

e.g. attribute reason
String reason();
void reason(String –reasono);
 Interface
module HelloApp
{
interface Hello
{
string sayHello();
oneway void shutdown();
};
};
 Idl to java
• idlj -fall Hello.idl (default generates client
bindings)

• public interface Hello extends HelloOperations,

org.omg.CORBA.Object,
org.omg.CORBA.portable.IDLEntity {…. }
• All operations in IDL interface are put in
operations interface.
• All CORBA objects are derived from
org.omg.CORBA.Object to ensure required
CORBA functionality.
 Idlj Output
• Hello.java
This interface contains the Java version of our IDL interface.
• 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.
• 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.
• HelloPOA.java
This abstract class is the stream-based server skeleton, providing basic
CORBA functionality for the server.
• HelloStub.java
This class is the client stub, providing CORBA functionality for the client.
• HelloHelper.java
This class provides auxiliary functionality, notably the narrow() method
required to cast CORBA object references to their proper
types.Reading and writing the data types to CORBA stream
 Stubs
• Java objects call stub methods
• Stubs communicate with CORBA objects
– and vice versa
• Transparent integration
 Skeletons
• ORB passes request to skeleton (like a
stub)
• Skeleton calls local implementation
 Remote Interfaces and Stubs

IDL Interface

implements implements
extends
Remote Object
Client Stub Skeleton
(Server)
 Implementing a server
• Creates and initializes an ORB instance
• Gets a reference to the root POA and activates the
POAManager
• Creates a servant instance (the implementation of one
CORBA Hello object) and tells the ORB about it
• Gets a CORBA object reference for a naming context in
which to register the new CORBA object
• Gets the root naming context
• Registers the new object in the naming context under the
name "Hello"
• Waits for invocations of the new object from the client
 Implementing Server and Servant
• The servant, HelloImpl, is the
implementation of the Hello IDL interface;
each Hello instance is implemented by a
HelloImpl instance. The servant is a
subclass of HelloPOA.
• The servant contains one method for each
IDL operation, sayHello() and shutdown()
methods. Code to deal with the ORB is
provided by the skeleton.
Importing Required Packages
// The package containing stubs
import HelloApp.*;
// HelloServer will use the naming service
import org.omg.CosNaming.*;
// The package containing special exceptions thrown by the
name service
import org.omg.CosNaming.NamingContextPackage.*;
// All CORBA applications need these classes
import org.omg.CORBA.*;
// Classes needed for the Portable Server Inheritance Model
import org.omg.PortableServer.*;
import org.omg.PortableServer.POA;
// Properties to initiate the ORB
import java.util.Properties;
 POA
• Object adapter is the mechanism that connects a request
using an object reference with the server code to service
that request.
• The Portable Object Adapter, or POA, is a particular type
of object adapter that is defined by the CORBA
specification.
The POA is designed to meet the following goals:
• Allow programmers to construct object implementations
that are portable between different ORB products.
• Provide support for objects with persistent identities.
• Provide support for transparent activation of objects.
• Allow a single servant to support multiple object identities
simultaneously.
class HelloImpl extends HelloPOA {
private ORB orb;
public void setORB(ORB orb_val) { orb = orb_val; }
// implement sayHello() method
public String sayHello() { return "\nHello world !!\n"; }
// implement shutdown() method
public void shutdown() { orb.shutdown(false); }
}
public class HelloServer {
public static void main(String args[]) {
try{ // create and initialize the ORB
ORB orb = ORB.init(args, null);
// get reference to rootpoa & activate the POAManager
POA rootpoa =
POAHelper.narrow(orb.resolve_initial_references("RootPOA"));
rootpoa.the_POAManager().activate();
// create servant and register it with the ORB
HelloImpl helloImpl = new HelloImpl();
helloImpl.setORB(orb);
// get object reference from the servant and convert to CORBA
object
org.omg.CORBA.Object ref =
rootpoa.servant_to_reference(helloImpl);
Hello href = HelloHelper.narrow(ref);
 POA Manager
• Each POA object has an associated POAManager object
that controls the processing state of the POAs.
• The POAManager can also deactivate the POA. A POA
Manager may be associated with one or more POA
objects.
The POAManager can have the following states:
• Holding - In this state, associated POAs will queue
incoming requests.
• Active - In this state, associated POAs will start
processing requests.
• Discarding - In this state, associated POAs will discard
incoming requests.
• Inactive - In this state, associated POAs will reject the
requests that have not begun executing as well as as
any new requests.
// get the root naming context
org.omg.CORBA.Object objRef =
orb.resolve_initial_references("NameService");
// Use NamingContextExt which is part of the Interoperable
// Naming Service (INS) specification.
NamingContextExt ncRef = NamingContextExtHelper.narrow(objRef);
// bind the Object Reference in Naming
String name = "Hello";
NameComponent path[] = ncRef.to_name( name );
ncRef.rebind(path, href);
System.out.println("HelloServer ready and waiting ...");
// wait for invocations from clients
orb.run();
 Implementing a client
• Create an ORB
• Get a reference to the Naming Context
• Look up the correct name in that Naming
Context
• Receive an object reference to that object
– Actually, to its Stub
• Invoke methods on the reference
import HelloApp.*; // the package containing our stubsimport
org.omg.CosNaming.*; // HelloClient will use the Naming Serviceimport
org.omg.CosNaming.NamingContextPackage.*;import org.omg.CORBA.*; // All
CORBA applications need these classes
ORB orb = ORB.init(args, null);
org.omg.CORBA.Object objRef =
orb.resolve_initial_references("NameService");
NamingContextExt ncRef = NamingContextExtHelper.narrow(objRef);
String name = "Hello";
helloImpl = HelloHelper.narrow(ncRef.resolve_str(name));
System.out.println("Obtained a handle on server object: " + helloImpl);
System.out.println(helloImpl.sayHello()); helloImpl.shutdown();
 Execution
• start orbd -ORBInitialPort 1050 -
ORBInitialHost localhost
• start java HelloServer -ORBInitialPort
1050 -ORBInitialHost localhost
• java HelloClient -ORBInitialPort 1050 -
ORBInitialHost localhost