01 OmniORB

• Terminology
• OmniORB
• Object Request Broker
• Portable Object Adapter
• POA Policies
• POA States
• Transient / Persistent Objects
• Feature
 Terminology

Client is an entity which issues requests

on an object.

Server is a process which may support

one or more servants.

IDL is compiled to stubs and skeletons

in the target language.

Stubs implement object references.

Skeletons support the incarnation of

2
21 servants.
 OmniORB

omniORB
 is a robust high performance CORBA ORB for
C++ and Python.

 is an Object Request Broker (ORB) that

implements version 2.6 of the Common Object
Request Broker Architecture (CORBA)
specification.

3
21
 OmniORB

IIOP
 The native transport is IIOP (Internet Inter-ORB
Protocol), and it comes complete with a COS
Naming Service.

 It supports C++ and Python language bindings.

4
21
 Object Request Broker

5
21
 Object Request Broker

The ORB brokers requests between objects.

Responsible for

object reference management

connection management

operation invocation

marshalling
6
21
 Object Request Broker

string object_to_string (in Object obj);

Converts an object reference into a standard

stringified form

e.g. IOR:010000001900000049444c3a5475746f7
269616c2f4578616d706c653a312e30000000000
100000000000000480000000101020007000000
6d79686f73740000d20400001c00000057617320
697420776f72746820747970696e672074686973
20696e3f01000000000000000800000001000000
00545441

7
21
 Object Request Broker

 stands for Interoperable Object Reference

 meaning it can be understood by any
compliant ORB.

 Converts an IOR string back into an

object reference.

8
21
 Object Request Broker

Client Side
 Client receives an object reference, either
from an ORB function, or a call to another
object and invokes operations on the object.

9
21
 Object Request Broker

Server Side
 Objects must be registered with an object
adapter.
 CORBA originally specified the BOA — Basic
Object Adapter.
Too loosely specified for server code to be
portable between ORBs.
 POA — Portable Object Adapter
Server code is portable between ORBs.
10 Specifies a very wide range of facilities.
21
 Portable Object Adapter

Objects are created within POAs.

Within a POA, an object is identified with an object id.

Objects can be activated and deactivated.

A servant incarnates an activated object.

11
21
 Portable Object Adapter

When an object is deactivated, the associated

servant is etherealized.

There can be a many-to-one mapping between

objects and servants.
i.e. a single servant can incarnate multiple
objects within a POA.
– or even within multiple POAs.

12
21
 POA Policies

The behavior of a POA is determined by its policies:

Single threaded or ORB-controlled threading.

One id per servant or multiple ids.

User-provided object ids, or system-provided ids.

Use an active object map, default servant, servant locator,

or servant activator.

Allow implicit activation or not.

13
21
 POA States

A POA’s state is controlled with its POA manager:

Holding Incoming requests are queued, up

to a limit.

Active Incoming requests are dispatched

to the relevant objects.

Discarding Incoming requests are met with

TRANSIENT exceptions.

14 Inactive The POA is about to be shut

21 down. Cannot leave this state.
 Transient / Persistent Objects

To clients, object references are opaque.

They cannot tell anything about the object’s life cycle.

Servers classify objects as transient or persistent.

Transient objects
do not exist past the life of the server process
good for callbacks, session management, etc

15
21
 Transient / Persistent Objects

Persistent objects

can exist past the life of a server process

good for long-lived services

16
21
 Feature

C++ and Python language bindings.

Support for the complete Portable Object Adapter

(POA) specification.

Support for the Interoperable Naming Service (INS).

Internet Inter-ORB Protocol (IIOP 1.2) is used as the

native protocol.

17
21
 Feature

The omniORB runtime is fully multithreaded.

It uses platform thread support encapsulated with a

small class library, omnithread, to abstract away
from differences in native thread APIs.

18
21
 Feature

TypeCode and type Any are supported.

DynAny is supported.

The Dynamic Invocation and Dynamic Skeleton

interfaces are supported.

Valuetype and abstract interfaces are supported.

19
21
 Feature

A COS Naming Service, omniNames.

Many platforms are supported, including most Unix

platforms and Window.

It has been successfully tested for interoperability via

IIOP with other ORBs.

20
21
 Feature

Asynchronous Method Invocation (AMI) supported,

including both polling and callback models.

Extensive control over connection management.

Soft real-time features including call deadlines and

timeouts.

21
21
 IDL compiler
02 and Naming
• The Echo Object Example
• Generating the Python stubs
• Setting up your environment
• Naming
• Data file
• Starting omniNames
 The Echo Object Example

define the object interface in IDL

use the IDL compiler to generate the stub

code, which provides the object mapping as
defined in the CORBA specification

provide the servant object implementation

write the client code

2
11
 The Echo Object Example

Define an object interface, called Echo, as follows:

interface Echo {
string echoString (in string mesg);
};

which takes a string as an argument

echoString ()
and returns a copy of the same string.

3
11
 Generating the Python stubs

The IDL compiler, omniidl are used to produce the

Python stubs for IDL file.

omniidl -bpython echo.idl

That produces two Python packages derived from

the echo.

Directory echo contains the client-side definitions;

directory echo__POA contains the server-side
4 skeletons.
11
 Setting up your environment

Download the omniORB from

http://omniorb.sourceforge.net/download.html

Extract the omniORB zip file and place the C drive.

Set up the System Variable

 Path=C:\omniORBpy-4.2.1\bin\x86_win32

 PYTHONPATH=C:\omniORBpy 4.2.1\lib\python;
C:\omniORBpy-4.2.1\lib\x86_win32

5
11
 Naming
omniNames is omniORB’s implementation of
the OMG’s COS Naming Service Specification.

It offers a way for a client to turn a human-

readable name into an object reference, on
which the client can subsequently invoke
operations in the normal way.

6
11
 Naming
The Naming Service stores a set of bindings of
names to objects.

These bindings can be arranged as an arbitrary

directed graph, although they are often arranged
in a tree hierarchy.

Each node in the graph is a naming context.

7
11
 Naming
There is a ‘root’ context at which name lookups
usually start.

This is the object returned by the call to

CORBA::ORB::resolve_initial_references
("NameService")

8
11
 Naming

9
11
 Data file
omniNames persists its contents in a data file.

The data file takes the form of a ‘redo log’, to

which it writes out an entry every time a change
is made to the naming graph.

Periodically the data file is check pointed,

removing unnecessary entries from the file.

The idle time between checkpoints defaults to

15 minutes.
10
11
 Starting omniNames
When starting omniNames for the first time, you can
either let it start with the default TCP port of 2809, or you
can specify the port number on which it should listen.

OmniNames –start

11
11
 Configuration and
Implementation of
03 OmniORB