Introduction to CORBA
Organizational Communications and
Technologies
Prithvi N. Rao
H. John Heinz III School of Public
Policy and Management
Carnegie Mellon University
Readings
Posting on the Class Web Site
Objectives

Examine features of an ORB

Present the use of an IDL


Present the creation and activation of an object
implementation
Present a simple client implementation
Problems Addressed by
CORBA

Platform and language dependent software





Software still specific to hardware platforms
Software specific to language
Leads to software legacy that is expensive to change
Cannot easily use software from other developers
Monolithic applications


Can have lots of “useless” features
Can take up valuable memory resources to run basic
features of application
Plug and Play Components

Goal is to combine software components written in
various languages

Goal to move away from monolithic applications

Discrete components contain required features

Goal towards smart components


Versioning
Security and self testing
API and the Software Bus

Bus is a framework into which components can be
plugged



Permits components to talk to each other
Similar to the hardware bus
Application Programmer’s Interface (API) is an
attempt to provide a software bus


Current APIs are still language specific
Current
Goals of Object Management
Group (OMG)

Reduce complexity and accelerate development time

Increase reusability, interoperability and portability
Interoperability
Interoperability is the ability of a component to be invoked across
networks, languages, operating systems and tools.
For CORBA interoperability means the ability of objects and
applications to exchange requests via ORBs.
i.e. the ability to make requests and respond to requests on the
same machine or across a network that uses the CORBA standard
Reusability
Reusability is the ability of a system to grow functionality through
the extension of existing components and the ability to combine
existing components in new ways in order to create new components
Portability
Portability is the ability to transfer a program from one hardware and
/or software environment to another.
CORBA Services

Augment the core CORBA capabilities that make it
possible for developers to share objects, component
and applications


Object creation
Control access to objects
Examples are persistence service, naming service,
transaction service and many others.
CORBA Domains

Provide capabilities for developing applications in
specific areas



Medicine
Telecommunications
Finance
Goal is to provide a specification of how to architect objects
and components for domain specific applications.
Object Management
Architecture
CORBA
Facilities
CORBA
Domains
CORBA
Applications
Common Object Request Broker Architecture (CORBA)
CORBA Services
The CORBA ORB

ORB is


Software that enables communication between distributed
heterogeneous applications
Software located between servers and clients that permits
them to communicate
An ORB allows applications to communicate with one
another no matter where they are located or what kind of
system on which they run.
Client
A client is an object component or application that makes requests for
services from other objects, components, or applications (also called
implementation objects or servers).
A given object or, component or application can be a client for some
requests and a server for other requests.
The client is not part of the ORB but uses the ORB
Server (object
implementation)
A server (also called an object implementation) also provides a response
to requests for services from other objects, components or applications.
A given object, component or application can be a server for some
requests and a client for other requests.
Servers are not part of the ORB
The ORB Core

Responsible for communicating requests and
encompasses the entire infrastructure required



Identify and locate objects
Handle connection administration
Deliver data
CORBA (revisited)
client
Dynamic
Invocation
Interface
(DII)
IDL
Client
Stub
ORB
Core
server
IDL
Server
Skeleton
ORB
Interface
ORB
Interface
IIOP
Dynamic
Skeleton
interface
Object adapter
ORB
Core
Internet Inter-ORB Protocol
(IIOP)



Standard protocol for communication between ORBs
on TCP/IP based networks
ORBs must support IIOP in order to be ORB
compliant
Can support other protocols but IIOP must be
supported for compliancy
IDL Client Stubs



Client stub generated by the IDL compiler
Permits the client to invoke an implementation
object’s services
Client stubs using the IDL are static


Also considered stodgy
Alternative is the dynamic invocation interface (DII)
Dynamic Invocation Interface
(DII)


Defines client side of interface that allows dynamic
creation and invocation of requests to objects
DII offers a non-static way to invoke server
operations
IDL Server Skeletons


Compiler generates IDL server skeletons
Code providing means by which server’s operation
can be accessed
Dynamic Skeleton Interface
(DSI)


Provides run-time binding mechanism for servers not
statically defined at compilation
DSI is similar to DII


Looks at parameter values of incoming requests and
determines target object
Determines target operation
Object Adapter


Primary mechanism by which server object has
access to ORB services
Performs several functions



Generates object references
Invokes methods
Basic security
ORB Interface



Collection of operations providing services common
to object implementations and clients
ORB initialization and facilities to obtain necessary
object references
Contains functions regardless of which Object
Adapter is used
Steps to Creating a CORBA
Application (Static)
1) Thorough OO analysis and design to determine distributed objects
2) Use static IDL to describe objects and compile the IDL file
3) Write a target language implementation
4) Write a main program that instantiates implementation objects
5) Write client applications that use implementation objects
6) Compile all source files (stubs, skeletons) and link executable
7) Run the ORBs and clients after starting the servers first
Object Request Broker
Interfaces

ORB can be a single component or a collection of
components


Vendor dependent
ORB interface is the intermediary between objects
and ORB i.e




object_to_string() converts object reference to a string
resolve_initial_reference() finds well-known server objects
string-to-object() converts a string to an object reference
BOA_init() returns an object that is a Basic Object Adapter
Interesting ORB flavors

Client and implementation


Server-based



Resides in the client application
Exists in separate process
Routes communications between clients and object
implementations
System-based


Server-like but ORB is part of OS
Enhances security
Object Identification

Identify an object by




Requesting an object reference
Name method to be invoked
Using all parameters required for method
Return value for the method in call
status = foo.getPassword(“John”);
object_to_string()


String reference to an object implementation can be
created
Client can read the string and use the method
string_to_object to convert reference to object
Directory Server


Some objects contain methods that return other
object references
Client must know the reference to one of these
objects in order to get access to references to other
objects

Client uses the reference to the directory object and calls a
method with the name of a service that it requires
Naming Service


Used for registering their object references and
names
Clients look up a known name to get object reference



Naming context is like a disk drive
Naming component is like a file
Have a root context
Using the Naming Service
1) Locate Naming Service root context server object
resolve_initial_reference(“NameService”);
2) Narrow returned object to a Naming Context object
3) Do some error checking
4) Create a Name for the Naming Context
5) Create Naming context using root context
6) Repeat step 5 above
7) Add the Name Component with the bind() operation
resolve_initial_references()


Interface can resolve several key ORB interfaces
including the Naming Service
Can call service’s methods in order to locate other
servers that have registered with the service
Turning Method Calls into
Requests
1) Client obtains an object reference for server
2) Client packages reference along with method name, parameters and
type of return value
3) Client executes server’s method by calling corresponding method in
client stub
4) Inside client stub call is turned into request
5) ORB interface operation is called to pass newly created request to
ORB
CORBA (revisited)
client
server
Client method
call
3
4
IDL
Server
Skeleton
IDL
Client
Stub
Object adapter
1
ORB
Core
IIOP
2
ORB
Core
Describing Objects with IDL


Interface Definition Language is basis for object
definition
Language independent way to define objects



Independent of OS and hardware platform
Permits design portability
Use IDL to define objects and modules making up
applications

Creates stubs and skeletons
Precursor to IDL

Must know what objects are

Must know name of each object

Must know data that objects deal with

Must know what each object is supposed to do
IDL Elements

Data Type


Operations



Action that object performs or service a client can invoke
Signature of a method
Interface


Description of accepted values for return values parameters
etc.
Defines an object’s data and its operations
Module

Group of interfaces
Example in Java
In the real world it is likely that an application developer will be handed
several completely implemented server classes that are written in Java.
The application developer is required to write the server application and
some client applications that use them.
Need to know the desired activation policy
Need to know the constructor parameters for one or more server objects
We will look at the persistence server policy in this example. This means
that once the server is activated it will wait forever for client connections.
Procedure
1) Decide on a server activation policy and write a server application in
Java.
2) Look in the implementation class source code for server objects.
3) Examine the interface definition language file for server objects to
determine their interfaces
4) Write client(s) in Java or other language
Persistent Server

Implemented as a standalone application


In java it is a class with a main() method
Activation policy is a procedure by which server
object is made ready to process method calls from
clients



Decide on a server activation policy
Identify which server objects must be created
Decide how to make server object reference available
Persistent Server
1) Import server object implementation class and other needed
classes
2) Create a class that has a single main() method
3) In the main() method (inside a try block) initialize the ORB
4) Create initial instance of desired server object(s)
5) Make reference to server object available to client applications
6) Wait for client application
Server Activation
import
import
import
import
import
import
import
PortfolioBrokerImplementation;
org.omg.CORBA.ORB;
org.omg.CORBA.object
org.omg.CosNaming.NameComponent;
org.omg.CosNaming.NameHolder;
org.omg.CORBA.SystemException;
SimpleNames;
public final class JavaServer {
public static void main(String args[]) {
try {
ORB orb = new ORB.init(args, null);
ORB myOrb = new ORB();
myOrb.init(args, null);
Creating an Instance of a
Server
PortfolioBrokerImplementation broker;
broker = new PortfolioBrokerImplementation();
orb.connect((Object)broker);
1) Create an instance of a server using new
2) Use orb.connect() to tell the ORB that the server is ready
No need to do an orb.connect() more than once for a
persistent server activation policy
Using the Naming Service
1) Have a server object ready to name
2) Place the name into an array of NameComponent objects
3) Use the SimpleNames.bindToName() static object method to
bind the object to the name
Steps for Server
NameComponent myName[] = new NameComponent[3];
myName[0] = new NameComponent(“Examples”, “OC&T”);
myName[1] = new NameComponent(“src”, “OC&T”);
if (!SimpleNames.bindToName(orb, (Object)broker, myName))
{
return;
}
Server Epilogue
}
try {
Thread.currentThread.join();
}
catch(InterrruptedException e1) {
System.exit(1);
}
}
catch(SystemException e2) {
System.exit(1);
}
}
Writing a Client
Import Portfolio.PortfolioBroker;
import org.omg.CORBA.ORB;
import org.omg.CORBA.Object;
import org.omg.CosNaming.NameComponent;
import org.omg.CORBA.SystemException;
import SimpleNames;
public final class FindBrokerFn {
public final static PortFolioBroker
FindBroker(ORB orb) {
Object obj;
PortFolioBroker Broker = null;
try {
Writing a Client
NameComponent name[] = new NameComponent[3];
name[0] = new NameComponent(“Example”, “OC&T”);
Name[1] = new NameComponent(“src”, “OC&T”);
obj = SimpleNames.getReference(orb, name);
Broker = PortfolioBrokerHelper.narrow(obj);
}
catch(SystemException e1) {
Broker = null;
}
Writing a client
If (Broker == null || Broker._non_existent()) {
Broker == null;
System.out.println(“Could not find object: Run server first\n”);
}
else
System.out.println(“ Located PortfolioBroker\n”);
return Broker;
}
}
Summary

Presented the basics of Object Request Broker

Presented Interface Definition Language (IDL)


Examined Persistence and object implementation
creation and instantiation
Presented a simple client