2004-02-02a. ghodsi [email protected] common object request broker architecture ali ghodsi...

2004-02-02 A. Ghodsi [email protected] 1

Common Object Request Broker Architecture

Ali [email protected]


Goal of lecture

Go a bit more into depth on the core architecture of CORBA

Less breadth Read van Steen’s book


Reading suggestions Tanenbaum & van Steen

CORBA Section 2.3 page page 85-98 Section 3.2.2 page 152-158 Section 9.1

Read chapter 9 and compare other systems with CORBA Compare RPC and DCE Remote Objects with CORBA

Links Nice CORBA tutorial: http://www.omg.org/gettingstarted/


Outlook General Overview

General Information Applications

Quick Architectural Overview OOP plus Distribution Transparency CORBA main overview

Interface Definition Language (IDL) Types Examples Mappings

ORB DII (and DSI) ORB interface Object Reference POA Persistent and Transient Objects

Conclusions


General CORBA Information

Distributed Object Model (more later)

It is a middleware Difference between Network OS Middleware?

Only a standard (v 2.7, 3.0) No reference implementation! Many independent implementations

OMG - Non-profit organization 800 members! Standardized UML and more…


Real World Applications? Support ”dinosaurs”

Companies have invested years of development in projects done in ADA, C, Smalltalk…

CORBA enables interoperability with new languages

Languages with small user-base Eg Erlang, again interoperability

Big ERM, ERP, IS Many different architectures, languages, platforms…


Outlook General Overview Quick Architectural Overview

OOP with Distribution Transparency CORBA overview

Interface Definition Language (IDL) Types Examples Mappings

ORB Conclusions


CORBA builds on the DOM Provides a nice model

Encapsulation

Inheritance

Polymorphism


Exploiting Encapsulation Encapsulation enables:

Distribution Transparency Have stubs and skeletons that together with ORBs

enable distribution*.

Inter-operability** Define interfaces in a standardised way Interface Definition Language (IDL)


Goal 1: Distribution Transparency

Encapsulation: black-box principle Has an interface Implementation details

hiddenpublic interface MathBox {

int add(int x, int y);

}

public class MathBoxCL implements MathBox {

MathBoxCL() {}

int add(int x, int y)

{ return x+y; }

}

…

MathBox obj = new MathBoxCL();

System.out.println(obj.add(10,20));

…

Transparently distribute


Distribution Transparency

Client…

MathBox obj = new MathBoxCL();Integer result = obj.add(10,20);

…

Server Implementationint add(int x, int y) { return x+y; }

MathBoxCL (PROXY)int add(int x, int y) { Msg msg=new Msg();

msg.Marshal(x);msg.Marshal(y);SendReqMsg(HOST,IP,msg);

}

MathBoxCL (SKELETON)int invoke(msg msg){ int x, y;

x=msg.Unmarshal(INT);y=msg.Unmarshal(INT);res=serverImpl.add(x,y);Msg msg=new Msg();msg.marshal(res);SendRespMsg(HOST, IP, msg);

}

MathBoxCL (PROXY)int add(int x, int y) { Msg msg=new Msg();

msg.Marshall(x);msg.Marshall(y);SendReqMsg(HOST,IP,msg);

}

MathBoxCL (SKELETON)int invoke(msg msg) { int x, y;

x=msg.Unmarshall(INT);y=msg.Unmarshall(INT);res=serverImpl.add(x,y);Msg msg=new Msg();msg.marshall(res);SendRespMsg(HOST,IP,msg);

}

Missing parts:

• Marshalling

• Unmarshalling

• References

• Binding client to server


Goal 2: Inter-operability

Use a language with standardized syntax to define the interface

Generate the stub and the skeleton Programming Language Independent

MathBoxCL (STUB)int add(int x, int y) { Msg msg=new Msg();

msg.Marshal(x);msg.Marshal(y);SendReqMsg(HOST,IP,msg);

}

MathBoxCL (SKELETON)int invoke(Msg msg) { int x, y;

msg=GetMsg();x=msg.Unmarshal(INT);y=msg.Unmarshal(INT);res=serverImpl.add(x,y);Msg msg=new Msg();msg.marshal(res);SendRespMsg(HOST, IP, msg);

}

JAVAC++


Overview

STUB

Client Object Implementationoperation()

args + return value

SKELETONObject Adapter

ORB-dependent implementation

Application specific Stub and Skeleton

ORB Core ORB Core

Same inteface. ORB-independent

Network


Outlook General Overview Architecture Overview Interface Definition Language (IDL)

Types Example Language Mappings

ORB Conclusions


Interface Definition Language

Builds on OOP principle of encapsulation Clear boundary between implementation and interface

Independent Programming Language (Only OO?) OS Platform Network Connection etc

Can be converted to a binary format and stored in a database (i.e. well-defined schema, iterators) Interface Repository (IR) A Repository ID for each interface


IDL’s Type System

Two levels: Interfaces for CORBA objects!

One interface per CORBA object Official types for variables

integers, floats struct, enum array string binary values …and more!

Scoped types modules exceptions Interfaces structs


Examples

DSLABS.IDL:typedef string GroupMembers[4];

interface DS_project {long register_project(in long groupId, in string status, inout string date);

long get_status(in long groupId, out string state, out string date, out GroupMembers gm);

};


IDL language mappings OMG defines mappings to different languages

C, C++, Java, Smalltalk, COBOL, Ada, Lisp, PL/1, Python, and IDLscript

Proprietary mappings exist for obscure languages, though not standardized!

Every ORB has an IDL compiler Creates

A STUB and A SKELETON


Outlook General Overview Architecture Overview Interface Definition Language (IDL) ORB

DII (and DSI) ORB interface Object References POA Persistent and Transient Objects

Conclusions


Compile time vs Runtime?

What if interfaces change? Recompile everything? Unfeasable Dynamic interface definitions required:

IS (Information Systems) ERM (Enterprise Resource Management systems) Batch Service etcetera


Dynamic Invocation Interface (DII)

Generic run-time invocation

No compile-time knowledge of CORBA object interfaces

No stub and skeleton needed a-priori Instead, a generic interface is used

Of course defined in IDL


Dynamic Invocation Interface (DII) cont.

In essence: Search and fetch an IDL from an Interface

Repository. (remember binary presentation of IDL)

Construct a request Specify target object, operation, and

parameters Invoke the request

C++ (not entirely true) invoke(remoteObj, ”getStatus”, paramters)

Java uses reflection/introspection (transparent): remoteObj.getStatus(paramters);


Complete picture

StaticStub


args + return value

StaticSkeletonDynamic

Invocation

Dynamic Skeleton Interface

Object Adapter



ORB Core ORB Core


Network


Object References Remote object references

Enable clients to invoke CORBA objects

Three incarnations Language specific implementation

E.g. pointer to a stub in C++ implementing the IDL

Not valid outside local computation space Language independent ORB representation

IOR, Inter-operable Object Referenece Supported by all ORBs

Textual representation Send by e-mail, store in DB, textfiles and so on.


Inter-operable Object References (IOR)

Remote Object Reference”Reference to an object on a serverProtocolHostname & Port

*GIOP, address, port ex: ”IIOP v1.0”,”ripper.it.kth.se”, 8765

Object Key(Adapter & Object Name)

*Which object adapter, which object?

ex: ”OA5”, ”_DSD”

Type Name(Repository ID)

Repository ID ex: ”IDL:KTH/imit/DSD:1.0”


ORB Interface

ORBInterface


args + return value

StaticStub

Static SkeletonDynamic

Invocation

Dynamic Skeleton Interface

Object Adapter



ORB Core ORB Core


Network


ORB Interface Standard interface (defined in IDL)

All ORBs implement this interface

Important services provided: Bootstrapping, getting initial references Converting Object References to Strings and

vice versa Object Reference Counting

Distributed garbage collection


How do I get an IOR? All ORBs implement:

string_to_object()file, e-mail, phone :)

resolve_initial_references()Returns an IOR for naming service, interface

repository Continue to search for IOR’s in a naming

service


Portable Object Adapter (POA)


args + return value

Object Adapter

ORB Core ORB CoreNetwork

ORBInterface

StaticStub

StaticSkeletonDynamic

Invocation

DynamicSkeletonInterface





Why Object Adapters?

Several clients call the same object, what to do? Demultiplex requests

Client 1

dsObject.calculate();

Client 2


Server

DsObject::calculate()

{

...

}


Why Object Adapters? (2)

Queue requests or run in separate threads? Serialize all requests One thread per object One thread per invocation Pool of threads

Client 1


Client 2


Server


{

...

}



Security between the objects? Sandboxing? Share methods, separate data?

Client 1


Client 2


Server


{

...

}



Lifespan policy: Transient objects Persistent Objects

Continues to exist even if activated/deactivated?

Client 1


Client 2


Server


{

...

}


Portable Object Adapter – PL meets ORB! POA is generic and CORBA object independent

and implements different activation policies

POA keeps pointers to skeletons*

An Object Identifier is associated with object.

A table called Active Object Map maps between Object Identifers => Skeletons


Portable Object Adapter

Server Demultiplexer

Dispatch requests

to the right POA

POA1

POA2

POA1 (policy1)

Invoke right

skeleton

Active Object Map

OBJ2 -> skel2

OBJ1 -> skel1

OBJ 1

skel1

OBJ 2

skel2

POA2(policy2)

Invoke the right

skeleton

Active Object Map

OBJ3 -> skel3

OBJ 3

skel3


Transient Object Illustration

Stub

Object Adapter

ORB Core

Client_dsd->student_operation() Object Implementation

ORB Core

Request message

Unique ID : ”13FABCDA” ”OA5”, ”_DSD”

student_operation() + *par

Active Object Maps

OA4:

_InfoSec

OA5:

_DSC

_DSD

Skeleton

Reply message

return variables, out parameters

Unique ID : ”13FABCDA”

STUB: Object Reference

”IIOP v1.0”,”ripper”, 8765 ”OA5”, ”_DSD”IDL:Institution/IT/DSD:1.0


Persistent Objects

A IOR to a Persistent Object always points to the same object Migration Transparency Location Transparency

Ceases to exist only if the CORBA object is logically destroyed Might move Might change IP, Port, Machine Might change POA etc


Persistent Objects continued Its life cycle is independent of the objects

I.e. its existence is independent of whether the object is in the local address-space.

ORBs can automatically startup objects implementing persistent CORBA objects


How is this possible? Implementation repository (IMR) is used Keeps information about

Object Adapter Startup Command Current Server


STUB: Object Reference

”IIOP v1.0”,”IMR”, 8765 ”OA5”, ”_DSD”IDL:KTH/imit/DSD:1.0

ORB Core

Persistent Objects Illustrated

Stub

ORB Core

Client_dsd->student_operation()

Object Implementation

ORB Core

Skeleton

Implem. Repository

IMR Table

Adapter Startup Address

xOA_1 rsh x ”/bin/st” bored:131

yOA_2 /startup ir:1444

OA5 rsh ripper /run ripper:313

Active Object Maps

OA4:

_InfoSec

OA5:

_DSC

_DSD

Request message

Unique ID : ”13FABCDA” ”OA5”, ”_DSD”

student_operation() + par

”IIOP v1.0”,”ripper”, 313

Location Forward

Reply message

return variables, out parameters

Unique ID : ”13FABCDA”


Failure and replication (IOR cont)

Protocol1Hostname1 & Port1

*GIOP, address, port ex: ”IIOP v1.0”,”ripper.it.kth.se”, 8765

Object1 Key(Adapter1 & Object1 Name)

Type Name(Repository ID)

Repository ID ex: ”IDL:KTH/imit/DSD:1.0”

HOST1/PORT2/ADAPTER2/OBJECT2 ex: ripper1/1234/oa1/obj1

HOST2/PORT2/ADAPTER2/OBJECT2 ex: ripper2/3233/oa3/obj6

…

Remote Object Reference”Reference to an object on a serverProtocol2Hostname2 & Port2

Object2 Key(Adapter2 & Object2 Name)

Multiple locations in one reference. If an invocation fails, go to next location


Summary-1 CORBA is a standardization effort

Based on the the Distributed Object Model

Provides inter-operability

Uses proprietary interface language: IDL All CORBA objects have an interface in IDL Most of the services offered by CORBA have an

interface in IDL


Summary-2

Provides both Dynamic and Static invocations DII/DSI and STUBS/SKELETONS

Stubs/Skeletons talk to an ORB

The ORB uses a standardized protocol to exchange Messages(Req/Resp), IORs (persistent/transient)

ORB uses a POA to implement different activation policies Threading policy Lifespan policy (Persistent vs. Transient Objects) Security (sandboxing of object implementations)


What did I miss? A whole lot!

CORBA facilities/services Synchronization Caching Replication Fault-tolerance Security

Comparison of CORBA against .NET DCOM Java RMI etcetera

Please read chapter 9!


The End

THANK YOU VERY MUCH!

2004-02-02a. ghodsi [email protected] common object request broker architecture ali ghodsi...

Documents