Introduction to CORBA

Organizational Communications and Technologies

Prithvi N. RaoH. John Heinz III School of Public

Policy and ManagementCarnegie 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 acrossnetworks, 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 thesame machine or across a network that uses the CORBA standard

Reusability

Reusability is the ability of a system to grow functionality throughthe extension of existing components and the ability to combineexisting 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

Common Object Request Broker Architecture (CORBA)

CORBA Services

CORBA Facilities

CORBADomains

CORBAApplications

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 forservices from other objects, components, or applications (also calledimplementation 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 responseto 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)

IIOPORBCore

ORBCore

client server

DynamicInvocationInterface

(DII)

IDLClientStub

ORBInterface Object adapter

ORBInterface

Dynamic Skeletoninterface

IDLServer

Skeleton

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

Resides in the client application Server-based

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 Service1) 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 andtype of return value

3) Client executes server’s method by calling corresponding method inclient 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)

IIOPORBCore

ORBCore

client server

IDLClientStub

Object adapter

IDLServer

Skeleton

Client methodcall

12

34

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

Description of accepted values for return values parameters etc.

Operations Action that object performs or service a client can

invoke Signature of a method

Interface 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 handedseveral completely implemented server classes that are written in Java.The application developer is required to write the server application andsome 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 meansthat once the server is activated it will wait forever for client connections.

Procedure1) 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 todetermine 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 Activationimport PortfolioBrokerImplementation;import org.omg.CORBA.ORB;import org.omg.CORBA.objectimport org.omg.CosNaming.NameComponent;import org.omg.CosNaming.NameHolder;import org.omg.CORBA.SystemException;import 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 ClientImport 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 ClientNameComponent 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