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

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

© Chinese University, CSE Dept. Distributed Systems / 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.

© Chinese University, CSE Dept. Distributed Systems / 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.

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

© Chinese University, CSE Dept. Distributed Systems / 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.

© Chinese University, CSE Dept. Distributed Systems / 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; } = ;

© Chinese University, CSE Dept. Distributed Systems / 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

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

© Chinese University, CSE Dept. Distributed Systems / /* client.c */ print_person(char * host, Person * pers) {... if (print_0(pers, clnt)==NULL) /* call failed /*... } 2.2 Use of Stubs

© Chinese University, CSE Dept. Distributed Systems / 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.

© Chinese University, CSE Dept. Distributed Systems / 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

© Chinese University, CSE Dept. Distributed Systems / 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.

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

© Chinese University, CSE Dept. Distributed Systems / 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!

© Chinese University, CSE Dept. Distributed Systems / 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.

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

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

© Chinese University, CSE Dept. Distributed Systems / 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

© Chinese University, CSE Dept. Distributed Systems / 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.

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

© Chinese University, CSE Dept. Distributed Systems / 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.

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

© Chinese University, CSE Dept. Distributed Systems / 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.

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

© Chinese University, CSE Dept. Distributed Systems / 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.

© Chinese University, CSE Dept. Distributed Systems / 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.

© Chinese University, CSE Dept. Distributed Systems / 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.

© Chinese University, CSE Dept. Distributed Systems / 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.

© Chinese University, CSE Dept. Distributed Systems / 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.