1DT057 Distributed Information System

1. 1DT057Distributed Information System Middleware: RPC and CORBA

2. Outline 1. Conceptual Framework 2. RPCs 3. CORBA Object Model 4. CORBA Remote Invocation 5. Comparison 6. Summary

3. 1 Conceptual Framework • Architecture. • Accessing components from programming languages. • Interfaces to lower layers. • Component identification (to achieve locationtransparency). • Service invocation styles. • Handling of failures.

4. RPC

5. 2 Remote Procedure Calls • Overview of RPC architecture. • Generation of client/server stubs. • RPC interface. • Binding. • Handling of remote procedures. • Failures of RPCs.

6. Client Server Remote Procedure Local Call Client Stub Server Stub RPC Interface RPC Interface send receive send receive Network 2.1 RPC Architecture

7. 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.

8. 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;

9. person.x rpcgen person_clnt.c person_svc.c client.c person.h server.c person_xdr.c C Compiler, Linker C Compiler, Linker librpc.a includes generates reads Client Server 2.2 Generation of Stubs

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

11. 2.2 Use of Stubs /* client.c */ print_person(char * host, Person * pers) { ... if (print_0(pers, clnt)==NULL) /* call failed /* ... }

12. 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.

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

14. 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.

15. 2.5 Handling of Remote Procedures • Call handled synchronously by server. • Concurrent RPCs: • serial or • concurrently. • Server availability: • continuous or • on-demand.

16. 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!

17. CORBA

18. 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.

19. 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.

20. 3 Automatic Teller Machine Example

21. 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.

22. 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).

23. 3.1 Types (Examples) struct Requester { int PIN; string AccountNo; string Bank; }; typedef sequence<ATM> ATMList;

24. 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.

25. 3.2 Attributes (Examples) readonly attribute ATMList ATMs; readonly attribute BankList banks;

26. 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.

27. 3.3 Exceptions (Example) exception InvalidPIN; exception InvalidATM; exception NotEnoughMoneyInAccount { short available; };

28. 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.

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

30. 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.

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

32. 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.

33. 3.6 Modules (Example) module Bank { interface AccountDB {}; }; module ATMNetwork { typedef sequence<Bank::AccountDB> BankList; exception InvalidPIN; interface ATM; interface TellerCtrl {...}; };

34. 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.

35. 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 {...};

36. 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!

37. Application Objects CORBAfacilities Object Request Broker CORBAservices 4.1 Object Management Architecture

38. Object Implementation Client Implementation Skeletons Object Adapter Dynamic Invocation ORB Interface Client Stubs ORB Core One standardized interface One interface per object operation One interface per object adapter ORB-dependent interface 4.2 Accessing Remote Objects

39. Person.idl Client.cc Server.cc IDL-Compiler Personcl.hh Personsv.hh Personcl.cc Personsv.cc C++ Compiler, Linker C++ Compiler, Linker includes generates reads Client Server 4.2 Stub/Skeleton Generation (for C++)

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.

41. 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.

42. 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.