CS 843 - Distributed Computing Systems
Chapter 17: CORBA
Chin-Chih Chang, chang@cs.twsu.edu
From Coulouris, Dollimore and Kindberg
Distributed Systems:
Concepts and Design
Edition 3, © Addison-Wesley 2001
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 (Common Object Request Broker
Architecture) is a specification of an architecture
supporting this.
• CORBA 1 in 1990 and CORBA 2 in 1996.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
CORBA RMI
•
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
o an external data representation, called CDR
o specifies formats for the messages in a request-reply
protocol including messages for enquiring about the
location of an object, for cancelling requests, and
for reporting errors.
4. The Internet Inter-ORB protocol (IIOP) defines a standard
form for remote object references.
• IIOP is GIOP implemented in TCP/IP
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
CORBA RMI
•
•
•
CORBA services are generic services useful in
distributed applications e.g. Naming Service, Event
Service.
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?)
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
CORBA Object Model
• The CORBA object has a model similar to the
remote object model in Chapter 5.
• Clients are not necessarily objects – 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.
 It has a remote object reference.
 Its methods can be invoked remotely.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
CORBA Object Model
• 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.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
CORBA IDL
• A CORBA interface specifies a name and a set of
methods that clients can request (Figure 17.1).
 Interfaces are used to specify the methods that clients
can request.
 Strucs are used to define the data structure used as
parameter types in defining the methods.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
Differences from a Java remote inteface?
Figure 17.1 CORBA IDLwhy
interfaces
Shape and types
ShapeList
are argument
defined in the IDL?
(not necerssary in Java remote interfaces)
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
by throw. They can have arguments.
Figure
17.1
extra out parameter of type
Shape.
No Dollimore
classes
can
Instructor’s
Guide for Coulouris,
and Kindberg
Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
be passed as arguments or results
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)
 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)
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
Parameters in CORBA IDL
• 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
• CORBA IDL allows exceptions to be defined in
interfaces and thrown by their methods.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
Parameters in CORBA IDL
• Implementations of CORBA provide some interfaces
to the functionality of the ORB called pseudoobjects.
• ORB is the name of an interface that represents the
functionality of the ORB that programmers need to
access:
 The method init, which must be called to initialize the
ORB.
 The method connect, which is used to register CORBA
objects with the ORB.
 Other methods, which enable conversions between
remote object references and strings.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
Parameters in CORBA IDL
• Remote invocation in CORBA:
 At-most-once call semantics is the default.
 Maybe semantics by using the oneway keyword. This is
only used for methods without results.
• The CORBA Naming Service 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))
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
CORBA Pseudo Objects
• ORB is the name of an interface that represents the
functionality of the ORB that programmers need to
use. It includes:
 The method init, which must be called to initialise the
ORB.
 The method connect, which is used to register CORBA
objects with the ORB.
 Other methods, which enable conversions between
remote object references and strings.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
CORBA Client and Server Example
• The Hello Client-Server Example.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 17.2
Java interface ShapeList generated by idltojava from CORBA interface ShapeList
public interface ShapeList extends org.omg.CORBA.Object {
Shape newShape(GraphicalObject g) throws ShapeListPackage.FullException;
Shape[] allShapes();
int getVersion();
}
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
CORBA Naming Service
• 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
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
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
o
o
o
o
o
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 {
Consider
resolve in the naming service, we ask it to look up
Shape newShape(GraphicalObject g) throws ShapeListPackage.FullException;
a reference
to ShapeList, it returns an Object. What is the problem?
Shape[] allShapes();
int getVersion();
}
Figure 17.2
What is the problem with out arguments in Java?
e.g. void getPerson(in string name, out Person p);
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
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() { ... }
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
}
© Addison-Wesley Publishers 2000
•
Figure 17.4 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
}
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
}
Figure 17.5 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
}
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
CORBA ORB Architecture (17.2.2)
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
CORBA ORB Architecture
• Object - This is a CORBA programming entity that
consists of an identity, an interface, and an
implementation, which is known as a Servant.
• Servant - This is an implementation programming
language entity that defines the operations that
support a CORBA IDL interface. Servants can be
written in a variety of languages, including C, C++,
Java, Smalltalk, and Ada.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
CORBA ORB Architecture
• Object - This is a CORBA programming entity that
consists of an identity, an interface, and an
implementation, which is known as a Servant.
• Servant - This is an implementation programming
language entity that defines the operations that
support a CORBA IDL interface. Servants can be
written in a variety of languages, including C, C++,
Java, Smalltalk, and Ada.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
CORBA ORB Architecture
• Client
 This is the program entity that invokes an operation on an
object implementation.
 Accessing the services of a remote object should be
transparent to the caller. Ideally, it should be as simple as
calling a method on an object, i.e., obj->op(args). The
remaining components in the Figure help to support this
level of transparency.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
CORBA ORB Architecture
• Object Request Broker (ORB):
 The ORB provides a mechanism for transparently
communicating client requests to target object
implementations.
 The ORB simplifies distributed programming by
decoupling the client from the details of the method
invocations.
 This makes client requests appear to be local procedure
calls. When a client invokes an operation, the ORB is
responsible for finding the object implementation,
transparently activating it if necessary, delivering the
request to the object, and returning any response to the
caller.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
CORBA ORB Architecture
• ORB Interface
 An ORB is a logical entity that may be implemented in
various ways (such as one or more processes or a set of
libraries).
 To decouple applications from implementation details, the
CORBA specification defines an abstract interface for an
ORB.
 This interface provides various helper functions such as
converting object references to strings and vice versa, and
creating argument lists for requests made through the
dynamic invocation interface described below.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
CORBA ORB Architecture
• Dynamic Invocation Interface (DII)
 This interface allows a client to directly access the
underlying request mechanisms provided by an ORB.
 Applications use the DII to dynamically issue requests to
objects without requiring IDL interface-specific stubs to be
linked in.
 Unlike IDL stubs (which only allow RPC-style requests),
the DII also allows clients to make non-blocking deferred
synchronous (separate send and receive operations) and
oneway (send-only) calls.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
CORBA ORB Architecture
• Dynamic Skeleton Interface (DSI)
 This is the server side's analogue to the client side's DII.
 The DSI allows an ORB to deliver requests to an object
implementation that does not have compile-time
knowledge of the type of the object it is implementing.
 The client making the request has no idea whether the
implementation is using the type-specific IDL skeletons or
is using the dynamic skeletons.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
CORBA ORB Architecture
• Object Adapter
 This assists the ORB with delivering requests to the object
and with activating the object. More importantly, an object
adapter associates object implementations with the ORB.
 Object adapters can be specialized to provide support for
certain object implementation styles (such as OODB
object adapters for persistence and library object adapters
for non-remote objects).
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
The Architecture of CORBA (Textbook)
• CORBA makes the distinction between static and
dynamic invocations.
 Static invocations are used when the remote interface of
the CORBA object is known at compile time, enabling
client stubs and server skeletons to be used.
 If the remote interface is not known at compile time,
dynamic invocation must be used.
 Most programmers prefer to use static invocation because
it provides a more natural programming model.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
The Architecture of CORBA
• CORBA Primary components in CORBA:




ORB core
Object adapter
Skeletons
Client stubs/proxies
• ORB core is the communication module for the
CORBA object and provides an interface including:
 operations enabling it to be started and stopped;
 operations to convert between remote object references
and strings;
 operations to provide argument lists for requests using
dynamic invocation.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Object Request Broker (ORB)
• On client side the ORB is responsible for
 accepting requests for a remote object
 finding implementation of the object
 accepting client-side reference to the remote object(converted to a
language specific form, e.g., a Java stub object)
 routing client method calls through the object reference to the object
implementation
• On server side the ORB




lets object servers register new objects
receives requests from the client ORB
uses object’s skeleton interface to invoke object’s activation method
creates reference for new object and sends it back to client
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 17.6
The main components of the CORBA architecture
client
client proxy
program for A
implementation
repository
Request
ORB
core
Reply
or dynamic invocation
server
interface
repository
object skeleton
adapter
ORB
core
or dynamic skeleton
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
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 dispatcher modules in
Fig. 5.6.
• An object adapter has the following tasks:
 it creates remote object references for CORBA objects;
 Each object adapter provides access to those services of an ORB
(such as activation, deactivation, object creation, object reference
management) used by a particular type of object implementation.
o it dispatches each RMI via a skeleton to the appropriate servant;
o it activates objects.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
Object Adapter
• An object adapter gives each CORBA object a
unique object name.
 the same name is used each time an object is activated.
o it is specified by the application program or generated by the object
adapter.
 Each active CORBA object is registered with its object
adapter,
o 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.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
The Architecture of CORBA (Textbook)
• Skeleton classes are generated in the language of
the server by an IDL compiler. Remote invocations
are dispatched via the appropriate skeleton to a
particular servant.
• The class of a proxy or a set of stub procedures is
generated from an IDL interface by an IDL compiler
for the client language.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
Static vs. Dynamic Invocation
• Static Invocation
 Static interfaces are generated in form of client stubs by the IDL (pre-)
compiler.
 This means that the structure of the object has to be known before
hand (at compile time).
 Allows for better type checking; less runtime overhead; selfdocumentation.
• Dynamic Invocation
 Dynamic Invocation Interface (DII) allows clients to invoke operations
on remote objects without having access to object stubs (another way
to do this without dynamic invocation is to download static client stubs
via a Java applet).
 Clients must discover interface-related information at runtime (e.g.,
using the interface repository)
 Servers can offer new services anytime without the need for
recompilation on the client side.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
Dynamic Requests
• The Dynamic Invocation Interface (DII) allows clients to
dynamically:





discover objects;
discover objects’ interfaces;
create requests;
invoke requests;
receive responses.
• Major features of Dynamic Invocation Interface:




requests appear as objects themselves;
requests are reusable;
invocation may be synchronous or asynchronous;
requests may be generated dynamically, statically or in combination
approach.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
Implementation repository
• Implementation repository (Server)
 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.
o when a server program is installed it can be registered
with the implementation repository.
o when an object implementation is activated in a server,
the hostname and port number of the server are added
to the mapping.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
Implementation repository
• Implementation repository
 Implementation repository entry:
 Not all CORBA objects (e.g. call backs) need be activated
on demand
 Access control information can be stored in an
implementation repository
object adapter pathname of object hostname and port number
of server
implementation
name
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
Interface Repository (Client)
• 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.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
Interface Repository
• 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.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
Summary of CORBA Interfaces
Implementation
Installation
IDL Interface
Definitions
Interface
Repository
Accesses
Client
Stubs
Includes
Client
Implementation
Skeletons
Implementation
Repository
Describes
Includes
Object Implementation
• All objects are defined in IDL by specifying their interfaces.
• Object definitions (interfaces) are manifested as objects in
the Interface Repository, as client stubs, and as
implementation skeletons.
• Descriptions of object implementations are maintained as
objects in the Implementation Repository
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
OMG IDL
• OMG Interface Definition Language (IDL):





mappings for many languages/compilers;
independent of any particular language/compiler;
multiple-inheritance, public interface-structured specification language;
not for implementation.
primary support for interoperability between static and dynamic
requests mechanisms.
Module auction {
exception NotAllowed {};
• IDL Structure
 Module
o a namespace
 Interface
o abstract type
o multiple inheritance
 Struct
o structured data
struct Sale {
int price;
string item;
}
interface Auction {
void bid (in long price)
raises NotAllowed;
}
}
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
CORBA IDL (17.2.3)
• 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.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
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 {
...};
}; Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design
Instructor’s
© Addison-Wesley Publishers 2000
Edn. 3
•
Figure 17.7
IDL module Whiteboard
module Whiteboard {
struct Rectangle{
...} ;
struct GraphicalObject {
...};
interface Shape {
...};
typedef sequence <Shape, 100> All;
interface ShapeList {
...};
};
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
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
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
IDL method signatures
we saw raises in the newShape
method of ShapeList
• Inheritance - IDL interfaces may extend one or more
interfaces
 all IDL interfaces are compatible with Object
o 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
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
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
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
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.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
Internet Inter-Orb Protocol (IIOP)
• CORBA specification is neutral with respect to network protocols
 the CORBA standard specifies what is known as the General Inter-ORB
Protocol (GIOP)
 GIOP is a high-level standard protocol for communication between ORBs
 not used directly; instead, it is specialized by a particular protocol that would
then be used directly
• Internet Inter-ORB Protocol (IIOP)
 IIOP is the GIOP-based protocol for TCP/IP networks
 As of the 2.0 version of the CORBA specification, vendors are required to
implement the IIOP protocol
• CORBA Networking Model
 CORBA applications are built on top of GIOP-derived protocols such as IIOP
 these protocols, in turn, rest on top of TCP/IP, DCE, or other underlying
transport protocol the network uses
 an application architecture can be designed to use a bridge that would
interconnect, for instance, DCE-based application components with IIOPbased ones.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
CORBA remote object references
• Interoperable Object References (IOR)
 An IOR is an object reference that is understood by ORBs
that can interoperate using the OMG-defined protocols
General Inter-ORB Protocol (GIOP) and Internet InterORB Protocol (IIOP).
 A client can obtain an object reference using
orb.object_to_string(objRef), as shown in the Browsing the
Namespace example, or as a result of an invocation on
another object reference.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
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
o 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.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
17.2.4 CORBA remote object references
• 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
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
object name
•
OMG Reference Model Architecture
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
OMG Reference Model Architecture
• Object Services
 These are domain-independent interfaces that are used by
many distributed object programs. For example, a service
providing for the discovery of other available services is
almost always necessary regardless of the application
domain.
 Two examples of Object Services that fulfill this role are:
object
o The Naming Service -- which allows clients to find objects based on
names;
o The Trading Service -- which allows clients to find objects based on their
properties.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
OMG Reference Model Architecture
• Common Facilities
 Like Object Service interfaces, these interfaces are also
horizontally-oriented, but unlike Object Services they are
oriented towards end-user applications.
 An example of such a facility is the Distributed Document
Component Facility (DDCF), a compound document
Common Facility based on OpenDoc. DDCF allows for the
presentation and interchange of objects based on a
document model, for example, facilitating the linking of a
spreadsheet object into a report document.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
OMG Reference Model Architecture
• Domain Interfaces
 These interfaces fill roles similar to Object Services and
Common Facilities but are oriented towards specific
application domains.
 For example, one of the first OMG RFPs issued for
Domain Interfaces is for Product Data Management (PDM)
Enablers for the manufacturing domain. Other OMG RFPs
will soon be issued in the telecommunications, medical,
and financial domains.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
OMG Reference Model Architecture
• Application Interfaces
 These are interfaces developed specifically for a given
application. Because they are application-specific, and
because the OMG does not develop applications (only
specifications), these interfaces are not standardized.
 However, if over time it appears that certain broadly useful
services emerge out of a particular application domain,
they might become candidates for future OMG
standardization.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
CORBA services include the following
• 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
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
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
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
Figure 17.9
Naming graph in CORBA Naming Service
initial naming context
initial naming context
B
ShapeList
initial naming context
XX
P
V
C
D
E
R
Q
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
S
T
U
Figure 17.10
Part of the CORBA Naming Service NamingContext interface in IDL
struct NameComponent { string id; string kind; };
typedef sequence <NameComponent> Name;
interface NamingContext {
void bind (in Name n, in Object obj);
binds the given name and remote object reference in my context.
void unbind (in Name n);
removes an existing binding with the given name.
void bind_new_context(in Name n);
creates a new naming context and binds it to a given name in my context.
Object resolve (in Name n);
looks up the name in my context and returns its remote object reference.
void list (in unsigned long how_many, out BindingList bl, out BindingIterator bi);
returns the names in the bindings in my context.
};
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Figure 17.11
CORBA event channels
event channel
supplier
consumer
notification
notification
proxy consumer
notification
proxy supplier
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Flat or Nested Transactions
• A flat transaction is a transaction which conform to atomicity
and isolation.
 Atomicity means that a transaction cannot be half-done.
 Isolation means that each transaction must remain unique.
• A nested transaction is a transaction created within the scope
of another transaction.
 A nested transaction commits with respect to its parent transaction. If
a nested transaction commits, the effects of the commit are not
permanent until the parent transaction commits. If the parent
transaction aborts, the nested transaction is also aborted.
 Changes made within the nested transaction are invisible to the toplevel transaction until the nested transaction is committed.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
Summary
• The main component of CORBA is the Object
Request Broker or ORB, which allows clients written
in one language to invoke operations in remote
objects (called CORBA objects) written in another
language.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
Summary
• CORBA addresses other aspects of heterogeneity
as follows:
 The CORBA General Inter-ORB protocol (GIOP) includes
an external data representation called CDR.
o It makes it possible for clients and servers to communicate
irrespective of their hardware.
o It also specifies a standard form for remote object references.
 GIOP also includes a specification for the operations of
a request-reply protocol that can be used irrespective of
the underlying operating system.
 The Internet Inter-ORB Protocol (IIOP) implements the
request-reply protocol over TCP/IP. IIOP remote object
references include the domain name and port number of a
server.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
Summary
• A CORBA object implements the operations in an
IDL interface.
 All that clients need to know to access a CORBA object is
the operations available in its interface.
 The client program accesses CORBA objects via proxies
or stubs, which are generated automatically from their IDL
interfaces in the language of the client.
 Server skeletons for CORBA objects are generated
automatically from their IDL interfaces in the language of
the client.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
Summary
• The object adapter is an important component of
CORBA servers.
 Its role is to create remote object references and to relate
remote object references in request messages to the
implementations of CORBA objects.
• The CORBA architecture allows CORBA objects to
be activated on demand.
 This is achieved by a component called the
implementation repository (server object database),
which keeps a database of implementations indexed by
their object adapter names.
 When a client invokes a CORBA object, it can be activated
if necessary in order to carry out the invocation.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
Summary
• An interface repository is a database of IDL interface
definitions indexed by a repository ID, which is
included in IORs.
 An interface repository (client interface database) can be
used to get information about the methods in the interface
of a CORBA object to allow dynamic method invocations.
• CORBA services provide functionality above RMI,
which may be required by distributed applications,
allowing them to use additional services such as
naming and directory services, event notifications,
transactions or security as required.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
•
Summary: CORBA Remote Method Invocation
• Clients use “object interfaces” through language mapping
 Java clients should work on any ORB that supports the Java language
bindings.
 Clients can call any object instance remotely, so long as the object
instance implements the interface.
• Clients can call remote objects statically or dynamically
 The server cannot tell whether the client is using static or dynamic
invocation.
• Objects are identified using a unique id: Interoperable Object
Reference (IOR)
 CORBA passes objects by reference
 IOR was Introduced in CORBA 2.0
 Object references can be converted to strings and back to “live”
objects via ORB interface functions.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Steps in Developing CORBA Applications
• Write specification for each object using IDL
• Use IDL Compiler (e.g., idlj, idl2java) to generate:
 Client Stub code
 Server Skeleton code
•
•
•
•
•
Write the client (in Java, can be applications or applets)
Write the server object implementation code (the “servant”)
Compile the client and server code
Start the server
Run the client application
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Data Types in CORBA IDL
• Basic Types
• short, long, unsigned long, unsigned short, float, double, long double,
char, wchar, boolean, string, octet, etc.
• Constructed Types
• struct and union (similar to C++; can be used in conjunction with a
typedef)
• sequence (variable sized arrays of objects)
• any (generic type which represents any possible IDL types; similar to the
Java Object type)
• enum (enumerated type with named integer values)
• arrays
• valuetypes (similar to interfaces; preceded with keyword valuetype to
provide pass-by-value semantics)
• Each CORBA IDL data type gets mapped to a native data type
via the appropriate language binding (e.g, IDL-to-Java
mapping).
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Data Types in CORBA IDL
module HelloApp {
interface Hello {
string sayHello();
};
};
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
What Does the IDL Compiler Generate?
Hello.idl
Implementation Skeleton
Client Stub
idlj
Client-Side
Server-Side
_HelloStub.java
HelloHelper.java
HelloHolder.java
_HelloImplBase.java
Hello.java
_HelloOperations.java
Note: these source files will be a part of the Java package Hello and will be placed in
a directory with the same name.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Data Types in CORBA IDL
• _HelloImplBase.java - This abstract class is the server
skeleton, providing basic CORBA functionality for the
server. It implements the Hello.java interface. The
server class HelloServant extends _HelloImplBase.
• _HelloStub.java - This class is the client stub,
providing CORBA functionality for the client. It
implements the Hello.java interface.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Data Types in CORBA IDL
• _Hello.java - This signature interface contains the
Java version of our IDL interface. The Hello.java
interface extends org.omg.CORBA.Object, providing
standard CORBA object functionality. It also extends
IDLEntity, and is used as the signature type in method
declarations when interfaces of the specified type are
used in other interfaces.
• HelloHelper.java - This final class provides auxiliary
functionality, notably the narrow() method required to
cast CORBA object references to their proper types.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000
Data Types in CORBA IDL
• HelloHolder.java - This final class holds a public
instance member of type Hello. It provides operations
for out and inout arguments, which CORBA allows, but
which do not map easily to Java's semantics.
• HelloOperations.java - This operations interface
contains the single method sayHello(). The IDL-toJava mapping puts all of the operations defined on the
IDL interface into this file. The operations interface is
used in the server-side mapping and as a mechanism
for providing optimized calls for co-located clients and
servers.
Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3
© Addison-Wesley Publishers 2000