1 / 30

Distributed Systems

Distributed Systems. Topic 4: RPCs vs. CORBA Dr. Michael R. Lyu Computer Science & Engineering Department The Chinese University of Hong Kong. Outline. 1. Conceptual Framework 2. RPCs 3. CORBA 4. Comparison 5. Summary. 1 Conceptual Framework. Architecture.

phyre
Télécharger la présentation

Distributed Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Outline 1. Conceptual Framework 2. RPCs 3. CORBA 4. Comparison 5. 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. 2 Remote Procedure Calls • Overview of RPC architecture. • Generation of client/server stubs. • RPC interface. • Binding. • Handling of remote procedures. • Failures of RPCs.

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

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

  7. /* 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; 2.2 The RPC Language (Example)

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

  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. 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. 3 CORBA • Object management architecture. • Accessing remote objects. • ORB interface. • Object identification • Activation strategies. • Request vs. notification. • Handling of failures.

  17. Application Objects CORBAfacilities Object Request Broker CORBAservices 3.1 Object Management Architecture

  18. Client Object Implementation Dynamic Invocation Client Stubs ORB Interface Server Skeleton Object Adapter ORB Core 3.2 Accessing Remote Objects

  19. 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 3.2 Stub/Skeleton Generation (for C++)

  20. 3.2 Static vs. Dynamic Invocation • 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. • Interface repository can be used to ensure that calls are type safe.

  21. 3.3 ORB Interface • Object type Object. • Initialization of object request broker. • Initialization of client / server applications. • Programming interface to interface repository.

  22. 3.4 Object Identification • 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.

  23. A A Shared Server B Unshared Server C Server per method D Persistent server D B C Process Basic Object Adapter Object Registration Activation 3.5 Activation Strategies

  24. 3.5 Request vs. Notification • 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.

  25. /* 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); }; 3.5 Notification (Example)

  26. 3.6 Failures • 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.

  27. 4 Comparison • RPC architecture lacks interface repository. • IDL is more expressive than RPCL: • inheritance, • attributes and • exceptions. • IDL has multiple standardized language bindings.

  28. 4 Comparison (cont´d) • Component identification is reflexive in IDL. • Basic object adapter provides more flexible activation strategies. • Oneway operations can be used for asynchronous notifications. • Handling of failures with exceptions is more expressive than returning a NULL pointer.

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

  30. 5 Summary • What are the basic conceptual framework in procedure call in distributed systems? • What is RPC? How does it work? • How does CORBA handle remote procedures? • What are the similarities between RPC and CORBA? How do they differ? • Read Textbook Chapter 5.

More Related