PreviousNext

The Remote Procedure Call Model

A remote procedure call executes a procedure located in a separate address space from the calling code. The RPC model is a well-tested, industry-wide framework for distributing applications. The RPC model is derived from the programming model of local procedure calls and takes advantage of the fact that every procedure contains a procedure declaration. The procedure declaration defines the interface between the calling code and the called procedure. The procedure declaration defines the call syntax and parameters of the procedure. All calls to a procedure must conform to the procedure declaration.

Applications that use remote procedure calls look and behave much like local applications. However, an RPC application is divided into two parts: a server, which offers one or more sets of remote procedures, and a client, which makes remote procedure calls to RPC servers. A server and its clients generally reside on separate systems and communicate over a network. RPC applications depend on the RPC runtime to control network communications for them. The DCE RPC runtime supports additional tasks, such as finding servers for clients and managing servers.

A distributes application uses dispersed computing resources such as CPUs, databases, devices, and services. The following are examples:

· A calendar-management application that allows authorized users to access the personal calendars of other users.

· A graphics application that processes data on central CPUs and displays the results on workstations.

· A manufacturing application that shares information about assembly components among design, inventory, scheduling, and accounting programs located on different computers.

DCE RPC meets the basic requirements of a distributed application, including

· Clients finding the appropriate servers

· Data conversion for operating in a heterogeneous environment

· Network communications

Distributed applications include tasks such as managing communications, finding servers, providing security, and so forth. A standalone distributed application needs to perform all of these tasks itself. Without a convenient mechanism for these distributed computing tasks, writing distributed applications is difficult, expensive, and error-prone.

DCE RPC software provides the code, called stubs, and the RPC runtime that perform distributed computing tasks for your applications. This code and the runtime libraries are linked with client and server application code to form an RPC application.

The following table shows the basic tasks for the client and server of a distributed application. Calling the procedure and executing the remote procedure, shown in bold text, are performed by your application code (just as in a local application) but here they are in the client and server address spaces. For the other tasks, some are performed automatically by the stubs and RPC runtime, while others are performed by the RPC runtime via API calls in your application.


Basic Tasks of an RPC Application

Client Tasks Server Tasks
1. Select network protocols.
2. Register RPC interfaces.
3. Register endpoints in endpoint map.
4. Advertise RPC interfaces and objects in the namespace.
5. Listen for calls.
6. Find compatible servers that offer the procedures.
7. Call the remote procedure.
8. Establish a binding with the server.
9. Convert input arguments into network data.
10. Transmit arguments to the server's runtime.
11. Receive a call.
12. Disassemble network data and convert input arguments into local data.
13. Locate and invoke the called procedure.
14. Execute the remote procedure.
15. Convert the output arguments and return value into network data.
16. Transmit results to the client's runtime.
17. Receive results.
18. Disassemble network data and convert output arguments into local data.
19. Return results and control to calling code.
More:

RPC Application Code

Stubs

The RPC Runtime

RPC Application Components That Work Together

Overview of DCE RPC Development Tasks