1. © Chinese University, CSE Dept. Distributed Systems / 4 - 1 Distributed Systems Topic 4: RPCs vs. CORBA Dr. Michael R. Lyu Computer Science & Engineering Department The Chinese University of Hong Kong

2. © Chinese University, CSE Dept. Distributed Systems / 4 - 2 Outline 1. Conceptual Framework 2. RPCs 3. CORBA 4. Comparison 5. Summary

3. © Chinese University, CSE Dept. Distributed Systems / 4 - 3 1 Conceptual Framework u Architecture. u Accessing components from programming languages. u Interfaces to lower layers. u Component identification (to achieve location transparency). u Service invocation styles. u Handling of failures.

4. © Chinese University, CSE Dept. Distributed Systems / 4 - 4 2 Remote Procedure Calls u Overview of RPC architecture. u Generation of client/server stubs. u RPC interface. u Binding. u Handling of remote procedures. u Failures of RPCs.

5. © Chinese University, CSE Dept. Distributed Systems / 4 - 5 2.1 RPC Architecture ClientServer Network Local Call Client Stub RPC Interface RPC Interface Server Stub Remote Procedure sendreceivesendreceive

6. © Chinese University, CSE Dept. Distributed Systems / 4 - 6 2.2 The RPC Language u 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. © Chinese University, CSE Dept. Distributed Systems / 4 - 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. © Chinese University, CSE Dept. Distributed Systems / 4 - 8 2.2 Generation of Stubs 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. © Chinese University, CSE Dept. Distributed Systems / 4 - 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. © Chinese University, CSE Dept. Distributed Systems / 4 - 10 /* client.c */ print_person(char * host, Person * pers) {... if (print_0(pers, clnt)==NULL) /* call failed /*... } 2.2 Use of Stubs

11. © Chinese University, CSE Dept. Distributed Systems / 4 - 11 2.3 RPC Interface u Used by client or server directly: –Locating servers. –Choosing a transport protocol. –Authentication and security. –Invoking RPCs dynamically. u Used by stubs for: –Generating unique message IDs. –Sending messages. –Maintaining message history.

12. © Chinese University, CSE Dept. Distributed Systems / 4 - 12 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); } 2.3 RPC Interface

13. © Chinese University, CSE Dept. Distributed Systems / 4 - 13 2.4 Binding u How to locate an RPC server that can execute a given procedure in a network? u Can be done –statically (i.e. at compile-time) or –dynamically (i.e. at run-time). u Dynamic binding is supported by portmap daemons.

14. © Chinese University, CSE Dept. Distributed Systems / 4 - 14 2.5 Handling of Remote Procedures u Call handled synchronously by server. u Concurrent RPCs: –serial or –concurrently. u Server availability: –continuous or –on-demand.

15. © Chinese University, CSE Dept. Distributed Systems / 4 - 15 2.6 Failures of RPCs u Machines or networks can fail at any time. u At most once semantics. u RPC return value indicates success. u Up to the client to avoid maybe semantics!

16. © Chinese University, CSE Dept. Distributed Systems / 4 - 16 3 CORBA u Object management architecture. u Accessing remote objects. u ORB interface. u Object identification u Activation strategies. u Request vs. notification. u Handling of failures.

17. © Chinese University, CSE Dept. Distributed Systems / 4 - 17 3.1 Object Management Architecture Application Objects CORBA facilities CORBA services Object Request Broker

18. © Chinese University, CSE Dept. Distributed Systems / 4 - 18 3.2 Accessing Remote Objects DynamicInvocationClientStubsORBInterfaceServerSkeletonObjectAdapter ORB Core Client Object Implementation

19. © Chinese University, CSE Dept. Distributed Systems / 4 - 19 3.2 Stub/Skeleton Generation (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

20. © Chinese University, CSE Dept. Distributed Systems / 4 - 20 3.2 Static vs. Dynamic Invocation u Static invocation: IDL operations must have been defined before client can be developed. u Does not suit every application. u Dynamic invocation interface enables clients to define operation invocations at run-time. u Interface repository can be used to ensure that calls are type safe.

21. © Chinese University, CSE Dept. Distributed Systems / 4 - 21 3.3 ORB Interface  Object type Object. u Initialization of object request broker. u Initialization of client / server applications. u Programming interface to interface repository.

22. © Chinese University, CSE Dept. Distributed Systems / 4 - 22 3.4 Object Identification u Objects are uniquely identified by object identifiers. u Object identifiers are persistent. u Identifiers can be externalized and internalized. u Identifiers can be obtained –from naming service or trading service, –by reading attributes, –from an operation result or –by internalizing an externalized reference.

23. © Chinese University, CSE Dept. Distributed Systems / 4 - 23 3.5 Activation Strategies C Basic Object Adapter Process Object A B D AShared Server BUnshared Server CServer per method DPersistent server Registration Activation

24. © Chinese University, CSE Dept. Distributed Systems / 4 - 24 3.5 Request vs. Notification u IDL operations are handled synchronously. u 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. u Client continues after notification is delivered.

25. © Chinese University, CSE Dept. Distributed Systems / 4 - 25 3.5 Notification (Example) /* 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); };

26. © Chinese University, CSE Dept. Distributed Systems / 4 - 26 3.6 Failures u CORBA operation invocations may fail for the same reasons as RPCs. u Failures are treated differently. u Exceptions give detailed account why an operation has failed. u System vs. application specific exceptions.

27. © Chinese University, CSE Dept. Distributed Systems / 4 - 27 4 Comparison u RPC architecture lacks interface repository. u IDL is more expressive than RPCL: –inheritance, –attributes and –exceptions. u IDL has multiple standardized language bindings.

28. © Chinese University, CSE Dept. Distributed Systems / 4 - 28 4 Comparison (cont´d) u Component identification is reflexive in IDL. u Basic object adapter provides more flexible activation strategies. u Oneway operations can be used for asynchronous notifications. u Handling of failures with exceptions is more expressive than returning a NULL pointer.

29. © Chinese University, CSE Dept. Distributed Systems / 4 - 29 4 Comparison (cont´d) u RPCs may be more efficient than CORBA operation invocations. u RPCs come with the UNIX OS whilst you would have to buy a CORBA product. u CORBA is more widely available on non-UNIX platforms. u RPCs are lightweight.

30. © Chinese University, CSE Dept. Distributed Systems / 4 - 30 5 Summary u What are the basic conceptual framework in procedure call in distributed systems? u What is RPC? How does it work? u How does CORBA handle remote procedures? u What are the similarities between RPC and CORBA? How do they differ? u Read Textbook Chapter 5.