CORBA

Introduction

The OMG - overview

It is the worlds largest computer industry consortium
Started with 8 members in 1989
3Com, American Airlines, Canon, Data General, Hewlett-Packard, Philips Telecommunications N.V., Sun Microsystems, Unisys

After few months it became international organization Currently approx 470 members

It provides a structure whereby its members specify technology and then produce commercial implementations complying with those specifications It emphasizes cooperation among members

OMGs goals
Promotion of object-oriented approach to software engineering Definition of an architecture for the distribution and cooperation of OO software components in heterogeneous, distributed environment Contrary to other organizations (like Open Software Foundation), OMG doesnt produce software; rather, it defines standards (guideline, specifications, architectural models) Compliance to specifications assures portability

Organizational structure of the OMG Domain

specific issue Infrastructure issue : ORB Object Service

How it works
Task forces issue Request For Proposal (RFP)
Detailed statements about a problem that needs to be solved Current RFP http://www.omg.org/public_schedule/

Response are solicited in terms of IDL specifications with semantic in English The most suitable specification is selected and presented to the tasks force controlling committee ..

Examples
Agent Metamodel and Profile (AMP) RFP (document ad/2008-09-05) Concrete Syntax for a UML Action Language RFP (document ad/2008-09-09) Date-Time Foundation Vocabulary RFP (document bmi/2008-03-02) Decision Support Service RFP (document health/2007-03-01) Diagram Definition RFP (document ad/2007-09-02) Event Metamodel and Profile (EMP) RFP (document ad/2008-09-15) SwA Evidence Metamodel RFP (document swa/2007-09-03) TACSIT Controller Service RFP (document c4i/2007-06-16) UML Profile for Advanced and Integrated Telecommunication Services RFP (document mars/2008-06-09) UML Profile for XBRL Global Ledger Framework RFP (document finance/2008-1202) Value Delivery Metamodel (VDM) RFP (document bmi/2009-03-09)

Example
A well known example is the UML language UML (last specification)

The Object Management Architecture

OMA is the general framework within all the OMG technology must fit Core Object Model
An abstract framework for refining an object model Important for ORB developers, not for application programmers

Reference Model
Architectural framework Relevant to application programmers

Core Object Model

Defines the main concepts of the model These definitions are extended with component to provide a more concrete specialization of the model The core plus one ore more component is called a profile

Core Object Model concept definitions

Objects Operations Nonobject types Interfaces Substitutability

Objects
Model of entities or concepts
A document, date, compiler,

Objects have an identity, fixed for the whole lifecycle, which is independent of the objects properties or behavior This identity is represented by an object reference
We will later see how the CORBA profile specifies this concept

Operations, signature,
An operation is a behavior that the object offers to the outside world through its signature
Sending a request to an object = invoking an operation on the object

An operations signature has

A name Set of parameters Set of returned values
Object reference may be returned

Operation, signature,
Operations may cause side-effects (change in the objects state) Exceptions are returned when the operation cannot be executed
Exceptions are defined in the CORBA profile

Nonobject type
They are usually called data types

Interface and Substitutability

It is a collection of operation signatures that can be invoked on the object Substitutability: One interface can be used in place of another without interaction error
Simplest form occurs when interface A offers a superset of the operation offered by B Transitive relationship

Core Object Model defines subtyping a form of substitutability based on inheritance

If A inherits from B, then A is a subtype of B (B is a supertype)

Object is the supertype of all objects

Example of inheritance

Inheritance
If interface A inherits from B, then A offers the same set of operations and may also offer some additional one This relationship explicitly relate A to B
The fact that the operations in A is a superset of those in B in not a coincide

OMA Reference model

Architectural framework for the standardization of interfaces to infrastructure and services that an application can use
Understand what support application from a concrete Model implementation

OMA Reference model

Reference model - components

Object Request Broker (ORB) Object Services Common Facilities Domain Specific Interface Application Interface

ORB
ORB is defined in the Common Object Request Broker Architecture and Specification (CORBA) document CORBA builds on the OMA Core Object Model
Syntax and Semantic of an IDL Framework for interoperability Set of language mappings from IDL to languages (C, C++, COBOL, Smalltalk,Ada95,java,lisp,Python)

Current specification CORBA 3.1

Popular ORB implementations

JacORB (java mapping) OmiORB (C++ and python) ACE-TAO (C++)
Designed for Real-time applications

Object services
Set of interface specifications to fundamental services for OO distributed applications The brand name is CORBAServices
Naming Notification Lifetime Transaction Concurrency .

Common Facilities
User-oriented interface providing facilities across application domains They are referred to as CORBAfacilities
Time Facility Printing Facility ..

Domain Interface
A.k.a. Vertical facilities Domain specific interfaces
Issued by the Domain Task Force

Equivalent view of OMA

CORBA - overview
Location transparency
Ability to access and invoke operations on CORBA objects (defined from the core object model plus specific profile) without the need of knowing where they reside

Programming language transparency

Implement the same CORBA object in the most appropriate programming language Implementation-neutral IDL
Language mapping (automatic translation of interface definition and gluing code stub /skeleton )

Stub, ORB, skeleton

IDL allows programs providing and using objects to agree on the form of their exchange
If two objects are substitutable, then clients can decide which object to use at run time

ORB interface
ORB interfaces are specified in IDL
Certain interfaces are designed as pseudo-IDL, meaning that they are not CORBA objects nor data types Pseudo-IDL interface may be implemented as pseudo-objects (they may correspond to libraries) Pseudo-objects are invoked as normal objects, but their reference cannot be passed as a parameter

CORBA Object model

Use the same concepts of the Core Model, but makes them more concrete and precise

Servant
Programming language entity implementing the operations defined by an IDL A CORBA Object can be incarnated by different Servant over its lifetime

Object reference
Identity used to invoke operations Handle to an object Can be passed as parameters They are opaque
Enough information for the ORB to send a request to the correct servant, but this information is inaccessible to the user

Interface
Group of operations Support of inheritance mechanism One-to-one mapping between Object and interface CORBA Component Model (CCM) allows objects to have many interfaces
Principal interface is the most specific interface than an object can support

Types
Object types
Support an interface All inherits from the CORBA Object

Valuetypes
Like an interface, but can define a state accessible to the client Local implementation passed by value

Non object types

Represented as constructed types in OMG IDL Exception type

Basic types
Integer, char,

Operation semantics
At-most-once
ORB conveys the arguments to the object implementation and returns the result (if any) to the requester The requester is blocked waiting for the reply (or exception is raised) Executed exactly once (if no exception), and no more than once if an exception occurs

Operation semantic
Best effort
The requester doesnt wait for the operation to complete Signature is through oneway keyword
Must return void, cannot contain in out nor inout parameter (see later)

Deferred-synchronous
Send the request without blocking Polling the reply

Signature
string SayHello(in string sn) raises (Invalid);
[oneway] returned type | operation_identifier [list of parameters] [context]

ORB Structure

Interface Repository

Implementation Repository

Client stub
Automatically generated from the IDL interface Must be linked to the client program invoking the operation In OO the stub is instantiated as a local proxy object that delegates invocation on its methods to the remote implementation Convert local representation to external representation
Marshalling / Unmarshalling

Dynamic Invocation Interface (DII)

Allows to send a Request message to an object denoted by its Object Reference Client have access to the Request pseudo-object
Defines the form of such a message A client that knowing the OR and its interface, may construct the message and invoke the operation without using the stub Client can become aware of these info at run-time (enables reflection)

Different semantics
At-most-once and deferred-synchronous

Implementation skeleton
Invoke the right method on the implementation object Automatically generated from IDL definition

Dynamic Skeleton Interface (DSI)

Useful for implementation already avaible before the IDL definition
Wrapper of a legacy application

Access a request message through the ServerRequest pseudo-object

ORB and Object Interface

ORB management functionality is available to the client and object implementation
Create a string to represent OR (and back) Copy/delete/compare OR Initialization

Seen as a pseudo-object whose interface definition is commented as PIDL (Pseudo-IDL)

Stringified OR
module CORBA { types interface ORB { //PIDL string object_to_string(in Object obj); Object string_to_object(in string obj); //others.. } input parameter }

Managing Objects
module CORBA { interface Object { InterfaceDef get_interface(); //from Interface repository boolean is_nil(); //this denotes no object Object duplicate(); void release(); boolean is_a(in string logical_type_id); boolean is_equivalent(in Object other_object); unsigned long hash(in unsigned long maximum); Policy get_policy(in PolicyType policy_type); Object set_policy_ovverrides(in PolicyList policies, in SetOverrideType set_add); DomainManagerList get_domain_managers(); //. } }

Managing Objects
module CORBA { interface Object { InterfaceDef get_interface(); //from Interface repository boolean is_nil(); //this denotes no object Object duplicate(); void release(); boolean is_a(in string logical_type_id); boolean is_equivalent(in Object other_object); unsigned long hash(in unsigned long maximum); Policy get_policy(in PolicyType policy_type); Object set_policy_ovverrides(in PolicyList policies, in SetOverrideType set_add); DomainManagerList get_domain_managers(); //. } }

Managing Objects
module CORBA { interface Object { InterfaceDef get_interface(); boolean is_nil(); Object duplicate(); void release(); boolean is_a(in string logical_type_id); boolean is_equivalent(in Object other_object); unsigned long hash(in unsigned long maximum); Policy get_policy(in PolicyType policy_type); Object set_policy_ovverrides(in PolicyList policies, in SetOverrideType set_add); DomainManagerList get_domain_managers(); //. } }

Invalid OR copy
1. OR is a reference to the Proxy 2. OR1 is created by the copy feature of the language 3. The proxy is not aware that is it pointed by two references (its reference count remains 1) 1. CORBA:relase() decreases the reference count to zero 2. The proxy assumes that no one points to it; then it de-allocates the resources and destroys itself!

Correct use of duplicate and release

1. Proxy is aware of the two reference to it 2. The remote object is aware of two OR to it

1. Proxy is not destroyed

Proxy creation when passing OR

1. Client invokes op on OR1 2. The operation returns another reference, which is a duplicate of the local reference OR2

Proxy creation when passing OR

1. A new local proxy is created; this means that the code has to be already available or it should somehow retrieved (e.g., Javas dynamic class downloading )

Invalid OR deletion

1. Deleting the OR data structure doesnt destroy the proxy

Managing Objects
module CORBA { interface Object { InterfaceDef get_interface(); Check if the Interface boolean is_nil(); Repository ID refers to Object duplicate(); a subtype of this void release(); object (use narrow) boolean is_a(in string logical_type_id); boolean is_equivalent(in Object other_object); hash of unsigned long hash(in unsigned long maximum); maximum size Policy get_policy(in PolicyType policy_type); of a reference Object set_policy_ovverrides(in PolicyList policies, in SetOverrideType set_add); DomainManagerList get_domain_managers(); //. } }

Managing Objects
module CORBA { interface Object { InterfaceDef get_interface(); boolean is_nil(); Object duplicate(); void release(); boolean is_a(in string logical_type_id); boolean is_equivalent(in Object other_object); unsigned long hash(in unsigned long maximum); Policy get_policy(in PolicyType policy_type); Object set_policy_ovverrides(in PolicyList policies, in SetOverrideType set_add); DomainManagerList get_domain_managers(); //. } }

Object Management model

Objects are managed according to a policy domain model A (policy) domain is a set of objects to which a common policy applies A domain is managed through a DomainManager interface that allows to retrieve the policy object for the domain
get_domain_managers

Object Management model

An object can belong to different domains
Security audit policy and access control policy

Policy allows for specifying different aspects of the object

Who may access the object Which requests are logged

A policy is defined as a type

For example, the SecContruction policy type is defined in the CORBA core module Other policies are defined in POA and Security Service (see later)

ORB initialization
module CORBA { // typedef string ORBid; typedef sequence<string> arg_list; ORB ORB_init(inout arg_list argv,in ORBid orbid); // interface ORB{ typedef string ObjectId; typedef sequnce <ObjectId> ObjectIdList; exception InvalidName{}; ObjectIdList list_initial_services(); Object resolve_initial_references (in ObjectId identifier) raises InvalidName } }

ORB initialization
The ORB is accessible as a pseudo-object Its reference in returned by ORB_init
It is not invoked on any object (bootstrap) Receives a configuration string and the name of the ORB from the command shell

Once the ORB is obtained, it is possible to know the basic services and facilities it supports and get a reference to them

ORB initialization
module CORBA { // typedef string ORBid; typedef sequence<string> arg_list; ORB ORB_init(inout arg_list argv,in ORBid orbid); // interface ORB{ typedef string ObjectId; typedef sequnce <ObjectId> ObjectIdList; exception InvalidName{}; ObjectIdList list_initial_services(); Object resolve_initial_references (in ObjectId identifier) raises InvalidName } }

Bootstrap process
Once the services are known, it is necessary to get an object reference to them This is achieved using a bootstrap operation with the name of the service as argument
CosNaming::NamingContext (Cos = Corba service) CosTrading::Lookup .

ORB initialization
module CORBA { // typedef string ORBid; typedef sequence<string> arg_list; ORB ORB_init(inout arg_list argv,in ORBid orbid); // interface ORB{ typedef string ObjectId; typedef sequnce <ObjectId> ObjectIdList; exception InvalidName{}; ObjectIdList list_initial_services(); Object resolve_initial_references (in ObjectId identifier) raises InvalidName } }

(Portable) Object Adapter

Request dispatching model

Based on POA component Provides a comprehensive set of interface for managing object references and servant Standard interface for
Mapping object reference to a servant Allow transparent activation of objects Associate policy information with objects Make objects persistent over server lifetimes

POA architecture
Servant: Implementation providing run-time semantics of one or more CORBA objects Object ID: ID used by a POA to identify an abstract object Active Object MAP: ServantObject ID table used to dispatch incoming requests Incarnation: Servant serving the request of an object (incarnates the object) Etherealizion: Destroying the object ID servant association Default Servant: Servant to which all incoming requests of object ID not in the AO Map are dispatched

POA architecture
Servant: Implementation providing run-time semantics of one or more CORBA objects Object ID: ID used by a POA to identify an abstract object Active Object MAP: ServantObject ID table used to dispatch incoming requests Incarnation: Servant serving the request of an object (incarnates the object) Etherealizion: Destroying the object ID servant association Default Servant: Servant to which all incoming requests of object ID not in the AO Map are dispatched

POA architecture
Servant: Implementation providing run-time semantics of one or more CORBA objects Object ID: ID used by a POA to identify an abstract object Active Object MAP: ServantObject ID table used to dispatch incoming requests Incarnation: Servant serving the request of an object (incarnates the object) Etherealizion: Destroying the object ID servant association Default Servant: Servant to which all incoming requests of object ID not in the AO Map are dispatched

POA architecture
Servant: Implementation providing run-time semantics of one or more CORBA objects Object ID: ID used by a POA to identify an abstract object Active Object MAP: ServantObject ID table used to dispatch incoming requests Incarnation: Servant serving the request of an object (incarnates the object) Etherealizion: Destroying the object ID servant association Default Servant: Servant to which all incoming requests of object ID not in the AO Map are dispatched

POA architecture
Servant: Implementation providing run-time semantics of one or more CORBA objects Object ID: ID used by a POA to identify an abstract object Active Object MAP: ServantObject ID table used to dispatch incoming requests Incarnation: Servant serving the request of an object (incarnates the object) Etherealizion: Destroying the object ID servant association Default Servant: Servant to which all incoming requests of object ID not in the AO Map are dispatched

POA Manager
Encapsulate the processing state of one or more POAs Requests associated to the POA are discarded, queued or served

Dynamic activations

Interoperable Object Reference (IOR): Application wide unique ID generated by the POA Adapter activator: May create a POA on demand, if the POA responsible for an object is not active Servant Manager: create servant on-demand (may be of two types: servant locator and servant activator see later)

Root POA
Created and managed by the ORB Available at the application through the initialization interface resolve_initial_references Application may register servant with root POA, or create other child POAs to manage servant with higher flexibility

POA Policy
Object ID uniqueness policy
One or many Object-ID refer to the same servant object

Lifespan policy
Determines if CORBA objects are transient or persistent (outlive after POA is destroyed and created again)

ID assignment
Generated automatically (by the ORB) or by the programmer If automatically generated and the POA lifespan is persistent, the ID must also be unique across all the instantiation of the same POA

POA Policy
Servant Retention policy
Keeps the Object ID servant association in the Active Object MAP or establish a new ObjectID/servant association each time a new request arrives (through activators)

POA policy
Request processing policy
Consult only the AOM
Object not found error reported to the client

Use a default servant

If not found, dispatch the request to the default

Invoke a servant manager

It is an implementation object that can incarnate a CORBA object or activate a servant and return it to the POA

POA Policy
POA-controlled Threading policy
Single thread: Multithread

ORB-controlled threading policy

POA processing
1. Locate the server process
IOR contains Host name and port number Or create a new server process on-demand (from the implementation repository) IOR contains an object key (Object-ID + POA name)

2. Locate the POA

3. Locate the servant
Use the retention policy

4. Locate the skeleton 5. Handling replies, exception and location forwarding

Skeleton marshals and returns parameters and exception (expect for ForwardRequest exception)

Layered Demultiplexing
High overhead, especially in number of objects is high

Priority inversion may occur FIFO dispatching strategy (not Qos based)

Perfect hashing
Low demux latency, O(1) Only for static objects

Active demux
OA dispatch based a (possibly dynamically) offeset Low cost, O(1)

Architectural design options (thread-per-connection)

An important architectural choice is how the server object handle request efficiently In general, one possible way to design a multithread server is using the thread-per-connection design pattern
1. An acceptor thread accepts connections on a communication end-point Clients connect to the endpoint Thread creates a new thread that manages the handler of the connection Client sends data The connection thread receives it ..and writes data somewhere

2. 3.

4. 5.

from

6.

Architectural design options (Reactor pattern)

Avoid thread management overhead

Requests arrive at a reactor (initiation dispatcher) (4)

Reactor uses a synchronous event demultiplexer to wait and being notified when an event occurs (2)

The demux may use the select() system call that examines a set of I/O descriptors and returns when at least one event occurs (3,4)
Reactor dispatches (callback) the handler of the event and the associated data (5) . As an event occurred the operation is not blocked

Handlers must register with the reactor (1,8)

Architectural design options (Leader-follower)

A leader thread waits for an event on an handle set

When an event occurs, the leader promotes a follower to become the new leader and processes the event itself or hand-offs the event to a follower thread in the thread set

An example, TAO
1. Query the client ORBs connection for exiting connection to the server S designated in the IOR
2. Create a new connection to S (if required) 3. Add connection to the cache 4. Add connection handle to the reactor 5. Accept a new connection 6. Add C to the cache (bidirectional) 7. Also add C to the reactor
c

8. Wait for new connections

An example, TAO
9. Allocate memory for marshalling 10. Send the marshalled data

11. Wait reply from the server

12. Read request header

13. Allocate memory

14. Read data

15. Demux request to POA

16. Send the reply 17. Wait for new events
c

18. Read the reply

19. The leader hands-off to the follower by signaling a Condition Variable 20. Demarshall parameters