2. 1DT057 D ISTRIBUTED I NFORMATION S YSTEM Middleware: RPC and CORBA 1

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

4. 1 C ONCEPTUAL F RAMEWORK Architecture. Accessing components from programming languages. Interfaces to lower layers. Component identification (to achieve location transparency ). Service invocation styles. Handling of failures. 3

5. 4 RPC

6. 2 R EMOTE P ROCEDURE C ALLS Overview of RPC architecture. Generation of client/server stubs. RPC interface. Binding. Handling of remote procedures. Failures of RPCs. 5

7. 2.1 RPC A RCHITECTURE ClientServer Network Local Call Client Stub RPC Interface RPC Interface Server Stub Remote Procedure sendreceivesendreceive 6

8. 2.2 T HE RPC L ANGUAGE 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

9. 2.2 T HE RPC L ANGUAGE (E XAMPLE ) /* 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

10. 2.2 G ENERATION OF S TUBS rpcgen person.x client.c server.c C Compiler, Linker person.h person_clnt.c person_svc.c person_xdr.c ClientServer includes generates reads librpc.a 9

11. 2.2 I MPLEMENTATION OF S ERVER /* 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

12. 2.2 U SE OF S TUBS /* client.c */ print_person(char * host, Person * pers) {... if (print_0(pers, clnt)==NULL) /* call failed /*... } 11

13. 2.3 RPC I NTERFACE 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

14. 2.3 RPC I NTERFACE 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

15. 2.4 B INDING 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

16. 2.5 H ANDLING OF R EMOTE P ROCEDURES Call handled synchronously by server. Concurrent RPCs: serial or concurrently. Server availability: continuous or on-demand. 15

17. 2.6 F AILURES OF RPC S 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

18. CORBA 17

19. 3 T HE CORBA O BJECT M ODEL Components  objects. Visible component state  object attributes. Usable component services  object operations. Component interactions  operation execution requests. Component service failures  exceptions. 18

20. 3 T HE OMG I NTERFACE D EFINITION L ANGUAGE 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

21. 3 Automatic Teller Machine Example 20

22. 3.1 T YPES OF D ISTRIBUTED O BJECTS 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

23. 3.1 T YPES 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

24. 3.1 T YPES (E XAMPLES ) struct Requester { int PIN; string AccountNo; string Bank; }; typedef sequence ATMList; 23

25. 3.2 A TTRIBUTES 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

26. 3.2 A TTRIBUTES (E XAMPLES ) readonly attribute ATMList ATMs; readonly attribute BankList banks; 25

27. 3.3 E XCEPTIONS 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

28. 3.3 E XCEPTIONS (E XAMPLE ) exception InvalidPIN; exception InvalidATM; exception NotEnoughMoneyInAccount { short available; }; 27

29. 3.4 O PERATIONS 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

30. 3.4 O PERATIONS (E XAMPLES ) void accept_request(in Requester req, in short amount) raises(InvalidPIN, NotEnoughMoneyInAccount); short money_in_dispenser(in ATM dispenser) raises(InvalidATM); 29

31. 3.5 I NTERFACES 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

32. 3.5 I NTERFACES (E XAMPLE ) interface ATM; interface TellerCtrl { typedef sequence 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

33. 3.6 M ODULES 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

34. 3.6 M ODULES (E XAMPLE ) module Bank { interface AccountDB {}; }; module ATMNetwork { typedef sequence BankList; exception InvalidPIN; interface ATM; interface TellerCtrl {...}; }; 33

35. 3.7 I NHERITANCE 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

36. 3.7 I NHERITANCE (E XAMPLES ) interface Controllee; interface Ctrl { typedef sequence CtrleeList; readonly attribute CtrleeList controls; void add(in Controllee new_controllee); void discard(in Controllee old_controllee); }; interface ATM : Controllee {...}; interface TellerCtrl : Ctrl {...}; 35

37. 3.7 I NHERITANCE (M ULTIPLE ) 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

38. 4 CORBA R EMOTE I NVOCATION Object management architecture. Accessing remote objects. ORB interface. Object identification Activation strategies. Request vs. notification. Handling of failures. 37

39. 4.1 O BJECT M ANAGEMENT A RCHITECTURE Application Objects CORBA facilities CORBA services Object Request Broker 38

40. One standardized interface One interface per object operation ORB-dependent interface One interface per object adapter Dynamic Invocation Dynamic Invocation Client Stubs Client Stubs ORB Interface ORB Interface Implementation Skeletons Implementation Skeletons Client Object Implementation ORB Core Object Adapter Object Adapter 4.2 A CCESSING R EMOTE O BJECTS 39

41. 4.2 S TUB /S KELETON G ENERATION ( FOR C++) IDL-Compiler Person.idl Client.cc Server.cc C++ Compiler, Linker Personcl.hh Personcl.cc Personsv.cc Personsv.hh ClientServer includes generates reads 40

42. 4.2 Stub/Skeleton Generation (for JAVA) IDL-Compiler(IDL2java) Person.idl ClientImp.java ServerImp.java Java Virtual Machine, VBJ NamingContext objects Person.java ServerStub.java NamingContext objects ClientServer resolve generates Invoke Bind Resolve Read ClientStub.java Import Operation.java 41

43. 4.2 S TATIC VS. D YNAMIC I NVOCATION Static invocation: IDL operations must have been defined before client can be developed. Does not suit every application. Dynamic invocation interface enables clients to define operation invocations at run-time. 42

44. 4.3 ORB I NTERFACE Object type Object. Initialization of object request broker. Initialization of client / server applications. Programming interface to interface repository. 43

45. 4.4 O BJECT I DENTIFICATION Objects are uniquely identified by object identifiers. Object identifiers are persistent. Identifiers can be externalized and internalized. Identifiers can be obtained from naming service or trading service, by reading attributes, from an operation result or by internalizing an externalized reference. 44

46. 4.5 A CTIVATION S TRATEGIES C Basic Object Adapter Process Object A B D AShared Server BUnshared Server CServer per method DPersistent server Registration Activation 45

47. 4.5 R EQUEST VS. N OTIFICATION IDL operations are handled synchronously. For notifications, it may not be necessary to await server, if operation does not have a return value, have out or inout parameters and raise specific exceptions. Notification can be implemented as oneway operations in IDL. Client continues after notification is delivered. 46

48. 4.5 N OTIFICATION (E XAMPLE ) /* person.idl */ enum sex_type { FEMALE, MALE }; struct Person { string first_name; string last_name; sex_type sex; string city; }; interface PersonManager { oneway void print(in Person); long store(in Person pers); Person load(in long pers_id); }; 47

49. 4.6 F AILURES CORBA operation invocations may fail for the same reasons as RPCs. Failures are treated differently. Exceptions give detailed account why an operation has failed. System vs. application specific exceptions. 48

50. 5 C OMPARISON 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

51. 5 C OMPARISON ( CONT ´ D ) Component identification is reflexive in IDL. Basic object adapter provides more flexible activation strategies. Oneway operations can be used for asynchronous notifications. 50

52. 5 C OMPARISON ( 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

53. 6 S UMMARY 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