lecture4 corba

Distributed Object Programming course 2003

CORBA

Common

Object Request Broker

Architecture


What is CORBA?

● Specifications, not products● Vision is portability (between vendors)

– Rely on supporting OS/platform?– Standards do not cover all needs

(extensions)– Standards and products evolve at different

rates

● Not all vendors support every option

● http://www.omg.org


Versions

● CORBA – simple remote object model

● CORBA 2 – interoperability, common server programming model, transactions, …

● CORBA 2.2, 2.3, …

● CORBA 3 – load balancing, components, …


Model

● Focus is on objects – Create remote objects and call their

methods● Used like local objects● Contain state like normal objects● Creation mechanism is different● Uses ‘stubs’ and ‘skeletons’

– Multi-language● Bindings for C, C++, Java, Ada, …● Available methods defined through IDL


Model (2)

● Remote stateful objects – Real objects, possibly shared and

persistent● Rich API set

– Programmers directly control security, transactions, finding object/servers by calling methods

● Quite far from stateless components– External state, container properties


Model (3)

One standardised interface

One interface per object operation

ORB-dependent interfaceOne interface per object adapter

DynamicDynamicInvocationInvocation

ClientStubs

ORBInterfaceInterface

Implementation Skeletons

Client Object Implementation

ORB Core

ObjectAdapter


Interface and Services

● Interface repository

● Implementation repository

● Services:

– Collection

– Query

– Concurrency control

– Transactions


More Services

● Services

– Event

– Notification

– Externalization

– Life cycle

– Licensing

– Naming● Finding servers and load balancing


Services (3)● Services:

– Property

– Trading

– Persistence

– Relationship

– Security● Common to use SSL for lightweight

authentication and encryption● CORBA standard security service

– Time


Communications

● Object invocations

– Synchronous

– One way

– Deferred synchronous

● Events

– Consumer and Supplier

– Push model vs Pull model


CORBA Processes

● Clients

– Simple to program

– IDL compiler creates a proxy implementation

– Interceptors: intercept request between client and server.

– Request level – between client and proxy

– Message level – between ORB and network


Interceptors

Client application

Clientproxy

Client ORB

Local OS

Request LevelInterceptors

Message LevelInterceptors

Invocationrequest


Portable Object Adapter

● Provides a consistent image of the object

● (also called wrapper)

● Makes server side code appears as CORBA objects

● Use a “servant” - implement client methods

● Maps object Ids (references) to servants.


Naming

● How do you find object or servers?– Using a name server– Directory of available objects

● Server processes call name server when they come up– Advertising their services/objects

● How do you find the name server?– Call resolve_initial_references– And local ORB ‘knows’ location of NS


Naming (2)

● Clients call name server to find the location of a factory/object/server

– Up to the name server to match clients to servers/objects

– Returns object reference (IOR?)● Includes location of server

● Client calls server process (via ORB) to access or create objects


Scaling

● NS can support load balancing

– Multiple servers/processors register the same service/object (object groups)

– Name server spreads out requests across available objects

– Proprietary until CORBA 3

● Extends IOR to IOGR.


Where is the IDL?

Client object

IDL stub (obj)

ORB

Networkservices

Server object

IDL skel (obj)

ORB/POA

Networkservices

Request

Request data

IIOP protocol


IDL Language

It’s a declarative language to define client object/server object interface. It’s somehow a simplified object definition; no implementation is defined. An example…

module Bank { struct Customer { string name; string address; string id; } interface Account { void debit( in unsigned long ammount ); void withdraw( in unsigned long ammount ); long balance(); } interface AccountMgr { Account getAccountByCustomer( Customer c ); }}


Example

module Bank { struct Customer { string name; string address; string id; } interface Account { void debit( in unsigned long ammount ); void withdraw( in unsigned long ammount ); long balance(); } interface AccountMgr { Account getAccountByCustomer( Customer c ); }}

Core concept: 2 kinds of programming types: Objects (interfaces) and non-objects (types)

Interfaces

Types


Language (2)

• Operations in interfaces define callable methods. Operations can have parameters, but not implementation

• Each parameter definition must say if it is an in , out or inout parameter and has a type and name

• There are also support for: exception handling, sequence templates, arrays; inheritance; abstract interfaces and so on


Language (3)

• Basic types: long, short, unsigned long, unsigned short, float, double, boolean, octet (fits anything, as sequence), any (really anything)

• Constructed types: There are constructed types: struct, union, enumeration type.

• The any type.

Struct <identifier> { <declaration>; … }union <identifier> switch (<switch-type>) { case <constant>: <declaration>; …}enum <identifier> { <identifier>, … }


IDL Mapping

• They must define the means of expressing in the language all CORBA IDL constructs.

• A complete language mapping will allow a programmer to have access to all ORB functionality in a way that is convenient for the particular programming language.

• To support source portability, all ORB implementations must support the same mapping for a particular language (mapping specification).


IDL Mapping

Objects specification in IDL

Client code Server code

compiler

Ada, C, C++, COBOL, Smalltalk, and Java, Lisp, CORBA scripting language

Java to IDL


IDL Mapping

interface myObj { long op1 (in long arg1 ); }

typedef CORBA_Object myObj;extern CORBA_long myObj_op1( example1 o, CORBA_long arg1, CORBA_Environment *ev );

class myObjOperations extends org.omg.CORBA.IDLEntity { void op1( … ); …};class myObj extends MyObjOperations { … } …

class myObj : virtual public CORBA::Object { …public: … virtual void op1( … );}

C

Java

C++


IDL Mapping

public interface myInt {...}

abstract interface myInt { ... }

package M;module M { ... }

public interface myObjOperations {... }public interface myObj extends myObjOperations ... {}

interface myObj { ... }

JavaCORBA


IDL Mapping

Op1 correspond to method op1 in object interface.in parameters are passed by value.out and inout parameters are passed through holder classes. For inout parameters, client must initialise the holder class with a value before calling the method.As interfaces are mapped to java interfaces, method and object’s signatures are maintained.

operations and parameter passing:op1(in Ob1 x,

out Ob2 y,

inout Ob3 z)

JavaCORBA


IDL MappingIDL TYPE JAVA TYPE EXCEPTIONS

boolean boolean

Char char CORBA::DATA_CONVERSION

wchar char CORBA::DATA_CONVERSION

octec byte

String Java.lang.String CORBA::MARSHALCORBA::DATA_CONVERSION

wstring Java.lang.String CORBA::MARSHALCORBA::DATA_CONVERSION

short short

Unsigned short short

Long int

Unsigned long int

Long long long

Unsigned long long long

float float

double double

fixed Java.math.BidDecimal CORBA::DATA_CONVERSION


IDL Mapping

see specificationunion, sequence, arrays, constants, etc.

final public class myStruct ... IDLEntity {

public int field1;

public String field2;

public myStruct() { } // empty!

public myStruct(int f1, String f2) { ... }

}

struct myStruct { long field1; string field2;}

JavaCORBA


IDL Example

module Bank {

struct StructType{ long initbalance; string acctname;

};

interface Account { float balance(); string getCalendar(); };

interface AccountManager { Account open(in StructType st); };};


IDL Example

●AccountManagerStub.java--Stub code for the AccountManager object on the client side.

●AccountStub.java--Stub code for the Account object on the client side.

●ccount.java--The Account interface declaration.

●AccountHelper.java--Declares the AccountHelper class, which defines helpful utility methods.

●AccountHolder.java--Declares the AccountHolder class, which provides a holder for passing Account objects.

●AccountManager.java--The AccountManager interface declaration.

●AccountManagerHelper.java--Declares the AccountManagerHelper class, which defines helpful utility methods.

●AccountManagerHolder.java--Declares the AccountManagerHolder class, which provides a holder for passing AccountManager objects.


IDL Example

●AccountManagerOperation.java--This interface provides declares the method signatures defined in the AccountManager interface in the Bank.idl file.

●AccountManagerPOA.java--POA servant code (implementation base code) for the AccountManager object implementation on the server side.

●AccountManagerPOATie.java--Class used to implement the AccountManager object on the server side using the tie mechanism,

●AccountOperations.java--This interface provides declares the method signatures defined in the Account interface in the Bank.idl file

●AccountPOA.java--POA servant code (implementation base code) for the Account object implementation on the server side.

●AccountPOATie.java--Class used to implement the Account object on the server side using the tie mechanism

●StructType.java--Declares the StrucType class, which is used both by Client and Server classes.


IDL Example

●StructTypeHelper.java--Declares the StructTypeHelper class, which defines helpful utitly methods.

●StructTypeHolder.java--Declares the StructTypeHolder class, which provides a holder for passing StructType objects.


Server Example

● Steps for server setup

– Initialize ORB

– Create and setup POA

– Activate the POA Manager

– Activate objects

– Wait for client requests


org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args,null);

// get a reference to the root POA

POA rootPOA = POAHelper.narrow(orb.resolve_initial_references("RootPOA"));

// Create policies for our persistent POA

org.omg.CORBA.Policy[] policies = {

rootPOA.create_lifespan_policy(LifespanPolicyValue.PERSISTENT)

};

// Create myPOA with the right policies

POA myPOA = rootPOA.create_POA( "bank_agent_poa", rootPOA.the_POAManager(),

policies );

// Create the servant

AccountManagerImpl managerServant = new AccountManagerImpl();


Code Example (cont)

// Decide on the ID for the servant

byte[] managerId = "BankManager".getBytes();

// Activate the servant with the ID on myPOA

myPOA.activate_object_with_id(managerId, managerServant);

// Activate the POA manager

rootPOA.the_POAManager().activate();

System.out.println(myPOA.servant_to_reference(managerServant) +

" is ready.");

// Wait for incoming requests

orb.run();


Client Example

● Steps for client setup

– Initialize ORB

– Locate Server using location service (smart agent)

– Obtains the balance of the Account using the object reference returned by bind().


Client Example

Org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args,null);

// Get the manager Id

byte[] managerId = "BankManager".getBytes();

// Locate an account manager. Give the full POA name and

// the servant ID.

Bank.AccountManager manager = Bank.AccountManagerHelper.bind(orb, "/bank_agent_poa", managerId);

// use args[0] as the account name, or a default.

// String name = args.length > 0 ? args[0] :

// "default account";

String name=args[0];

Integer initbalance=new Integer(args[1]);


Client Example (cont)

Bank.StructType stname= new Bank.StructType(initbalance.intValue(),name);

// Request the account manager to open a named account.

System.out.println(stname);

Bank.Account account = manager.open(stname);

// Get the balance of the account.

float balance = account.balance();

String strtime= account.getCalendar();

// Print out the balance.

System.out.println ("The balance in " + name +

"'s account is $" + balance +

"and time is "+ strtime);

lecture4 corba

Education

object groups

portable object adapter

simplified object definition

corba objects

returns object reference

kinds of programming

local objects

remote objects