© city university london, dept. of computing distributed systems / 6 - 1 distributed systems...

© City University London, Dept. of Computing Distributed Systems / 6 - 1

Distributed Systems

Session 6:

Implementing Distributed Systems with OMG/CORBA

Christos KloukinasDept. of Computing

City University London


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


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 Systems7 Naming and Trading8 Concurrent Processes and Threads9 Transactions10 Security


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


0.1 Last session: Object Management Architecture

ApplicationObjects

CORBA facilities

CORBA services

Object Request Broker

Naming trading concurrency Lifecycle

SecurityTransactions


0.2 Last session: CORBA Architecture


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


Outline of Session 6

IDL programming language bindings.

Difference between centralised and distributed

object lifecycle.

CORBA Lifecycle Service.


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 relocated and during that may have to be migrated to different platforms. Also objects may have to be removed.


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


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.


1.1 Polylingual Applications with IDL

Client side

Object Implementation

Side

Infra-structure

IDLJavaClient

C++ Obj.Impl.

IDL

•Multiple polylingual clients accessing same object

•IDL/JAVA binding enables client to invoke exported operations on server object

•IDL/C++ Binding used to implement exported operations


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.


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.


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


1.5 An Example: IDL/Java

1 Modules2 Atomic Types3 Enumerations4 Records5 Interfaces6 Attributes7 Operations8 Inheritance9 Exceptions10 Operation Execution Requests


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.


1.5.1 Modules

IDL:

Java:

module BankApplication { ...};

package BankApplication; ...


1.5.2 Atomic Types

IDL Javashort/unsigned short shortlong/unsigned long intlong long/unsigned long long longfloat floatdouble doublechar charboolean booleanoctet bytestring String


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.


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


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 implements java.lang.Cloneable {

public static final int _male = 0;

public static final Sex male = new Sex(_male);

public static final int _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;}

private int ___value;

public java.lang.Object clone(){return from_int(___value);}

}


1.5.4 Records

final public class Info { public int height; public short weight; public Info() {} public Info(int height, short weight){

this.height = height;this.weight = weight;}

};

struct Info { long height; short weight;};

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.


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.

1.5.5 Interfaces


1.5.6 Attributes

IDL

Java

interface person { attribute readonly string name; attribute address lives_at;};

public interface person { public String name(); public address lives_at(); public void lives_at(address value);};


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.


1.5.7 Operations

IDL interface Dog { void bark(out short times); void growl(in string at);};

public interface Dog{public void bark(org.omg.CORBA.ShortHolder times);public void growl(String at);};

Java


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.


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


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!)


Operations (2)

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

•Contents of the instance are modified by server invocation•Client then uses possibly changed contents


1.5.8 Inheritance

interface student : person { attribute string subject; };

public interface student extends person{ string subject(); void subject(String value);}

IDL

Java

IDL provides multiple inheritance, JAVA does not.

How is the problem solved??


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.


1.5.9 Exceptions

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;}

IDL

Java

Exceptions that are declared within an interface are mapped to Java classes.


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…)


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!


1.5.10 Operation Execution Requests

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; };};

Java


2 Lifecycle Service

ApplicationObjects

CORBAfacilities

CORBAservices

Object Request Broker

Lifecycle


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.


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.


2.1 Introduction (ctd.)

Obj1

Obj1

Obj1

Obj1

Obj1

creation

duplication

migration

removal

replication

Obj1

Obj1

Obj1

Obj2 Obj3

Cli

ent

Server


2.2 CORBA Lifecycle Service - Object Creation

Object creation is done in the CORBA lifecycle service by so called Factory objects. These are plain CORBA objects themselves that export an operation that create and return new objects.

The factory objects use object constructors 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.


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.


2.2 Object Creation

Factory finder objects can be located by other means (e.g. naming or trading).(will discuss in next lecture)

interface FactoryFinder { Factories find_factories (in Key factory_key) raises (NoFactory);

};

Factory location supported by:


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.


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.


Example

import org.omg.CosNaming.*; import org.omg.CosLifeCycle.*;import org.omg.CORBA.*;

//1) Instantiating the factory from an interoperable object reference stored in fileString 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",

"object interface");NameComponent key[] = {nc};NVP mycriteria[] = {};

org.omg.CORBA.Object objRef = fact.create_object(key, mycriteria);Buyer1Ref = BuyerHelper.narrow(objRef);


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,...); ...

};


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


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);};


2.5 Object Migration

Migration is the removal of an object implementation from one location to another location.

The client view of migration is also defined by the LifeCycleObject interface by means of the move operation.

Interfaces defining specific objects that inherit from LifeCycleObject redefine move in an application specific way! It is often possible to use the copy and the remove operation for that purpose. This, however, is not done generically, as more efficient ways may be possible in application specific situations.

interface LifeCycleObject { void move(in FactoryFinder there) raises(NoFactory,NotMovable);};


2.6 What’s Missing: Replication No relationship is maintained between two objects once they have

been copied. They therefore do not evolve together but are completely independent from each other.

This means that the life cycle service does not support replication and therefore replication transparency is not support in the CORBA framework.

There are integrations of particular CORBA products (Orbix, for instance) with replication middleware components (ISIS). These integrations, however, are not standardised and applications that use them will not be portable.

The advantages of replication are that it allows for a higher load and also it supports fault tolerance because the state of an object can be recovered from a replica if an implementation has crashed.


4 Summary

Polylingual applications.



object lifecycle.



EXTRA GOODIES

(Do read these…)


3 Static vs. Dynamic Invocation

Dynamic Dynamic InvocationInvocation

ClientClientStubsStubs

ORBORBInterfaceInterface

ServerServerSkeletonSkeleton

ObjectObjectAdapterAdapter

ORB CoreORB Core

ClientClient Object ImplementationObject Implementation


3.1 Generic Applications

Example: Object Browser

Person

Name:

Age:

Celia Cruz

56

Generic applications use components whose types are not (yet) known.


3.2 Static Invocation

Advantages:» Requests are simple to define.

» Availability of operations checked by programming language compiler.

» Requests can be implemented fairly efficiently.

Disadvantages:» Generic applications cannot be build.

» Recompilation required after operation interface modification.


3.3 Dynamic Invocation Interface

Interface to create operation execution requests dynamically.

Requests are objects. Attributes for operation name, parameters and

results. Operations to

» change operation parameters,

» issue the request and

» obtain the request results.


3.4 Creation of Requests

interface Object { ORBstatus create_request ( in Context ctx, // operation context in Identifier operation, // operation to exec in NVList arg_list, // args of operation inout NamedValue result, // operation result out Request request // new request object in Flags req_flags // request flags ); ...};


3.5 Synchronous Requests

Client Server

invoke


3.6 Deferred Synchronous Requests

Client Server

send

get_response


3.7 Interface Repository

Makes type information of interfaces available at run-time.

Enables development of generic applications.

Achieves type-safe dynamic invocations.

Supports construction of interface browser.

Used by ORB itself.


3.8 Locating Interface Definitions

Alternatives for locating interface definitions: Any interface inherits the operation

InterfaceDef get_interface() from Object.

Associative search using lookup_name.

Navigation through the interface repository using contents and defined_in attributes.


3.9 Example: Object Browser

Use interface repository to find out about object types at run-time

Use dynamic invocation interface to obtain attribute values.

Person

Name:

Age:

Celia Cruz

56


3.10 Object Browser Interaction Diagram

Object InterfaceDef Request Requestget_interface()

name()

describe_interface()

create_request()

invoke()

create_request()

invoke()


4 Summary

Polylingual applications.



object lifecycle.

Dynamic vs static invocation


© city university london, dept. of computing distributed systems / 6 - 1 distributed systems...

Documents