Chapter 17-corba Case Study

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

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

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

Distributed Systems Course

CORBA case study 17.1 Introduction 17.2 CORBA RMI 17.2.1 Client and server example 17.2.2 Architecture 17.2.3 CORBA IDL 17.2.4 CORBA object references

17.3 Services (just a summary)

Introduction to CORBA  The Object Management Group (OMG) was formed in 1989. Its aims were: – to make better use of distributed systems – to use object-oriented programming – to allow objects in different programming languages to communicate with one another

 The object request broker (ORB) enables clients to invoke methods in a remote object  CORBA is a specification of an architecture supporting this. – CORBA 1 in 1990 and CORBA 2 in 1996. 2

•

Introduction to CORBA

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

The main components of CORBA’s RMI framework are: 1. An interface definition language known as IDL. 2. An architecture. 3. The General Inter-ORB protocol (GIOP) defines data representation, called CDR • an external GIOP is just about external data representation  specifies formats for the messages in a request-reply protocol. and a Request­reply protocol  • including messages for enquiring about the location of an allowing for objects to be activated 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 applications e.g. Naming Service, Event Service. The architecture allows for mixed languages and object activation (added to Figure 5.6) 3

•

CORBA RMI  CORBA RMI is a multi-language RMI system.  The programmer needs to learn the following new concepts: – the object model offered by CORBA; – the interface definition language and its mapping onto the implementation language. (e.g. a struct in IDL is mapped onto what in Java?)

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

 The term CORBA object is used to refer to remote objects. – a CORBA object implements an IDL interface, has a remote object reference and its methods can be invoked remotely.

 A CORBA object can be implemented by a language without classes. – the class concept does not exist in CORBA. – therefore classes cannot be defined in CORBA IDL, which means that instances of classes cannot be 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{ long width;  long height; long x; this struct is used in  long y; defining another struct.  } ; interface Shape { long getVersion() ; GraphicalObject getAllState() ; };

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

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

 // returns state of the GraphicalObject

an interface specifies a name and a set of methods

sequences and arrays in typedefs typedef sequence <Shape, 100> All;  interface ShapeList { interface ShapeList exception FullException{ };  Shape newShape(in GraphicalObject g) raises (FullException); All allShapes(); // returns sequence of remote object references long getVersion() ; the parameter of newShape is an in parameter and  }; Exceptions defined by raises and set  of type Graphical Object  The return value is an  Figure 17.1 extra out parameter of type Shape. No classes can  5 be passed as arguments or results

by throw. They can have arguments.

•

Parameters in CORBA IDL  Passing CORBA objects: – Any parameter or return value whose type is specified by the name of a IDL interface, e.g. Shape, is a reference to a CORBA object (see newShape) – and the value of a remote object reference is passed.

 Passing CORBA primitive and constructed types: – Arguments of primitive and constructed types are copied and passed by value. On arrival, a new value is created in the recipient’s process. E.g., the struct GraphicalObject (argument of newShape and result of getAllState)

 Note: the method allShapes returns an array of remote object references as follows: typedef sequence <Shape, 100> All; All allShapes();

 Type Object - is a supertype of all IDL interfaces (its values are object references). When would it be useful? Hint: – Think about the name server 6

•

CORBA Naming Service (see Section17.3.1)  It is a binder that provides methods including – rebind for servers to register the remote object references of CORBA objects by name (e.g. rebind (path, Object) e.g of 2nd argument? – resolve for clients to look them up by name.(e.g.Object = resolve(path)) – these methods belong to an interface called NamingContext (Fig 17.10)

 The names are structured in a hierarchy, – a path is an array of NameComponent (a struct with a name in it) – the path starts from an initial context provided by CORBA – This makes access in a simple example seem rather complex!

 The name service is present in all CORBA installations. (It’s role is like the Java RMI registry)  Its use will be shown in program examples 7

•

Illustration of programming CORBA

 We illustrate CORBA with a Java client and server  The interface compiler is called idltojava – when given an IDL interface, it produces     

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

public interface ShapeList extends org.omg.CORBA.Object { 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  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. How does it do that? ShapeList). Here 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 } 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); interface (ShapeList). newShape is a factory          return s;         method. It creates new CORBA objects. It uses the       } connect method to inform the ORB about the new public  Shape[] allShapes(){ ... } CORBA object. (it has a remote reference module) public int getVersion() { ... } } 9 •

Java class ShapeListServer (the server class) • • • • –

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.*; it creates and initialises the ORB makes a NameComponent containing the public class ShapeListServer { 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                  reference ShapeListServant shapeRef = new ShapeListServant(orb);        orb.connect(shapeRef);                        it creates an instance of ShapeListServant class - a Java                          object - which is made a CORBA object org.omg.CORBA.Object objRef =  by using the connect method to register it with   orb.resolve_initial_references("NameService");          the ORB   NamingContext ncRef = NamingContextHelper.narrow(objRef); NameComponent nc = new NameComponent("ShapeList", ""); NameComponent path[] = {nc}; ncRef.rebind(path, shapeRef);                                            it waits for client requests    Figure 17.4 java.lang.Object sync = new java.lang.Object(); 10 • synchronized (sync) {   sync.wait();}

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.*; • Narrows it to NamingContext import org.omg.CORBA.*; it creates and initialises an ORB • It makes a name component public class ShapeListClient{ • It makes a path public static void main(String args[]) { • 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", ""); 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 Client stubs/proxies Skeletons Dynamic invocation interface is designed to allow clients  The CORBA architecture are inadapter the client language. ORB core– these –skeleton Object classes (for OO languages) generated in the In some applications (e.g. browsers), a client without the are appropriate

language the server by an between IDL compiler. – an to invoke in CORBA objects IDLmethods compiler forofthe client language uses an IDL interface to Implementation repository –may an object bridges gap The proxy role ofclass the ORB core isadapter toathat ofthe the communication module of Figure 5.6. need tosimilar invoke method in a remote object. generate one of the following: –remote method invocations are viaprogramming the appropriate  Interface repository and CORBA objects with IDL interfaces and – activates registered servers on demand locates running servers clients objects can be implemented indispatched aand variety of In addition, an ORB core provides an interface that includes the following: CORBA doesfor notobject-oriented allow classes for proxies to be downloaded at run time skeleton to a particular servant, languages the class ofofa the proxy the programming language interfaces corresponding servant classes. theasinterface repository provides information about registered IDL interfaces to clients uses the object adapter name to register and activate servers. - operations enabling it to be started and stopped; inlanguages Java RMI.  procedural languages athis setlater. ofreference stub –the unmarshals the procedures. arguments in requestmodules messages and–servers that require it.skeleton More about –it for does the work of the remote and despatcher it has the following additional components compared to Figure 5.6 in Fig. 5.6 more about this later - operations convert between remote object references and strings; The dynamic invocation interface is CORBA’s alternative. (we will discuss and marshals exceptions and results in reply messages. –toas before, the client stubs/proxies marshal the arguments in –more about the object adapter later.  object adapter, implementation repository interface repository it later with the Interface Repository) invocation requests and exceptions and results in replies. - operations to provide argument listsunmarshal for requests usingand dynamic invocation.

client

client proxy program for A

implementation repository

ORB core

or dynamic invocation

server

interface repository

Request

object skeleton adapter ORB core

Reply

Figure 17.6

or dynamic skeleton 12

Servant A

•

The OA has a remote object reference  Object adapter and a method to be invoked on it What does dispatch do in C++/Java?  an object adapter bridges 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 of server implementation name

- not all CORBA objects (e.g. call backs) need be activated on demand - access control information can be stored in an implementation repository 14

•

Interface repository  it provides information about registered IDL interfaces – for an interface of a given type it can supply the names of the methods and for each method, the names and types of the arguments and exceptions. – a facility for reflection in CORBA. – if a client has a remote reference to a CORBA object, it can ask the interface repository about its methods and their parameter types – the client can use the dynamic invocation interface to construct an invocation with suitable arguments and send it to the server.

 the IDL compiler gives a type identifier to each IDL type  a type identifier is included in remote object references  this type identifier is called the repository ID – because the interface repository stoes interfaces against their IDs

 applications that use static invocation with client proxies and IDL skeletons do not require an interface repository. – Not all ORBs provide an interface repository. 15

•

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.

Figure 17.7

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

•

IDL method signatures

we saw raises in the newShape  method of ShapeList

[oneway] <method_name> (parameter1,..., parameterL) [raises (except1,..., exceptN)] [context (name1,..., nameM)]

 each parameter is labelled as in, out or inout, e.g. – void getPerson(in string name, out Person p);

 oneway e.g. oneway void callback(in int version) – the client will not be blocked and maybe semantics is used – at-most-once call semantics is the default

 Inheritance - IDL interfaces may extend one or more interfaces – all IDL interfaces are compatible with Object  ee can use type Object for parameters that may be of any type e.g. bind and resolve in the Naming Service

– an extended interface may add new methods, types, constants and exceptions – It may redefine types, constants and exceptions but not methods 18

•

Figure 17.8 IDL constructed types – 1 Type

Examples

Use

sequence

typedef sequence <Shape, 100> All; typedef sequence <Shape> All bounded and unbounded sequences of Shapes String name;  typedef string<8> SmallString;  unbounded and bounded sequences of characters

Defines a type for a variable­length sequence of elements of a specified    IDL type.  An upper bound on the length may be specified. Defines a sequences of characters, terminated by the null character. An upper bound on the length may be specified.

typedef octet uniqueId[12]; typedef GraphicalObject GO[10][8]

Defines a type for a multi­dimensional fixed­length sequence of elements of a specified IDL type.

string

array

this figure continues on the next slide See Fig 5.1 for an example of string 19

•

Figure 17.8 IDL constructed types – 2 Type

Examples

Use

record

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

Defines a type for a record containing a group of related entities.  Structs are passed by value in arguments and results.  

enumerated

enum Rand      (Exp, Number, Name);

The enumerated type in IDL maps a type name onto a small set of integer values.

union

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

The IDL discriminated union allows one of a given set of types to be passed as an argument. The header is parameterized by an  enum, which   specifies which member is in use.  

20

•

17.2.4 CORBA remote object references  'interoperable object references' (IORs) – CORBA 2.0 

– suitable whether or not the object is activatable. Transient IORs are for objects that last as long as the host process – they contain the address of the server hosting the CORBA object  The server ORB core receives the request message containing the object adapter name and object name of the target. It uses the object adapter name to locate the object adapter, which uses the object name to locate the servant.



Persistent IORs last between activations – they contain the address of the implementation repository – the implementation repository receives the request and uses the object adapter name to activate the object, then gives the server address to the client – the client sends subsequent invocations to the server IOR format

Page 684

IDL interface type name Protocol and address details

Object key   

interface repository identifier

adapter name  object name

IIOP host domain name   

 port number 21

•

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

22

S

U

T

Figure 17.10 Part of the CORBA Naming Service NamingContext interface in IDL struct NameComponent { string id; string kind; }; typedef sequence  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 proxy consumer

notification 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  email: [email protected] 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.

From Coulouris, Dollimore and Kindberg

Distributed Systems: Concepts and Design Edition 3, © Addison-Wesley 2001

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