Distributed Systems

1. Distributed Systems Session 6: Implementing Distributed Systems with OMG/CORBA Christos Kloukinas Dept. of Computing City University London

2. Announcements • Milestone 2 Due today • Server Implementation • A least version 1 • 1 submission per pair • Identify your partner in the submission • Some Self Assessment questions up on CitySpace

3. Taking Stock: Module Outline 1 Motivation 2 Distributed Software Engineering 3 Communication 4 RMI 5 CORBA vs RMI 6 Building Distributed Systems with CORBA - Common Problems in Distributed Systems 7 Naming and Trading 8 Concurrent Processes and Threads 9 Transactions 10 Security

4. 0.0 CORBA IDL • CORBA IDL is very expressive and widely available on many platforms for different programming languages. This has motivated the use of CORBA as a mechanism to explain, study and experiment with principles of distributed systems

5. 0.1 Last session: Object Management Architecture Application Objects CORBA facilities Object Request Broker Transactions CORBA services Security Naming trading concurrency Lifecycle

6. 0.2 Last session: CORBA Architecture

7. 0.3 Last session Summary • Revisited CORBA/IDL • Static Vs Dynamic Invocation • Interface Repository • Dynamic Invocation Interface (DII) • Dynamic Skeleton Interface (DSI). • Basic Object Adapter • CORBA Communication and the IIOP Protocol • Hello World Example • Compare and Contrast, CORBA and JAVA RMI

8. Outline of Session 6 • IDL programming language bindings. • Difference between centralised and distributed object lifecycle. • CORBA Lifecycle Service.

9. Outline • To actually develop distributed systems an IDL is not sufficient. The operations declared at the interface need to be implemented in order to be used. • For both implementation and use of distributed operations, bindings to existing programming languages need to be defined. The standardisation of these programming language bindings will then facilitate the interoperability between distributed objects that are implemented in different programming languages to form so called polylingual applications. • A further prerequisite for distributed object-oriented applications is the ability to create distributed objects in a location transparent way. Moreover, objects may have to be copied or relocatedand during that may have to be migrated to different platforms. Also objects may have to be removed.

10. 1 IDL Programming Language Bindings 1 Polylingual applications 2 Standardisation of bindings 3 Available bindings 4 What bindings need to address 5 An example: IDL/Java

11. 1.1 Polylingual Applications • Distributed computing frameworks, such as CORBA are not only used for the construction and a-priori integration of new components. They are probably more often used for the a-posteriori integration of applications from existing components. • Polylingual applications have components in different programming languages. • To achieve interoperability between these components, language bindings are needed that map different language concepts onto each other. • Problem: with n different languages, n(n-1) different language bindings needed. • Solution: One language (such as IDL) as a mediator. Requires only n bindings.

12. Java Client C++ Obj. Impl. Infra- structure IDL IDL 1.1 Polylingual Applications with IDL Client side • Multiple polylingual clients accessing same object Object Implementation Side • IDL/JAVA binding enables client to invoke exported operations on server object • IDL/C++ Binding used to implement exported operations

13. 1.2 Standardisation of Bindings • Facilitate portability: • If different ORB vendors used different programming language bindings, neither object implementations nor clients of these implementations would be portable. As this is very undesirable, the OMG has standardised a number of language bindings. • ORB vendors must respect these language bindings to be able to claim that they are CORBA compliant. • Decrease learning curve of developers: • Developers who studied one language binding do not have to learn the binding again if they switch to an ORB from another vendor.

14. 1.3 Available Bindings • C • C++ • Smalltalk • Ada-95 • OO Cobol • Java It is sufficient for the compliance of an object request broker product to the CORBA standard if it provides one of these bindings. Most brokers, however, provide more than one binding. Nevertheless, no product is currently available that implements all bindings.

15. 1.4 What Bindings Need to Address • Atomic data types and type constructors • Constants • Interfaces and multiple inheritance • Object references • Attribute accesses • Operation execution requests • Exceptions • Invocation of ORB operations

16. 1.5 An Example: IDL/Java 1 Modules 2 Atomic Types 3 Enumerations 4 Records 5 Interfaces 6 Attributes 7 Operations 8 Inheritance 9 Exceptions 10 Operation Execution Requests

17. 1.5.1 Modules • As an example, assume that an interface Account is included in the IDL BankApplication module. This interface will be represented in Java as class Account. From outside the package BankApplication, the class can be accessed using BankApplication.Account. • Note that in this way the avoidance of name clashes is supported, which makes the approach particularly useful for the construction of large distributed systems.

18. 1.5.1 Modules IDL: Java: module BankApplication { ... }; package BankApplication; ...

19. 1.5.2 Atomic Types IDL Java short/unsigned short short long/unsigned long int long long/unsigned long long long float float double double char char boolean boolean octet byte string String

20. 1.5.2 Atomic Types (ctd.) • Most atomic types map naturally to Java • Java’s platform independence is of great value here. In the IDL to C++ mapping, for example, there is the problem of different representations on different platforms (shorts can be 32 or 64 bit on Unix and 16 bit on PCs or the significance of a byte may be different (low endian vs high endian architecture). Therefore IDL-to-C++ does not map anything to atomic C++ types. Java does not have this problem because the Java Virtual Machine is standardised.

21. 1.5.3 Enumerations • IDL provides an enumeration type; • An ordered list of identifiers whose values are assigned in ascending order according to their order in enumerationmodule addresses{ enum Sex {male, female};}; • Java has no enumeration type and thereforehas to implement an enumeration as a class!  The class provides constants of the enumeration type which is internally realised as integers  Additionally the Java class provides a method to convert integers to the enumeration type

22. Enumeration (2) • One shortcoming of Java is the missing enumeration type. An IDL enumeration is mapped to an enumeration class in Java • Example: The above IDL enumeration in implemented by the Java code below. The constants can be accessed as Sex.male and Sex.female . Integers (0 and 1 in this case) can be translated to enumeration type package Addresses; public final class Sex implementsjava.lang.Cloneable { public static final int _male = 0; public static final Sex male = new Sex(_male); public static finalint _female = 1; public static final Sex female = new Sex(_female); public static final Sex IT_ENUM_MAX = new Sex(Integer.MAX_VALUE); public int value () {return ___value;} public static Sex from_int (int value) { switch (value) { case _male : return male; case _female : return female; default : throw new org.omg.CORBA.BAD_PARAM("Enum out of range"); } } private Sex (int value) { ___value = value;} privateint ___value; publicjava.lang.Object clone(){return from_int(___value);} }

23. struct Info { long height; short weight; }; 1.5.4 Records IDL Java Likewise, IDL records are mapped to a Java class. Attributes of the record are mapped to public attributes of the class. Names used in IDL are used directly in Java. final public class Info { public int height; public short weight; public Info() {} public Info(int height, short weight){ this.height = height; this.weight = weight;} };

24. 1.5.5 Interfaces • IDL interfaces are translated into Java public interfaces. The reasons for that are obvious: The inheritance and subtype relationships in IDL can be mapped to inheritance in Java and interface components, such as attributes and operations can be implemented as Java methods. • The interface name can be kept as the class name because no name conflicts can occur in Java which would not have already been detected in IDL.

25. interface person { attribute readonly string name; attribute address lives_at; }; 1.5.6 Attributes IDL Java public interface person { public String name(); public address lives_at(); public void lives_at(address value); };

26. 1.5.6 Attributes (ctd.) • IDL attributes are implemented as Java class attribute with access methods. For readonly attributes a single (get) method is generated and for other attributes a pair of (set and get) methods is created. • An access of an attribute from a remote object can fail for similar reasons as an operation execution request. These failures are handled using exceptions in both Java and IDL. • The visibility of methods that implement attributes is public. This is necessary to retain the IDL semantics that any attribute that is declared can be accessed from other classes.

27. interface Dog { void bark(out short times); void growl(in string at); }; 1.5.7 Operations IDL Java public interface Dog{ public void bark(org.omg.CORBA.ShortHolder times); public void growl(String at); };

28. 1.5.7 Operations (ctd.) • Operations defined in an IDL interface are mapped to public Java methods of the class that represents the interface. • The method name is retained because again this cannot cause scoping problems in Java that would not have been detected in IDL. Likewise, parameter names are retained as they cannot cause name clashes. • The mapping of parameter types is more complicated. Since Java does NOT provide pointers, parameters of atomic type are passed by value, • IMPORTANT STUFF • Truth #1: Everything in Java is passed by value. Objects, however, are never passed at all.., ONLY their references are (by value again…). • Truth #2: The values of variables are always primitives or references, never objects.

29. Operations ctd. (in, out,inout parameters) • IN : to be passed with a meaningful value • Value of the actual parameter is copied into the formal parameter when the operation is invoked. Modification of formal parameter affects only the formal parameter, not the actual parameter. This is the most common form of parameter passing and is the only one provided in C & Java(CALL-BY-VALUE) • OUT: Whose value will be changed by operation • The value of the formal parameter is copied into the actual parameter when the procedure returns. Modifications to the formal parameter do not affect the formal parameter until the function returns. (CALL-BY-RESULT) • So it really should be passed by reference (to be modified!) • INOUT: Combination of IN and OUT • E.G. Consider f(s) and call f(g), s: formal parameter,and g actual parameter

30. Operations ctd (implementing out, inout) • CORBA IDL in parameter implement call-by-value semantics , JAVA supports this, so consequently in maps to normal JAVA parameters and requires no additional effort. • whereas IDL’s out and inout parameter do NOT have JAVA counterparts, SO some additional mechanism is required for call-by-result, etc • Java creates for every type a holder class, a container, an object which wraps up the value. Since object references can be passed by value the out/inout parameter can now be realised in java programs. • I.e Clients instantiate an instance of appropriate Holder class, which is then passed by value. • To support portable stubs and skeletons, holder classes also implement the org.omg.CORBA.portable.Streamable interface, to allow for marshalling and unmarshalling. (The whole object is sent!)

31. Operations (2) • Contents of the instance are modified by server invocation • Client then uses possibly changed contents • package org.omg.CORBA; • public final class ShortHolder • { • public short value; • public ShortHolder() {} • public ShortHolder(short s) { value = s; } • } • The short-holder class of the above example is, for example, part of the org.omg.CORBA package: • In language bindings providing pointers out/inout parameters are realised by pointers

32. 1.5.8 Inheritance IDL Java interface student : person { attribute string subject; }; public interface student extends person { string subject(); void subject(String value); } IDL provides multiple inheritance, JAVA does not. How is the problem solved??

33. 1.5.8 Inheritance (ctd.) • Inheritance between IDL interfaces is implemented as inheritance between the respective Java interfaces. • Note : Java interfaces do allow multiple inheritance whereas Java classes do not. • Therefore IDL interfaces with multiple inheritance map to JAVA interfaces with multiple inheritance • When implementing such a Java interface one uses the implements-keyword and therefore inherits only the names of methods and attributes and not any code. The Java class implementing a Java interface with multiple inheritance implements every single method/attribute of the interface and is therefore in control.

34. interface employee : person { exception too_young{...}; void retire() raises (too_young); }; public interface Employee extends org.omg.CORBA.Object { public void retire() throws EmployeePackage.too_young; } 1.5.9 Exceptions IDL Java Exceptions that are declared within an interface are mapped to Java classes.

35. Exceptions (2) • The previous example leads to the following Java class: package Exception.EmployeePackage; public final class too_young extends org.omg.CORBA.UserException implements java.lang.Cloneable { public String explanation; public short age; public too_young() {super();} public too_young(String explanation,short age) { super(); this.explanation = explanation; this.age = age;} ...} • Note that programming languages such as C which do not provide exceptions, model exceptions by additional parameters to methods. (much faster but easier to ignore…)

36. 1.5.10 Operation Execution Requests • Operation execution requests have no counterpart in IDL as IDL is an interface and not an implementation definition language!

37. 1.5.10 Operation Execution Requests Java employee emp; ... try { emp.retire(); } catch (too_young e){ // Handle the Specific Exception } catch (SystemException se){ switch (SysEx.minor() ) { case BAD_PARAM : ... ; break; case NO_MEMORY : ... ; break; }; };

38. Application Objects CORBAfacilities Object Request Broker CORBAservices Lifecycle 2 Lifecycle Service

39. Introduction/Summary • The problem of distributed object life cycle is the problem of • Creating an Object, Deleting an Object, Moving and Copying an object, Operating on a graph of distributed objects. • Client model of object lifecycle is based on • Factories and target objects supporting LifeCycleObject interface which defines operation for delete, move and copy • GenericFactory interface is defined • Generic factory is sufficient to create objects of different types • By Defining GenericFactory interface, implementations that administer resources are enabled.

40. 2.1 Introduction • Component creation in a distributed system is more complicated than in a centralised system mainly because: • 1) Often the component is to be created on a non-local machine. The component creation mechanisms available in programming languages (such as constructors in Java) cannot be used because location specification has to be included. • 2) Location has to be identified, and identification must be transparent • More problems arise for duplication and migration of components • due to potentially heterogeneous source and target platform, also 2) above • The deletion of components is more difficult as well. • Garbage collection techniques assume that all objects are available in one address space. This is not the case in a distributed system. The techniques cannot be directly applied.

41. 2.1 Introduction (ctd.) creation Obj1 duplication Obj1 Obj1 Server Client Obj1 migration Obj1 removal Obj1 replication Obj1 Obj1 Obj2 Obj3

42. 2.2 CORBA Lifecycle Service - Object Creation • Object creation is done in the CORBA lifecycle service by so called Factoryobjects. These are plain CORBA objects themselves that export an operation that create and return new objects. • The factory objects use objectconstructors for the implementation of these creation operations. The new objects, therefore, run in the same address space as the factory object. • An example is the personFactory object which can be used to create a new object of type person. To do so a client who wishes to create a person object calls the operation createPerson which will return a reference to a newly created person object. This person object will run on the same machine as the object of type personFactory. • The problem of location transparency then gets down to locating factory objects.

43. 2.2 Object Creation (ctd.) • Object Creation is done in CORBA lifecycle service by factory objects • The life cycle module exports the FactoryFinder interface, which supports factory location. • A client wishing to locate a factory can invoke the find_factories operation, which will return a sequence of Factory objects. The parameter of the find_factory operation is a key that can be considered as an external (and location independent) name. If no factories are found with that name, the NoFactory exception will be raised. • Factories register with a factory finder using a private protocol. This protocol is likely to be defined in an interface that inherits from the FactoryFinder interface.This, however, is transparent for clients. • Factory finders are not only used for the immediate location of a factory (for creation purposes), but they are also used as proxies (placeholders) for location information that is to be passed to move and copy operations.

44. 2.2 Object Creation • Factory finder objects can be located by other means (e.g. naming or trading).(will discuss in next lecture) Factory location supported by: interface FactoryFinder { Factories find_factories (in Key factory_key) raises (NoFactory); };

45. 2.2 Object Creation (ctd.) • It would be fairly costly if a factory interface had to be created for each object type. This would immediately double the number of interfaces in the distributed application. • The life cycle service therefore defines the GenericFactory interface. It exports an operation by means of which it can be checked whether the Factory is able to create an object of a particular type (whose name is given as a key). • A second operation allows clients to create an instance of the type whose name is given as a key. • This overcomes the problem that type specific factories are not needed. In addition, resources can be managed for instances of different types that reside on one location. • As a disadvantage, however, a type specific initialisation (which can be achieved within an object constructing operation of a specific factory) is not possible through this generic interface.

46. 2.2 Object Creation • LifeCycle Service includes generic factory: interface GenericFactory { boolean supports(in Key k); Object create_object(in Key k, in NVP criteria) raises (NoFactory, InvalidCriteria, CannotMeetCriteria); }; • Advantage: no type specific factories required. • Disadvantage: No specific initialisations.

47. Example import org.omg.CosNaming.*; import org.omg.CosLifeCycle.*; import org.omg.CORBA.*; //1) Instantiating the factory from an interoperable object reference stored in file String factoryIOR; factoryIOR = getFactoryIOR("genfac.ior"); org.omg.CORBA.Object genFacRef = orb.string_to_object(factoryIOR); GenericFactory fact = GenericFactoryHelper.narrow(genFacRef); //2) Using the factory to create an object // struct NameComponent { Istring id; Istring kind; }; NameComponent nc = new NameComponent("sBuyer::BuyerServer", "objectinterface"); NameComponent key[] = {nc}; NVP mycriteria[] = {}; org.omg.CORBA.Object objRef = fact.create_object(key, mycriteria); Buyer1Ref = BuyerHelper.narrow(objRef);

48. 2.3 Object Duplication • The interface to duplicate objects is in LifeCycleObject. • The copy operation takes a FactoryFinder as a parameter. This factory finder defines the (set of) locations on which the copy should be created. • Object types that are to be copied or moved around to other locations have to be subtypes of LifeCycleObject. • To accomplish type specific implementations of the copy operation while retaining a unique and generic interface that is seen by clients, subtypes of LifeCycleObject redefine the copy operation. • interface LifeCycleObject { LifeCycleObject copy (in FactoryFinder there) raises (NoFactory,...); ... };

49. 2.3 Object Duplication • The copying of an object cannot be implemented by the ORB. • It uses the factory to create a new object on the target machine. In this way, the problem of heterogeneous machine code of object implementations is resolved. • Attribute values are transferred either • through parameters of the object constructing operation • through explicit operation invocations done after the object has been made. This way heterogeneity of data representation is resolved

50. 2.4 Object Deletion • Objects that are created also have to be removed. In many object oriented programming languages this is done implicitly as the object is no longer referenced. • This requires reference counting and garbage collection techniques which are not applicable to distributed objects because they are too expensive in a distributed setting! • Deletion of an object is defined in the LifeCycleObject interface as well. To free the resources allocated by an object clients explicitly invoke the remove operation. interface LifeCycleObject { void remove() raises (NotRemovable); };