1 DT 057 DISTRIBUTED INFORMATION SYSTEM Middleware RPC

1 DT 057 DISTRIBUTED 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

RPC 4

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 Local Call Remote Procedure Client Stub Server Stub RPC Interface Client RPC Interface send receive send Server receive 6 Network

2. 2 THE RPC LANGUAGE Definition of types (similar to C). Component is described as a 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; string last_name; sex_type sex; string city; }; program PERSONPROG { version PERSONVERS { void PRINT(Person)=0; int STORE(Person)=1; Person LOAD(int)=2; } = 0; } = 105040; 8

2. 2 GENERATION OF STUBS person. x person_clnt. c client. c rpcgen person_svc. c person. h server. c person_xdr. c C Compiler, Linker Client librpc. a includes generates reads C Compiler, Linker Server 9

2. 2 IMPLEMENTATION OF SERVER /* server. c */ void * print_0(Person *argp, struct svc_req * rqstp) { static char * result; printf("%s %snn", 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 INTERFACE print_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 Account. No; string Bank; }; typedef sequence 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 Bank. List 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 Invalid. PIN; exception Invalid. ATM; exception Not. Enough. Money. In. Account { 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(Invalid. PIN, Not. Enough. Money. In. Account); short money_in_dispenser(in ATM dispenser) raises(Invalid. ATM); 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 Teller. Ctrl { typedef sequence ATMList; exception Invalid. PIN; exception Not. Enough. Money. In. Account {. . . }; readonly attribute ATMList ATMs; readonly attribute Bank. List banks; void accept_request(in Requester req, in short amount) raises(Invalid. PIN, Not. Enough. Money. In. Account); 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 Account. DB {}; }; module ATMNetwork { typedef sequence Bank. List; exception Invalid. PIN; interface ATM; interface Teller. Ctrl {. . . }; }; 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 Ctrlee. List; readonly attribute Ctrlee. List controls; void add(in Controllee new_controllee); void discard(in Controllee old_controllee); }; interface ATM : Controllee {. . . }; interface Teller. Ctrl : 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 Teller. Ctrl: Set, Ctrl {. . . }; Name clashes are not allowed! 36

4. 1 OBJECT MANAGEMENT ARCHITECTURE Application Objects CORBA facilities Object Request Broker CORBA services 38

4. 2 ACCESSING REMOTE OBJECTS Object Implementation Client Dynamic Invocation Client Stubs ORB Interface Implementation Skeletons Object Adapter ORB Core One standardized interface One interface per object operation One interface per object adapter ORB-dependent interface 39

4. 2 STUB/SKELETON GENERATION (FOR C++) Person. idl Client. cc Server. cc IDL-Compiler Personcl. hh Personsv. hh Personcl. cc Personsv. cc C++ Compiler, Linker Client C++ Compiler, Linker includes generates reads Server 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