Middleware - RWTH Aachen University · Examples for middleware • DCOM as Microsoft's solution on distributed objects • GLOBE as middleware designed for large distributed system

Middleware

Why Middleware?Advantages of Distributed Systems• Easy to add new components• Integration of existing solutions• Autonomy of single components• Flexibility und adaptability

Requirements to Distributed Systems• Openness, integration• Modularisation, federations• Security• Manageability, transparency

Problems:• different hardware• different operating systems• different applications

SUN Solaris

NTHP UX

Heterogeneity

Solution: Middleware platform as software infrastructure for handling heterogeneity

Middleware

Middleware:• Realisation of distributed accesses by suitable software infrastructure• Hiding the complexity of the distributed system from the programmer• Supporting the interaction between application components which could run on

heterogeneous systems• Separation of interface and implementation• Is added to the operating system or build upon it to take over some of its tasks

The middleware is build upon different operating systems, networks, and communication protocols (layer 1-4).

The applications can be programmed in different languages.

... and the middleware realises the cooperation between the software components.

Middleware

Middleware supports...• The communication between application components (normally RPC- or RMI-

based)• Constructing modular applications• Dynamic binding• Supporting services, e.g.

! Naming ! Synchronisation ! Replication

Examples for Middleware implementations:• Distributed Computing Environment (DCE)• ANSAware• DCOM• GLOBE• Common Object Request Broker Architecture (CORBA)

Middleware - Principles

Distributed file systems• Distribution transparencies for files• Popular because of its scalability

Remote Procedure Call (RPC)• Early middleware approach for transparency in communication

Distributed objects (RMI)• Enhancements of RPC to access to remote objects• Only the interface can be seen from outside, the implementation details are

transparent

Distributed documents• Example World Wide Web• Information are seen as documents, addressed by an URL

Examples for middleware

• DCOM as Microsoft's solution on distributed objects

• GLOBE as middleware designed for large distributed system

• CORBA as a general (industry defined) way to support distribution in heterogeneous systems

Basic Technique in Microsoft's Windows: COM (Component Object Model)• Supports the development of components that can be dynamically activated and

interact with each other• Can be used in executables as well as in dynamic link libraries• Was developed to support compound documents

• DCOM: 'distributed version' of COM to support activation/interaction with components located on another machine. For a programmer, the distinction between COM and DCOM is hidden behind interfaces (access transparency)

Distributed Component Object Model (DCOM)

ActiveX: • covers the tasks of OLE, together

with new features like starting variants, scripting support, …

OLE: Object Linking and Embedding. • Serves for gluing together different

parts of compound documents

COM: • communication infrastructure

between different objects located on the same computer

Object Model

• DCOM bases on the remote object model: objects can be placed in the same process as the client, in another process on the same machine, or in a process on a remote machine

• Basic concept: ! distinction between interface and implementation! The developer first specifies an object by its interface in an Interface Definition

Language (IDL; Microsoft IDL = MIDL)! An object simply is an implementation of an interface! Interface means binary interface: a table of pointers to methods belonging to

an interface. In this way, interfaces are language-independent

• Each interface is assigned with a globally unique Interface Identifier (IID)

• DCOM object:• instance of a class object, which represents an interface• By calling a function CreateInstance on a class object (identified by a class

ID, CLSID), a new object with this interface is build.

Object Model

All objects implement a standard interface: IUnknown• A pointer to IUnknown is passed back when creating an object• Important method in this interface: QueryInterface, which returns a pointer to

another interface implemented by the object• By this, a standard method to get access to each object's methods is given

All objects in DCOM are transient• Reference counting is part of IUnknown• Having no more references, an object is destroyed

An object can implement the IDispatch interface• Dynamic invocation of objects• An object does not have to know in advance all interfaces it will have to contact in

its lifetime• When an object implements this interface, calls to it can be constructed at runtime

Type Library and RegistryType library: storage for interface definitions• Used to figure out the signature of a method to be invoked dynamically• Used as a type library for supporting program developers

Registry (Windows registry)• Used to provide a mapping from interface identifiers to executable code. • In case of a remote invocation, the Service Control Manager (SCM) on the target

host is contacted by a client to access the remote registry

Communication in DCOMClient side:• Client proxy: providing the object's interface and sending the request to the object• Proxy marshaller: translating a request into a transport format before sending

Server side:• Object stub: receives a call from a client proxy and passes it on to the object• Proxy marshaller: extracts a request from a receives message

Communication at the beginning only was synchronous using RPC

Alternatives:

• Callback interfaces

! The client provides an interface where the server can call back after working on a request

• Asynchronous communication! For each method, two methods are implemented:

A start method the client passes its request toA finish method the client calls to read the response of the server

EventsReal asynchronous communication without the need for both, client and object, to be

active: using events• An event is modelled as a method call• An event class groups events and can be instantiated to event objects which can

send events of specific types• To register an implementation for a method so that events can be sent to it, a

pointer to the corresponding interface has to be sent to the event system• The event system can store events to pass them on to the receiver later

• Supplier: someone who creates events

• Consumer: someone who receives events

• m_event: method of an object

Clients• A client does not see distribution; the invocation of remote objects with DCOM is

the same as an invocation of a local object with COM• Difference: in COM an object is referenced by an interface pointer, in DCOM a

remote object is referenced by implementing an interface as a proxy• Passing on an object reference to another client is made by sending it the proxy

which contains all connection information

Naming in DCOM

Returns interface pointer of object to clientMoniker7

Loads its state from fileObject6

Instructs object to load previously stored stateMoniker5

Creates object and returns interface pointer to monikerClass object4

Loads class objectSCM3

Looks up associated CLSID and instructs SCM to create objectMoniker2

Calls BindMoniker at monikerClient1

DescriptionPerformerStep

• Only low-level naming• Objects are only transient. To expand an object's lifetime, additionally a persistent

object reference is stored to an object. This reference is called moniker.• Monikers have all information available to reconstruct an object and reload its state

Types of Monikers

Reference to an object in a remote processPointer moniker

Reference to a moniker in a compositionItem moniker

Reference to a composition of monikersComposite moniker

Reference to a class objectClass moniker

Reference to an object constructed from a URLURL moniker

Reference to an object constructed from a fileFile moniker

DescriptionMoniker type

Active Directory• Windows 2000 contains a directory service called Active Directory which can be

used by DCOM• A distributed system based on Windows 2000 is partitioned into domains consisting

of a number of resources and users• Each domain has a domain controller which is a local directory server• A domain controller is implemented as a LDAP directory server• LDAP servers are registered in DNS • Problem: a client has to know the target domain for its request

GLOBE

GLobal Object-Based Environment

• Experimental distributed system developed by Vrije Universiteit Amsterdam

• Design goal: support huge number of objects and users spread across the Internet, scalability is central role

• Fundamental concept: how are objects viewed?

! Objects don't only encapsulate state and operations, but additionally they encapsulate the implementation of policies that prescribe the distribution of an object's state across multiple machines

! Each object determines how its state is migrated, replicated or distributed over its replicas

Globe Object Model• Not uses the remote object model• Objects, i.e. their states can be physically distributed (and replicated). They are

called distributed shared objects• Each process running a 'part' of an object has a local implementation of the

object's interface implementation (local representative, local object)• Each local object offers an interface SOInf (similar to IUnknown in DCOM)• Local objects implement binary interfaces, interfaces are described using an IDL

Composed ObjectsTwo kinds of local objects• Primitive local object• Composite local object: composed of several primitive or composed local objectsComposition is used to construct a usable local object

• Semantics subobject implements the functionality

• Communication subobjectprovides a standard interface to the underlying network; it offers message-passing primitives for communication

• Replication subobject implements the object's distribution strategy

• Control subobject is intermediate between user interface and all object functions

Process-to-Object Binding• No concepts like type library and registry for getting interface descriptions and

activating objects.• Used in Globe:

Communication• Only synchronous communication• Some local objects (here in process A) can be seen as proxies only forwarding

requests• If an object's state is replicated, the replication subobject forwards the request to all

replicas and merges the results

Globe Client and Server

Get the status of a specific local objectStatLRReturns a list of all local objects for a given objectsListDSOReturns a list of all local objectsListAllLets the server remove all local objects of a given objectUnbindDSOLets the server remove a local object of a given objectRemoveLRLets the server create a local object for a new distributed objectCreateLRLets the server bind to an object, even if it is already boundAddBindingLets the server bind to a given object, unless it is already boundBindDescriptionMethod

Client: Process bound to a distributed shared object, invoking this object by making calls at the control subobject (process A on the last slide)

Server Process that can handle only invocations coming in through the network (processes B and C on the last slide)

Additionally: object servers for supporting distributed shared objects/hosting local objects. Interface for such object servers:

Naming

Reference to a file in a class repository (URL)Implementation handleA protocol-specific addressProtocol addressA constant representing a (known) protocolProtocol identifierDescriptionField

• Globe distinguishes between naming and locating objects• Each distributed shared object is assigned a globally unique object identifier (OID)• An object handle contains the OID• Location service is organised hierarchically• The address given back by the location service can be a

! Stacked address:

! Instance address:

String that is used to initialize an implementationInitialization string

Reference to a file in a class repositoryImplementation handle

DescriptionField

Globe Naming ServiceSimple naming service with human-friendly names:• Based on DNS• Names are represented by a Uniform Resource Identifier (URI)

CORBA

• Distributed object-based system• Common Object Request Broker Architecture (CORBA) • CORBA is a specification of a distributed system. There are no suggestions made

about the implementation of the middleware itself• These specifications have been drawn up by the Object Management Group

(OMG), a non-profit organisation with more than 800 members• Goals:

! make better use of distributed systems! use object-oriented programming! define a distributed system that could overcome many of the interoperability

problems with integrating networked applications• Core component: the object request broker (ORB), a 'software bus' for enabling

and managing communication

CORBA

• No implementation guidelines were made, but many organisations thought that CORBA would be a good product:

! Large set of options to define every aspect of a distributed system! Competition: fast implementations to be first-on-the-market! Poor performance due to fast implementation and large set of specified

options! In the first versions: incompatibilities between implementations of different

vendors! Problems with the specification lead to new specifications, forcing vendors to

re-build their implementations! Re-building implementations lead to re-design of the developers software

• Today, lot of different implementations exist, e.g.! Commercial: Orbix, VisiBroker, …! Freeware: MICO, OmniORB, ...! Integrated: e.g. Java-ORB

Components of the CORBA Framework

CORBA specifies...• A (raw) abstract object model• An interface definition language (IDL)• Mapping from IDL to different programming languages: Ada, C, C++,

COBOL, Java, Lisp, Python, SmallTalk, …• A repository for managing IDL specifications• The ORB as communication infrastructure• A communication protocol (GIOP/IIOP), together with a transfer syntax

and message formats• A client interface to the ORB (proxy)• A server interface to the ORB (skeleton)• Interoperability with other standards, e.g. DCOM• Services supporting management and use of distributed applications:

Naming, Transactions, ...

CORBA Architecture

• Reference model consists of four components

! The Object Request Broker (ORB) as communication infrastructure

! CORBAservices as useful services for all distributed applications

! CORBAfacilities as additional services used by some applications

! Application Objects as the distributed applications implemented by a programmer for its special purposes

Application Objects

CORBAservices

...Naming

TradingEvent

SecurityNotification

LifeCycle

CORBAfacilitiesVerticalHorizontal

Object Request Broker

Application Objects

CORBAservices

...Naming

TradingEvent

SecurityNotification

LifeCycle

CORBAfacilitiesVerticalHorizontal

Object Request Broker

CORBA ComponentsObject Request Broker• Core of any CORBA system• Responsible for enabling basic (synchronous!) communication between objects and

their clients while hiding issues related to distribution and heterogeneity

CORBAservices• Set of basic services (used by many applications) supporting a programmer in

constructing a distributed application and supporting the application at runtime• Examples: Naming, LifeCycle, Event, Security

CORBAfacilities• General purpose high level services with useful functions needed by several

applications, but which are not necessary for basic functioning• Horizontal facilities: services that are independent of an application domain such as

user interfaces or system management• Vertical facilities: services that are targeted to a specific application domain such as

electronic commerce, banking, medicine, telecommunications, ...

Application Objects• Not standardised, these are all objects programmed by a user for a special purpose

Object Model

• CORBA uses the remote object model with RMI as communication principle: used is multi-language RMI

• Objects and services are specified in the CORBA Interface Definition Language(CORBA IDL)

• IDL provides precise syntax for expressing methods and their parameters, but not the semantics. By using IDL, the whole interface of an object is specified

• The CORBA implementation provides compilers to translate the IDLspecification into an object with proxies resp. stubs (client) and skeletons (server) for handling the communication. The programmer only has to specify the application-specific code, not the communication mechanism

• It is necessary to provide exact rules concerning the mapping of IDL specifications to exisiting programming languages (C, C++, Java, Smalltalk, Ada and Cobol)

• Each object is 'named' by an unique object reference• The term CORBA object is used to refer to remote objects. A CORBA object

implements an IDL interface, has a remote object reference and its methods can be invoked remotely

Comparison to DCOM

• DCOM generates binary interfaces

• CORBA generates language-dependent stubs

• One specification of an interface

• Re-use of the specification

• A new specification for each mapping to a programming language

• Separate translation of the interface for each languageCORBA

DCOM

CORBA IDL

• Abstract interface definition• IDL has the same lexical rules as C++ but has additional keywords to support

distribution• The grammar of IDL is a subset of ANSI C++ with additional constructs to support

method signatures• IDL provides facilities for defining modules, interfaces, types, attributes and method

signatures• It allows standard C++ pre-processing facilities, e.g. #include for including other

interface definition files in the new file (inheritance)• Through an interface, only CORBA data types can be passed for an invocation.

CORBA provides a lot of data types, but own data types which have to be passed are to be defined together with the interface specification

• Notice: pointers are not supported!

IDL Basic Types

Support of basic keywords and data types:

any default inout out switch

attribute double interface raises TRUE

boolean enum long readonly typedef

case exception module sequence unsigned

char FALSE Object short union

const float octet string void

context in oneway struct

IDL definitions

IDL definition: definition of

• Modules to group interface definitions into name spacesmodule <ModulName> { ... };

• Interfaces as access points to objects. Interfaces can inherit from several other interfaces

interface <InterfaceName> { ... };

• Constantsconst <Typ> <ConstantName> = <Wert>

• Types to group basic data typestypedef <TypeName> ...enum <EnumName> { ... };struct <StructName> { ... };

• Exceptions for receiving ORB-specific or other (self-defined) distribution-specific error messages

exception <ExceptionName> ...

IDL Attributes

• Components of interfaces

• Equivalent to two operations: read and write an attribute value

• Definition: attribute <TypeIdentifier> <AttributeName>;Example: attribute short x;

• Special attributes for read-only:readonly attribute short x;

Meaning: a client can't modify the attribute value, but the object itself possibly can

• The IDL compiler generates a write operation and a read operation for such a definition

IDL Methods• Similar to function declarations in C++

• Consist of an identifier for the resulting type, one for the function name, and a list of identifiers for arguments

short operation(in short arg1, in short arg2);

• Optional: oneway (the client gets no response)oneway void operation(in char arg);

• Optional: Exceptions (for catching error messsages)void operation(out short arg2) raises (Except);

• Arguments: differentiation between three types:

! in for parameters only used to pass information to the object

! out for parameters only used to give back a result to the client

! inout for parameters used in both directions

• General method signature:[oneway] <return_type> <method_name> (parameter1,...,parameterL)

[raises (except1,..., exceptN)] [context (name1,..., nameM)]

Data Types• Basic types

Any char float Object short void unsigned shortboolean double long octet string unsigned long

- boolean: defined values TRUE, FALSE- char: 1 Byte.- octet: similar to char, but with a constant value- any: can contain each combination of other IDL data types- Object: Interface type; all interfaces inherit from this type to offer special

functions for binding or name resolving

• Structs- Combines several data type to a new one- Example:

struct structure {char element1;short element2;

};

Data Types

Type Examples Use

sequence typedef sequence <Shape, 100> All;typedef sequence <Shape> Allbounded and unbounded sequencesof Shapes

Defines a type for a variable-lengthsequence of elements of a specifiedIDL type. An upper bound on thelength may be specified.

string String name; typedef string<8> SmallString; unbounded and boundedsequences of characters

Defines a sequences of characters,terminated by the null character. Anupper bound on the length may bespecified.

array typedef octet uniqueId[12];typedef GraphicalObject GO[10][8]

Defines a type for a multi-dimensionalfixed-length sequence of elements ofa specified IDL type.

Data Types

Type Examples Use

record struct GraphicalObject {string type;Rectangle enclosing;boolean isFilled;

};

Defines a type for a record containing agroup of related entities. Structs arepassed by value in arguments andresults.

enumerated enum Rand(Exp, Number, Name);

The enumerated type in IDL maps atype name onto a small set of integervalues.

union union Exp switch (Rand) {case Exp: string vote;case Number: long n;case Name: string s;

The IDL discriminated union allowsone of a given set of types to be passedas an argument. The header isparameterised by an enum whichspecifies which member is in use.};

IDL Interfaces and Modules

interface Grid{

readonly attribute short height;readonly attribute short width;void set(in short n, in short m, in long value);long get(in short n, in short m);

};

Interfaces group all methods and parameters:

… and modules form a name space:

module Whiteboard {struct Rectangle{...} ;struct GraphicalObject {...};interface Shape {...};typedef sequence <Shape, 100> All;interface ShapeList {...};

};

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 <Shape, 100> All;

interface ShapeList {exception FullException{ }; Shape newShape(in GraphicalObject g) raises (FullException);All allShapes(); // returns sequence of remote object referenceslong getVersion() ;

};

Parameters in CORBA IDL

• Passing CORBA objects:– Any parameter or return value whose type is specified by the name of a

IDL interface, e.g. Shape, is a reference to a CORBA object (see newShape)

– and the value of a remote object reference is passed

• Passing CORBA primitive and constructed types:– Arguments of primitive and constructed types are copied and passed by

value. On arrival, a new value is created in the recipient’s process. E.g., the struct GraphicalObject (argument of newShape and result of getAllState)

• Note: the method allShapes returns an array of remote object references as follows:

typedef sequence <Shape, 100> All;All allShapes();

• Type Object - is a supertype of all IDL interfaces (its values are object references)

Client Server

ClientApplication(Object Code)

Server Application(Object Code)

IDL

IDL-Compiler

Client Stub

Header Server Stub

Compiler & Linker Compiler & Linker

Client-Code

Server-Code

IDL Compiler

The IDL compiler generates programming language constructs from the interface definitions:

IDL Compiler Example

Example Orbix:• save interface definition in file grid.idl• Language Mapping to C++ by using the IDL compiler: idl -B grid.idl• generates:

– grid.hh#include file containing all common type definitions used by client and server

– gridC.ccfunctions needed by the client to access the ORB (stub)

– gridS.ccfunctions needed by the server to access the ORB (stub)

IDL Language Mapping• Mapping of IDL definitions to data structures. Here: C++ in Orbix• Generated: Stubs of client and server. Additionally: Management of dynamically

allocated memory for IDL data types• Determination of how to execute an operation call for an object reference

Simple mapping rules:module M { ... }; namespace M { ... };

interface I { ... }; class I { ... };

struct S { ... }; struct S { ... };

Very simple: interfaces can be mapped to classes; by this, objects to an interface can be instantiated easily.

Mapping of basic types: e.g.short CORBA::Short

unsigned short CORBA::UShort

IDL Language Mapping• Arguments

!The mapping of arguments depends on their usage:IDL: type0 op(in type1 arg1, inout type2 arg2, out type3 arg3);

C++: type0 op(type1 arg1, type2& arg2, type3& arg3);

interface example {

readonly attribute long ro_value;

attribute long value;

void op(in long in_par, out long out_par);

};

class example : public virtual CORBA::Object {

public:

virtual CORBA::Long ro_value();

virtual CORBA::Long value();

virtual void value(CORBA::Long val);

virtual void op(CORBA::Long in_par,

CORBA::Long& out_par);

};

Note: the virtual class is generated by the IDL compiler and has to be implemented as a class by the programmer

IDL Language MappingStrings• Are defined as char*• ORB manages memory for character strings• Two possible definitions of string variables:

char* string1;

CORBA::String_var string2;

• Warning: do not mix them! Otherwise you are mixed up with finding the memory leaks!

• ORB offers some functions for working with strings (recommended to use them):char* CORBA::string_alloc(CORBA::Ulong len);

char* CORBA::string_dup(const char*);

char* CORBA::string_free(char*);

Other types, e.g. sequence• _var is defined as above (regarding memory management)• Mapped to a list, accessible by giving the index:

IDL: typedef sequence<Content> Example

C++: Example_var ex_variable;

ex_variable[2] = ...

Writing Client and Sever using the IDL-generated Stubs (Orbix)

Defining the interface• Specify the IDL definition in file.idl• Use IDL compiler to map it to C++

Writing the object implementation• Include fileS.cc (server stub)• Implement the operations which were defined in IDL• Register the server with the ORB

Writing the client• Include fileC.cc (client stub)• Implement client functionality, including operation requests• Bind to the server

Simple Example – grid / C++

• Specifying the interface IDL // In file grid.idl

interface Grid {

readonly attribute short height;

readonly attribute short width;

void set(in short n, in short m, in long value);

long get(in short n, in short m);

};

• Compiling the interface definition produces! grid.hh

! gridC.cc

! gridS.cc

Simple Example – grid / C++

• The grid.hh file produced by the IDL compiler contains the following:// Automatically produced (in grid.hh).

class Grid : public virtual CORBA::Object {

public:

virtual CORBA::Short height(CORBA::Environment& IT_env =

CORBA::default_environment);

virtual CORBA::Short width(CORBA::Environment& IT_env =

CORBA::default environment);

virtual void set(CORBA::Short n, CORBA::Short m, CORBA::Long value,

CORBA::Environment& IT_env =

CORBA::default_environment);

virtual CORBA::Long get(CORBA::Short n, CORBA::Short m,

CORBA::Environment& IT_env =

CORBA::default_environment);

};

Notice: each class inherits from the general CORBA object

Simple Example – grid / C++

• (partly) generated header file for your implementation - grid_i.h#include "grid.hh"

class Grid_i : public virtual GridBOAImpl {

CORBA::Short m_height;

CORBA::Short m_width;

CORBA::Long** m_a;

public:

Grid_i(CORBA::Short h, CORBA::Short w); // Constructor

virtual ~Grid_i(); // Destructor

virtual CORBA::Short width(CORBA::Environment&);

virtual CORBA::Short height(CORBA::Environment&);

virtual void set(CORBA::Short n, CORBA::Short m,

CORBA::Long value, CORBA::Environment&);

virtual CORBA::Long get(CORBA::Short n, CORBA::Short m,

CORBA::Environment&);

};

Simple Example – grid / C++• Your server implementation - grid_i.C#include "grid_i.h"

Grid_i::Grid_i(CORBA::Short h, CORBA::Short w) : m_height(h), m_width(w) {m_a = new CORBA::Long*[h];CORBA::Short i;for (i = 0; i < h; i++) m_a[i] = new CORBA::Long[w];

}Grid_i::~Grid_i() {

CORBA::Short i;for (i = 0; i < m_height; i++) delete[] m_a[i];delete[] m_a;

}CORBA::Short Grid_i::height(CORBA::Environment&) {

return m_height;}... // the same for Grid_i::weightvoid Grid_i::set(CORBA::Short n, CORBA::Short m, CORBA::Long value,

CORBA::Environment&) {m_a[n][m] = value;

}CORBA::Long Grid_i::get(CORBA::Short n, CORBA::Short m, CORBA::Environment&) {

return m_a[n][m];}

Simple Example – grid / C++• Providing the server - Srv_Main.C#include "grid_i.h"

#include <iostream.h>

main() {

// We could create any number of objects

// here but we just create one.

Grid_i myGrid(100,100);

// Orbix objects can be explicitly named,

// but this is not required in this simple

// example.

CORBA::Orbix.impl_is_ready("GridSrv");

cout << "Server terminating" << endl;

}

Note: additionally it is necessary now to make an entry for GridSrv in the so-called Interface Repository which enables a mapping of the server name to an executable

Simple Example – grid / C++

• Writing a client - Client.C#include "grid.hh"

#include <iostream.h>

main() {

Grid_var gVar;

gVar = Grid::_bind(":GridSrv");

cout << "height is " << gVar->height() << endl;

cout << "width is " << gVar->width() << endl;

gVar->set(2,4,123);

cout << "Grid[2,4] is "

<< gVar->get(2,4) << endl;

}

Simple example – Orbix provides a comfortable bind function. In other implementations, you would have to work with object references – try on your own in exercise 5.

Now: what makes all that work?

• The ORB is not a single component, rather it is a service executed on each computer (maybe as a daemon)

• The skeleton is the generated stub for the server side, the generated proxy is the stub for the client side (implements the same interface as the object the client is using). Both stubs are specific for the current application and are the only parts the client resp. the server see; the ORB is invisible for them

ImplementationRepository

InterfaceRepository

CORBA Architecture CORBA Architecture

ORB services (from the perspective of a process):• The ORB is offering a few functions by itself:

1. Manipulating object references (marshal and unmarshal object references to exchange them between processes, comparing object references)

2. Finding the services that are available to a process (an initial reference to an object implementing a specific CORBA service, in general a naming service)

Object Adapter

• Bridges the gap between CORBA objects with IDL interfaces and the programming language interfaces of the corresponding server

• Creates object references for CORBA objects• Each active CORBA object is registered with its object adapter, which keeps a

remote object table to map names of CORBA objects to servers • Responsible for dispatching incoming requests via a skeleton to the addressed

object• Possibly has to activate an object when a request comes in

Portable Object AdapterObject adapter • Implements an activation policy for a group of objects (single thread,

multithreading, ...)• Responsible for providing a consistent image of what an object• Adapts a program such that clients can see the program as an object

Portable Object Adapter (POA)• Server-side code can be written independently of specific ORB - it is portable in

means of ORBs from different vendors• Assumes: object implementations are partly provided by servants - the part of an

object that implements the methods that clients can invoke. Servants are programming-language dependent

• Each POA offers the following operation:Objectld activate_object(in Servant p_servant);

• This operation takes a pointer to a servant as input parameter and returns a CORBA object identifier as a result

• No universal definition of type servant; it is mapped to a language dependent data type

• The returned ObjectId is an index into the POA's Active Object Map

Dynamic Invocations

Dynamic Invocation Interface (DII)/ Dynamic Skeleton Interface (DSI)• There are occasions in which statically defined interfaces are simply not available

to a client, instead it has to find out what it needs during runtime

• DSI and DII are providing generic interfaces for sending/receiving each request, independent of specific proxies and skeletons

• E.g. used for implementing gateways to achieve interoperarbility between different platforms, e.g. CORBA and DCOM

• Required knowledge: what does the interface to a specific object looks like? • Subsequently compose an invocation request for that object

Dynamic Interfaces

What does DII do?• CORBA offers DII to clients, which allows them to construct an invocation request

at runtime• It provides a generic invoke operation, which takes

• (1) an object reference,• (2) a method identifier, and• (3) a list of input values as parameters.• These information are marshalled into a request and send to an object• Later it returns the result in a list of output variables provided by the caller

What does DSI do?• In the same way, a server object has a DSI which is able to receive any

request and decompose it into object reference, method identifier an parameters.

Interface Repository

How to find information about interfaces to construct a dynamic request? For this, the Interface Repository is needed.

• Stores all interface definitions• Often implemented by means of a separate process offering a standard interface

to store and retrieve interface defintions• Can be viewed as the part of CORBA that assists in runtime type checking

facilities• Whenever an interface definition is compiled, the IDL compiler assigns a

repository identifier to that interface• The repository ID can be used to retrieve an interface definition from the

repository• By default it is derived from the name of the interface and its methods (no

guarantees are given with respect to its uniquness)• Because interface information are stored in IDL, it is possible to structure each

implementation repository in the same way. The interface repositories in CORBA all offer the same operations for navigating through interface definitions

Implementation Repository

How to assign object references with real files?• CORBA systems offer an Implementation repository• Contains all that is needed to implement, register and activate objects, as well as

locating running servers• Stores a mapping of the names of object adapters to the file containing the object

implementation• Such functionality is related to the ORB (and its implementation) itself as well as

to the underlying operating system. For this, it is difficult to provide a standard implementation for each CORBA system.

• Mainly used by an object adapter, which is responsible for dispatching a request to the right object. If this object isn't running in the address space of a server, the object adapter could contact the implementation repository to find out what needs to be done: map the object reference to a binary file, start this file as a CORBA server in a specific way, …

Communication in CORBASimple communication model: only synchronous communication(But: with the time, some invocation facilities were added to this model)

Object invocation model:• When a client invokes an object, it sends a request to the corresponding object

server and blocks until it receives a response. These semantics correspond exectly to a normal method invocation when the caller and callee reside in the same address space.

• In the presence of failures, a client will receive an exception indicating that the invocation did not fully complete.

One-way request: • Problem with synchronous communication: if the client does not get back a result,

it is blocked unnecessaryly• Solution: a form of invocation, in which no result is expected. The client isn't

blocked, but it has no guarantees that the request is delivered

Deferred synchronous communication:• One-way requests are used by a client to make a request and by a server to pass

back the result

Interoperability

CORBA only specifies functionalities, not implementation issues.• Each manifacturer for a CORBA implementation had his own way of enabling

communication between clients and object servers as well as referencing objects→ lack of interoperability

• This problem was solved by the

General Inter-ORB Protocol (GIOP)• Standard protocol for communication in CORBA• Builds upon a reliable, connection oriented transport protocol• Specifies message types, a 'Common Data Representation' (CDR) as transfer

sytax, interoperable object references (IORs), and more

Internet Inter-ORB Protocol (IIOP)• The realisation of GIOP running on top of TCP• Not the only communication protocol implemented, but the widest used

Message Types

Part (fragment) of a larger messageBothFragmentContains information on an errorBothMessageErrorIndication that connection will be closedBothCloseConnectionIndicates client no longer expects a replyClientCancelRequestContains location information on an objectServerLocateReply

Contains a request on the exact location of an objectClientLocateRequest

Contains the response to an invocationServerReplyContains an invocation requestClientRequestDescriptionOriginatorMessage type

GIOP (and thus IIOP or any other realisation of GIOP) knows eight different message types:

Interceptors

• Client implementations are simple: define IDL, generate proxy, done.• But… if an object expects a client to enhance its functionality (e.g. caching), the

client is not enabled to do so.• Thus: some addition is needed enhancing the current software

Interceptors• Mechanism by which an invocation can be intercepted on its way from client to

server and adapted as necessary before letting it continue• Piece of code modifying or analysing a request• General method to achieve extensibility• There may be various interceptors added to an ORB• Also possible for server-side• Are seen only by the ORB, the ORB has to invoke them

Interceptors

Marshalling/Unmarshalling Interceptor

outRequestPreMarshal

inReplyPostMarshal

inReplyPreMarshal

outRequestPostMarshal

Client Process

Server Process

request

reply

inRequestPreMarshal

inRequestPostMarshal

outReplyPreMarshal

outReplyPostMarshal

t

Application Process

Example: implementation-specific realisation for the CORBA implementation Orbix:

Types of Interceptors

1. Request level interceptor: is logically placed between a client's proxy and the ORB• Comes in before an invocation request is passed to the ORB • The interceptor may modify the request• On server side, it is placed between the ORB and the object adapter

2. Message level interceptor: placed between an ORB and the underlying network• Knows nothing about the message content that is to be sent• Only sees GIOP messages that it could modify

add additional information, e.g. for instructing a server process or enhance a client by caching

modify request, e.g. for fragmenting large GIOP messages or to transparently redirect a request by exchanging the IOR

Both types: add monitors to analyse the performance of communications

AgentsCORBA adopts a model allowing agents of different systems to co-operate• Prescribes standard interfaces that an agent system should implement (different

types of agents can be used in a single distributed application)• Agent system: a platform that allows the creation, execution, transfer, and

termination of agents• Each agent system has an associated profile describing exactly what the

agent system looks like• An agent is always located at a particular place (server) in an agent system.

There can be multiple places in an agent system• Agent systems are grouped in regions. Thesre are administrative domains in

which an agent system resides

Agents

• An agent in CORBA is assumed to be constructed from a collection of classes• It should be possible to name an agent's implementation, and pass that name to an

agent system to allow the creation or transfer of an agent• Each agent system must implement a number of standard operations (create or

terminate an agent, receive an agent for execution, list the current set of agents, list the places where an agent may reside, suspend and resume an agent)

• Each region has an associated finder to find the location of agents, places and agent systems (simple directory service for a region)

CORBAservicesCORBAservices are general purpose and application independent services. CORBAservices strongly resemble the types of services commonly provided by an operating system.

Provides the current time within specified error marginsTime

Mechanisms for secure channels, authorisation, and auditingSecurity

Facilities for expressing relationships between objectsRelationship

Facilities for persistently storing objectsPersistence

Facilities to publish and find the services on object has to offerTrading

Facilities for associating (attribute, value) pairs with objectsProperty

Facilities for system-wide name of objectsNaming

Facilities for attaching a license to an objectLicensing

Facilities for creation, deletion, copying, and moving of objectsLifeCycle

Facilities for marshaling and unmarshaling of objectsExternalization

Advanced facilities for event-based asynchronous communicationNotification

Facilities for asynchronous communication through eventsEvent

Flat and nested transactions on method calls over multiple objectsTransaction

Facilities to allow concurrent access to shared objects (locking)Concurrency

Facilities for querying collections of objects in a declarative mannerQuery

Facilities for grouping objects into lists, queue, sets, etc.Collection

DescriptionService

Event Service

Asynchronous communication can by realised with one-way calls, but…• One-way calls are best effort• Overhead when simply a signalling information should be transmitted

→ Communication by events

CORBA's Event Service• Provide a service that could simply signal the occurance of an event.• In this model each event is associated with a single data item, generally

represented by means of an object reference or otherwise an application-specific value.

• An event is produced by a supplier and received by a consumer• The event service offers an event channel which is logically placed betwenn

suppliers and consumers and suits for delivering events

Push and Pull Model

Push model:• Whenever en event occures, the supplier produces the event and pushes it

through the event channel• Event channel passes the event on to its consumers• In this model consumers passively wait for event propagation and expect to be

interrupted when an event happens

Pull model:• Consumers poll the the event channel to check whether an event has happened• The event channel in turn polls the various suppliers

Note: the models can be combined

How does it work?• For both, consumers and suppliers, proxies (for push and pull operations) are

implemented in the event channel.• Consumer and producer use synchronous communication with these proxies for

the time delivering or getting events

Event Channel

PushSupplier 1

PushSupplier n

PullSupplier 1

PullSupplier m

PushConsumer 1

PushConsumer r

PullConsumer 1

PullConsumer s

Event Channel

ProxyPushConsumer

ProxyPullConsumer ProxyPullSupplier

ProxyPushSupplier

...

......

...

Notification Service

Event services drawbacks:• CORBA's event service does not support persistence of events. If a consumer

connects to the event channel too late, events get lost• Consumers have no chance to filter events. Each event is passed to every

consumer. If different event types need to be distinguished it is necessary to set on a separate event channel for each event type.

• Event propagation is unreliable. No guarantees need to be given concerning the dilivery of events

→ Notification service• Event typing• Filtering capabilities have been added • Offers facilities to prevent event propagation when no consumers are

interested in a specific event

Messaging• Communication in CORBA is transient• Many applications require persistent communication as offered by message

queuing• CORBA supports this model as an additional messaging service• Messaging in CORBA is different because it is inherent object based approach

in communication .• Two models for messaging:

! Callback modelA client implements a callback method. The communication system calls this method to deliver a result from an asynchronous requestIt is the client's responsibility to transform the original synchronous invocation into an asynchronous oneThe server is presented a normal (synchronous) invocation request

! Polling modelThe client is offered a collection of operations to poll its ORB for incoming results It is the client's responsibility to transform the original synchronous invocation into an asynchronous one

Callback Model

Constructing an asynchronous invocation is done in two steps:1. The original interface as implemented by the object is replaced by two new

interfaces that are to be implemented by the client-side software:" Specification of methods that the client can call; none of these methods

returns a value or has any output parameter " Callback interface

2. This step consists of simply compiling the generated interfaces

Original method:

int add(in int I, in int j, out int k);

New methods:

void sendcb_add(in int I, in int j);

void replycb_add(in int ret_val, in int k);

Polling Model

• Again, the original method is replaced by two new methods• The ORB has to provide the second method

Original method:

int add(in int I, in int j, out int k);

New methods:

void sendpoll_add(in int I, in int j);

void replypoll_add(out int ret_val, out int k);

Naming

• CORBA supports different types of names• Most basic types, object references and character-based names, are supported by

the CORBA naming service• There are a number of advance naming facilities whereby objects can found based

on associated properties• Independently from logical object names, CORBA objects can be addresses by

URLs:– iioploc://appserver.klick-and-bau.com:4711/object-24

references the CORBA object which can be connected to on host'appserver.klick-and-bau.com' using port 4711 and object identifier 'object-24'

– iiopname://appserver.klick-and-bau.com/Buchhaltung/Stammdaten/ArtikelHomereferences the CORBA object which the naming service on host'appserver.klick-and-bau.com' knows by the name'Buchhaltung/Stammdaten/ArtikelHome'

– In both cases, IIOP is used as communication protocol

Object References

• A client needs an object reference to invoke a method at an object• A client resp. a server uses a language specific implementation of an object

reference - in most cases this is a pointer to a local representation of the object• That reference cannot be passed from a process A to process B• Process A will first have to marshal the pointer into a process independent

representation (done by the ORB) • The ORB uses an own, language-independent representation• Process B unmarshals it• When a process refers to an object its underlaying ORB is implicitly passed

enough information to know which object is actually being referenced• Common representation of an object reference: Interoperable Object Reference

(IOR)• The IOR is used to pass references to other ORBs. Internally, ORBs can have

their own representation.

Object References

Organization of an IOR with specific information for IIOP:

• Tagged Profile: complete information to invoke an object. If the object serversupports several protocols, multiple tagged profiles are included

• Object key: server-specific information for demultiplexing incoming requests to the object

• Components: optionally contains additional information needed for invoking the referenced object (e.g. security information)

BindingHow does a client bind to an object to invoke a method?• Use a name service to resolve a given name to an object reference (IOR)• Because this IOR references directly to an object, the following is called direct

binding• The client's ORB uses the repository ID to place a proxy at the client and pass a

pointer to this proxy on to the client• The ORB uses a tagged profile, e.g. for IIOP and sets up a TCP connection with

the object's server• A client's invocation is marshalled into an IIOP request message and sent over

the TCP connection to the POA associated with the object key• The POA forwards the request to the proper servant where it is unmarshalled and

transformed into an actual method call

Alternative: indirect binding• An implementation repository is involved• The implementation repository is identified in the IOR• It acts as a registry to locate and activate an object before transmitting invocations• primarily used for persistent objects

Indirect Binding

• First step: binding to the implementation repository• The repository checks if the server is already running. If yes, it checks, where it is

located. If no, the repository starts it• When the client invokes the referenced object for the first time, the invocation

request is sent to the implementation repository which responds by giving the details where the object's server can actually be reached

• So the invocation requests are forwarded to the proper server

CORBA Naming Service• Used to look up object references using a character based name• Names in CORBA are sequences of name components each taking the form of a

(id,kind)-pair, where id and kind are both strings: id is used to name an object, kind is a simple indication of the name object (e.g. 'dir' for a directory object)

• The representation of a sequence is a language dependent• There are no restrictions with respect to the structure of a naming graph.• Each node in a naming graph is treated as an object • Naming context: an object that stores a table mapping name components to

object references (like directory node)• Naming graph does not have a root context, however each ORB is required to

provide an initial naming context which effectively operates as the root in a naming graph

• Names are always resolved with respect to a given naming context• A client resolves a name by invoking the resolve method on a specific naming

context• If name resolution succeeds, it always returns either a reference to a naming

context or a reference to a named object• Name resolution proceeds exactly as presented in part 3 of the lecture

Part of the CORBA Naming Service Interface in IDL

struct NameComponent { string id; string kind; };

typedef sequence <NameComponent> Name;

interface NamingContext {void bind (in Name n, in Object obj);

binds the given name and remote object reference in my contextvoid unbind (in Name n);

removes an existing binding with the given namevoid bind_new_context(in Name n);

creates a new naming context and binds it to a given name in my contextObject resolve (in Name n);

looks up the name in my context and returns its remote object referencevoid list (in unsigned long how_many, out BindingList bl,

out BindingIterator bi);

returns the names in the bindings in my context};

How to Find the First NamingContext?

• The CORBA name service allows you to search a name context and to navigate through several name contexts. This works as in other name services. But… how to find the root context, i.e. the naming service itself?

• The naming service is identified by an object reference…• To solve the problem, the ORB itself is responsible to provide facilities to get

initial object references. A reference to the root context can be got by calling the function resolve_initial_reference("Name Service") provided by the ORB:

interface ORB {

...

Object resolve_initial_references (in String name);

...

}

• CORBA defines some more names the ORB has to resolve, e.g. "RootPOA" and "InterfaceRepository". Further names can be configured by the administrator.

Synchronisation andTransactions

Two important services that facilitate synchronisation in CORBA are the Concurrency control service and the Transaction service

• The two services collaborate to implement distributed and nested transactions using two phase locking! A tranaction is initiated by a client and consists of a series of invocations on

objects. When an object is invoked for the first time it automatically becomes part of the tranaction. This information is passed to the server when invoking the object

! Two types of objects can be part of a transaction:! Recoverable object: is executed by an object server capable of participating

in two phase commit protocol ! Transactional objects: executed by server that do not participate in a

transaction's two phase commit protocol (typically read-only objects)• CORBA transactions are similar to distributed transactions and their protocols as

presented in the 6th part of the lecture• The service is implemented using a central lock manager; it does not use

distributed locking techniques• The service distinguishes read from write locks and is also capable of supporting

locks at different granularities (e.g. whole tables vs. single records)

Replication and Fault Tolerance

• CORBA offers no support for generic caching and replication• Application developers have to resort to an ad-hoc approach when replication is

needed (such approaches are often based on using interceptors)• Only the replication of objects for fault tolerance is included in the current CORBA

version 3

Fault Tolerance• Dealing with failures: replicate objects into object groups, consisting of identical

copies of an object referenced as if it would be a single object.• A group offers the same interface as the objects it contains• Uses a special kind of an IOR, the Interoperable Object Group Reference (IOGR)

Fault Tolerance

• Supported strategies: passive replication, active replication, quorum-based replication

• When a client passes an IOGR to the ORB, the ORB attempts to bind to one ofthe replicas. The Components filed could refer to the primary or a copy of the object's replicas

• If binding fails, the ORB can try another copy

Fault Tolerance

• Replication manager: creating and managing object groups, replacing replicas incase of a failure

• Interceptors are used to pass invocations to a separate replication component maintaining consistency and realising recoverability

Comparison of CORBA, DCOM and Globe

NoNoYesTrading serviceNoYesYesDirectory serviceObject dependentHard-codedFlexible (POA)Object serverNoYesYesMessagingNoYesYesEventsNoYesYesCallbacks

NoYesYesAsynchronous communication

YesYesYesSynchronous communication

BinaryBinaryIDL basedInterfacesFewFrom environmentMany of its ownServices Distributed objectsRemote objectsRemote objectsObject modelScalabilityFunctionalityInteroperabilityDesign goalsGlobeDCOMCORBAIssue

Comparison of CORBA, DCOM and Globe

GlobeDCOMCORBAIssue

More work neededVarious mechanisms

Various mechanisms

SecurityNoBy transactionsYesRecovery supportBy replicationBy transactionsBy replicationFault toleranceNoYesYesTransactions

Separate subobject

NoneSeparate serverReplication support

Only intra-objectTransactionsTransactionsSynchronisationTrue identifierInterface pointerObject's locationObject referenceYesNoNoLocation serviceYesYesYesNaming service