CORBA

Common Object Request Broker Architecture

Vishal Singh (205111043) Sanjeev Singh (205111046)

The Common Object Request Broker Architecture is a Standard defined by the object management group that Enables software components written in multiple computer languages and running on multiple computers to work together.

CORBA

Fig - The global architecture of CORBA.

Overview

ORB is core of any COBRA Distributed System.

ORB is responsible for enabling communication Between objects and their clients while hiding issues related to distribution and heterogeneity.

Object Request Broker

CORBA use the remote object model in which the implementation of an object reside in the address space of a server.

Objects and services are specified in the CORBA Interface Definition Language(IDL).

Object Model

Fig - The general organization of a CORBA system.

Object Model

Service Collection Query Concurrency

Description Facilities for grouping objects into lists, queue, sets, etc. Facilities for querying collections of objects in a declarative manner Facilities to allow concurrent access to shared objects

Transaction
Event Notification Externalization

Flat and nested transactions on method calls over multiple objects

Facilities for asynchronous communication through events Advanced facilities for event-based asynchronous communication Facilities for marshaling and unmarshaling of objects

Life cycle
Licensing Naming Property Trading Persistence

Facilities for creation, deletion, copying, and moving of objects

Facilities for attaching a license to an object Facilities for systemwide name of objects Facilities for associating (attribute, value) pairs with objects Facilities to publish and find the services on object has to offer Facilities for persistently storing objects Facilities for expressing relationships between objects

Relationship

Corba Services

Security
Time

Mechanisms for secure channels, authorization, and auditing

Provides the current time within specified error margins

Fig - Overview of CORBA services.

Communication Object Invocation Models

Request type Synchronous Failure semantics At-most-once Description Caller blocks until a response is returned or an exception is raised Caller continues immediately without waiting for any response from the server Caller continues immediately and can later block until response is delivered

One-way

Best effort delivery

Deferred synchronous

At-most-once

Fig - Invocation models supported in CORBA.

1.

Event and Notification Services

Fig - The logical organization of suppliers and consumers of events, following the push-style model.

2.

Fig - The pull-style model for event delivery in CORBA.

Event and Notification Services

1.

Fig - CORBA's callback model for asynchronous method invocation.

Messaging

2.

Messaging

Fig - CORBA'S polling model for asynchronous method invocation.

Message type Request Reply LocateRequest LocateReply

Originator Client Server Client Server

Description Contains an invocation request Contains the response to an invocation Contains a request on the exact location of an object Contains location information on an object

CancelRequest
CloseConnection MessageError Fragment

Client
Both Both Both

Indicates client no longer expects a reply

Indication that connection will be closed Contains information on an error Part (fragment) of a larger message

Interoperability

Fig - GIOP message types.

Process

Client- simple one Server

IDL specification are compiled into a proxy Marshall invocation info Un-Marshall corresponding reply Proxies are just to connect to underlying ORB

Client Process

It is a mechanism by which an invocation can intercepted on its way from client to server and adopt it Request level interceptor Message level interceptor

Interceptor

Logical placement of interceptor

It is just like a wrapper Responsible for providing consistent image of what an object is It provides mechanism such that client can see that program is just an object POA are responsible to show server-side code as object to client Server side code need not to worry about underlying ORB

Object adapter

a) POA supporting multiple servant b) POA supporting single servant

Portable object adapter

To facilitate agent based system CORBA adopts a model in which different kind of system can co-operate CORBA provides standard interface that has to be followed Agent system - creation, execution, transfer, termination Each agent system has its profile Region, finder

Agents

CORBA's overall model of agents, agent systems, and regions

Object reference Character based

Naming

How objects are referenced? Client side object reference and ORB object reference are different A reference of X can not be passed to Y because of address space So marshaling is used by underlying ORB for this ORB has language independent reference called IOR ( interoperable object reference)

Object reference

The organization of an IOR with specific information for IIOP

Starts with repository identifier Most important part is tagged profile Profile ID Host field Port field Object key components

IOR details

Binding request is first sent to implementation repository It acts as a registry by which reference objects can be located and activated

Indirect binding

Indirect binding example

CORBA naming service(char based)

Offered by CORBA to lookup object reference using characterbased names (id,kind) pair where both are string (vishal,dir) as an example

Object groups - replicate objects into object groups Identical copies of same object Replication is transparent to client But how object group are referenced ?

Fault tolerance

IOGR (interoperable object group reference)

IOGR contains multiple reference to different objects (of same type) IOR contains multiple reference to same object ORB binds IOGR to one of the replicas

A possible organization of an IOGR for an object group having a primary and backups.

An example architecture

Security
The general organization for secure object invocation in CORBA.

Application level objects are unaware of security mechanism At binding time ORB decides which security service is to be used at client side Selection of service is done by security policy Security policies are done by policy objects

Secure object invocation

 1. 2.

Two different interceptors Access control interceptor- checks the rights Secure invocation interceptor- message protection and it is able to encrypt the request and response also

Replaceable security service

The role of security interceptors in CORBA.