2. CS 843 - Distributed Computing Systems Chapter 17: CORBA Chin-Chih Chang, chang@cs.twsu.edu From Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edition 3, © Addison-Wesley 2001

3. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Introduction to CORBA The Object Management Group (OMG) was formed in 1989. Its aims were:OMG  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 (Common Object Request Broker Architecture) is a specification of an architecture supporting this.CORBA CORBA 1 in 1990 and CORBA 2 in 1996.

4. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 CORBA RMI 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 oan external data representation, called CDR ospecifies 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

5. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 CORBA RMI CORBA services are generic services useful in distributed applications e.g. Naming Service, Event Service. 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?)

6. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 CORBA Object Model The CORBA object has a model similar to the remote object model in Chapter 5. Clients are not necessarily objects – 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.  It has a remote object reference.  Its methods can be invoked remotely.

7. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 CORBA Object Model 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.

8. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 CORBA IDL A CORBA interface specifies a name and a set of methods that clients can request (Figure 17.1).  Interfaces are used to specify the methods that clients can request.  Strucs are used to define the data structure used as parameter types in defining the methods.

9. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 17.1 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 All; interface ShapeList { 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 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)

10. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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)  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)

11. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Parameters in CORBA IDL 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 IDL allows exceptions to be defined in interfaces and thrown by their methods.

12. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Parameters in CORBA IDL Implementations of CORBA provide some interfaces to the functionality of the ORB called pseudo- objects. ORB is the name of an interface that represents the functionality of the ORB that programmers need to access:  The method init, which must be called to initialize the ORB.  The method connect, which is used to register CORBA objects with the ORB.  Other methods, which enable conversions between remote object references and strings.

13. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Parameters in CORBA IDL Remote invocation in CORBA:  At-most-once call semantics is the default.  Maybe semantics by using the oneway keyword. This is only used for methods without results. The CORBA Naming Service 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) )

14. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 CORBA Pseudo Objects ORB is the name of an interface that represents the functionality of the ORB that programmers need to use. It includes:  The method init, which must be called to initialise the ORB.  The method connect, which is used to register CORBA objects with the ORB.  Other methods, which enable conversions between remote object references and strings.

15. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 CORBA Client and Server Example The Hello Client-Server Example.Hello Client-Server Example

16. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 17.2 Java interface ShapeList generated by idltojava from CORBA interface ShapeList public interface ShapeList extends org.omg.CORBA.Object { Shape newShape(GraphicalObject g) throws ShapeListPackage.FullException; Shape[] allShapes(); int getVersion(); }

17. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 CORBA Naming Service 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

18. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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 oserver skeletons for each class (e.g. _ShapeListImplBase) oproxy classes (e.g. _ShapeListStub) oa Java class for each struct e.g. Rectangle, GraphicalObject ohelper classes (narrow method) and holder classes (for out arguments) othe 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 up a reference to ShapeList, it returns an Object. What is the problem?

19. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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() {... } } zA 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?

20. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 17.4 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

21. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 17.5 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 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 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 Shape the value returned is of type GraphicalObject

22. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 CORBA ORB Architecture (17.2.2)

23. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 CORBA ORB Architecture Object - This is a CORBA programming entity that consists of an identity, an interface, and an implementation, which is known as a Servant. Servant - This is an implementation programming language entity that defines the operations that support a CORBA IDL interface. Servants can be written in a variety of languages, including C, C++, Java, Smalltalk, and Ada.

24. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 CORBA ORB Architecture Object - This is a CORBA programming entity that consists of an identity, an interface, and an implementation, which is known as a Servant. Servant - This is an implementation programming language entity that defines the operations that support a CORBA IDL interface. Servants can be written in a variety of languages, including C, C++, Java, Smalltalk, and Ada.

25. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 CORBA ORB Architecture Client  This is the program entity that invokes an operation on an object implementation.  Accessing the services of a remote object should be transparent to the caller. Ideally, it should be as simple as calling a method on an object, i.e., obj->op(args). The remaining components in the Figure help to support this level of transparency.

26. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 CORBA ORB Architecture Object Request Broker (ORB):  The ORB provides a mechanism for transparently communicating client requests to target object implementations.  The ORB simplifies distributed programming by decoupling the client from the details of the method invocations.  This makes client requests appear to be local procedure calls. When a client invokes an operation, the ORB is responsible for finding the object implementation, transparently activating it if necessary, delivering the request to the object, and returning any response to the caller.

27. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 CORBA ORB Architecture ORB Interface  An ORB is a logical entity that may be implemented in various ways (such as one or more processes or a set of libraries).  To decouple applications from implementation details, the CORBA specification defines an abstract interface for an ORB.  This interface provides various helper functions such as converting object references to strings and vice versa, and creating argument lists for requests made through the dynamic invocation interface described below.

28. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 CORBA ORB Architecture Dynamic Invocation Interface (DII)  This interface allows a client to directly access the underlying request mechanisms provided by an ORB.  Applications use the DII to dynamically issue requests to objects without requiring IDL interface-specific stubs to be linked in.  Unlike IDL stubs (which only allow RPC-style requests), the DII also allows clients to make non-blocking deferred synchronous (separate send and receive operations) and oneway (send-only) calls.

29. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 CORBA ORB Architecture Dynamic Skeleton Interface (DSI)  This is the server side's analogue to the client side's DII.  The DSI allows an ORB to deliver requests to an object implementation that does not have compile-time knowledge of the type of the object it is implementing.  The client making the request has no idea whether the implementation is using the type-specific IDL skeletons or is using the dynamic skeletons.

30. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 CORBA ORB Architecture Object Adapter  This assists the ORB with delivering requests to the object and with activating the object. More importantly, an object adapter associates object implementations with the ORB.  Object adapters can be specialized to provide support for certain object implementation styles (such as OODB object adapters for persistence and library object adapters for non-remote objects).

31. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 The Architecture of CORBA (Textbook) CORBA makes the distinction between static and dynamic invocations.  Static invocations are used when the remote interface of the CORBA object is known at compile time, enabling client stubs and server skeletons to be used.  If the remote interface is not known at compile time, dynamic invocation must be used.  Most programmers prefer to use static invocation because it provides a more natural programming model.

32. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 The Architecture of CORBA CORBA Primary components in CORBA:  ORB core  Object adapter  Skeletons  Client stubs/proxies ORB core is the communication module for the CORBA object and provides an interface including:  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.

33. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Object Request Broker (ORB) On client side the ORB is responsible for  accepting requests for a remote object  finding implementation of the object  accepting client-side reference to the remote object(converted to a language specific form, e.g., a Java stub object)  routing client method calls through the object reference to the object implementation On server side the ORB  lets object servers register new objects  receives requests from the client ORB  uses object’s skeleton interface to invoke object’s activation method  creates reference for new object and sends it back to client

34. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 17.6 The main components of the CORBA architecture client server proxy or dynamic invocation implementation repository object adapter ORB skeleton or dynamic skeleton client program interface repository Request Reply core for A Servant A

35. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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 dispatcher modules in Fig. 5.6. An object adapter has the following tasks:  it creates remote object references for CORBA objects;  Each object adapter provides access to those services of an ORB (such as activation, deactivation, object creation, object reference management) used by a particular type of object implementation. oit dispatches each RMI via a skeleton to the appropriate servant; oit activates objects.

36. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Object Adapter An object adapter gives each CORBA object a unique object name.  the same name is used each time an object is activated. oit is specified by the application program or generated by the object adapter.  Each active CORBA object is registered with its object adapter, owhich 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.

37. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 The Architecture of CORBA (Textbook) Skeleton classes are generated in the language of the server by an IDL compiler. Remote invocations are dispatched via the appropriate skeleton to a particular servant. The class of a proxy or a set of stub procedures is generated from an IDL interface by an IDL compiler for the client language.

38. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Static vs. Dynamic Invocation Static Invocation  Static interfaces are generated in form of client stubs by the IDL (pre-) compiler.  This means that the structure of the object has to be known before hand (at compile time).  Allows for better type checking; less runtime overhead; self- documentation. Dynamic Invocation  Dynamic Invocation Interface (DII) allows clients to invoke operations on remote objects without having access to object stubs (another way to do this without dynamic invocation is to download static client stubs via a Java applet).  Clients must discover interface-related information at runtime (e.g., using the interface repository)  Servers can offer new services anytime without the need for recompilation on the client side.

39. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Dynamic Requests The Dynamic Invocation Interface (DII) allows clients to dynamically:  discover objects;  discover objects’ interfaces;  create requests;  invoke requests;  receive responses. Major features of Dynamic Invocation Interface:  requests appear as objects themselves;  requests are reusable;  invocation may be synchronous or asynchronous;  requests may be generated dynamically, statically or in combination approach.

40. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Implementation repository Implementation repository (Server)  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. owhen a server program is installed it can be registered with the implementation repository. o when an object implementation is activated in a server, the hostname and port number of the server are added to the mapping.

41. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Implementation repository  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 object adapter name pathname of object implementation hostname and port number of server

42. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Interface Repository (Client) 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.

43. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Interface Repository 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.

44. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 IDL Interface Definitions Implementation Installation Client Stubs Interface Repository Implementation Repository Implementation Skeletons Client Object Implementation Accesses Includes Describes Includes Summary of CORBA Interfaces All objects are defined in IDL by specifying their interfaces. Object definitions (interfaces) are manifested as objects in the Interface Repository, as client stubs, and as implementation skeletons. Descriptions of object implementations are maintained as objects in the Implementation Repository

45. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 OMG IDL OMG Interface Definition Language (IDL):  mappings for many languages/compilers;  independent of any particular language/compiler;  multiple-inheritance, public interface-structured specification language;  not for implementation.  primary support for interoperability between static and dynamic requests mechanisms. IDL Structure  Module oa namespace  Interface oabstract type omultiple inheritance  Struct ostructured data Module auction { exception NotAllowed {}; struct Sale { int price; string item; } interface Auction { void bid (in long price) raises NotAllowed; } Module auction { exception NotAllowed {}; struct Sale { int price; string item; } interface Auction { void bid (in long price) raises NotAllowed; }

46. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 CORBA IDL (17.2.3) 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.

47. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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 All; interface ShapeList {...}; }; Figure 17.7

48. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 17.7 IDL module Whiteboard module Whiteboard { struct Rectangle{...} ; struct GraphicalObject {...}; interface Shape {...}; typedef sequence All; interface ShapeList {...}; };

49. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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 used  at-most-once call semantics is the default we saw raises in the newShape method of ShapeList

50. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 IDL method signatures Inheritance - IDL interfaces may extend one or more interfaces  all IDL interfaces are compatible with Object oee 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

51. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 17.8 IDL constructed types – 1 TypeExamplesUse sequence typedef sequence All; typedef sequence 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 SmallString; unboundedand 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

52. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 17.8 IDL constructed types – 2 TypeExamplesUse 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 anenum, which specifies which member is in use. };

53. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Internet Inter-Orb Protocol (IIOP) CORBA specification is neutral with respect to network protocols  the CORBA standard specifies what is known as the General Inter-ORB Protocol (GIOP)  GIOP is a high-level standard protocol for communication between ORBs  not used directly; instead, it is specialized by a particular protocol that would then be used directly Internet Inter-ORB Protocol (IIOP)  IIOP is the GIOP-based protocol for TCP/IP networks  As of the 2.0 version of the CORBA specification, vendors are required to implement the IIOP protocol CORBA Networking Model  CORBA applications are built on top of GIOP-derived protocols such as IIOP  these protocols, in turn, rest on top of TCP/IP, DCE, or other underlying transport protocol the network uses  an application architecture can be designed to use a bridge that would interconnect, for instance, DCE-based application components with IIOP- based ones.

54. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 CORBA remote object references Interoperable Object References (IOR)  An IOR is an object reference that is understood by ORBs that can interoperate using the OMG-defined protocols General Inter-ORB Protocol (GIOP) and Internet Inter- ORB Protocol (IIOP).  A client can obtain an object reference using orb.object_to_string(objRef), as shown in the Browsing the Namespace example, or as a result of an invocation on another object reference.Browsing the Namespace

55. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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 oThe 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.

56. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 17.2.4 CORBA remote object references 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 nameProtocol and address detailsObject key interface repository identifier IIOPhost domain name port numberadapter name object name Page 684

57. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 OMG Reference Model Architecture

58. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 OMG Reference Model Architecture Object Services  These are domain-independent interfaces that are used by many distributed object programs. For example, a service providing for the discovery of other available services is almost always necessary regardless of the application domain.  Two examples of Object Services that fulfill this role are: object oThe Naming Service -- which allows clients to find objects based on names; oThe Trading Service -- which allows clients to find objects based on their properties.

59. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 OMG Reference Model Architecture Common Facilities  Like Object Service interfaces, these interfaces are also horizontally-oriented, but unlike Object Services they are oriented towards end-user applications.  An example of such a facility is the Distributed Document Component Facility (DDCF), a compound document Common Facility based on OpenDoc. DDCF allows for the presentation and interchange of objects based on a document model, for example, facilitating the linking of a spreadsheet object into a report document.

60. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 OMG Reference Model Architecture Domain Interfaces  These interfaces fill roles similar to Object Services and Common Facilities but are oriented towards specific application domains.  For example, one of the first OMG RFPs issued for Domain Interfaces is for Product Data Management (PDM) Enablers for the manufacturing domain. Other OMG RFPs will soon be issued in the telecommunications, medical, and financial domains.

61. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 OMG Reference Model Architecture Application Interfaces  These are interfaces developed specifically for a given application. Because they are application-specific, and because the OMG does not develop applications (only specifications), these interfaces are not standardized.  However, if over time it appears that certain broadly useful services emerge out of a particular application domain, they might become candidates for future OMG standardization.

62. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 CORBA services include the following 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

63. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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

64. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 17.9 Naming graph in CORBA Naming Service initial naming context ShapeList C DE B initial naming context P R S T V Q U XX

65. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 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. };

66. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 17.11 CORBA event channels consumer supplier proxy consumer notification proxy supplier event channel notification

67. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Flat or Nested Transactions A flat transaction is a transaction which conform to atomicity and isolation.  Atomicity means that a transaction cannot be half-done.  Isolation means that each transaction must remain unique. A nested transaction is a transaction created within the scope of another transaction.  A nested transaction commits with respect to its parent transaction. If a nested transaction commits, the effects of the commit are not permanent until the parent transaction commits. If the parent transaction aborts, the nested transaction is also aborted.  Changes made within the nested transaction are invisible to the top- level transaction until the nested transaction is committed.

68. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Summary The main component of CORBA is the Object Request Broker or ORB, which allows clients written in one language to invoke operations in remote objects (called CORBA objects) written in another language.

69. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Summary CORBA addresses other aspects of heterogeneity as follows:  The CORBA General Inter-ORB protocol (GIOP) includes an external data representation called CDR. oIt makes it possible for clients and servers to communicate irrespective of their hardware. oIt also specifies a standard form for remote object references.  GIOP also includes a specification for the operations of a request-reply protocol that can be used irrespective of the underlying operating system.  The Internet Inter-ORB Protocol (IIOP) implements the request-reply protocol over TCP/IP. IIOP remote object references include the domain name and port number of a server.

70. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Summary A CORBA object implements the operations in an IDL interface.  All that clients need to know to access a CORBA object is the operations available in its interface.  The client program accesses CORBA objects via proxies or stubs, which are generated automatically from their IDL interfaces in the language of the client.  Server skeletons for CORBA objects are generated automatically from their IDL interfaces in the language of the client.

71. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Summary The object adapter is an important component of CORBA servers.  Its role is to create remote object references and to relate remote object references in request messages to the implementations of CORBA objects. The CORBA architecture allows CORBA objects to be activated on demand.  This is achieved by a component called the implementation repository (server object database), which keeps a database of implementations indexed by their object adapter names.  When a client invokes a CORBA object, it can be activated if necessary in order to carry out the invocation.

72. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Summary An interface repository is a database of IDL interface definitions indexed by a repository ID, which is included in IORs.  An interface repository (client interface database) can be used to get information about the methods in the interface of a CORBA object to allow dynamic method invocations. CORBA services provide functionality above RMI, which may be required by distributed applications, allowing them to use additional services such as naming and directory services, event notifications, transactions or security as required.

73. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Summary: CORBA Remote Method Invocation Clients use “object interfaces” through language mapping  Java clients should work on any ORB that supports the Java language bindings.  Clients can call any object instance remotely, so long as the object instance implements the interface. Clients can call remote objects statically or dynamically  The server cannot tell whether the client is using static or dynamic invocation. Objects are identified using a unique id: Interoperable Object Reference (IOR)  CORBA passes objects by reference  IOR was Introduced in CORBA 2.0  Object references can be converted to strings and back to “live” objects via ORB interface functions.

74. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Steps in Developing CORBA Applications Write specification for each object using IDL Use IDL Compiler (e.g., idlj, idl2java) to generate:  Client Stub code  Server Skeleton code Write the client (in Java, can be applications or applets) Write the server object implementation code (the “servant”) Compile the client and server code Start the server Run the client application

75. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Data Types in CORBA IDL Basic Types short, long, unsigned long, unsigned short, float, double, long double, char, wchar, boolean, string, octet, etc. Constructed Types struct and union (similar to C++; can be used in conjunction with a typedef) sequence (variable sized arrays of objects) any (generic type which represents any possible IDL types; similar to the Java Object type) enum (enumerated type with named integer values) arrays valuetypes (similar to interfaces; preceded with keyword valuetype to provide pass-by-value semantics) Each CORBA IDL data type gets mapped to a native data type via the appropriate language binding (e.g, IDL-to-Java mapping).

76. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Data Types in CORBA IDL module HelloApp { interface Hello { string sayHello(); };

77. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 What Does the IDL Compiler Generate? idlj Hello.idl _HelloStub.java HelloHelper.javaHelloHolder.java _HelloImplBase.java Hello.java_HelloOperations.java Client-SideServer-Side Client Stub Implementation Skeleton Note: these source files will be a part of the Java package Hello and will be placed in a directory with the same name.

78. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Data Types in CORBA IDL _HelloImplBase.java - This abstract class is the server skeleton, providing basic CORBA functionality for the server. It implements the Hello.java interface. The server class HelloServant extends _HelloImplBase. _HelloStub.java - This class is the client stub, providing CORBA functionality for the client. It implements the Hello.java interface.

79. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Data Types in CORBA IDL _Hello.java - This signature interface contains the Java version of our IDL interface. The Hello.java interface extends org.omg.CORBA.Object, providing standard CORBA object functionality. It also extends IDLEntity, and is used as the signature type in method declarations when interfaces of the specified type are used in other interfaces. HelloHelper.java - This final class provides auxiliary functionality, notably the narrow() method required to cast CORBA object references to their proper types.

80. Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Data Types in CORBA IDL HelloHolder.java - This final class holds a public instance member of type Hello. It provides operations for out and inout arguments, which CORBA allows, but which do not map easily to Java's semantics. HelloOperations.java - This operations interface contains the single method sayHello(). The IDL-to- Java mapping puts all of the operations defined on the IDL interface into this file. The operations interface is used in the server-side mapping and as a mechanism for providing optimized calls for co-located clients and servers.