CORBA Part I A RMI case study

®

Distributed Systems

Copyright Karsten Schulz Terp-Nielsen

CORBA Part IA RMI case study

Karsten Schulz Terp-Nielsen

®

Distributed Systems


Agenda

Object Managment Group (OMG) Corba Overview

– Architecture– OMG IDL – ORB– Object Model – The Interoperability Architecture– Language mappings

J2SE 1.4 support for CORBA

®

Distributed Systems


Object Management Group (OMG)CORBA/OMG

CORBA is the acronym for Common Object Request Broker Architecture

CORBA is OMG's open, vendorindependent specification for an architecture and infrastructure that computer applications use to work together over networks

OMG is the world’s largest computer industry consortium with over 800 members ( year 2000 figure)

OMG began its work in 1989 The goals of OMG are

– promotion of the object-oriented approach to software engineering

– development of a common architectual framework for writing distributed object-oriented applications based on interface specifications for the objects in the application

®

Distributed Systems


Object Management Group (OMG) OMA

Besides CORBA OMG also controls the Object Management Architecture (OMA) specification and other specifications in the area Analysis and Design (XMI, UML etc.)

OMA is the framework which all OMGs adapted technology fits

OMA consists of two main parts– Core Object Model– The Reference Model

®

Distributed Systems


Object Management Group (OMG) OMA Core Object Model

Defines concepts that allow distributed application development to be facilitated by an ORB

– Contains abstract definitions

The goals of the Core Object Model are – portability (design portability - to be able to

create components that don’t rely on existence and location of a particular object implementation)

– interoperability (to be able to invoke operations on objects regardless of where they are located, on which platform they execute, or in which programming language they are implemented

®

Distributed Systems


Object Management Group (OMG) OMA Core Object Model

The Core Object Model is a classic object model (actions performed by invoking operations on objects)

– Objects (entities or concepts, identity represented by an object reference)

– Operations: signatures, parameters, return values, exceptions

– Nonobject types (data types), Not specified by the core model, CORBA does

– Interfaces, grouping of operations– Substitutability

When two interfaces can act as substitutes to each other (only substitution through inheritance are acceptable in the CoreObject Model)

Two interfaces having the same operations are not substi-tutable as they problably don’t have the same semantic

®

Distributed Systems


Object Management Group (OMG) OMA Reference Model

OMA defines the interfaces for the objects and leave the implementationto software vendors

OMA is OMGs vision for a software component environment where all theirwork fits

The OMA Reference Model categories objects into four application areas

Your CORBAobjects!

Naming, Notification,Security, Trading etc.

Mobile Agents,MOF, DataInterchange

Tele, HealthCare, Manu-facturing etc.

Domain objects Common facilities

Object ervices

®

Distributed Systems


CORBA OverviewCORBA

Introduction Architecture OMG IDL ORB Object Model The Interoperability Architecture Language mappings

®

Distributed Systems


CORBA OverviewIntroduction

CORBA builds on the OMA Core Object Model and provides

– syntax and semantics for IDL– A framework for interoperability: two specific

protocols– a set of language mappings from IDL to

prog.lang.

CORBA is operating with transparency– Location transparency– Programming Language transpareny– Platform/vendor transparency– Network HW/SW transparency

®

Distributed Systems



The key to Location transparency is the Object Request Broker (ORB)

The key to Programming Language Transparency is an implementation neutral Interface Definition Language called OMG IDL that provides separation of interface and implementation

The key to Platform transparency and Network HW/SW transparency is GIOP/CDR (Common Data Representation)

®

Distributed Systems



In other words……………..

CORBA allow programs from any vendor, on almost any computer, operating system, programming language, and network, to interoperate with a CORBA-based program from the same or another vendor, on almost any other computer, operating system, programming language, and network

®

Distributed Systems


CORBA OverviewArchitecture

client server

proxy

or dynamic invocation

implementation repository object

adapter

ORBORB

skeleton

or dynamic skeleton

client program

interface repository

Request

Replycorecore for A

Servant A

The Orb core equals the Communication Module in the generic RMI architecture

The ORB can be implemented in many ways; stand-alone, distributedTo the programmer the ORB is a pseudo-object; interface to library functions

ORB

IIOP

®

Distributed Systems


CORBA OverviewArchitecture

Compared to the Generic RMI architecture there is only 3 new modules

– Object Adapter– Implementation Repository– Interface Repository

The communication protocol used by CORBA is based on the GIOP (General Inter-ORB Protocol) specification

IIOP (Internet Inter-ORB Protocol) denotes the implementation of GIOP over TCP/IP

®

Distributed Systems


CORBA OverviewOMG IDL

OMG IDL is a declarative language for defining the interfaces of CORBA objects

OMG IDL is language independent OMG IDL is used by ORB-specific IDL

compilers to generate stubs, skeletons and interface code in a given programming language in compliance with the IDL mapping specification for that programming language

®

Distributed Systems



The syntax of OMG IDL is drawn from C++ but it contains different keywords for stuff

OMG IDL doesn’t contain programming statements as its only purpose is to define interface signatures

The following constructs are available– Constants– Data type declarations (IDL types)– Attributes

®

Distributed Systems



– Operations Parameters are marked as either in, out or inout

– Interfaces Group data type, attribute and operation

declarations Exceptions can be defined Support for multiple inheritance – name collision

not allowed– Valuetypes

Group data type, state and operation declaration When client invokes methods -> local method

invocation– Modules

Name space separation

®

Distributed Systems


CORBA OverviewOMG IDL - Example

struct Rectangle{ 1long width; long height;long x;long y;

} ;

struct GraphicalObject { 2string type; Rectangle enclosing; boolean isFilled;

};

interface Shape { 3long getVersion() ;GraphicalObject getAllState() ; // returns state of the GraphicalObject

};

typedef sequence <Shape, 100> All; 4interface ShapeList { 5

exception FullException{ }; 6Shape newShape(in GraphicalObject g) raises (FullException); 7All allShapes(); // returns sequence of remote object references 8long getVersion() ;

};

®

Distributed Systems


CORBA OverviewOMG IDL - Example

public interface ShapeList extends org.omg.CORBA.Object {Shape newShape(GraphicalObject g) throws ShapeListPackage.FullException;Shape[] allShapes();int getVersion();

}

The following are generated by the idl2java (ORBACUS: jidl) compiler

+ ShapeListHolder.java, ShapeListHelper.java, ShapeListOperations.java, ShapeListPOA.java, _ShapeListStub.java, ShapeHolder.java, ShapeHelper.java, ShapePOA.java, _ShapeStub.java, Shape.java, ShapeOperations.java, FullException.java, FullExceptionHolder.java, FullExceptionHelper.java, GraphicalObject.java, GraphicalObjectHolder.java, GraphicalObjectHelper.javaRectangle.java, RectangleHolder.java, RectangleHelper.javaAllHelper.java, AllHolder.java

®

Distributed Systems


CORBA OverviewORB

The ORB is particular responsible for – making the location transparency ie. routing

the request from a client to object and routing the reply to destination

– management of the Interface Repository; a distributed database of IDL definitions

– Client side services for converting remote object references to and from strings

– Client side dynamic invocation of remote objects

– Server side resource management that is activation and deactivation of objects

®

Distributed Systems


CORBA OverviewORB - Components

Implementation Repository (optional) Interface Repository Client Stubs Server Skeletons Portable Object Adapter (POA) Dynamic Invocation Interface (DII) Dynamic Skeleton Interfaces (DSI)

®

Distributed Systems


CORBA OverviewORB - Components diagram

The ImplementationRepository and theInterface Repositoryare not shown here

®

Distributed Systems


CORBA OverviewORB - Implementation Repository

ORBs also often communicate with a ORB deamon process which is a Implementation Repository

Implementation Repository is a database of object implementation information which the ORB can use for locating the server housing the object implementation

Implementation Repository is a server activator Example: Java IDL in Java 1.4

– ORBD

Example: Orbacus fra IONA– Imr

®

Distributed Systems


CORBA OverviewORB - Implementation Repository

An Implementation Repository is responsible for locating and activating on demand registered CORBA servers

An Implementation Repository stores a mapping from names of Object Adapters to servers address (host:port) along with scripts/batch files for starting the server if not runningImplementation Repository: Jupiter:8080

POA1 \bin\server\startPOA1 TestHost:8888

The ORBcus IMRconsole is an ex.of GUI adm. of theIMR

®

Distributed Systems


CORBA OverviewORB - Interface Repository

The Interface Repository stores information about registered IDL Interfaces to clients and servers

– names of methods– for each method the names and types of arguments

and exceptions– the key is a IDL compiler generated unique identifier

which is generated for each IDL type it compiles

The Interface Repository is the fundament for reflection in CORBA

The Interface Repository and the Dynamic Invocation Interface adds the power of reflection to CORBA

®

Distributed Systems


CORBA OverviewORB - Interface Repository

The Interface Repository can be access by both clients and servers

The Interface Repository is often a autonom server/process which contain command line commandos for feeding interface definitions into and deleting interface definitions from the Repository

Example: ORBacus– irserv, irfeed, irdel

®

Distributed Systems


CORBA OverviewORB - Client stubs/proxy

Generated from an OMG IDL compiler to the client language of choise

Acts as a local proxy for the remote object Aggregates the IOR Marshals data to be send;Unmarshal result

– Data send is typically Object key, name of operation and in and inout parameters

There exists one client stub instance per instance of remote object

Can’t be downloaded at run-time as in JavaRMI

®

Distributed Systems


CORBA OverviewORB - Client stubs/proxy example

interface Hello

{

string say_hello();

void shutdown();

};

public interface HelloOperations

{ //

// IDL:Hello/say_hello:1.0

//

/***/

String say_hello();

//

// IDL:Hello/shutdown:1.0

//

/***/

void shutdown();

}

hello.idlGenerated HelloOperations.java interface to use for the Skeleton

public interface Hello extends HelloOperations,

org.omg.CORBA.Object,

org.omg.CORBA.portable.IDLEntity

{

}

Generated Hello.java interface to use for the Stub

®

Distributed Systems


CORBA OverviewORB - Client stubs/proxy example

public class _HelloStub extends org.omg.CORBA.portable.ObjectImpl

implements Hello

{

private static final String[] _ob_ids_ = { "IDL:Hello:1.0", };

….

// IDL:Hello/say_hello:1.0

public String say_hello() {

while(true) {

if(!this._is_local()) {

org.omg.CORBA.portable.OutputStream out = null;

org.omg.CORBA.portable.InputStream in = null;

try {

out = _request("say_hello", true);

in = _invoke(out);

String _ob_r = in.read_string();

return _ob_r;

} catch(org.omg.CORBA.portable.RemarshalException _ob_ex)

Create output stream

Create input stream as a Result of the invocation

Marshall arguments

Un-Marshall result, out, inout

®

Distributed Systems


CORBA OverviewORB - Skeleton

Generated from an OMG IDL compiler to the server language of choice

Unmarshals request data; Dispatch request to servant; Marshals reply data

Servant is the actual CORBA object implementation in a chosen programming language

Skeletons are used by the POA

®

Distributed Systems


CORBA OverviewORB - Skeleton example

public abstract class HelloPOA extends org.omg.PortableServer.Servant

implements org.omg.CORBA.portable.InvokeHandler, HelloOperations

{

static final String[] _ob_ids_ = { "IDL:Hello:1.0",};

public org.omg.CORBA.portable.OutputStream _invoke(String opName,

org.omg.CORBA.portable.InputStream in,

org.omg.CORBA.portable.ResponseHandler handler) {

final String[] _ob_names = { "say_hello","shutdown" };

….

//Find index for operation

…..

switch(_ob_index) {

case 0: // say_hello

return _OB_op_say_hello(in, handler);

case 1: // shutdown

return _OB_op_shutdown(in, handler);

} throw new org.omg.CORBA.BAD_OPERATION();}

Skeleton codefor hello.idl produced byIDL2Javacompiler fromORBACus-jidl

®

Distributed Systems


CORBA OverviewORB - Skeleton example continued

private org.omg.CORBA.portable.OutputStream

_OB_op_say_hello(org.omg.CORBA.portable.InputStream in,

org.omg.CORBA.portable.ResponseHandler handler)

{

org.omg.CORBA.portable.OutputStream out = null;

String _ob_r = say_hello();

out = handler.createReply();

out.write_string(_ob_r);

return out;

}

private org.omg.CORBA.portable.OutputStream

_OB_op_shutdown(org.omg.CORBA.portable.InputStream in,

org.omg.CORBA.portable.ResponseHandler handler)

{

….

}

}

Skeleton codecontinued

®

Distributed Systems


CORBA OverviewORB - Portable Object Adapter

An Object Adapter is responsible for – Generation and interpretation of IORs– Carrying out method invocations– Security on interactions– CORBA Object/implementation

activation and deactivation– Mapping of IORs to corresponding

object implementations– Registration of object implementations

The component in the ORB architecture that maps the abstract concept ofa CORBA Object onto concrete concepts provided by a specific prog. lang.

Life cycle managment

®

Distributed Systems



Terminology– Servant: Implementation object providing the run-

time semantic of one or more CORBA objects– ObjectID: An identifier, unique within a POA, that a

POA uses to identify a CORBA Object– AOM: A table of Associations between ObjectIDs

and servants– Incarnate: The action of providing a running

servant to serve requests associated with a particular ObjectID The POA will keep the association in AOM if

configurated to do that

®

Distributed Systems



– Etherealize: The action of destroying the association between an ObjectID and a servant

– Activated: When a CORBA Object has been associated with a servant incarnating the object

– Deactivated: When a CORBA Object has no incarnating servant

– Default Servant: An object for which all incomming requests for ObjectIDs not in AOM are dispatched to Only if configurated to do that

®

Distributed Systems



An Object Adapter provides a public interface to object implementations

An Object Adapter provides a private interface to the Skeleton

An Object Adapter is build upon a private ORB-dependent interface to the ORB Core

There are a variety of possible Object Adapters but it preferrable to use a few as possible as the object implementation is dependent upon them

®

Distributed Systems


CORBA OverviewORB - Portable Object Adapter - high-level architecture

ORBCore

POAManager POA

Server Application

Servants

Dispatch withhelp from skeletonsRequest

®

Distributed Systems


CORBA OverviewORB - Portable Object Adapter – POA Manager

Represents an transport endpoint (host-port for TCP/IP)

Associated with a POA when the POA is created - cannot be changed

Acts as a gate and controls the flow of requests into one or more POAs

A default POA Manager exists for all server processes

The developer can create custom POA Managers

®

Distributed Systems


CORBA OverviewORB - Portable Object Adapter – POA Manager

Active

Holding

Discarding

Inactive

Creation

Hold_requests

Active

Active

Hold_requests

Discard_requests

Discard_requests

Deactivate

Deactivate

Deactivate

POA Manager state transitions

®

Distributed Systems


CORBA OverviewORB - Portable Object Adapter – POA overview

A server process contains one or more POAs

All server processes contains one special POA called the ”rootPOA” which is managed by the ORB

– Developers can use this if default policies are suitable

Additional POAs can be created as children of other POA resulting in a hierarcy with the ”rootPOA” as the root

Advantages: Different policies can be assigned to each POA

®

Distributed Systems



import org.omg.CORBA.*;import org.omg.PortableServer.*;

// Initialize ORB and POAORB orb = ORB.init (args, props);POA rootPOA = POAHelper.narrow (orb.resolve_initial_references ("RootPOA"));

// Get a reference to the POA managerPOAManager manager = rootPOA.the_POAManager();

// Create a servant and activate itHelloWorldImpl hwImpl = new HelloWorldImpl();HelloWorld hw = hwImpl._this (orb);

// Wait for incoming requests ("run the implementation")manager.activate();orb.run();

Server code when usingrootPOA with default policies

®

Distributed Systems



Each POA form a namespace for servants

All servants sharing the same POA share common implementation characteristics determined by the POA’s policies

Each servant has exactly one POA but many servants may share the same POA

The POA manage the relationships between object references, object IDs and servants

®

Distributed Systems



ORBextract POA namefrom Object Key

POAfindPOA

Object Reference(with Object Key)

requestfrom a client

or

Adaptor Activator

call AdaptorActivator ifPOA not found

create POA

extract Object Idfrom Object Key Active Object Map

Object ID

Object ID

Object IDServant

Servant

incarnateservant

Default Servant

or

Servant Manager

or

ServantActivator

ServantLocator

createservant

updatemap

®

Distributed Systems


CORBA OverviewORB - Portable Object Adapter – Adapter Activator

An Adapter Activator is an application object the developer can associate with a POA

The ORB will invoke an operation on an adapter if its processing a request for a child POA that does not currently exist

The Adapter Activator can then create the child POA on demand and the ORB will deliver the request to the newly created POA

®

Distributed Systems


CORBA OverviewORB - Portable Object Adapter – Life cycle managment

To better understand the activation/passivation mechanism offered by the POA, let’s talk a little bit about Life Cycle management in distributed OO systems

When we make OO development we make a conceptual model of the problem domain consisting of system entities denoted objects categorized in classes

The conceptual model is then mapped to the machine when we make a design model for the application – a model for the system running on a machine

®

Distributed Systems



Phenomenons

Problem spec.concepts

Abstraction

Machine lang.

RealizedConcepts

Abstraction

Problem domain System model

Modeling

A conceptual model is made for the Problem domain

OOA

Problem spec. Concepts are defined from the realized concepts OOD

We find elements that model phenomenos and concepts from the problem domain/conceptual model

OOP

®

Distributed Systems



The Implementation Model model the behaviour of the objects in the problem domain

– The application will consist of the implementation model plus objects modeling the functionality and interfaces (UI+integration)

The model register and remember relevant states in the problem domain

– The objects in the implementation model register the behaviour of the objects in the problem domain

– With some delay the state of the implementation model objects are changed according to events happening in the problem domain

®

Distributed Systems



When done modeling we have one or more implementation objects register relevant state changes for each system entity (problem domain object)

The life cycle of a system entity in the problem domain and the related implementation objects need not be the same

– The difference between system entities and object implementations is the heart of Life Cycle and Persistence

®

Distributed Systems



Persistence is chiefly concerned with what it means for an system entity to exist when its implementation object(s) does not

Life cycle is chiefly concerned with the life cycle of system entities versus the life cycle of the runtime implementation objects

– System entities: created, activated, deactivated, destroyed

– Runtime instance: instantiated, persistent information loaded, remote reference exported etc.

In CORBA most of the basic life cycle support lies within the POA

®

Distributed Systems



In CORBA persistence is provided through a CORBA service named Persistent State Service

– Likewise is enhanced Life cycle support provided through Life cycle service

In CORBA system entities are implemented/modeled by CORBA Objects

CORBA Objects are identified by remote object references, specified through IDL interfaces and implemented by servants

So CORBA Objects and servants have different life cycle and remember: System entities and CORBA objects have different life cycle

®

Distributed Systems


CORBA OverviewORB - Portable Object Adapter – Life cycle management

There is no actual relationship between the life time of a servant and the life time of a CORBA Object

– Only that a servant must exist at the time the CORBA Object is activated

– The servant may have been created before the CORBA Object activation or even before the remote object reference creation

– The servant may exists beyond the time the CORBA Object is active or even exists

®

Distributed Systems



CORBA Object non-existent

CORBA Object existent

CORBA Object activated

CORBA Object deactivated

activatecreate reference

CORBA Object State diagram

deactivate

activate

All transitions are triggeredby operations on a POA

When activating an CORBAobject immediately - thecorresponding remote refdoesn’t have to be createdright away; it can done anytime later

When creating an remoteobject ref - an ObjectID and a remote object reference isassociated; activation canbe done later!

destroy

Remember when the CORBA Object does not exist, the system entity can exist in terms of fx. a row in a db table

®

Distributed Systems



Object create_reference (in CORBA::RepositoryId intf)raises (WrongPolicy);

Object create_reference_with_id (in ObjectId oid,in CORBA::RepositoryId intf)

raises (WrongPOlicy);

ServantManager get_servant_manager ()raises (WrongPolicy);

void set_servant_manager (in ServantManager imgr)raises (WrongPOlicy);

Servant get_servant ()raises (NoServant, WrongPolicy);

void set_servant (in Servant serv)raises (WrongPOlicy);

ObjectId activate_object (in Servant serv)raises (ServantAlreadyActive, WrongPolicy);

void activate_object_with_id (in ObjectId oid,in Servant serv)

raises (ServantAlreadyActive, ObjectAlreadyActive, WrongPolicy);

Object activation with servant Remote reference creation without servant

CORBA object activated CORBA object exist

Servant manager registration Default servant registration

®

Distributed Systems


CORBA OverviewORB - Portable Object Adapter – Life cycle management

Object Reference

Object Id

Servant

ObjectId reference_to_id (in Object ref)raises (WrongAdapter, WrongPolicy);

Object id_to_reference (in ObjectId oid)raises (ObjectNotActive, WrongPolicy);

ObjectId reference_to_id (in Object ref)raises (WrongAdapter, WrongPolicy);

Object id_to_reference (in ObjectId oid)raises (ObjectNotActive, WrongPolicy);

ObjectId servant_to_id (in Servant serv)raises (ServantNotActive, WrongPolicy);

Servant id_to_servant (in ObjectId oid)raises (ObjectNotActive, WrongPolicy);

ObjectId servant_to_id (in Servant serv)raises (ServantNotActive, WrongPolicy);

Servant id_to_servant (in ObjectId oid)raises (ObjectNotActive, WrongPolicy);

Servant reference_to_servant (in Object ref)raises (ObjectNotActive, WrongAdapter, WrongPolicy);

Object servant_to_reference (in Servant serv)raises (ServantNotActive, WrongPolicy);

Servant reference_to_servant (in Object ref)raises (ObjectNotActive, WrongAdapter, WrongPolicy);

Object servant_to_reference (in Servant serv)raises (ServantNotActive, WrongPolicy);

Methods on the POAOnly if RETAIN policy

Plus UNIQUE_IDOr IMPLICIT_ACTIVATIONAnd not active

Plus UNIQUE_IDOr MULTIPLE_IDAnd not active

activated

®

Distributed Systems


CORBA OverviewORB - Portable Object Adapter - Policies

Each POA maintain a Active Object Map (AOM) that map object IDs to servants

.

.

ServantsAOM

POA

OBJID:1

OBJID:N+1

OBJID:N

IOR Object Reference

POA1,OBJID:N

Client

…… …..

It can however be disabled

®

Distributed Systems



Each POA is associated with 7 policies when its created – they are not changeable later

The policies are not inherited from parent POA to its children POA upon creation

– Given a set of standard policies

Policies control implementation characteristics of the servants and object references

Examples are– threading model for request dispatch– life time of references

®

Distributed Systems



LifespanPolicy– Transient object references– Persistent object references

IdAssignmentPolicy– Object id provided by either the

application or the system (USER_ID, SYSTEM_ID)

– Persistent object references usually use IDs generated by the application (fx. Db primary key) uses activate_object_with_id on POAs

– Transient object references usually use IDs generated by the system

Detailed furtherin discussingthe object model

®

Distributed Systems



IdUniquenessPolicy– How object references are mapped to

servants– one servant for each Corba object

(UNIQUE_ID)– one servant for more Corba objects

(MULTIPLE_ID)..

ServantsAOM

POA

OBJID:1

OBJID:N+1

OBJID:N

.

.

ServantsAOM

POA

OBJID:1

OBJID:N+1

OBJID:N

OBJID:N+2

current

®

Distributed Systems



– Using MULTIPLE_ID offers you scalability possible slow access to servant state

ImplicitActivationPolicy– Whether newly instantiated servants need be

registered with the ORB (activation) manually or that happen automatically (NO_IMPLICIT_ACTIVATION, IMPLICIT_ACTIVATION)

– Transient object references usually use implicit activation of servants

– Persistent object references usually use explicit activation of servants

Lets you developthe server as ‘Type’based while clientssee it as instancebased!!!!!

®

Distributed Systems



RequestProcessingPolicy– Whether the POA uses static servant mapping (AOM)

or servants are instantiated dynamically

– Possible values USE_ACTIVE_OBJECT_MAP_ONLY USE_DEFAULT_SERVANT USE_SERVANT_MANAGER

Servant Activator (RETAIN - servant for continues use)

Servant Locator (NON-RETAIN - servant for just the single operation - preInvoke()/postInvoke())

®

Distributed Systems



ServantRetentionPolicy– Whether the POA keep the servants in memory

all the time (RETAIN) or not (NON_RETAIN)– NON_RETAIN has to be used with

USE_DEFAULT_SERVANT or USE_SERVANT_MANAGER RequestProcessing

– If AOM the POA automatically calls a default servant or a servant manager if the requested object ID isn’t in the AOM

– This policy can be used to create the illusion of all objects running in the server - the default servant or servant manager just creates servants on request and maybe destroys them again

®

Distributed Systems



ThreadPolicy– Whether the POAs processes request

single threaded or whether the ORB chooses a threading model for request dispatch (ORB_CTL_MODEL, SINGLE_THREAD_MODEL)

– Single-threaded means that all requests for that POA is serialized

– If you choose to let the ORB decide you have to consult your ORBs documentation to see which threading the particular ORB practices

®

Distributed Systems



ORBaCus provides more threading models

– SingleThreaded Blocking (Client)– SingleThreaded Reactive (Client/Server)– Threaded (Client/Server)– Thread-per-Client (Server)– Thread-per-Request (Server)– ThreadPool (Server)

Java ORB 1.4 doesn’t support SingleThreaded model

®

Distributed Systems



Default values for the 7 policies for the RootPOA

– transient– system_id– unique_id– retain– use_active_object_map_only– implicit_activation– orb_ctl_model

®

Distributed Systems



Standard policies for POA creation– transient– system_id– unique_id– retain– use_active_object_map_only– no_implicit_activation– orb_ctl_model

®

Distributed Systems



Code for creation of policies

......Policy[] tpolicy = new Policy[3];tpolicy[0] = rootPOA.create_lifespan_policy( LifespanPolicyValue.TRANSIENT );tpolicy[1] = rootPOA.create_request_processing_policy( RequestProcessingPolicyValue.USE_ACTIVE_OBJECT_MAP_ONLY );tpolicy[2] = rootPOA.create_servant_retention_policy( ServantRetentionPolicyValue.RETAIN);POA myPOA = rootPOA.create_POA(”myPOA”,rootPOA.the_POAmanager(), tpolicy);.....

Each policy has its own factory

®

Distributed Systems



When deciding on how to configurate the POA, the following main design factors has to be taken into account

– How many objects will the POA host?– What is the expected request load?– Do objects have persistent state?

®

Distributed Systems


CORBA OverviewORB - Portable Object Adapter example

To create a POA based CORBA server application you have to

1) IDL-2-Java compile the interfaces you are going to use -> this produces the following files for IDL interface hello:HelloOperations.java, HelloPOA.java HelloPOATie.java (--tie), HelloHelper.java, HelloHolder.java, _HelloStub.java, Hello.java

2) make a servant class

3) make a CORBA server that instantiates the servant and activate it

®

Distributed Systems


CORBA OverviewORB - Portable Object Adapter example

To make the servant class – Inherit from the POA skeleton generated by the

OMG Idl-2-Java compiler

– What if I want to servant to inherit from another class? Solution - generate the skeleton as a tie

implementation

– Example Hello (eksempler/hello) Servant class:Hello_impl.java Server class:Server.java

– This program uses the default values for the 7 policies for the RootPOA

®

Distributed Systems


CORBA OverviewORB - Dynamic Invocation Interface (DII)

DII is how you from a client can invoke remote object without having stubs/proxies for them

– As noted earlier; in Java RMI this is done by downloading the stubs/proxies at run-time

The steps involved are– Client obtain interface from the Interface

Repository– Client constructs an invocation by usage of

DII and sends it to the server

®

Distributed Systems


CORBA OverviewORB - Dynamic Invocation Interface (DII)

DII requests send to server can be of the following types

– Synchronous; blocking call invoke()– Asynchronous; non-blocking call send_deferred returns

without waiting for the invocation to complete to get the result the client can either invoke the blocking

get_response() or poll for completion by poll_response()

– One-way call send_oneway() without reply from server

Multiple requests can also be issued for one-way and asynchronous requests by providing a list of request

®

Distributed Systems


CORBA OverviewORB - Dynamic Skeleton Interface (DSI)

The Dynamic Skeleton Interface allows an ORB to invoke an object implementation without compile-time knowledge about the interface ie. without a Skeleton class

This allows for writing programs that deal with requests in a generic manner

– look at request and arguments– interpreted the semantic dynamically and

return result

The server is coded normally!

®

Distributed Systems


CORBA OverviewORB - Dynamic Skeleton Interface (DSI)

class HelloServant extends DynamicImplementation

{ // store the repository ID for the implemented interface

static String[] myIDs = {"IDL:JavaIDL/DSIExample:1.0"};

ORB orb;

// create a reference to the ORB

HelloServant(ORB orb) {

this.orb = orb;

}

// must implement invoke() for handling requests

public void invoke(ServerRequest request) {

try {

System.out.println("DSI: invoke called, op = "+request.op_name());

// create an NVList to hold the parameters

NVList nvlist = orb.create_list(0);

// need an if statement like this for each method name

if (request.op_name().equals("printHelloArgs") == true) {

Example of servantcode using DSI

Essentially - you code the Skeleton code your self!!!

®

Distributed Systems


CORBA OverviewORB - Bootstrapping

Before a program can use CORBA objects, it must initialize itself

– Create a ORB object– Obtain one or more initial object references,

typically at least a Naming Context in a Naming Service

To create a ORB object the following is done

import org.omg.CORBA.ORB; public static void main(String args[]) { try{ ORB orb = ORB.init(args, null); // code continues

®

Distributed Systems



Remeber that the ORB object is just a pseudo-object that can’t be passed around like a normal object

For Applets its special

import org.omg.CORBA.ORB; public void init() { try { ORB orb = ORB.init(this, null); // code continues

Must be upplied so the ORB canretrieve the Applet properties

®

Distributed Systems



If there are more ORBs present in the runtime invi-ronment it has to be pointed out which ORB to use

– Some browers contain an ORB– The Java 1.2 SE and up contains an ORB

import java.util.Properties; import org.omg.CORBA.*; public class MyApplet extends java.applet.Applet { public void init() { // Instantiate the Java IDL ORB, passing in this applet // so that the ORB can retrieve the applet properties. Properties props = new Properties(); props.put("org.omg.CORBA.ORBClass", "com.sun.CORBA.iiop.ORB"); ORB orb = ORB.init(this, props); ... }}

®

Distributed Systems



To invoke a CORBA object the client must have a reference for it

Four ways to get a reference for a CORBA object

– From a string created from a remote reference– From a Naming Service/Trader Service– From the ORB operation

resolve_initial_references– From the result of calling a remote method on a

CORBA object

®

Distributed Systems


CORBA OverviewORB - Bootstrapping Stringified object references

ORB implementation independent - the ORB can always convert a CORBA object reference to and from a string

Ensure that the object referred to is in fact accessible from where the client is running

Obtain the stringified reference, perhaps from a file or a parameterObject obj = orb.string_to_object("relfile:/Hello.ref");if(obj == null) { System.err.println("hello.Client:cannot read Hello.ref"); return 1;}Hello hello = HelloHelper.narrow(obj);

®

Distributed Systems


CORBA OverviewORB - Bootstrapping Stringified object references

The following fragment shows how a server converts a CORBA object reference to a string:

org.omg.CORBA.ORB orb = // get an ORB objectorg.omg.CORBA.Object obj = // create the object referenceString str = orb.object_to_string(obj);// make the string available to the client

This code fragment shows how a client converts the stringified object reference back to an object: org.omg.CORBA.ORB orb = // get an ORB object

String stringifiedref = // read stringorg.omg.CORBA.Object obj = orb.string_to_object(stringifiedref);

®

Distributed Systems


CORBA OverviewORB - Bootstrapping ORB references to services

The ORB resolve_initial_references is intended for bootstrapping object references into a newly started client

ORB dependent implementation for many services but now specified for the Naming Service

The operation takes a string argument that names one of a few recognized objects; it returns a CORBA Object, which must be narrowed to the type the client knows it to be

®

Distributed Systems


CORBA OverviewORB - Bootstrapping ORB references to services

Examples of recognized objects are– NamingService, TradingService– RootPOA, InterfaceRepository

public calls NameClient {

public static void main(String args[]) { try { Properties props = new Properties(); props.put("org.omg.CORBA.ORBInitialPort", "1050"); ORB orb = ORB.init(args, props); NamingContext ctx = NamingContextHelper.narrow( orb.resolve_initial_references("NameService")); ...

®

Distributed Systems


CORBA OverviewORB - Java CORBA Client example

To create a CORBA based Java client application you do the following

– Implement the client application Bootstrap ORB Get initial reference (NamingService, file etc.) Get remote object reference

– Example: Hello Client: Client.java

uses file to get initial reference which in this case equals the remote object reference

®

Distributed Systems


CORBA OverviewObject Model

The OMA Core Object Model defines some fundamental definitions of concepts which are extended, made more specific and concrete by CORBA

The class concept does not exist in CORBA as non-Object Oriented programming languages can be used as implementation language

Clients for remote objects are not necessary objects as Client implementation languages also can be non-Object Oriented

®

Distributed Systems


CORBA OverviewObject Model - remote object references

Remote Object References can be in two forms Session form and Interoperable Object Reference (IOR) form

The session form is a vendor specific format– In session form there is no information that is

meaningful for the client as the ref is only interpreted at the server side

The IOR form is intended for interoperability between different ORBs

– The IOR form can be stringified to enable IORs to be stored, emailed, printed, and retrieved

®

Distributed Systems




Repository IDTransport Address IIOP:host:port

Object Key

POA Name

Object ID

Identifies Interface Type

Identifies a transport endpoint

Identifies the object within POA

Is in proprietary format for a given ORB

Interoperability is not affectedas the server is the only onelooking in it

®

Distributed Systems



Object references are opaque - application code isn’t allowed to look inside or make any assumptions about the internals

Remote Object references have a semantics very similar to class pointers in C++ - they can dangle ie pointing at a non-existing or unreachable object

– If the server where the remote object lived is shutdown and started again on another host

®

Distributed Systems



CORBA distinguishes between transient and persistent object references (LifeSpan policy)

A transient IOR continues to work a long as the corresponding server process where the remote object remains available

– Once the server process is shutdown the IOR is non-functional forever (even if the server process is started again)

IOR Host:port contains the server process information for the POA

®

Distributed Systems



If the server is up and running -> Ok

If the server is down - > OBJECT_NOT_EXIST

If the server is running but not the right adapter ID (check for pseudo-random number) -> OBJECT_NOT_EXIST

If the server is running but not the right ORB (check for vendor specific tag in IOR identifying ORB) ->OBJECT-NOT_EXIST


IDL:MyObject TestHost:8888

Server: TestHost:8888

OBJID:11

OBJID:12

POA1,OBJID:12

OBJID:13

Client

POA1

Pseudo-random number

®

Distributed Systems



A persistent object reference survives shutdown of the server process - it still denotes the same CORBA object

This works even if the server process is started on another host:port

The persistent object reference has a life cycle independent of the life cycle of the servant

Many ORBs can transparently start server processes and shut them down again after some idle time in order to save resources

®

Distributed Systems



Persistent object references are implemented by usage of the Implementation Repository

IOR Host:port contains the Implementation Repository server process information

– More host:port occurences allow for replicated Implementation Services

Implementation Repository acts as a level of indirection and delivers at runtime the address of the POA server process to the client

®

Distributed Systems




IDL:MyObject Jupiter:8080

Server: TestHost:8888

OBJID:11

OBJID:12

POA1,OBJID:12

OBJID:13

Client

POA1

Pseudo-random number

Implementation Repository: Jupiter:8080

POA1 \bin\server\startPOA1 TestHost:8888

®

Distributed Systems


CORBA OverviewObject Model - Persistent Reference example

To make the Hello object references persistent you do the following

– Create a new Policy the LifeSpanPolicy equals persistent the IDAssignmentPolicy equals user_id for all others default values are used

– Create new POA associated with RooTManager with Policy ‘the new policy’

– Create servant and explicit activate servant– Example hello_imr

®

Distributed Systems


CORBA OverviewInteroperability Architecture

The Interoperability Architecture for CORBA contain elements like

– ORB interoperability– Inter-ORB bridge support– GIOPs and IIOPs

An ORB is considered being interoperability compliant when supporting

– GIOP/IIOP– IOR

®

Distributed Systems


CORBA OverviewLanguage Mappings

The following language specific OMG IDL compilers are contained in specifications

ADA

C

C++

Java

Smalltalk

CORBA Script

COBOL

LISP

Phyton

Client Server

ADA

C

C++

Java

Smalltalk

CORBA Script

COBOL

LISP

Phyton

®

Distributed Systems


CORBA OverviewLanguage Mappings - cross language example

To show CORBA is language independent use the IDL2CPP (idl) compiler on hello.idl to generate a interface and a stub

idl --no-skeletons hello.idl

Make a client.cpp implementation and link it to a client.exe

Start the Java ORB based hello server and start the C++ ORB based hello client

®

Distributed Systems


J2SE 1.4 support for CORBA

®

Distributed Systems


J2SE 1.4 support for CORBACORBA compliance

JDK 1.4 contains a Java ORB implementation supporting a part of CORBA specification 2.3.1

– http://java.sun.com/j2se/1.4/docs/api/org/omg/CORBA/doc-files/compliance.html

JDK 1.4 contains the following CORBA tools– IDL-to-Java compiler (idlj)– Implementation Repository (orbd)– transient Naming Service (orbd)– persistent Naming Service (orbd)– servertool (cmd line interface tool)– tnamesrv (backward compability)

®

Distributed Systems


J2SE 1.4 support for CORBACORBA features

GIOP 1.2 (IIOP) POA Portable interceptors

– provides hooks, or interception points, through which ORB services can intercept the normal flow of execution of the ORB

– three types IORInterceptor ClientRequestInterceptor ServerRequestInterceptor

®

Distributed Systems


J2SE 1.4 support for CORBACORBA features

– The class ORBInitializer facilitates interceptor registration and ORB initialization done through properties

org.omg.PortableInterceptor.ORBInitializerClass.<Service>

where <Service> is the string name of a class which implements

org.omg.PortableInterceptor.ORBInitializer

Interoperable Naming Service– can use corba urls

®

Distributed Systems


J2SE 1.4 support for CORBACORBA example

Example of using persistent object references and the implementation repository in J2SE 1.4 (javacorba\exservertool)

– start the orbd (startorbd)– start the server tool (startservertool)– register HelloServer and start it up– start the client (startclient)

every 6 seconds the client class the sayHello() on the remote object and shutdown the server

watch in Taskmanager how the server is automatically started up when its shutdown by the client

®

Distributed Systems


Next TimeCORBA Part II

Summary IDL to Java mapping Corba Communication Models CORBA Services CORBA Naming Service CORBA Transaction Service CORBA Concurrency Service RMI/IIOP CORBA 3.0 - Whats new?

CORBA Part I A RMI case study

Documents

Transcript of CORBA Part I A RMI case study