1DT057DISTRIBUTED INFORMATION SYSTEM

Middleware: RPC and CORBA

1

OUTLINE

1. Conceptual Framework

2. RPCs

3. CORBA Object Model

4. CORBA Remote Invocation

5. Comparison

6. Summary

2

1 CONCEPTUAL FRAMEWORK

Architecture.

Accessing components from programming languages.

Interfaces to lower layers.

Component identification (to achieve location transparency).

Service invocation styles.

Handling of failures.

3

4

RPC

2 REMOTE PROCEDURE CALLS

Overview of RPC architecture.

Generation of client/server stubs.

RPC interface.

Binding.

Handling of remote procedures.

Failures of RPCs.

5

2.1 RPC ARCHITECTURE

Client Server

Network

Local Call

ClientStub

RPCInterface

RPCInterface

ServerStub

RemoteProcedure

send receive send receive

6

2.2 THE RPC LANGUAGE Definition of types (similar to C). Component is described as a PROGRAM. PROGRAM has an identification and a version number. PROGRAM exports procedures

Procedures have a result type and a parameter list, Procedure can be called from remote components, Call can be defined statically or dynamically.

7

2.2 THE RPC LANGUAGE (EXAMPLE)/* person.x */const NL=64;enum sex_type { FEMALE = 1,MALE = 2 };struct Person { string first_name<NL>; string last_name<NL>; sex_type sex; string city<NL>; };

program PERSONPROG { version PERSONVERS { void PRINT(Person)=0; int STORE(Person)=1; Person LOAD(int)=2; } = 0;} = 105040;

8

2.2 GENERATION OF STUBS

rpcgen

person.x

client.c server.c

C Compiler, Linker C Compiler, Linker

person.h

person_clnt.c person_svc.c

person_xdr.c

Client Serverincludesgeneratesreads

librpc.a

9

2.2 IMPLEMENTATION OF SERVER

/* server.c */void * print_0(Person *argp, struct svc_req * rqstp){ static char * result; printf("%s %s\n%s\n\n", argp->first_name, argp->last_name, argp->city); return((void *) &result);}

10

2.2 USE OF STUBS

/* client.c */

print_person(char * host, Person * pers) {

...

if (print_0(pers, clnt)==NULL)

/* call failed /*

...

}

11

2.3 RPC INTERFACE

Used by client or server directly: Locating servers. Choosing a transport protocol. Authentication and security. Invoking RPCs dynamically.

Used by stubs for: Generating unique message IDs. Sending messages. Maintaining message history.

12

2.3 RPC INTERFACEprint_person(char * host, Person * pers) { CLIENT *clnt; clnt = clnt_create(host, PERSONPROG, PERSONVERS, "udp"); if (clnt == (CLIENT *) NULL) { exit(1); } if (print_0(pers, clnt)==NULL) clnt_perror(clnt, "call failed"); clnt_destroy(clnt);}

13

2.4 BINDING

How to locate an RPC server that can execute a given procedure in a network?

Can be done statically (i.e. at compile-time) or dynamically (i.e. at run-time).

Dynamic binding is supported by portmap daemons.

14

2.5 HANDLING OF REMOTE PROCEDURES

Call handled synchronously by server.

Concurrent RPCs: serial or concurrently.

Server availability: continuous or on-demand.

15

2.6 FAILURES OF RPCS

Machines or networks can fail at any time.

At most once semantics.

RPC return value indicates success.

Up to the client to avoid maybe semantics!

16

CORBA

17

3 THE CORBA OBJECT MODEL

Components objects. Visible component state object attributes. Usable component services object operations. Component interactions operation execution

requests. Component service failures exceptions.

18

3 THE OMG INTERFACE DEFINITION LANGUAGE

OMG/IDL is a language for expressing all concepts of the CORBA object model.

OMG/IDL is programming-language independent, orientated towards C++, and not computationally complete.

Different programming language bindings are available.

19

3 Automatic Teller Machine Example

20

3.1 TYPES OF DISTRIBUTED OBJECTS

Attributes, operations and exceptions are properties objects may export to other objects.

Multiple objects may export the same properties.

Only define the properties once!

Attributes and operations, and exceptions are defined in object types.

21

3.1 TYPES

A type is one of the following: Atomic types

(void, boolean, short, long, float, char, string), Object types (interface), Constructed types:

Records (struct), Variants (union), and Lists (sequence), or

Named types (typedef).

22

3.1 TYPES (EXAMPLES)

struct Requester {

int PIN;

string AccountNo;

string Bank; };

typedef sequence<ATM> ATMList;

23

3.2 ATTRIBUTES

Attributes are declared uniquely within an interface.

Attributes have a name and a type. Type can be an object type or a non-object

type. Attributes are readable by other components. Attributes may or may not be modifyable by

other components. Attributes correspond to one or two operations

(set/get). Attributes can be declared as read-only. 24

3.2 ATTRIBUTES (EXAMPLES)

readonly attribute ATMList ATMs;

readonly attribute BankList banks;

25

3.3 EXCEPTIONS

Service requests in a distributed system may not be properly executed. Exceptions are used to explain reason of failure to requester of operation execution.

Operation execution failures may be generic or specific.

Specific failures may be explained in specific exceptions.

Exceptions have a unique name. Exceptions may declare additional data

structures.26

3.3 EXCEPTIONS (EXAMPLE)

exception InvalidPIN;

exception InvalidATM;

exception NotEnoughMoneyInAccount {

short available;

};

27

3.4 OPERATIONS

Operations have a unique identifier.

Operations have a parameter list. parameters are in, out or inout, parameter identifiers are unique within the list, and parameter types have been declared.

Operations have a result type.

Operations declare exceptions they may raise.

28

3.4 OPERATIONS (EXAMPLES)

void accept_request(in Requester req,

in short amount)

raises(InvalidPIN,

NotEnoughMoneyInAccount);

short money_in_dispenser(in ATM dispenser)

raises(InvalidATM);

29

3.5 INTERFACES

Attributes, exceptions and operations are defined in interfaces.

Interfaces have an identifier, which denotes the object type associated with the interface.

Interfaces must be declared before they can be used.

Interfaces can be declared forward.

30

3.5 INTERFACES (EXAMPLE)interface ATM;

interface TellerCtrl {

typedef sequence<ATM> ATMList;

exception InvalidPIN;

exception NotEnoughMoneyInAccount {...};

readonly attribute ATMList ATMs;

readonly attribute BankList banks;

void accept_request(in Requester req,

in short amount)

raises(InvalidPIN,NotEnoughMoneyInAccount);

}; 31

3.6 MODULES

A global name space for identifiers is unreasonable.

IDL includes Modules to restrict visibility of identifiers.

Access to identifiers from other modules by qualification with module identifier.

32

3.6 MODULES (EXAMPLE)

module Bank {

interface AccountDB {};

};

module ATMNetwork {

typedef sequence<Bank::AccountDB> BankList;

exception InvalidPIN;

interface ATM;

interface TellerCtrl {...};

};33

3.7 INHERITANCE

Properties shared by several types should be defined only once.

Object types are organized in a type hierarchy. Subtypes inherit attributes, operations and

exceptions from their supertypes. Subtypes can add more specific properties. Subtypes can redefine inherited properties.

34

3.7 INHERITANCE (EXAMPLES)

interface Controllee;

interface Ctrl {

typedef sequence<Controllee> CtrleeList;

readonly attribute CtrleeList controls;

void add(in Controllee new_controllee);

void discard(in Controllee old_controllee);

};

interface ATM : Controllee {...};

interface TellerCtrl : Ctrl {...};35

3.7 INHERITANCE (MULTIPLE)

Multiple Inheritance May cause name clashes if different super-types

export the same identifier. Example: interface Set {

void add(in Element new_elem);

};

interface TellerCtrl:Set, Ctrl { ... }; Name clashes are not allowed!

36

4.1 OBJECT MANAGEMENT ARCHITECTURE

ApplicationObjects

CORBAfacilities

CORBAservices

Object Request Broker

38

One standardized interface

One interface per object operation

ORB-dependent interfaceOne interface per object adapter

DynamicInvocation DynamicInvocation

ClientStubsClientStubs

ORBInterface ORBInterface

Implementation SkeletonsImplementation Skeletons

ClientClient Object ImplementationObject Implementation

ORB CoreORB Core

ObjectAdapter ObjectAdapter

4.2 ACCESSING REMOTE OBJECTS

39

4.2 STUB/SKELETON GENERATION (FOR C++)

IDL-Compiler

Person.idl

Client.cc Server.cc

C++ Compiler, Linker C++ Compiler, Linker

Personcl.hh

Personcl.cc Personsv.cc

Personsv.hh

Client Server

includesgeneratesreads

40

5 COMPARISON

RPC architecture lacks interface repository.

IDL is more expressive than RPCL: inheritance,

attributes and

exceptions.

IDL has multiple standardized language bindings.

Corba handles failures with exceptions which are more expressive than returning a NULL pointer.

49

5 COMPARISON (CONT´D)

RPCs may be more efficient than CORBA operation invocations.

RPCs come with the UNIX OS whilst you would have to buy a CORBA product.

CORBA is more widely available on non-UNIX platforms.

RPCs are lightweight.

51

6 SUMMARY

The basic conceptual framework for remote object invocation in distributed systems.

Definition of RPC and how it works. CORBA object model and IDL. CORBA remote procedure definition and remote

object invocation. The similarities and differences between RPC and

CORBA. Read Textbook Chapters 5 and 20.

52