CORBA

1
 Early Distributed Computing

 Language specific remote procedure calls

- Tightly coupled to protocol
- Tightly coupled to language semantics
- Often highly proprietary
 Homogenous environment
 Typically one to one cardinality
- Not highly scalable

2
 What is CORBA?

 Architecture for interoperable distributed computing

- Based on the OMG’s Object Management Architecture
 Internet Interoperability Protocol (IIOP)
 Language mappings (OMG IDL)
 Integrated and reusable services

3
 Distributed Object-based Systems
 Goal: transparently access remote objects in a distributed
system
 Challenges:
- Ensure semantics of invoking a local object
- Accommodate heterogeneity, e.g., multiple languages, OSes, …

Client Server

Object Object

Middleware 4
 Two Examples

 Common Object Request Broker Architecture (CORBA)

- International standard: multiple languages, OSes, vendors

 Distributed Common Object Model (DCOM)

- MS standard: only MS OSes

5
 CORBA
 CORBA is similar in high level concepts to RMI
 RMI is basically a simplified form of CORBA
 It Adds:
Cross-platform
Multiple language interfaces
 Widely used standard
 Allows programs written in various languages to communicate
with each other as would two processes in the same address space.
 Features leveraged by clients:
- Invocation transparency
- Implementation transparency
- Location transparency

6
 CORBA Architecture
 Remote-object: object implementation resides in server’s
address space

Client Server

Java Object

C++ Object

Skeleton

Stub Object Adapter

IIOP
ORB ORB
7
 Stub
 Provides interface between client object and ORB
 Marshalling: client invocation
 Unmarshalling: server response

Client Server

Java Object

C++ Object

Skeleton

Stub Object Adapter

IIOP
ORB ORB

8
 Skeleton
 Provides iterface between server object and ORB
 Unmarshaling: client invocation
 Marshaling: server response

Client Server

Java Object

C++ Object

Skeleton

Stub Object Adapter

IIOP
ORB ORB

9
Object Adapters

10
 Object Adapters

 Object Adapters provide a layer between object method

requests and the servers that service the requests.
Functions include:

 Generate and interpret object references

 Activate and deactivate object implementations
 Starting up the actual server program(s)
 Handling security
 Handle method invocations via skeletons
 Basic Object Adapter (BOA)
 Portable Object Adapter (POA)
11
Object Adapters

12
 Basic Object Adapter (BOA)

 Defines how objects are activated/deactivated

- Initializing server objects:
• BOA.obj_is_ready( /* the object ref */ );
 Registers the object with the ORB

• BOA.impl_is_ready();
 Tells the BOA/ORB to begin listening for requests

 Underspecified
- Initially unclear which features would be required on various
platforms

13
 Portable Object Adapter (POA)

 Replaces BOA
- Most commercial implementations still use BOA
 Expanded scope of OA to include
- Activation policies
- Threading models
- Object life cycle (transient/persistent)
- Pre/post invocation capabilities

14
 (Portable) Object Adapter (POA)
 Register class implementations
 Creates and destroys objects
 Handles method invocation
 Handles client authentication and access control

Client Server

Java Object

C++ Object

Skeleton

Stub Object Adapter

IIOP
ORB ORB

15
 What is an ORB?

 A distributed object bus

 Hides transport mechanisms
- Location
- Method invocation
- Marshalling
ORB
 OMG Interface Definition Language
(IDL) provides the language
independent semantics

16
 Object Request Broker (ORB)

 Enables object to transparently make and receive requests and

responses

“...like a telephone exchange, providing the basic

mechanism for making and receiving calls…”

ORB

17
 Object Request Broker (ORB)

 Abstracts remote request and response mechanisms

 Transport for distributing method invocations

Client Object Implementation

Request

ORB

18
 ORB Usage

 ORB is a singleton
 ORB initialization
- Single static call to init() an ORB

- Afterorg.omg.CORBA.ORB
initialization, you register
orb = objects
org.omg.CORBA.ORB.init();
with the ORB using an Object Adapter

19
Proxy-based Invocation

Client Object Implementation

Request
Request

Stub Skeleton

Request

ORB

20
 ORB Abstraction

 How is this possible in a heterogeneous environment?

Client

Java
Java
? C++ Object Implementation

C++

IDL IDL

ORB

21
 Object Request Broker ...
 Communication infrastructure sending messages between
objects
 Communication type:
- GIOP (General Inter-ORB Protocol)
- IIOP (Internet Inter-ORB Protocol) (GIOP on TCP/IP)

Client Server

Java Object

C++ Object

Skeleton

Stub Object Adapter

IIOP
ORB ORB

22
 ORB and IIOP

The IIOP is a protocol by which ORBs communicate

23
 Internet Inter ORB Protocol (IIOP)

 Transport protocol
- Defines inter ORB communication
- Runs on top of TCP/IP
- Defines CORBA messages
 IIOP is a specification
- Vendors must implement to be “CORBA-compliant”
- Allows for multi-vendor interoperability

24
 CORBA Object

Server

CORBA
Interoperable Object Reference
Object
Interface C++/Java
IDL Implementation Servant

25
 Interoperable Object Reference (IOR)

• Uniquely identifies an object (see object references)

Server

CORBA
Interoperable Object Reference
Object
Interface C++/Java
IDL Implementation Servant

26
 Interface Definition Language (IDL)

 Describes interface
 Language independent
 Client and server platform independent

Server

CORBA
Interoperable Object Reference
Object
Interface C++/Java
IDL Implementation Servant

27
 IDL (cont…)

 In RMI we had an RMI compiler run on the .class file we

wanted to be remote. It’s more complex under CORBA

 The interface is written in Interface Definition Language,

IDL. IDL is language-neutral (by being a different language
than anything else) though highly reminiscent of C++
(multiple inheritance, similar syntax, etc.)

 IDL has a set of primitive data types similar to most

languages—integer, float, string, byte, etc.

28
29
30
 Overall CORBA Architecture

Implementation Interface
repository repository Server
Client

C++ Object IDL Java Object

Interface
Interface repository
repository
interface
interface repository
repository provides
provides information
information about
about registered
registered IDL
IDL interfaces
interfaces to
to clients
clients
and
and servers
servers that
that require
require it.
it.
Skeleton

Stub
Implementation
Implementation repository
repository Object Adapter
activates
activates registered
IIOPon demand
registered servers
servers on demand and
and locates
locates running
running servers
servers
ORB
uses
uses the
the object
object adapter
adapter name
name to
to register
ORB
register and
and activate
activate servers
servers

31
 Development Steps

1 IDL

4 3
idltojava
Client Application Object Implementation

Stub 2 2 Skeleton
request
ORB ORB
response

steps:
1 write the IDL file
2 compile with idltojava (stubs/skeleton generated automatically)
3 write object implementation (servant)
4 write client application

32
 Example of CORBA Services

 Naming: Keeps track of association between object

names and their reference. Allows ORB to locate
referenced objects
 Life Cycle: Handles the creation, copying, moving,
and deletion of objects
 Trader: A “yellow pages” for objects. Lets you find
them by the services they provide
 Event: Facilitates asynchronous communications
through events
 Concurrency: Manages locks so objects can share
resources
 Query: Locates objects by specified search criteria
 …

33
 CORBAservices are the baseline services available to all
objects sitting on the ORB communication bus.

1. Naming Service 9. Query Service

2. Event Management Service 10. Licensing Service
3. Life Cycle Service 11. Property Service
4. Persistent State Service 12. Time Service
5. Transaction Service 13. Security Service
6. Concurrency Service 14. Notification Service
7. Relationship Service 15. Trader Service
8. Externalization Service 16. Collections Service

34
 Corba Services
Service Description
Collection Facilities for grouping objects into lists, queue, sets, etc.
Query Facilities for querying collections of objects in a declarative manner
Concurrency Facilities to allow concurrent access to shared objects
Transaction Flat and nested transactions on method calls over multiple objects
Event Facilities for asynchronous communication through events
Notification Advanced facilities for event-based asynchronous communication
Externalization Facilities for marshaling and unmarshaling of objects
Life cycle Facilities for creation, deletion, copying, and moving of objects
Licensing Facilities for attaching a license to an object
Naming Facilities for systemwide name of objects
Property Facilities for associating (attribute, value) pairs with objects
Trading Facilities to publish and find the services on object has to offer
Persistence Facilities for persistently storing objects
Relationship Facilities for expressing relationships between objects
Security Mechanisms for secure channels, authorization, and auditing
Time Provides the current time within specified error margins

35
 RMI Deployment

Interface Implementation
Definition Installation

Stubs Skeletons

Client Object Implementation

36
 CORBA Deployment

IDL Definition Implementation

Installation

Interface Implementation
Stubs Skeletons
Repository Repository

Client Object Implementation

37
38
 CORBA Features

 Language independence
 Location transparency
 Reuse of facilities & services
 OMG IDL defined interfaces
 Stub & Skeleton generation
 Server activation

39
 Technical/Architectural Overview

 CORBA facilities come in two groups:

1. horizontal facilities
– target client-side functionality
2. vertical facilities
– target domain-specific functionality

40
 Technical/Architectural Overview
(cont.)

 Horizontal facilities specifications:

1. Mobile Agents Facility
2. Printing Facility
3. Internationalization Facility
 Vertical facilities domain-specific services are being
developed for various business areas:
1. Common Enterprise Models
2. Finance/Insurance
3. Electronic Commerce
4. Manufacturing
5. Healthcare
6. Telecommunications

41
 Technical/Architectural Overview
(cont.)

7. Transportation
8. Life Science Research
9. Utilities
10. C4I (Command, Control, Communications, Computers, and
Intelligence)
11. Space

42
Technical/Architectural Overview
(cont.)

No n-st a n d a rd ize d a p p - Ap p lic a t io n d o ma in - Ho rizo nt a l fa c ilit y

sp e c ific in t e rfa c e s sp e c ific in te rfa c e s in te rfa c e s
Ap p lic a tio n In t e rfa c e s C o m m o n Fa c ilitie s
CORBAfacilities Do m a in In te rfa c e s
CORBAfacilities

O b je c t Re q u e st Bro ke r

Ob je c t Se rv ic e s
G e n e ra l se rvic e in te rfa c e s

Object Management Architecture reference

model.

43
 CORBA Basics
IDL J a va
module package
interface interface
struct class
const public static final
boolean boolean
char char
wchar wchar
octet octet
string java.lang.String
wstring java.lang.String
short short
unsigned short short
long int
unsigned long int
long long long
unsigned long long long
float float
double double
fixed (not supported in idlj) java.math.BigDecimal
sequence [] (array)
[] (array) [] (array)
Fig . 26.9 IDL ke yw o rd s, typ e s a n d th e ir m a p p in g s to J a va ke yw o rd s.

44
 Static Invocation Interface (SII), Dynamic Invocation
Interface (DII) and Dynamic Skeleton Interface (DSI)

 Two ways to invoke a request:

1. statically – using Static Invocation Interface (SII)
– relies on creating a request through invoking a static method
in a stub
 stub generated from compile-time definition of an object type
(IDL interface) and object operations (methods within IDL
interface)
2. dynamically – using Dynamic Invocation Interface (DII)
– programmatically creates and send invocation request directly
to ORB without assistance of stub
– developers responsible for guaranteeing sending proper type
and number of arguments to invocation
 Server unaware of process that created the request.

45
 Static Invocation Interface (SII), Dynamic Invocation
Interface (DII) and Dynamic Skeleton Interface (DSI)
(cont.)

 Interface Repository (IR)

- contains descriptive information about distributed objects:
• modules available
• interfaces defined
• names of operations defined within interfaces
• argument types
• return types
• exceptions raised
 Steps needed to make DII call:
1. Obtain object reference to server object
2. Look up desired method in Interface Repository
3. Build argument list using IR’s OperationDef
4. Create and initialize Request object
5. Invoke Request and wait for call to unblock (return)
6. Get results
46
 BOAs, POAs
 Object adapter
- stands between a distributed object and its ORB
- enables clients to access ORB services:
• IOR generation
• security
• activation/deactivation
 OMG specified two adapter types:

- Basic Object Adapter (BOA)

• vague definition of an adapter which led to inconsistencies
between different vendors’ implementations

47
 BOAs, POAs (cont’d)

- Portable Object Adapter (POA)

• Provides CORBA objects with a common set of methods for
accessing ORB functions, ranging from user authentication to
object activation and object persistence

• Basic task is to create object references and to dispatch ORB

requests aimed at target objects to their respective servants

48
 BOAs, POAs (cont.)

 POA connects an object reference to developer-written

code using code found in IDL generated skeleton.
- allow fine-grained control
 Distributed objects inherit from a POA base definition
generated by IDL compiler
- enables distributed object to be usable by a POA,
- enables POA to control all access to servant through policies

49
 BOAs, POAs (cont.)

 POA policies:
- ImplicitObjectActivation,
• tells POA outside object created servant and activated it
- IDAssignmentPolicy, and
• determines who is responsible for assigning a unique ID to a
given servant
- RequestProcessingPolicy.
• uses object id either to find matching servant or invoke default
service that uses object id to perform lookup in database
 Policy combinations provide POAs with fine-grained control
over one or many servants.

50
 BOAs, POAs and TIEs (cont.)

 Another way for developer to us a POA is to wrap their

servants in a TIE.
- enables interaction with a POA without having servant’s object
implementation inherit structure from POAImpl.
- servant can inherit from other base classes freely

51
 CORBA services

 CORBAservices define base services and a support

structure useful to a wide range of applications.
 Five most commonly used services:
1. Naming Service
2. Security Service
3. Object Transaction Service
4. Persistent State Service
5. Event and Notification Services

52
 Naming Service

 Associates name objects with arbitrary value (known as

name bindings).
 A path to a name binding consists of zero or more naming
contexts (a collection of unique name bindings).
 Resolving a name binding returns object associated with
name.
 Binding a name creates association between a name and
an object.
 Multiple name bindings can point to a single object.

53
 Security Service

 Consists of two levels

- Level 1
• provides basic security for
1. user authentication,
2. invocation security, and
3. availability of authentication principals to security-aware
applications
• allows applications to ignore system-security requirements

54
 Security Service (cont.)

- Level 2
• is everything level 1 provides in addition to:
1. more fine-grained user authentication
2. greater invocation security
3. auditing
4. finer control over secure invocations
5. delegation
6. administrators can set security policies
7. discovery of security policies by security-aware applications
8. discovery of security policies by ORBs and other services

55
 Object Transaction Service

 Enables CORBA objects to execute as parts of distributed

transactions.
- a transaction describes a collection of interactions where multiple
users may access and/or modify data.
• acronym ACID describes four standard requirements for
reliable transactions:
1. Atomic – completion of numerous steps must be conducted
as one, otherwise each step must be undone.
2. Consistent – effects of transaction are repeatable and
predictable.
3. Isolated – transaction not interrupted from outside and gives
no indication if execution is proceeding serially or
concurrently.
4. Durable – transaction results are persistent.

56
 Object Transaction Service (cont.)

- transactions complete in one of two ways:

1. committed
• changes are made to persist
2. rolled back
• changes made to data are discarded
- POAs dictate transaction types supported by servants
• shared transactions
• unshared transactions
• shared and unshared transactions

57
 Object Transaction Service (cont.)

 Concepts of transactional clients, transactional objects and

recoverable objects define the OTS.
- transactional clients interact with OTS to create and commit or
rollback a transaction
- transaction objects’ behaviors vary when invoked within a
transaction (object’s data not recoverable)
- recoverable object is a transactional object in which data is
recoverable (maintain their data and capable of restoring their lost
state)
 Java Transaction Service (JTS) is Java implementation of
distributed transaction service
- uses CORBA OTS specification to define protocol

58
 Persistent State Service

 Persistent State Service (PSS) stores and retrieves

objects.
 Abstracts interaction between objects and datastores.
 Persistent State Definition Language (PSDL) defines a
distributed object schema in a portable fashion.
- PSDL is a superset of IDL
• defines two new constructs
 storagetype
 storagehome

59
 Persistent State Service (cont.)

- contains two definition types:

• abstract definition
 define portable definition of the persistable state of a CORBA
object
• concrete definition

60
 Event and Notification Services

 Event Service defines mechanism that decouples delivery

of events (messages) from source of events.
- no predefined event types in specification
- keeps track of action events and event listeners
 Supplier creates events that are processed by a consumer.
 In push model, supplier sends event messages
asynchronously to all consumers registered to receive
messages.
 In pull model, consumer polls supplier for events.

61
 Event and Notification Services
(cont.)

 Notification Service is a direct extension of the Event

Service.
- objects can create and destroy event channels arbitrarily, and can
filter output using Filter Objects and Object Constraint Language

62