Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Teaching material 
based on Distributed 
Systems: Concepts 
and Design, Edition 3, 
Addison-Wesley 2001. 
Copyright © Geor...
2 
Introduction to CORBA 
 The Object Management Group (OMG) was formed 
in 1989. Its aims were: 
– to make better use of...
Don't be put off by GIOP and IIOP 
They are just names for familiar things 
IIOP is just about remote object references 
3...
4 
CORBA RMI 
 CORBA RMI is a multi-language RMI system. 
 The programmer needs to learn the following new concepts: 
– ...
CORBA IDL interfaces Shape and ShapeList 
5 
struct Rectangle{ 
long width; 
long height; 
long x; 
long y; 
} ; 
struct G...
6 
Parameters in CORBA IDL 
 Passing CORBA objects: 
– Any parameter or return value whose type is specified by the name ...
CORBA Naming Service (see Section17.3.1) 
 It is a binder that provides methods including 
– rebind for servers to regist...
Illustration of programming CORBA 
 We illustrate CORBA with a Java client and server 
 The interface compiler is called...
The ShapeListServant class of the Java server program for the 
CORBA interface ShapeList. Figure 17.3 
This class has to c...
Java class ShapeListServer (the server class) 
The server class contains the main method 
import org.omg.CosNaming.*; 
imp...
Java client program for CORBA interfaces Shape and 
ShapeList 
import org.omg.CosNaming.*; 
import org.omg.CosNaming.Namin...
The main components of the CORBA architecture 
Client Skeletons 
stubs/proxies 
– these are in the client language. 
– an ...
13 
Object adapter 
 an object adapter bridges the gap between 
– CORBA objects with IDL interfaces and 
– the programmin...
14 
Implementation repository 
 Implementation repository 
– it activates registered servers on demand and locates runnin...
15 
Interface repository 
 it provides information about registered IDL interfaces 
– for an interface of a given type it...
16 
CORBA IDL 
 IDL provides facilities for defining modules, 
interfaces, types, attributes and method signatures. 
– ex...
17 
IDL module Whiteboard 
 Modules allow interfaces and associated definitions 
to be grouped. 
 A module defines a nam...
18 
IDL method signatures 
[oneway] <return_type> <method_name> (parameter1,..., parameterL) 
[raises (except1,..., except...
19 
Figure 17.8 
IDL constructed types – 1 
Type Examples Use 
sequence typedef sequence <Shape, 100> All; 
typedef sequen...
20 
Figure 17.8 
IDL constructed types – 2 
Type Examples Use 
record struct GraphicalObject { 
string type; 
Rectangle en...
17.2.4 CORBA remote object references 
 'interoperable object references' (IORs) – CORBA 2.0 
– suitable whether or not t...
CORBA services include the following 
 Naming Service (it would be a good idea to study it!) 
 Event Service and Notific...
23 
Summary 
 CORBA addresses heterogeneity: 
– RMI between a client and a remote remote object in different languages. 
...
Upcoming SlideShare
Loading in …5
×

Chapter 17 corba

2,806 views

Published on

  • Login to see the comments

Chapter 17 corba

  1. 1. Teaching material based on Distributed Systems: Concepts and Design, Edition 3, Addison-Wesley 2001. Copyright © George Coulouris, Jean Dollimore, Tim Kindberg 2001 email: authors@cdk2.net 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)
  2. 2. 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. •
  3. 3. Don't be put off by GIOP and IIOP They are just names for familiar things IIOP is just about remote object references 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. • GIOP is just about external data representation and a Request-reply protocol allowing for objects to be activated The architecture allows for mixed languages and object activation (added to Figure 5.6)
  4. 4. 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. •
  5. 5. CORBA IDL interfaces Shape and ShapeList 5 struct Rectangle{ long width; long height; long x; long y; } ; struct GraphicalObject { string type; Rectangle enclosing; boolean isFilled; }; interface Shape { this struct is used as a parameter or result type in methods in the remote interfaces. long getVersion() ; GraphicalObject getAllState() ; // returns state of the GraphicalObject }; typedef sequence <Shape, 100> All; interface ShapeList { sequences and arrays in typedefs exception FullException{ }; Shape newShape(in GraphicalObject g) raises (FullException); All allShapes(); // returns sequence of remote object references long 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 Exceptions defined by raises and set by throw. They can have arguments. • this struct is used in defining another struct.
  6. 6. 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 •
  7. 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 7 •
  8. 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(); 8 } Figure 17.2 •
  9. 9. The ShapeListServant class of the Java server program for the CORBA interface ShapeList. Figure 17.3 This class has to create CORBA objects of type Shape. How does it do that? 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? 9 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) •
  10. 10. Java class ShapeListServer (the server class) The server class contains the main method import org.omg.CosNaming.*; import org.omg.CosNaming.NamingContextPackage.*; import org.omg.CORBA.*; public class ShapeListServer { 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 10 public static void main(String args[]) { try{ it creates and initialises the ORB 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) { ... } } } it waits for client requests Figure 17.4 • 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
  11. 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{ 1. it contacts the NamingService for initial context 2. Narrows it to NamingContext 3. It makes a name component 4. It makes a path 5. It gets a reference to the CORBA object called “ShapeList”, using resolve and narrows it it uses one of the remote references in the array to invoke the getAllState method in the corresponding CORBA object whose type is Shape the value returned is of type GraphicalObject 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 11 public static void main(String args[]) { try{ ORB orb = ORB.init(args, null); org.omg.CORBA.Object objRef = it creates and initialises an ORB 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 •
  12. 12. The main components of the CORBA architecture Client Skeletons 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: 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)  The CORBA architecture is designed to allow clients ORB core Object adapter The role of the ORB –an object core is adapter similar bridges to that of the the gap communication between 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. –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. to invoke Implementation methods repository in CORBA objects – clients and objects can be implemented in a variety of programming CORBA objects with IDL interfaces and the programming language interfaces of the corresponding servant classes. activates registered servers on demand and locates running servers for object-oriented languages the class of a proxy uses the object adapter name to register and activate servers. for procedural languages a set of stub procedures. more about this later –it does the work of the remote reference and despatcher modules in Fig. 5.6 –more about the object adapter later. – as before, the client stubs/proxies marshal the arguments in invocation requests and unmarshal exceptions and results in replies. for A core core 12 client server proxy or dynamic invocation implementation repository object adapter ORB ORB skeleton or dynamic skeleton client program interface repository Request Reply Servant A languages – it has the following additional components compared to Figure 5.6  object adapter, implementation repository and interface repository Figure 17.6 Interface repository the interface repository provides information about registered IDL interfaces to clients and servers that require it. More about this later. •
  13. 13. 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. •
  14. 14. 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 •
  15. 15. 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. •
  16. 16. 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. •
  17. 17. 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 •
  18. 18. 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
  19. 19. 19 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 Defines a type for a variable-length sequence of elements of a specified IDL type. An upper bound on the length may be specified. string String name; typedef string<8> SmallString; unbounded and bounded sequences of characters Defines a sequences of characters, terminated by the null character. An upper bound on the length may be specified. array 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. this figure continues on the next slide • See Fig 5.1 for an example of string
  20. 20. 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 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. •
  21. 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. 21  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 repository IIOP host domain identifier name Page 684 port number adapter name object name
  22. 22. 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 22  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 •
  23. 23. 23 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 •

×