common object request broker architecture n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Common Object Request Broker Architecture PowerPoint Presentation
Download Presentation
Common Object Request Broker Architecture

Loading in 2 Seconds...

play fullscreen
1 / 45

Common Object Request Broker Architecture - PowerPoint PPT Presentation


  • 131 Views
  • Uploaded on

Common Object Request Broker Architecture. Ali Ghodsi aligh@imit.kth.se. 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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Common Object Request Broker Architecture' - apu


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
common object request broker architecture

Common Object Request Broker Architecture

Ali Ghodsi

aligh@imit.kth.se

A. Ghodsi aligh@imit.kth.se

goal of lecture
Goal of lecture
  • Go a bit more into depth on the core architecture of CORBA
  • Less breadth
    • Read van Steen’s book

A. Ghodsi aligh@imit.kth.se

reading suggestions
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/

A. Ghodsi aligh@imit.kth.se

outlook
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

A. Ghodsi aligh@imit.kth.se

general corba information
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…

A. Ghodsi aligh@imit.kth.se

real world applications
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…

A. Ghodsi aligh@imit.kth.se

outlook1
Outlook
  • General Overview
  • Quick Architectural Overview
    • OOP with Distribution Transparency
    • CORBA overview
  • Interface Definition Language (IDL)
    • Types
    • Examples
    • Mappings
  • ORB
  • Conclusions

A. Ghodsi aligh@imit.kth.se

corba builds on the dom
CORBA builds on the DOM
  • Provides a nice model
    • Encapsulation
    • Inheritance
    • Polymorphism

A. Ghodsi aligh@imit.kth.se

exploiting encapsulation
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)

A. Ghodsi aligh@imit.kth.se

goal 1 distribution transparency

public interface MathBox {

int add(int x, int y);

}

publicclass MathBoxCL implements MathBox {

MathBoxCL() {}

int add(int x, int y)

{ return x+y; }

}

Transparently distribute

MathBox obj = new MathBoxCL();

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

Goal 1: Distribution Transparency
  • Encapsulation: black-box principle
    • Has an interface
    • Implementation details

hidden

A. Ghodsi aligh@imit.kth.se

distribution transparency

Missing parts:

  • Marshalling
  • Unmarshalling
  • References
  • Binding client to server

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);

}

MathBoxCL (PROXY)

int add(int x, int y)

{ Msg msg=new Msg();

msg.Marshall(x);

msg.Marshall(y);

SendReqMsg(HOST,IP,msg);

}

Distribution Transparency

Client

MathBox obj = new MathBoxCL();

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

Server Implementation

int add(int x, int y)

{ return x+y; }

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.Marshal(x);

msg.Marshal(y);

SendReqMsg(HOST,IP,msg);

}

A. Ghodsi aligh@imit.kth.se

goal 2 inter operability

C++

JAVA

Goal 2: Inter-operability
  • Use a language with standardized syntax to define the interface
  • Generate the stub and the skeleton
    • Programming Language Independent

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);

}

MathBoxCL (STUB)

int add(int x, int y)

{ Msg msg=new Msg();

msg.Marshal(x);

msg.Marshal(y);

SendReqMsg(HOST,IP,msg);

}

A. Ghodsi aligh@imit.kth.se

overview

operation()

Client

Object Implementation

args + return value

Object

Adapter

STUB

SKELETON

Network

ORB Core ORB Core

ORB-dependent implementation

Application specific Stub and Skeleton

Same inteface. ORB-independent

Overview

A. Ghodsi aligh@imit.kth.se

outlook2
Outlook
  • General Overview
  • Architecture Overview
  • Interface Definition Language (IDL)
    • Types
    • Example
    • Language Mappings
  • ORB
  • Conclusions

A. Ghodsi aligh@imit.kth.se

interface definition language
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)
    • InterfaceRepository (IR)
    • A Repository ID for each interface

A. Ghodsi aligh@imit.kth.se

idl s type system
IDL’s Type System
  • Two levels:
    • Interfacesfor 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

A. Ghodsi aligh@imit.kth.se

examples
Examples

DSLABS.IDL:

typedef string GroupMembers[4];

interface DS_project {

long register_project(inlong groupId, in string status, inoutstring date);

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

};

A. Ghodsi aligh@imit.kth.se

idl language mappings
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

A. Ghodsi aligh@imit.kth.se

outlook3
Outlook
  • General Overview
  • Architecture Overview
  • Interface Definition Language (IDL)
  • ORB
    • DII (and DSI)
    • ORB interface
    • Object References
    • POA
    • Persistent and Transient Objects
  • Conclusions

A. Ghodsi aligh@imit.kth.se

compile time vs runtime
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

A. Ghodsi aligh@imit.kth.se

dynamic invocation interface dii
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

A. Ghodsi aligh@imit.kth.se

dynamic invocation interface dii cont
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);

A. Ghodsi aligh@imit.kth.se

complete picture

operation()

Client

Object Implementation

args + return value

Object

Adapter

Static

Stub

Dynamic Skeleton Interface

Static

Skeleton

Dynamic

Invocation

Network

ORB Core ORB Core

ORB-dependent implementation

Application specific Stub and Skeleton

Same inteface. ORB-independent

Complete picture

A. Ghodsi aligh@imit.kth.se

object references
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.

A. Ghodsi aligh@imit.kth.se

inter operable object references ior

Remote Object Reference

Type Name

(Repository ID)

Object Key

(Adapter & Object Name)

Protocol

Hostname & Port

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

*Which object adapter, which object?

ex:”OA5”, ”_DSD”

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

Inter-operable Object References (IOR)

”Reference to an object on a server

A. Ghodsi aligh@imit.kth.se

orb interface

Dynamic Skeleton Interface

Static Skeleton

Dynamic

Invocation

Static

Stub

Object

Adapter

Network

ORB Core ORB Core

ORB-dependent implementation

Application specific Stub and Skeleton

Same inteface. ORB-independent

ORB Interface

operation()

Client

Object Implementation

args + return value

ORB

Interface

A. Ghodsi aligh@imit.kth.se

orb interface1
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

A. Ghodsi aligh@imit.kth.se

how do i get an ior
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

A. Ghodsi aligh@imit.kth.se

portable object adapter poa

ORB

Interface

Dynamic

Skeleton

Interface

Static

Skeleton

Dynamic

Invocation

Static

Stub

ORB-dependent implementation

Application specific Stub and Skeleton

Same inteface. ORB-independent

Portable Object Adapter (POA)

operation()

Client

Object Implementation

args + return value

Object

Adapter

Network

ORB Core ORB Core

A. Ghodsi aligh@imit.kth.se

why object adapters
Why Object Adapters?
  • Several clients call the same object, what to do?
    • Demultiplex requests

Server

DsObject::calculate()

{

...

}

Client 1

dsObject.calculate();

Client 2

dsObject.calculate();

A. Ghodsi aligh@imit.kth.se

why object adapters 2
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

Server

DsObject::calculate()

{

...

}

Client 1

dsObject.calculate();

Client 2

dsObject.calculate();

A. Ghodsi aligh@imit.kth.se

why object adapters 21
Why Object Adapters? (2)
  • Security between the objects?
    • Sandboxing?
    • Share methods, separate data?

Server

DsObject::calculate()

{

...

}

Client 1

dsObject.calculate();

Client 2

dsObject.calculate();

A. Ghodsi aligh@imit.kth.se

why object adapters 22
Why Object Adapters? (2)
  • Lifespan policy:
    • Transient objects
    • Persistent Objects
      • Continues to exist even if activated/deactivated?

Server

DsObject::calculate()

{

...

}

Client 1

dsObject.calculate();

Client 2

dsObject.calculate();

A. Ghodsi aligh@imit.kth.se

portable object adapter pl meets orb
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

A. Ghodsi aligh@imit.kth.se

portable object adapter
Portable Object Adapter

OBJ 3

OBJ 1

OBJ 2

skel3

skel1

skel2

POA2(policy2)

Invoke the right

skeleton

POA1 (policy1)

Invoke right

skeleton

Active Object Map

OBJ3 -> skel3

Active Object Map

OBJ2 -> skel2

OBJ1 -> skel1

Server Demultiplexer

Dispatch requests

to the right POA

POA1

POA2

A. Ghodsi aligh@imit.kth.se

transient object illustration

STUB: Object Reference

Reply message

return variables, out parameters

Request message

IDL:Institution/IT/DSD:1.0

”IIOP v1.0”,”ripper”, 8765

”OA5”, ”_DSD”

Unique ID : ”13FABCDA”

Unique ID : ”13FABCDA”

”OA5”, ”_DSD”

student_operation() + *par

Active Object Maps

OA4:

_InfoSec

OA5:

_DSC

_DSD

Transient Object Illustration

Client

_dsd->student_operation()

Object Implementation

Stub

Skeleton

Object

Adapter

ORB Core

ORB Core

A. Ghodsi aligh@imit.kth.se

persistent objects
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

A. Ghodsi aligh@imit.kth.se

persistent objects continued
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

A. Ghodsi aligh@imit.kth.se

how is this possible
How is this possible?
  • Implementation repository (IMR) is used
  • Keeps information about
    • Object Adapter
    • Startup Command
    • Current Server

A. Ghodsi aligh@imit.kth.se

persistent objects illustrated

Reply message

return variables, out parameters

Request message

Unique ID : ”13FABCDA”

Unique ID : ”13FABCDA”

”OA5”, ”_DSD”

Location Forward

student_operation() + par

Active Object Maps

OA4:

_InfoSec

OA5:

_DSC

_DSD

STUB: Object Reference

IDL:KTH/imit/DSD:1.0

”IIOP v1.0”,”IMR”, 8765

”OA5”, ”_DSD”

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

Persistent Objects Illustrated

Client

_dsd->student_operation()

Implem. Repository

Object Implementation

IMR Table

ORB Core

Stub

ORB Core

Skeleton

ORB Core

A. Ghodsi aligh@imit.kth.se

failure and replication ior cont

Type Name

(Repository ID)

Object1 Key

(Adapter1 & Object1 Name)

Object2 Key

(Adapter2 & Object2 Name)

Failure and replication (IOR cont)

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

Protocol1

Hostname1 & Port1

”Reference to an object on a server

Protocol2

Hostname2 & Port2

Remote Object Reference

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

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

HOST1/PORT2/ADAPTER2/OBJECT2ex: ripper1/1234/oa1/obj1

HOST2/PORT2/ADAPTER2/OBJECT2ex: ripper2/3233/oa3/obj6

A. Ghodsi aligh@imit.kth.se

summary 1
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

A. Ghodsi aligh@imit.kth.se

summary 2
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)

A. Ghodsi aligh@imit.kth.se

what did i miss
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!

A. Ghodsi aligh@imit.kth.se

the end
The End

THANK YOU VERY MUCH!

A. Ghodsi aligh@imit.kth.se