Common Object Request Broker Architecture

1
Common Object Request Broker Architecture

• Ali Ghodsi
• aligh_at_imit.kth.se

2
Goal of lecture

• Go a bit more into depth on the core architecture
  of CORBA
• Less breadth
• Read van Steens book

3
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/

4
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

5
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

6
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

7
Outlook

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

8
CORBA builds on the DOM

• Provides a nice model
• Encapsulation
• Inheritance
• Polymorphism

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

10
Goal 1 Distribution Transparency

• Encapsulation black-box principle
• Has an interface
• Implementation details
• hidden

11
Distribution Transparency
Client MathBox obj new MathBoxCL() Integer
result obj.add(10,20)
Server Implementation int add(int x, int y)
return xy
MathBoxCL (SKELETON) int invoke(msg msg) int
x, y xmsg.Unmarshal(INT) ymsg.Unmarshal(INT)
resserverImpl.add(x,y) Msg msgnew
Msg() msg.marshal(res) SendRespMsg(HOST, IP,
msg)
MathBoxCL (PROXY) int add(int x, int y)
Msg msgnew Msg() msg.Marshal(x) msg.Marshal(y
) SendReqMsg(HOST,IP,msg)
12
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 msgGetMsg() xmsg.Unmarshal(INT) ymsg
.Unmarshal(INT) resserverImpl.add(x,y) Msg
msgnew Msg() msg.marshal(res) SendRespMsg(HOS
T, IP, msg)
MathBoxCL (STUB) int add(int x, int y)
Msg msgnew Msg() msg.Marshal(x) msg.Marshal(y
) SendReqMsg(HOST,IP,msg)
13
Overview
14
Outlook

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

15
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

16
IDLs 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

17
Examples

• DSLABS.IDL
• typedef string GroupMembers4
• 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)

18
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

19
Outlook

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

20
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

21
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

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

23
Complete picture
24
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.

25
Inter-operable Object References (IOR)
Reference to an object on a server
26
ORB Interface
operation()
Client
Object Implementation
args return value
ORB Interface
27
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

28
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 IORs in a naming service

29
Portable Object Adapter (POA)
operation()
Client
Object Implementation
args return value
Object Adapter
Network
ORB Core ORB Core
30
Why Object Adapters?
Client 1 dsObject.calculate()
Server DsObjectcalculate() ...
Client 2 dsObject.calculate()

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

31
Why Object Adapters? (2)
Client 1 dsObject.calculate()
Server DsObjectcalculate() ...
Client 2 dsObject.calculate()

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

32
Why Object Adapters? (2)
Client 1 dsObject.calculate()
Server DsObjectcalculate() ...
Client 2 dsObject.calculate()

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

33
Why Object Adapters? (2)
Client 1 dsObject.calculate()
Server DsObjectcalculate() ...
Client 2 dsObject.calculate()

• Lifespan policy
• Transient objects
• Persistent Objects
• Continues to exist even if activated/deactivated?

34
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 gt Skeletons

35
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 -gt skel3
Active Object Map OBJ2 -gt skel2 OBJ1 -gt skel1
Server Demultiplexer Dispatch requests to the
right POA
POA1 POA2
36
Transient Object Illustration
Client _dsd-gtstudent_operation()
Object Implementation
Stub
Skeleton
Object Adapter
ORB Core
ORB Core
37
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

38
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

39
How is this possible?

• Implementation repository (IMR) is used
• Keeps information about
• Object Adapter
• Startup Command
• Current Server

40
Persistent Objects Illustrated
Client _dsd-gtstudent_operation()
Object Implementation
Implem. Repository
IMR Table
ORB Core
Stub
ORB Core
Skeleton
ORB Core
41
Failure and replication (IOR cont)
Multiple locations in one reference. If an
invocation fails, go to next location
Protocol1 Hostname1 Port1
Remote Object Reference
Reference to an object on a server
Protocol2 Hostname2 Port2
GIOP, address, port ex IIOP v1.0,ripper.it.kt
h.se, 8765
Repository ID ex IDLKTH/imit/DSD1.0 HOST1/
PORT2/ADAPTER2/OBJECT2 ex ripper1/1234/oa1/obj1
HOST2/PORT2/ADAPTER2/OBJECT2 ex
ripper2/3233/oa3/obj6
42
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

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

44
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!

45
The End

• THANK YOU VERY MUCH!