Distributed Systems Course CORBA case study

Click here to load reader

  • date post

  • Category


  • view

  • download


Embed Size (px)


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. - PowerPoint PPT Presentation

Transcript of Distributed Systems Course CORBA case study

  • Introduction to CORBAThe Object Management Group (OMG) was formed in 1989. Its aims were: to make better use of distributed systemsto use object-oriented programmingto allow objects in different programming languages to communicate with one anotherThe object request broker (ORB) enables clients to invoke methods in a remote objectCORBA is a specification of an architecture supporting this. CORBA 1 in 1990 and CORBA 2 in 1996.

  • Introduction to CORBAThe main components of CORBAs RMI framework are:An interface definition language known as IDL.An architecture.The General Inter-ORB protocol (GIOP) defines an external data representation, called CDRspecifies 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. 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 thingsGIOP is just about external data representationand a Request-reply protocol allowing for objects to be activatedThe architecture allows for mixed languagesand object activation (added to Figure 5.6)IIOP is just about remote object references

  • CORBA RMICORBA 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 modelsimilar 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.

  • CORBA IDL interfaces Shape and ShapeListstruct 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 All; interface ShapeList {exception FullException{ }; Shape newShape(in GraphicalObject g) raises (FullException);All allShapes();// returns sequence of remote object referenceslong getVersion() ;};Figure 17.1

  • Parameters in CORBA IDLPassing CORBA objects:Any parameter or return value whose type is specified by the name of a IDL interface, e.g. Shape, is a reference to a CORBA object (see newShape)and the value of a remote object reference is passed. Passing CORBA primitive and constructed types:Arguments of primitive and constructed types are copied and passed by value. On arrival, a new value is created in the recipients process. E.g., the struct GraphicalObject (argument of newShape and result of getAllState)Note: the method allShapes returns an array of remote object references as follows:typedef sequence 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

  • 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 CORBAThis makes access in a simple example seem rather complex!The name service is present in all CORBA installations. (Its role is like the Java RMI registry) Its use will be shown in program examples

  • Illustration of programming CORBA We illustrate CORBA with a Java client and serverThe interface compiler is called idltojavawhen given an IDL interface, it producesserver skeletons for each class (e.g. _ShapeListImplBase)proxy classes (e.g. _ShapeListStub)a Java class for each struct e.g. Rectangle, GraphicalObjecthelper classes (narrow method) and holder classes (for out arguments)the equivalent Java interfaces (e.g. ShapeList below)

  • The ShapeListServant class of the Java server program for the CORBA interface ShapeList. Figure 17.3A Java server has classes for its IDL interfaces (e.g. Shape and ShapeList). Here is the class ShapeListServantimport 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() { ... }}CORBA objects are instances of servant classes.In non-OO languages implementations of CORBA objects cant be classes. What might they be in C?This class has to create CORBA objects of type Shape. How does it do that?

  • 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

  • Java client program for CORBA interfaces Shape and ShapeListimport 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

  • The main components of the CORBA architectureThe 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.6object adapter, implementation repository and interface repositoryFigure 17.6

  • Object adapteran 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.

  • Implementation repositoryImplementation repositoryit 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:- not all CORBA objects (e.g. call backs) need be activated on demand- access control information can be stored in an implementation repository

  • Interface repositoryit provides information about registered IDL interfacesfor 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 typesthe 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 referencesthis type identifier is called the repository IDbecause the interface repository stoes interfaces against their IDsapplications that use static invocation with client proxies and IDL skeletons do not require an interface repository. Not all ORBs provide an interface repository.

  • CORBA IDLIDL 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.

  • IDL module WhiteboardModules allow interfaces and associated definitions to be grouped.A module defines a naming scope.

  • IDL method signatures[oneway] (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 usedat-most-once call semantics is the defaultInheritance - IDL interfaces may extend one or more interfacesall 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 Servicean extended interface may add new methods, types, constants and exceptions It may redefine types, constants and exceptions but not methods

  • Figure 17.8IDL constructed types 1this figure continues on the next slideSee Fig 5.1 for an example of string

  • Figure 17.8 IDL constructed types 2

  • 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 objectThe 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 activationsthey contain the address of the implementation repositorythe implementation repository receives the request and uses the object adapter name to activate the object, then gives the server address to the clientthe client sends subsequent invocations to the server

  • CORBA services include the followingNaming Service (it would be a good idea to study it!)Event Service and Notification Service:in ES suppliers and consumers communicate via an event channelNS extends this to allow filtering and typed eventsSecurity service:authentication of principals and access control of CORBA objects with policiesauditing by servers, facilities for non-repudiationTrading service: allows CORBA objects to be located by attributeTransaction service and concurrency control serviceTS provides flat or nested transactions CCS provides locking of CORBA objectsPersistent object service:for storing the state of CORBA objects in a passive form and retrieving it

  • SummaryCORBA 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 adapterrelates request messages to implementations of CORBA objectsImplementation repositoryenables CORBA objects to be activated on demandInterface repositoryallows dynamic invocation of CORBA objectsIDL for defining interfaces

    This set of slides took about 1 hour 15 minutes at to present - but was little rushed. A little longer would be usefuldiffers from Java in that Java has classes but IDL does not.CORBA must define anything that will be passed as argument or returned as result.in Java the argument types are classes which can be defined in the language. Object is useful as argument or result where any type of remote object reference might be used. e.g. in lookup and bind.e,g, of argumnent - reference to ShapeListnarrow method is for casting down e.g. from a reference of type Object to one of type ShapeList

    Java only has a single result, no out arguments.it uses a factory method to create CORBA objectsCORBA objects in C are a set of data e.g. in a struct and a set of functions to access it.animation goes through the components

    in both cases, the dispatcher knows a method and some arguments as well as the reference to a CORBA object.

    dispatcher in C++/Java invokes a method in the local object whose reference is obtained from the CORBA object reference.In C, the object reference is passed as an extra argument to a function that is called.The server might not have the code for a class mentioned in a constructor.These are specifications of interfaces to services, they may be implementaed in a variety of ways, for example the POS may use files or a database to store object state.