You are on page 1of 23

Teachingmaterial

basedonDistributed
Systems:Concepts
andDesign,Edition3, Distributed Systems Course
AddisonWesley2001.

CORBA case study

CopyrightGeorge 17.1 Introduction


Coulouris,JeanDollimore,
TimKindberg2001
email:authors@cdk2.net
17.2 CORBA RMI
Thismaterialismade
availableforprivatestudy
andfordirectuseby
17.2.1 Client and server example
individualteachers.
Itmaynotbeincludedinany 17.2.2 Architecture
productoremployedinany
servicewithoutthewritten 17.2.3 CORBA IDL
permissionoftheauthors.
17.2.4 CORBA object references
Viewing:Theseslides
mustbeviewedin 17.3 Services (just a summary)
slideshowmode.
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
Don't be put off by GIOP and IIOP
Introduction to CORBA
They are just names for familiar thin

The main components of CORBAs RMI framework are:


1. An interface definition language known as IDL.
2. An architecture.
3. The General Inter-ORB protocol (GIOP) defines
GIOPdata
an external is just about external
representation, called CDR data representatio
andformats
specifies a Request-reply
for the messages protocol
in a request-reply protocol.
including
allowing messages for enquiring
for objects toabout the location of an
be activated
object, for cancelling requests and for reporting errors.
4. The Internet Inter-ORB protocol (IIOP) defines a standard
form for remote object
IIOP is justreferences.
about remote object references
IIOP is GIOP implemented in TCP/IP
CORBA services - generic services useful in distributed
The
applications e.g. architecture
Naming allows
Service, Event for mixed
Service.
languages 3
and object activation (added to
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;
its mapping onto the implementation language.
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
structRectangle{ structGraphicalObject{
longwidth; stringtype;
longheight; Rectangleenclosing;
longx; booleanisFilled;
longy; this struct is used in };
}; defining another this struct is used as a parameter
struct. or result type in methods in the
interfaceShape{ remote interfaces.
longgetVersion();
GraphicalObjectgetAllState(); //returnsstateoftheGraphicalObject
}; an interface specifies a name and a set of methods

typedefsequence<Shape,100>All; sequences and arrays in typedefs


interfaceShapeList{
exceptionFullException{}; interface ShapeList
ShapenewShape(inGraphicalObjectg)raises(FullException);
AllallShapes(); //returnssequenceofremoteobjectreferences
longgetVersion();
}; parameter of newShape is an in
the Exceptions defined by raises
parameter and of type Graphical Object and set by throw. They can
Figurevalue
The return 17.1 is an extra out
have arguments.
parameter of type Shape. No classes can
5
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 recipients 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. (Its
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)

publicinterfaceShapeListextendsorg.omg.CORBA.Object{
ShapenewShape(GraphicalObjectg)throwsShapeListPackage.FullException;
Shape[]allShapes();
intgetVersion();
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 objec
importorg.omg.CORBA.*;
IDL interfaces (e.g. Shape and
of type Shape
classShapeListServantextends_ShapeListImplBase{ . HowHere
ShapeList).
does
is
itclass
the
do that?
ORBtheOrb;
privateShapetheList[]; ShapeListServant
a servant class extends the corresponding
privateintversion;
privatestaticintn=0; skeleton class (e.g. ShapeListImplBase)
publicShapeListServant(ORBorb){
theOrb=orb; CORBA objects are instances of servant
classes.
//initializetheotherinstancevariables
}
In non-OO languages implementations of CORBA
objects cant be classes. What might they be in C?
publicShapenewShape(GraphicalObjectg)throwsShapeListPackage.FullException{
version++;
Shapes=newShapeServant(g,version);
if(n>=100)thrownewShapeListPackage.FullException();
theList[n++]=s;
a servant class implements the methods in the
theOrb.connect(s);
returns;
interface (ShapeList). newShape is a factory
} method. It creates new CORBA objects. It uses the
publicShape[]allShapes(){...} connect method to inform the ORB about the new
publicintgetVersion(){...} CORBA object. (it has a remote reference module)
} 9
Java class ShapeListServer (the server class)
importorg.omg.CosNaming.*; The server class contains the main method
1. itimportorg.omg.CosNaming.NamingContextPackage.*;
gets a reference to the Naming Service
2. narrows it to NamingContext- from Object
importorg.omg.CORBA.*;
3. makes a NameComponent containing the
publicclassShapeListServer{ it creates and initialises the ORB
name ShapeList
publicstaticvoidmain(Stringargs[]){
4. makes a try{path
ORBorb=ORB.init(args,null);
5. uses rebind to register the name and object

reference ShapeListServantshapeRef=newShapeListServant(orb);
orb.connect(shapeRef);
it creates an instance of ShapeListServant class - a Java
object - which is made a CORBA object
org.omg.CORBA.ObjectobjRef=
by using the connect method to register it with
orb.resolve_initial_references("NameService"); the ORB
NamingContextncRef=NamingContextHelper.narrow(objRef);
NameComponentnc=newNameComponent("ShapeList","");
NameComponentpath[]={nc};
ncRef.rebind(path,shapeRef);
it waits for client requests

java.lang.Objectsync=newjava.lang.Object(); Figure 17.4
synchronized(sync){sync.wait();}
10
Java client program for CORBA interfaces Shape and
ShapeList

importorg.omg.CosNaming.*;
1. it contacts the NamingService for initial context
importorg.omg.CosNaming.NamingContextPackage.*;
importorg.omg.CORBA.*; 2. Narrows it to NamingContext
it creates and initialises an ORB
publicclassShapeListClient{ 3. It makes a name component
4. It makes a path
publicstaticvoidmain(Stringargs[]){
try{ 5. It gets a reference to the CORBA object called
ShapeList, using resolve and narrows it
ORBorb=ORB.init(args,null);
org.omg.CORBA.ObjectobjRef=
orb.resolve_initial_references("NameService");
it uses one ofinthe remote references in the array to
it invokes the allShapes method the CORBA object
NamingContextncRef=NamingContextHelper.narrow(objRef); to get an array
containing remote invoke thetogetAllState
references all of the method in the corresponding
GraphicalObjects currently
NameComponentnc=newNameComponent("ShapeList","");
stored by the server CORBA object whose type is Shape
NameComponentpath[]={nc};
the value returned is of type GraphicalObject
ShapeListshapeListRef=
ShapeListHelper.narrow(ncRef.resolve(path));
Shape[]sList=shapeListRef.allShapes();
GraphicalObjectg=sList[0].getAllState();
}catch(org.omg.CORBA.SystemExceptione){...}
} Figure 17.5
11
The main components of the CORBA architecture

DynamicClient stubs/proxies
Skeletons
invocation interface

ORB The CORBA
core Object
these are architecture
adapter
in the
skeletonclient is
language.
classes (for OOdesigned
languages) togenerated
are allow inclients
the
In some applications (e.g. browsers), a client without the appropriate
to invoke
The proxy
role an
ofclass
the ORB IDL
may
an methods
Implementation language
compiler
core
object
need isadapter
tosimilar
invoke in
repository
forofthe
the CORBA
server
toaclient
that
bridges ofthe
method by
language
thegap
in an objects
IDL compiler.
uses
communication
between
a remote an IDL
object. interface
module to
of Figure 5.6.
Interface
In addition,
CORBA repository
clientsgenerate
an ORB
does
and one
remote
activates
objects
core
not CORBA
allow
of the
registered
can
objects
provides
classes
following:
method
be
anwith
for
invocations
servers
implemented on
IDL interfaces
interface
proxies that
to be
are
demand in dispatched
anda and
includes locates
variety
the
downloaded ofvia the appropriate
running
programming
following:
at run time servers
uses skeleton
forobject-oriented toadapter
alanguages
particular servant,
the class ofofa the
proxy
inlanguages
theasinterface
- operations repository
enabling
Java RMI.

the
it the
toprogramming
provides
beobject
started language
information
and name
stopped;interfaces
about
to registered
register andcorresponding
IDL interfaces
activate servant
servers. classes.
to clients
andservers that for the
procedural
require
itmore
does languages
theit.skeleton
More
work ofabout
the athis
unmarshalsset later.
remote ofreference
stub
the procedures.
arguments in requestmodules
and despatcher messages in Fig. 5.6
- operations it has
The dynamic to the
convertfollowing
invocation
andabout
between additional
this
marshals later
remote
interface is components
object
CORBAs
exceptions and references compared
and
alternative.
results strings;
(we to
will Figure
discuss 5.6
asmore
before, the
about client
the stubs/proxies
object adapter marshal
later. theinarguments
reply messages. in
it laterwith
- operations object
to the adapter,
invocation
provideInterface
argumentimplementation
requests Repository)
and
listsunmarshal repository
for requests exceptions
using and interface
and results
dynamic repository
in replies.
invocation.

client server
implementation interface
repository repository object skeleton
adapter

client proxy Request ORB Servant


ORB
program for A core core A
Reply

or dynamic invocation
Figure 17.6 or dynamic skeleton
12
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


name implementation of server

- 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.

moduleWhiteboard{
Figure 17.7 structRectangle{
...};
structGraphicalObject{
...};
interfaceShape{
...};
typedefsequence<Shape,100>All;
interfaceShapeList{
...};
};
17
we saw raises in the newShape
IDL method signatures 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 typedefsequence<Shape,100>All; Definesatypeforavariablelength
typedefsequence<Shape>All sequenceofelementsofaspecified
boundedandunboundedsequences IDLtype.Anupperboundonthe
ofShapes lengthmaybespecified.
string Stringname; Definesasequencesofcharacters,
typedefstring<8>SmallString; terminatedbythenullcharacter.An
unboundedandbounded upperboundonthelengthmaybe
sequencesofcharacters specified.

array typedefoctetuniqueId[12]; Definesatypeforamultidimensional


typedefGraphicalObjectGO[10][8] fixedlengthsequenceofelementsofa
specifiedIDLtype.

thisfigurecontinuesonthenextslide
See Fig 5.1 for an example of string
19
Figure 17.8
IDL constructed types 2

Type Examples Use


record structGraphicalObject{ Definesatypeforarecordcontaininga
stringtype;
groupofrelatedentities.Structsare
Rectangleenclosing;
passedbyvalueinargumentsand
booleanisFilled;
results.
};
enumerated enumRand TheenumeratedtypeinIDLmapsa
(Exp,Number,Name); typenameontoasmallsetofinteger
values.
union unionExpswitch(Rand){ TheIDLdiscriminatedunionallows
caseExp:stringvote;
oneofagivensetoftypestobepassed
caseNumber:longn;
asanargument.Theheaderis
caseName:strings; parameterizedbyan enum,which
}; specifieswhichmemberisinuse.

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

IORformat Page 684


IDLinterfacetypename Protocolandaddressdetails Objectkey
interfacerepository IIOP hostdomain portnumber adaptername objectname
identifier name
21
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