+ All Categories
Home > Documents > Chapter 17-CORBA Case Study

Chapter 17-CORBA Case Study

Date post: 11-Apr-2015
Category:
Upload: api-3748895
View: 3,315 times
Download: 15 times
Share this document with a friend
47
Copyright © George Coulouris, Jean Dollimore, Tim Kindberg 2001 email: [email protected] t This material is made available for private study and for direct use by individual teachers. It may not be included in any product or employed in any service without the written permission of the authors. Viewing: These slides must be viewed in slide show mode. Teaching material based on Distributed Systems: Concepts and Design, Edition 3, Addison- Wesley 2001. Distributed Systems Course CORBA case study 17.1 Introduction 17.2 CORBA RMI 17.2.1 Client and server example 17.2.2 Architecture 17.2.3 CORBA IDL 17.2.4 CORBA object references 17.3 Services (just a summary)
Transcript
Page 1: Chapter 17-CORBA Case Study

Copyright © George Coulouris, Jean Dollimore, Tim Kindberg 2001 email: [email protected] material is made available for private study and for direct use by individual teachers.It may not be included in any product or employed in any service without the written permission of the authors.

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

Teaching material based on Distributed Systems: Concepts and Design, Edition 3, Addison-Wesley 2001.

Distributed Systems Course

CORBA case study

17.1 Introduction

17.2 CORBA RMI

17.2.1 Client and server example

17.2.2 Architecture

17.2.3 CORBA IDL

17.2.4 CORBA object references

17.3 Services (just a summary)

Page 2: Chapter 17-CORBA Case Study

2

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.

Page 3: Chapter 17-CORBA Case Study

3

Introduction to CORBA

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 data representation, called CDR 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

CORBA services - generic services useful in distributed applications e.g. Naming Service, Event Service.

Don't be put off by GIOP and IIOPThey are just names for familiar things

GIOP is just about external data representationand a Request-reply protocol allowing for objects to be activated

The architecture allows for mixed languagesand object activation (added to Figure 5.6)

IIOP is just about remote object references

Page 4: Chapter 17-CORBA Case Study

4

CORBA RMI

CORBA RMI is a multi-language RMI system. The programmer needs to learn the following new concepts:

– the object model offered by CORBA;– the interface definition language and its mapping onto the implementation

language. (e.g. a struct in IDL is mapped onto what in Java?)

CORBA's object model– similar to the remote object model in Chapter 5 (what are the main features?) – clients are not necessarily objects (why not?)– a client can be any program that

sends request messages to remote objects and receives replies.

The term CORBA object is used to refer to remote objects. – a CORBA object implements an IDL interface, has a remote object reference and

its methods can be invoked remotely.

A CORBA object can be implemented by a language without classes. – the class concept does not exist in CORBA.– therefore classes cannot be defined in CORBA IDL, which means that instances

of classes cannot be passed as arguments.

Page 5: Chapter 17-CORBA Case Study

5

CORBA IDL interfaces Shape and ShapeList

struct Rectangle{long width; long height;long x;long y;

} ;

struct GraphicalObject {string type; Rectangle enclosing; boolean isFilled;

};

interface Shape {long getVersion() ;GraphicalObject getAllState() ; // returns state of the GraphicalObject

};

typedef sequence <Shape, 100> All; interface ShapeList {

exception FullException{ }; Shape newShape(in GraphicalObject g) raises (FullException);All allShapes(); // returns sequence of remote object referenceslong getVersion() ;

};

Figure 17.1

an interface specifies a name and a set of methods

interface ShapeList

the parameter of newShape is an in parameter and of type Graphical Object The return value is an extra out parameter of type Shape. No classes can be passed as arguments or results

sequences and arrays in typedefs

Exceptions defined by raises and set by throw. They can have arguments.

this struct is used as a parameter or result type in methods in the remote interfaces.

this struct is used in defining another struct.

Differences from a Java remote inteface?

why are argument types defined in the IDL?(not necerssary in Java remote interfaces)

Page 6: Chapter 17-CORBA Case Study

6

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

Page 7: Chapter 17-CORBA Case Study

7

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

Page 8: Chapter 17-CORBA Case Study

8

Illustration of programming CORBA

We illustrate CORBA with a Java client and server The interface compiler is called idltojava

– when given an IDL interface, it produces server skeletons for each class (e.g. _ShapeListImplBase) proxy classes (e.g. _ShapeListStub) a Java class for each struct e.g. Rectangle, GraphicalObject helper classes (narrow method) and holder classes (for out arguments) the equivalent Java interfaces (e.g. ShapeList below)

public interface ShapeList extends org.omg.CORBA.Object {Shape newShape(GraphicalObject g) throws ShapeListPackage.FullException;Shape[] allShapes();int getVersion();

}Figure 17.2

•What is the problem with out arguments in Java?e.g. void getPerson(in string name, out Person p);

Consider resolve in the naming service, we ask it to look upa reference to ShapeList, it returns an Object. What is the problem?

Page 9: Chapter 17-CORBA Case Study

9

The ShapeListServant class of the Java server program for the CORBA interface ShapeList. Figure 17.3

import org.omg.CORBA.*;class ShapeListServant extends _ShapeListImplBase {

ORB theOrb;private Shape theList[];private int version;private static int n=0;public ShapeListServant(ORB orb){

theOrb = orb; // initialize the other instance variables

}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; theOrb.connect(s); return s; }

public Shape[] allShapes(){ ... }public int getVersion() { ... }

}

A Java server has classes for its IDL interfaces (e.g. Shape and ShapeList). Here is the class ShapeListServant

a servant class extends the corresponding skeleton class (e.g. ShapeListImplBase)

a servant class implements the methods in the interface (ShapeList). newShape is a factory method. It creates new CORBA objects. It uses the connect method to inform the ORB about the new CORBA object. (it has a remote reference module)

CORBA objects are instances of servant classes.In non-OO languages implementations of CORBA objects can’t be classes. What might they be in C?

This class has to create CORBA objects of type Shape. How does it do that?

Page 10: Chapter 17-CORBA Case Study

10

Java class ShapeListServer (the server class)

import org.omg.CosNaming.*;import org.omg.CosNaming.NamingContextPackage.*;import org.omg.CORBA.*;public class ShapeListServer {

public static void main(String args[]) {try{

ORB orb = ORB.init(args, null);

ShapeListServant shapeRef = new ShapeListServant(orb); orb.connect(shapeRef);

org.omg.CORBA.Object objRef =

orb.resolve_initial_references("NameService"); NamingContext ncRef = NamingContextHelper.narrow(objRef);

NameComponent nc = new NameComponent("ShapeList", "");NameComponent path[] = {nc};ncRef.rebind(path, shapeRef);

java.lang.Object sync = new java.lang.Object();synchronized (sync) { sync.wait();}

} catch (Exception e) { ... }}

}

Figure 17.4

The server class contains the main method

it creates and initialises the ORB

it creates an instance of ShapeListServant class - a Java object - which is made a CORBA object by using the connect method to register it with the ORB

it waits for client requests

1. it gets a reference to the Naming Service 2. narrows it to NamingContext- from Object 3. makes a NameComponent containing the

name “ShapeList” 4. makes a path

5. uses rebind to register the name and object reference

Page 11: Chapter 17-CORBA Case Study

11

Java client program for CORBA interfaces Shape and ShapeList

import org.omg.CosNaming.*;import org.omg.CosNaming.NamingContextPackage.*;import org.omg.CORBA.*;public class ShapeListClient{

public static void main(String args[]) {try{

ORB orb = ORB.init(args, null); org.omg.CORBA.Object objRef =

orb.resolve_initial_references("NameService");NamingContext ncRef = NamingContextHelper.narrow(objRef);NameComponent nc = new NameComponent("ShapeList", "");NameComponent path [] = { nc };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

it creates and initialises an ORB

1. it contacts the NamingService for initial context2. Narrows it to NamingContext3. It makes a name component4. It makes a path5. It gets a reference to the CORBA object called

“ShapeList”, using resolve and narrows it

it invokes the allShapes method in the CORBA object to get an array containing remote references to all of the GraphicalObjects currently stored by the server

it uses one of the remote references in the array to invoke the getAllState method in the corresponding CORBA object whose type is Shapethe value returned is of type GraphicalObject

Page 12: Chapter 17-CORBA Case Study

12

The main components of the CORBA architecture

client server

proxy

or dynamic invocation

implementation repository object

adapter

ORBORB

skeleton

or dynamic skeleton

client program

interface repository

Request

Replycorecore for A

Servant A

The CORBA architecture is designed to allow clients to invoke methods in CORBA objects – clients and objects can be implemented in a variety of programming

languages – it has the following additional components compared to Figure 5.6

object adapter, implementation repository and interface repository

Figure 17.6

ORB coreThe role of the ORB core is similar to that of the communication module of Figure 5.6.

In addition, an ORB core provides an interface that includes the following:

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

Dynamic invocation interface In some applications (e.g. browsers), a client without the appropriate proxy class may need to invoke a method in a remote object.

CORBA does not allow classes for proxies to be downloaded at run time as in Java RMI.

The dynamic invocation interface is CORBA’s alternative. (we will discuss it later with the Interface Repository)

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–more about the object adapter later.

Skeletons–skeleton classes (for OO languages) are generated in the language of the server by an IDL compiler.–remote method invocations are dispatched via the appropriate skeleton to a particular servant, –the skeleton unmarshals the arguments in request messages and marshals exceptions and results in reply messages.

Client stubs/proxies– these are in the client language. – an IDL compiler for the client language uses an IDL interface to generate one of the following:

for object-oriented languages the class of a proxyfor procedural languages a set of stub procedures.

– as before, the client stubs/proxies marshal the arguments in invocation requests and unmarshal exceptions and results in replies.

Implementation repositoryactivates registered servers on demand and locates running servers uses the object adapter name to register and activate servers.more about this later

Interface repository the interface repository provides information about registered IDL interfaces to clients and servers that require it. More about this later.

Page 13: Chapter 17-CORBA Case Study

13

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.

The OA has a remote object reference and a method to be invoked on itWhat does dispatch do in C++/Java?What does dispatch in C?

Page 14: Chapter 17-CORBA Case Study

14

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 name

pathname of object implementation

hostname and port number 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

Page 15: Chapter 17-CORBA Case Study

15

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.

Page 16: Chapter 17-CORBA Case Study

16

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.

there are no constructors in IDL,so how do we create CORBA objects?

Suppose there was a constructor,what would be the problem for a servere.g. being asked to create an instance of a given class?

Page 17: Chapter 17-CORBA Case Study

17

IDL module Whiteboard

Modules allow interfaces and associated definitions to be grouped.

A module defines a naming scope.

module Whiteboard {struct Rectangle{...} ;struct GraphicalObject {...};interface Shape {...};typedef sequence <Shape, 100> All;interface ShapeList {...};

};

Figure 17.7

Page 18: Chapter 17-CORBA Case Study

18

IDL method signatures

[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

we saw raises in the newShape method of ShapeList

Page 19: Chapter 17-CORBA Case Study

19

Figure 17.8IDL constructed types – 1

Type Examples Use

sequence typedef sequence <Shape, 100> All;typedef sequence <Shape> Allbounded and unbounded sequencesof Shapes

Defines a type for a variable-lengthsequence of elements of a specified IDL type. An upper bound on thelength may be specified.

string String name; typedef string<8> SmallString; unbounded and boundedsequences of characters

Defines a sequences of characters,terminated by the null character. Anupper bound on the length may bespecified.

array typedef octet uniqueId[12];

typedef GraphicalObject GO[10][8]

Defines a type for a multi-dimensionalfixed-length sequence of elements of aspecified IDL type.

this figure continues on the next slide

•See Fig 5.1 for an example of string

Page 20: Chapter 17-CORBA Case Study

20

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 agroup of related entities. Structs arepassed by value in arguments andresults.

enumerated enum Rand (Exp, Number, Name);

The enumerated type in IDL maps atype name onto a small set of integervalues.

union union Exp switch (Rand) { case Exp: string vote; case Number: long n; case Name: string s;

The IDL discriminated union allowsone of a given set of types to be passedas an argument. The header isparameterized by an enum, which specifies which member is in use. };

Page 21: Chapter 17-CORBA Case Study

21

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

IDL interface type name Protocol and address details Object key

interface repositoryidentifier

IIOP host domainname

port number adapter name object name

Page 684

Page 22: Chapter 17-CORBA Case Study

22

Figure 17.9Naming graph in CORBA Naming Service

initial naming context

ShapeList

CD E

B

initial naming context

P

R S T

V

Q U

initial naming context

XX

Page 23: Chapter 17-CORBA Case Study

23

Figure 17.10Part 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.};

Page 24: Chapter 17-CORBA Case Study

24

Figure 17.11CORBA event channels

consumersupplier

proxy consumer

notification

proxy supplier

event channel

notificationnotification

Page 25: Chapter 17-CORBA Case Study

25

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

Page 26: Chapter 17-CORBA Case Study

26

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•

Page 27: Chapter 17-CORBA Case Study

Copyright © George Coulouris, Jean Dollimore, Tim Kindberg 2001 email: [email protected] material is made available for private study and for direct use by individual teachers.It may not be included in any product or employed in any service without the written permission of the authors.

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

Teaching material based on Distributed Systems: Concepts and Design, Edition 3, Addison-Wesley 2001. Exercises for Chapter 17:

CORBA CASE STUDY

From Coulouris, Dollimore and Kindberg

Distributed Systems: Concepts and Design

Edition 3, © Addison-Wesley 2001

Page 28: Chapter 17-CORBA Case Study

28

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

Page 29: Chapter 17-CORBA Case Study

29

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

Page 30: Chapter 17-CORBA Case Study

30

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

Page 31: Chapter 17-CORBA Case Study

31

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

Page 32: Chapter 17-CORBA Case Study

32

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

Page 33: Chapter 17-CORBA Case Study

33

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

Page 34: Chapter 17-CORBA Case Study

34

Exercise 17.7

Describe the necessary modifications to the Task Bag interface to allow callbacks to be used.

page 677

Page 35: Chapter 17-CORBA Case Study

35

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

Page 36: Chapter 17-CORBA Case Study

36

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

Page 37: Chapter 17-CORBA Case Study

37

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

Page 38: Chapter 17-CORBA Case Study

38

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

Page 39: Chapter 17-CORBA Case Study

39

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

Page 40: Chapter 17-CORBA Case Study

40

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

Page 41: Chapter 17-CORBA Case Study

41

Exercise 17.14

To what extent may CORBA objects be migrated from one server to another?

page 679 and page 684

Page 42: Chapter 17-CORBA Case Study

42

Exercise 17.15

Discuss the benefits and drawbacks of the two-part names or NameComponents in the CORBA naming service.

page 688

Page 43: Chapter 17-CORBA Case Study

43

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

Page 44: Chapter 17-CORBA Case Study

44

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

Page 45: Chapter 17-CORBA Case Study

45

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

Page 46: Chapter 17-CORBA Case Study

46

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();

---};

Page 47: Chapter 17-CORBA Case Study

47

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


Recommended