Teaching material
based on Distributed
Systems: Concepts
and Design, Edition 3,
Addison-Wesley 2001.
Copyright © George
Coulouris, Jean Dollimore,
Tim Kindberg 2001
email: authors@cdk2.net
This material is made
available for private study
and for direct use by
individual teachers.
It may not be included in any
product or employed in any
service without the written
permission of the authors.
Viewing: These slides
must be viewed in
slide show mode.
Distributed Systems Course
CORBA case study
17.1 Introduction
17.2 CORBA RMI
17.2.1 Client and server example
17.2.2 Architecture
17.2.3 CORBA IDL
17.2.4 CORBA object references
17.3 Services (just a summary)
Introduction to CORBA
 The Object Management Group (OMG) was formed
in 1989. Its aims were:
– to make better use of distributed systems
– to use object-oriented programming
– to allow objects in different programming languages to communicate
with one another
 The object request broker (ORB) enables clients to
invoke methods in a remote object
 CORBA is a specification of an architecture
supporting this.
– CORBA 1 in 1990 and CORBA 2 in 1996.
2
•
Introduction to CORBA
Don't be put off by GIOP and IIOP
They are just names for familiar things
The main components of CORBA’s RMI framework are:
1. An interface definition language known as IDL.
2. An architecture.
3. The General Inter-ORB protocol (GIOP) defines
• an external GIOP
data representation,
CDR data representation
is just aboutcalled
external
 specifies formats
the messages inprotocol
a request-reply protocol.
and aforRequest-reply
• including
messages
forobjects
enquiring
about
the location of an
allowing
for
to
be
activated
object, for cancelling requests and for reporting errors.
4. The Internet Inter-ORB protocol (IIOP) defines a standard
form for remoteIIOP
object
references.
is just
about remote object references
• IIOP is GIOP implemented in TCP/IP

CORBA services - generic services useful in distributed
applications e.g.
Naming
Service,
EventforService.
The
architecture
allows
mixed languages
and object activation (added to Figure 5.6)
3
•
CORBA RMI
 CORBA RMI is a multi-language RMI system.
 The programmer needs to learn the following new concepts:
– the object model offered by CORBA;
– the interface definition language and its mapping onto the implementation
language. (e.g. a struct in IDL is mapped onto what in Java?)
 CORBA's object model
– similar to the remote object model in Chapter 5 (what are the main features?)
– clients are not necessarily objects (why not?)– a client can be any program
that sends request messages to remote objects and receives replies.
 The term CORBA object is used to refer to remote objects.
– a CORBA object implements an IDL interface, has a remote object reference
and its methods can be invoked remotely.
 A CORBA object can be implemented by a language without classes.
– the class concept does not exist in CORBA.
– therefore classes cannot be defined in CORBA IDL, which means that
instances of classes cannot be passed as arguments.
4
•
CORBA IDL interfaces Shape and ShapeList
struct Rectangle{
long width;
long height;
long x;
this struct is used in
long y;
defining another struct.
};
interface Shape {
long getVersion() ;
GraphicalObject getAllState() ;
};
struct GraphicalObject {
string type;
Rectangle enclosing;
boolean isFilled;
};
this struct is used as a parameter or result
type in methods in the remote interfaces.
// returns state of the GraphicalObject
an interface specifies a name and a set of methods
sequences and arrays in typedefs
typedef sequence <Shape, 100> All;
interface ShapeList {
interface ShapeList
exception FullException{ };
Shape newShape(in GraphicalObject g) raises (FullException);
All allShapes();
// returns sequence of remote object references
long getVersion() ;
the};parameter of newShape is an in parameter and
Exceptions defined by raises and set
of type Graphical Object The return value is an
Figure
17.1 of type Shape. No classes can
extra out
parameter
5
be passed as arguments or results
by throw. They can have arguments.
•
Parameters in CORBA IDL
 Passing CORBA objects:
– Any parameter or return value whose type is specified by the name of a IDL
interface, e.g. Shape, is a reference to a CORBA object (see newShape)
– and the value of a remote object reference is passed.
 Passing CORBA primitive and constructed types:
– Arguments of primitive and constructed types are copied and passed by value.
On arrival, a new value is created in the recipient’s process. E.g., the struct
GraphicalObject (argument of newShape and result of getAllState)
 Note: the method allShapes returns an array of remote object
references as follows:
typedef sequence <Shape, 100> All;
All allShapes();
 Type Object - is a supertype of all IDL interfaces (its values
are object references). When would it be useful? Hint:
– Think about the name server
6
•
CORBA Naming Service (see Section17.3.1)
 It is a binder that provides methods including
– rebind for servers to register the remote object references of CORBA objects
by name (e.g. rebind (path, Object) e.g of 2nd argument?
– resolve for clients to look them up by name.(e.g.Object = resolve(path))
– these methods belong to an interface called NamingContext (Fig 17.10)
 The names are structured in a hierarchy,
– a path is an array of NameComponent (a struct with a name in it)
– the path starts from an initial context provided by CORBA
– This makes access in a simple example seem rather complex!
 The name service is present in all CORBA installations. (It’s
role is like the Java RMI registry)
 Its use will be shown in program examples
7
•
Illustration of programming CORBA
 We illustrate CORBA with a Java client and server
 The interface compiler is called idltojava
– when given an IDL interface, it produces





server skeletons for each class (e.g. _ShapeListImplBase)
proxy classes (e.g. _ShapeListStub)
a Java class for each struct e.g. Rectangle, GraphicalObject
helper classes (narrow method) and holder classes (for out arguments)
the equivalent Java interfaces (e.g. ShapeList below)
public interface ShapeList extends org.omg.CORBA.Object {
Shape newShape(GraphicalObject g) throws ShapeListPackage.FullException;
Shape[] allShapes();
int getVersion();
Figure 17.2
}
8
•
The ShapeListServant class of the Java server program for the
CORBA interface ShapeList. Figure 17.3
 A Java server has classes for its
This class has to create CORBA objects
import org.omg.CORBA.*;
IDL interfaces (e.g. Shape and
class ShapeListServant extends _ShapeListImplBase
{
of type
Shape.
HowHere
does
it do
that?
ShapeList).
is
the
class
ORB theOrb;
ShapeListServant
private Shape theList[];
a servant class extends the corresponding
private int version;
skeleton class (e.g. ShapeListImplBase)
private static int n=0;
public ShapeListServant(ORB orb){
theOrb = orb;
CORBA objects are instances of servant classes.
// initialize the other instance variables
In non-OO languages implementations of CORBA
}
can’t be classes. What might
public Shape newShape(GraphicalObject g) objects
throws ShapeListPackage.FullException
{ they be in C?
version++;
Shape s = new ShapeServant( g, version);
if(n >=100) throw new ShapeListPackage.FullException();
theList[n++] = s;
a servant class implements the methods in the
theOrb.connect(s);
interface (ShapeList). newShape is a factory
return s;
method. It creates new CORBA objects. It uses the
}
connect method to inform the ORB about the new
public Shape[] allShapes(){ ... }
CORBA object. (it has a remote reference module)
public int getVersion() { ... }
}
9
•
Java class ShapeListServer (the server class)
1.
2.
3.
4.
5.
import org.omg.CosNaming.*;
The server class contains the main method
itimport
gets org.omg.CosNaming.NamingContextPackage.*;
a reference to the Naming Service
narrows
it to NamingContext- from Object
import org.omg.CORBA.*;
it creates and initialises the ORB
makes
a NameComponent
public class
ShapeListServer { containing the
public
static void main(String args[]) {
name
“ShapeList”
try{
makes a
path
ORB orb = ORB.init(args, null);
uses rebind to register the name and object
ShapeListServant shapeRef = new ShapeListServant(orb);
reference orb.connect(shapeRef);
org.omg.CORBA.Object objRef =
it creates an instance of ShapeListServant class - a Java
orb.resolve_initial_references("NameService");
- which is made a CORBA object
NamingContext ncRef object
= NamingContextHelper.narrow(objRef);
the connect method to register
it with the ORB
NameComponent nc = by
newusing
NameComponent("ShapeList",
"");
NameComponent path[] = {nc};
ncRef.rebind(path, shapeRef);
java.lang.Object sync = new java.lang.Object();
synchronized (sync) { sync.wait();}
it waits for client requests
} catch (Exception e) { ... }
Figure 17.4
}
10
•
}
Java client program for CORBA interfaces Shape and
ShapeList
import org.omg.CosNaming.*;
1. it contacts the NamingService for initial context
import org.omg.CosNaming.NamingContextPackage.*;
2. Narrows it to NamingContext
import org.omg.CORBA.*;
it creates and initialises an ORB
3.
It
makes
a
name
component
public class ShapeListClient{
4. {It makes a path
public static void main(String args[])
5. It gets a reference to the CORBA object called
try{
“ShapeList”, using resolve and narrows it
ORB orb = ORB.init(args, null);
org.omg.CORBA.Object objRef =
orb.resolve_initial_references("NameService");
it uses
one ofinthe
remote
references
in the
array
to
it invokes
the
allShapes
method
the
CORBA
object
to
get
an
array
NamingContext ncRef
= NamingContextHelper.narrow(objRef);
invoke
thetogetAllState
method in the corresponding
containing
remote references
all of the GraphicalObjects
currently
NameComponent
nc
=
new
NameComponent("ShapeList",
"");
CORBA object whose type is Shape
stored
by the serverpath
NameComponent
[] = { nc };
the value returned is of type GraphicalObject
ShapeList shapeListRef =
ShapeListHelper.narrow(ncRef.resolve(path));
Shape[] sList = shapeListRef.allShapes();
GraphicalObject g = sList[0].getAllState();
} catch(org.omg.CORBA.SystemException e) {...}
Figure 17.5
}
11
•
The main components of the CORBA architecture
Client
stubs/proxies
Skeletons
Dynamic
invocation
interface is designed to allow clients

The
CORBA
architecture
are
inadapter
the client
language.
ORB
core– these
Object
–skeleton
classes
(for
OO languages)
generated in the
In some applications
(e.g. browsers),
a client
without the are
appropriate
language
the
server
by
anbetween
IDL
compiler.
to invoke
in
CORBA
objects
– an
IDLmethods
compiler
forofthe
language
uses
an IDL
interface
to
Implementation
repository
–an
object
bridges
gap
The proxy
role
ofclass
the
ORB
core
isadapter
toaclient
that
ofthe
the
communication
module
of Figure
5.6.
may
need
tosimilar
invoke
method
in
a remote
object.
generate
one
of
the
following:
–remote
method
invocations
are
dispatched
viaprogramming
the appropriate
Interface
repository
CORBA
objects
with
IDL interfaces
and
activates
registered
servers
on
demand
and
locates
running
–
clients
and
objects
can
be
implemented
in
a
variety
of
In addition,
an
ORB
core
provides
an
interface
that
includes
the
following:
CORBA doesfor
notobject-oriented
allow
classes
for proxies
toclass
be downloaded
at run time servers
skeleton
to
a
particular
servant,
languages
the
of
a
proxy
the
programming
language
interfaces
of the
corresponding
servant
classes.
theasinterface
repository
provides
information
about
registered
IDL interfaces
to clients
uses
the
object
adapter
name
to register
and
activate
servers.
- operations
enabling
it
to
be
started
and
stopped;
inlanguages
Java
RMI.
procedural
languages
athis
set later.
ofreference
stub
–the
unmarshals
the procedures.
arguments
in requestmodules
messages
and–servers
that
require
More
–itfor
does
theit.skeleton
work
ofabout
the
remote
and despatcher
in Fig. 5.6
it
has
the
following
additional
components
compared
to
Figure
5.6
more
about
this
later
- operations
convert
between
remote
references
and
strings;
The dynamic
invocation
interface
is object
CORBA’s
alternative.
(we
will
discuss
and
marshals
exceptions
and
results
inarguments
reply
messages.
–toas
before,
the
client
stubs/proxies
marshal
the
in
–more
about
the
object
adapter
later.
object
implementation
repository
interface
repository
it laterwith
the adapter,
Interface
Repository)
invocation
requests
and
exceptions
and results
in replies.
- operations
to
provide
argument
listsunmarshal
for requests
usingand
dynamic
invocation.
client
client proxy
program for A
implementation
repository
ORB
core
or dynamic invocation
server
interface
repository
Request
object skeleton
adapter
ORB
core
Reply
Figure 17.6
or dynamic skeleton
12
Servant
A
•
Object adapter
 an object adapter bridges the gap between
– CORBA objects with IDL interfaces and
– the programming language interfaces of the corresponding servant (classes).
– it does the work of the remote reference and despatcher modules in Fig. 5.6.
 An object adapter has the following tasks:
– it creates remote object references for CORBA objects;
– it dispatches each RMI via a skeleton to the appropriate servant;
– it activates objects.
 An object adapter gives each CORBA object a unique object
name.
– the same name is used each time an object is activated.
 it is specified by the application program or generated by the object adapter.
– Each active CORBA object is registered with its object adapter,
 which keeps a remote object table to maps names of CORBA objects to servants.
 Each object adapter has its own name - specified by the
application program or generated automatically.
13
•
Implementation repository
 Implementation repository
– it activates registered servers on demand and locates running servers
– it uses the object adapter name to register and activate servers.
– it stores a mapping from the names of object adapters to the
pathnames of files containing object implementations.
 when a server program is installed it can be registered with the
implementation repository.
 when an object implementation is activated in a server, the hostname and
port number of the server are added to the mapping.
– Implementation repository entry:
object adapter pathname of object hostname and port number
of server
implementation
name
- not all CORBA objects (e.g. call backs) need be activated on demand
- access control information can be stored in an implementation repository
14
•
Interface repository
 it provides information about registered IDL interfaces
– for an interface of a given type it can supply the names of the methods and for
each method, the names and types of the arguments and exceptions.
– a facility for reflection in CORBA.
– if a client has a remote reference to a CORBA object, it can ask the interface
repository about its methods and their parameter types
– the client can use the dynamic invocation interface to construct an invocation
with suitable arguments and send it to the server.
 the IDL compiler gives a type identifier to each IDL type
 a type identifier is included in remote object references
 this type identifier is called the repository ID
– because the interface repository stoes interfaces against their IDs
 applications that use static invocation with client proxies and
IDL skeletons do not require an interface repository.
– Not all ORBs provide an interface repository.
15
•
CORBA IDL
 IDL provides facilities for defining modules,
interfaces, types, attributes and method signatures.
– examples of all of the above, except modules, in Figures 5.2 and 17.1.
 IDL has the same lexical rules as C++ but has
additional keywords to support distribution,
– for example interface, any, attribute, in, out, inout, readonly, raises.
 It allows standard C++ pre-processing facilities. e.g.
typedef for All in Figure 17.7.
 The grammar of IDL is a subset of ANSI C++ with
additional constructs to support method signatures.
16
•
IDL module Whiteboard
 Modules allow interfaces and associated definitions
to be grouped.
 A module defines a naming scope.
Figure 17.7
module Whiteboard {
struct Rectangle{
...} ;
struct GraphicalObject {
...};
interface Shape {
...};
typedef sequence <Shape, 100> All;
interface ShapeList {
...};
};
17
•
IDL method signatures
we saw raises in the newShape
method of ShapeList
[oneway] <return_type> <method_name> (parameter1,..., parameterL)
[raises (except1,..., exceptN)]
[context (name1,..., nameM)]
 each parameter is labelled as in, out or inout, e.g.
– void getPerson(in string name, out Person p);
 oneway e.g. oneway void callback(in int version)
– the client will not be blocked and maybe semantics is used
– at-most-once call semantics is the default
 Inheritance - IDL interfaces may extend one or more
interfaces
– all IDL interfaces are compatible with Object
 ee can use type Object for parameters that may be of any type e.g. bind and
resolve in the Naming Service
– an extended interface may add new methods, types, constants and
exceptions
– It may redefine types, constants and exceptions but not methods
18
•
Figure 17.8
IDL constructed types – 1
Type
Examples
Use
sequence
typedef sequence <Shape, 100> All;
typedef sequence <Shape> All
bounded and unbounded sequences
of Shapes
String name;
typedef string<8> SmallString;
unbounded and bounded
sequences of characters
Defines a type for a variable-length
sequence of elements of a specified
IDL type. An upper bound on the
length may be specified.
Defines a sequences of characters,
terminated by the null character. An
upper bound on the length may be
specified.
typedef octet uniqueId[12];
typedef GraphicalObject GO[10][8]
Defines a type for a multi-dimensional
fixed-length sequence of elements of a
specified IDL type.
string
array
this figure continues on the next slide
See Fig 5.1 for an example of string
19
•
Figure 17.8
IDL constructed types – 2
Type
Examples
Use
record
struct GraphicalObject {
string type;
Rectangle enclosing;
boolean isFilled;
};
Defines a type for a record containing a
group of related entities. Structs are
passed by value in arguments and
results.
enumerated
enum Rand
(Exp, Number, Name);
The enumerated type in IDL maps a
type name onto a small set of integer
values.
union
union Exp switch (Rand) {
case Exp: string vote;
case Number: long n;
case Name: string s;
};
The IDL discriminated union allows
one of a given set of types to be passed
as an argument. The header is
parameterized by an enum, which
specifies which member is in use.
20
•
17.2.4 CORBA remote object references
 'interoperable object references' (IORs) – CORBA 2.0

– suitable whether or not the object is activatable.
Transient IORs are for objects that last as long as the host process
– they contain the address of the server hosting the CORBA object
 The server ORB core receives the request message containing the object adapter
name and object name of the target. It uses the object adapter name to locate the
object adapter, which uses the object name to locate the servant.

Persistent IORs last between activations
– they contain the address of the implementation repository
– the implementation repository receives the request and uses the object
adapter name to activate the object, then gives the server address to the client
– the client sends subsequent invocations to the server
IOR format
Page 684
IDL interface type name Protocol and address details
Object key
interface repository
identifier
adapter name
IIOP host domain
name
port number
21
object name
•
CORBA services include the following
 Naming Service (it would be a good idea to study it!)
 Event Service and Notification Service:
– in ES suppliers and consumers communicate via an event channel
– NS extends this to allow filtering and typed events
 Security service:
– authentication of principals and access control of CORBA objects with policies
– auditing by servers, facilities for non-repudiation
 Trading service:
– allows CORBA objects to be located by attribute
 Transaction service and concurrency control service
– TS provides flat or nested transactions
– CCS provides locking of CORBA objects
 Persistent object service:
– for storing the state of CORBA objects in a passive form and retrieving it
22
•
Summary
 CORBA addresses heterogeneity:
– RMI between a client and a remote remote object in different languages.
– GIOP
 specifies an external data representation called CDR – clients and servers can
have different hardware.
 specifies OS independent operations for request-reply protocol
 specifies a standard form for remote object references.
– IIOP implements the request-reply protocol over TCP/IP.
 Object adapter
– relates request messages to implementations of CORBA objects
 Implementation repository
– enables CORBA objects to be activated on demand
 Interface repository
– allows dynamic invocation of CORBA objects
 IDL for defining interfaces
23
•