Teaching material 

based on Distributed 
Systems: Concepts 
and Design, Edition 3,  Distributed Systems Course
Addison­Wesley 2001. 

CORBA case study

Copyright © George  17.1 Introduction

Coulouris, Jean Dollimore, 
Tim Kindberg 2001 
email: authors@cdk2.net 17.2 CORBA RMI
This material is made 
available for private study 
and for direct use by 
17.2.1 Client and server example
individual teachers.
It may not be included in any  17.2.2 Architecture
product or employed in any 
service without the written  17.2.3 CORBA IDL
permission of the authors.
17.2.4 CORBA object references
Viewing: These slides 
must be viewed in 
slide show mode.
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 •
 Don't be put off by GIOP and IIOP
Introduction to CORBA 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 is just about external data representation
data representation, called CDR
and a Request­reply protocol 
 specifies formats for the messages in a request-reply protocol.
• includingallowing for objects to be activated
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 remoteIIOP is just about remote object references
object references.
• IIOP is GIOP implemented in TCP/IP
 CORBA services - generic services useful in distributed
The architecture allows for mixed languages
applications e.g. Naming Service, Event Service.
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 passed4 as arguments.
•
 Differences from a Java remote inteface?
CORBA IDL interfaces Shape and ShapeList
why are argument types defined in the IDL?
(not necerssary in Java remote interfaces)
struct Rectangle{ struct GraphicalObject {
long width;  string type; 
long height; Rectangle enclosing; 
long x; boolean isFilled;
long y; this struct is used in  };
} ; defining another struct.  this struct is used as a parameter or result 
type in methods in the remote  interfaces. 
interface Shape {
long getVersion() ;
GraphicalObject getAllState() ;  // returns state of the GraphicalObject
}; an interface specifies a name and a set of methods

typedef sequence <Shape, 100> All;  sequences and arrays in typedefs
interface ShapeList {
exception FullException{ };  interface ShapeList
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 classes can 
be passed as arguments or results
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 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 {
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);
8 •
The ShapeListServant class of the Java server program for the
CORBA interface ShapeList. Figure 17.3

import org.omg.CORBA.*; This class has to create CORBA objects
 A Java server has classes for its
IDL interfaces (e.g. Shape and
 of type Shape. How does it do that?
class ShapeListServant extends _ShapeListImplBase {
ShapeList). Here is the class
ORB theOrb;
private Shape theList[]; ShapeListServant
a servant class extends the corresponding
private int version;
private static int n=0; skeleton class (e.g. ShapeListImplBase)
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
objects can’t be classes. What might they be in C?
public Shape newShape(GraphicalObject g) throws ShapeListPackage.FullException {
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);
         return s;        
interface (ShapeList). newShape is a factory
      } method. It creates new CORBA objects. It uses the
public  Shape[] allShapes(){ ... } connect method to inform the ORB about the new
public int getVersion() { ... } CORBA object. (it has a remote reference module)
} 9 •
 Java class ShapeListServer (the server class)
import org.omg.CosNaming.*; The server class contains the main method
• itimport org.omg.CosNaming.NamingContextPackage.*;
gets a reference to the Naming Service
• narrows it to NamingContext- from Object
import org.omg.CORBA.*;
• public class ShapeListServer {
makes a NameComponent containing the it creates and initialises the ORB
name public static void main(String args[]) {
“ShapeList”
• makes a try{path
ORB orb = ORB.init(args, null);                       
– uses rebind to register the name and object
                
reference ShapeListServant shapeRef = new ShapeListServant(orb);     
  orb.connect(shapeRef);                       
                         it creates an instance of ShapeListServant class - a Java
org.omg.CORBA.Object objRef = 
object - which is made a CORBA object
  orb.resolve_initial_references("NameService");  
by using the connect method to register it with        the ORB
  NamingContext ncRef = NamingContextHelper.narrow(objRef);
NameComponent nc = new NameComponent("ShapeList", "");
NameComponent path[] = {nc};
ncRef.rebind(path, shapeRef);                                           
it waits for client requests
  
java.lang.Object sync = new java.lang.Object(); Figure 17.4
synchronized (sync) {   sync.wait();}
10 •
Java client program for CORBA interfaces Shape and
ShapeList

import org.omg.CosNaming.*;
• it contacts the NamingService for initial context
import org.omg.CosNaming.NamingContextPackage.*;
import org.omg.CORBA.*; • Narrows it to NamingContext
it creates and initialises an ORB
public class ShapeListClient{ • It makes a name component
• It makes a path
public static void main(String args[]) {
try{ • It gets a reference to the CORBA object called
“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
NamingContext ncRef = NamingContextHelper.narrow(objRef); to get an array
containing remote invoke thetogetAllState
references all of the method in the corresponding
GraphicalObjects currently
NameComponent nc = new NameComponent("ShapeList", "");
stored by the server CORBA object whose type is Shape
NameComponent path [] = { 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

DynamicClient stubs/proxies
Skeletons
invocation interface is designed to allow clients

ORB The CORBA
core– these
Object
are architecture
inadapter
the client
–skeleton language.
classes (for OO languages)
without the are generated in the
In some applications (e.g. browsers), a client appropriate
to invoke
The proxy
role ofclass
the ORB IDLmethods
Implementation
– an –may
an language
compiler
object
core
need isadapter
tosimilar
invoke
in
forofthe
the
repository CORBA
bridgesserver
client
toathat ofthe
method
by
language
thegap
in
objects
an between
IDL compiler.
uses
communication
a remote an IDL
object. interface
module to
of Figure 5.6.
Interface –
In addition, repository
generate
clients
an
CORBA doesfor
and
ORB  one
–remote
objects
activates
CORBA
core
of
provides
notobject-oriented
allow
the
can
registered following:
method
objects
classes be
an with
for
invocations
implemented
servers on
IDL interfaces
interface
proxies that
to be
are
demand indispatched
and aand
includes variety
downloaded locates
the viaprogramming
of the appropriate
running
following:
at run time servers
skeleton to a particular
languages servant,
the class ofofa the
proxy
inlanguages
theasinterface the programming
repository
uses provides language
information interfaces
about registered corresponding
IDL interfaces servant classes.
to clients
- operations Javaenabling
RMI. it the
to beobject adapter
started and name
stopped; to register and activate servers.
and–servers –it for
that –the
procedural
require
does the languages
it.skeleton
More
work of about
the athis
unmarshalssetlater.
remote ofreference
stub
the procedures.
arguments
and in requestmodules
despatcher messages
- operations it has
The dynamic the
–toas more
convert following
invocation
andabout
between additional
this later
remote
interface
marshals is components
object
CORBA’s
exceptions references
and compared
resultsand
alternative. in strings;
(we
reply to
will Figure
discuss
messages. 5.6 in Fig. 5.6
before,
–more the client
about the objectstubs/proxies
adapter marshal the arguments in
later.
- operations

it later withobject
to provide adapter,
the Interface
invocation requests
argument implementation
Repository)
and
listsunmarshal repository
for requests usingand
exceptions 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 •
 The OA has a remote object reference 
Object adapter and a method to be invoked on it
 an object adapter bridges What does dispatch do in C++/Java?
the gap between
What does dispatch in C?
– 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 •
 Suppose there was a constructor,
there are no constructors in IDL,
CORBA IDL
what would be the problem for a server
so how do we create CORBA objects?
e.g. being asked to create an instance of a given class?
 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.

module Whiteboard {
Figure 17.7 struct Rectangle{
...} ;
struct GraphicalObject {
...};
interface Shape {
...};
typedef sequence <Shape, 100> All;
interface ShapeList {
...};
}; 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 typedef sequence <Shape, 100> All; Defines a type for a variable­length
typedef sequence <Shape> All sequence of elements of a specified   
bounded and unbounded sequences IDL type.  An upper bound on the
of Shapes length may be specified.
string String name;  Defines a sequences of characters,
typedef string<8> SmallString;  terminated by the null character. An
unbounded and bounded upper bound on the length may be
sequences of characters specified.

array typedef octet uniqueId[12]; Defines a type for a multi­dimensional

typedef GraphicalObject GO[10][8] fixed­length sequence of elements of a
specified IDL type.

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 {     Defines a type for a record containing a
string type;
     group of related entities.  Structs are
Rectangle enclosing;
     passed by value in arguments and
boolean isFilled;
   results.  
};
enumerated enum Rand      The enumerated type in IDL maps a
(Exp, Number, Name); type name onto a small set of integer
values.
union union Exp switch (Rand)  { The IDL discriminated union allows
 case Exp: string vote;
     one of a given set of types to be passed
case Number: long n;
     as an argument. The header is
case Name: string s; 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 IIOP host domain  port number adapter name  object name
identifier name   
21 •
Figure 17.9
Naming graph in CORBA Naming Service

initial naming context initial naming context initial naming context

ShapeList B XX V
P
C
D E S T
R Q U

22
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.
};
23
Figure 17.11
CORBA event channels

event channel
supplier consumer

notification notification notification

proxy consumer proxy supplier

24
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
25 •
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
26 •
Teaching material 
based on Distributed 
Systems: Concepts 
and Design, Edition 3, 
Addison­Wesley 2001.  Exercises for Chapter 17:
CORBA CASE STUDY

Copyright © George 
Coulouris, Jean Dollimore, 
Tim Kindberg 2001 
From Coulouris, Dollimore and Kindberg
email: authors@cdk2.net
This material is made  Distributed Systems:
available for private study 
and for direct use by 
individual teachers.
Concepts and Design
It may not be included in any 
product or employed in any  Edition 3, © Addison-Wesley 2001
service without the written 
permission of the authors.

Viewing: These slides 
must be viewed in 
slide show mode.
Exercise 17.1

 The Task Bag is an object that stores pairs of (key and value). A key is a
string and a value is a sequence of bytes. Its interface provides the
following remote methods:
pairOut: with two parameters through which the client specifies a key and a value to be
stored.
pairIn: whose first parameter allows the client to specify the key of a pair to be removed
from the Task Bag. The value in the pair is supplied to the client via a second
parameter. If no matching pair is available, an exception is thrown.
readPair: is the same as pairIn except that the pair remains in the Task Bag.
Use CORBA IDL to define the interface of the Task Bag. Define an
exception that can be thrown whenever any one of the operations cannot
be carried out. Your exception should return an integer indicating the
problem number and a string describing the problem. The Task Bag
interface should define a single attribute giving the number of tasks in the
bag. page 680

28
Exercise 17.2

 Define an alternative signature for the methods

pairIn and readPair, whose return value indicates
when no matching pair is available. The return
value should be defined as an enumerated type
whose values can be ok and wait. Discuss the
relative merits of the two alternative approaches.
Which approach would you use to indicate an error
such as a key that contains illegal characters?
page 680

29
Exercise 17.3

 Which of the methods in the Task Bag interface

could have been defined as a oneway operation?
Give a general rule regarding the parameters and
exceptions of oneway methods. In what way does
the meaning of the oneway keyword differ from the
remainder of IDL?
page 680

30
Exercise 17.4

 The IDL union type can be used for a parameter that

will need to pass one of a small number of types.
Use it to define the type of a parameter that is
sometimes empty and sometimes has the type
Value.
page 683

31
Exercise 17.5

 In Figure 17.1 the type All was defined as a

sequence of a fixed length. Redefine this as an
array of the same length. Give some
recommendations as to the choice between arrays
and sequences in an IDL interface.
page 683

32
Exercise 17.6

 The Task Bag is intended to be used by cooperating

clients, some of which add pairs (describing tasks)
and others remove them (and carry out the tasks
described). When a client is informed that no
matching pair is available, it cannot continue with its
work until a pair becomes available. Define an
appropriate callback interface for use in this
situation.
page 677

33
Exercise 17.7

 Describe the necessary modifications to the Task

Bag interface to allow callbacks to be used.
page 677

34
Exercise 17.8

 Which of the parameters of the methods in the

TaskBag interface are passed by value and which
are passed by reference?
page 672

35
Exercise 17.9

 Use the Java IDL compiler to process the interface

you defined in Exercise 17.1. Inspect the definition
of the signatures for the methods pairIn and
readPair in the generated Java equivalent of the IDL
interface. Look also at the generated definition of the
holder method for the value argument for the
methods pairIn and readPair. Now give an example
showing how the client will invoke the pairIn method,
explaining how it will acquire the value returned via
the second argument.
page 685

36
Exercise 17.10

 Give an example to show how a Java client will

access the attribute giving the number of tasks in the
Task bag object. In what respects does an attribute
differ from an instance variable of an object?
page 682

37
Exercise 17.11

 Explain why the interfaces to remote objects in

general and CORBA objects in particular do not
provide constructors. Explain how CORBA objects
can be created in the absence of constructors.
Chapter 5 and page 684

38
Exercise 17.12

 Redefine the Task Bag interface from Exercise 17.1

in IDL so that it makes use of a struct to represent a
Pair, which consists of a Key and a Value. Note that
there is no need to use a typedef to define a struct.
page 683

39
Exercise 17.13

 Discuss the functions of the implementation

repository from the point of view of scalability and
fault tolerance.
page 679 and page 684

40
Exercise 17.14

 To what extent may CORBA objects be migrated

from one server to another?
page 679 and page 684

41
Exercise 17.15

 Discuss the benefits and drawbacks of the two-part

names or NameComponents in the CORBA naming
service.
page 688

42
Exercise 17.16

 Give an algorithm that describes how a multipart

name is resolved in the CORBA naming service. A
client program needs to resolve a multipart name
with components “A”, “B” and “C”, relative to an
initial naming context. How would it specify the
arguments for the resolve operation in the naming
service?
page 688

43
Exercise 17.17

 A virtual enterprise consists of a collection of

companies who are cooperating with one another to
carry out a particular project. Each company wishes
to provide the others with access to only those of its
CORBA objects relevant to the project. Describe an
appropriate way for the group to federate their
CORBA Naming Services.
page 690

44
Exercise 17.18

 Discuss how to use directly connected suppliers and consumers of the

CORBA event service in the context of the shared whiteboard application.
The PushConsumer and PushSupplier interfaces are defined in IDL as
follows:
interface PushConsumer {
void push(in any data) raises (Disconnected);
void disconnect_push_consumer();
}
interface PushSupplier {
void disconnect_push_supplier();
}
Either the supplier or the consumer may decide to terminate the event
communication by calling disconnect_push_supplier() or
disconnect_push_consumer() respectively. page 690

45
Exercise 17.19 (first part)

 Describe how to interpose an Event Channel between the supplier and the
consumers in your solution to Exercise 17.18. An event channel has the following
IDL interface:
interface EventChannel {
ConsumerAdmin for_consumers();
SupplierAdmin for_suppliers();
};
where the interfaces SupplierAdmin and ConsumerAdmin, which allow the supplier
and the consumer to get proxies are defined in IDL as follows:
interface SupplierAdmin {
ProxyPushConsumer obtain_push_consumer();
---
};
interface ConsumerAdmin {
ProxyPushSupplier obtain_push_supplier();
---
};

46
Exercise 17.19 continued

 The interface for the proxy consumer and procy supplier are
defined in IDL as follows:
interface ProxyPushConsumer : PushConsumer{
void connect_push_supplier (in PushSupplier supplier)
raises (AlreadyConnected);
};
interface ProxyPushSupplier : PushSupplier{
void connect_push_consumer (in PushConsumer consumer)
raises (AlreadyConnected);
};

What advantage is gained by the use of the event channel?

page 690

47