Explain the Client- Server Interface Using Procedures

Developers must realize that client-server impose a division of labor in application programs. Programs must be broken up into components, each communicating with the other through well-defined interfaces. These interface boundaries may be the procedures within the program and may hide the fact that the functions may be executing on or communicating with other machines. Components may interact via a Request/Response mechanism implemented at the procedure level.

This is the scenario employed by RPCs and their related technologies. A procedure makes a request of another to provide some service of which it expects results to be returned. There is a clear definition of the request and response components, and the only overlap of the two is the parameters they pass and return. These responding procedures can then be migrated to the server for processing. The example to follow will document this process in great detail. It employs pseudocode to help document programmatically what a sample interface might resemble. For my procedural components, I chose to implement a single interface for all client -server interaction. Doing this focuses the stand- alone application developer into a well- defined interface (although still very flexible). In fact, the example will document the process a procedural interface must go through to be transformed into client-server. Generally, a developer wouldn't have to perform all these duties, as an RPC pre-compiler might provide and mask these requirements. It is a very good exercise, however, to document the procedural flow required between client and server.