本文介绍了远程过程调用（RPC）的基本概念及其在分布式应用中的作用。RPC允许客户端与服务器进行通信而无需深入了解网络细节。文章详细解释了RPC的工作原理、接口定义文件的重要性以及绑定方法的不同类型。
Chapter 2: Introduction to RPC
This chapter provides an overview of the Remote Procedure Call (RPC) model. For more information refer to your DCE publications.
2.1 Overview
A Remote Procedure Call is a mechanism which enables you to set up communication between the client and the server in a distributed application without involving you in the details of network communication. An essential part of the RPC mechanism is the definition of the interface between the client and the server. This is contained in an interface definition file . A remote procedure call in client source code is similar to a local procedure call, the difference being that the communication with the remote procedure is through DCE over the network.
2.2 Operation
An RPC distributed application is basically divided into two parts, the client side and the server side. The client side runs on one node and makes requests for services on behalf of the user. The server side runs on another node and services the client's requests. It can offer many remote procedures to an application.
2.2.1 RPC Interfaces and Stubs
The DCE RPC requires an interface definition which is used to generate the RPC stub files. These provide the actual DCE RPC support, as shown in Figure 2-1.
*
Figure 2-1: RPC Interface Structure
The interface definition describes the interface procedures and their associated parameters. Each version of an interface must be exactly the same for all implementations of that interface. As such, various clients from separate applications can call the same interface from remote locations.
Generated RPC stub files perform basic communication functions for remote procedure calls. They use RPC facilities to find servers for clients and send and receive remote procedure calls. They also perform data conversions if necessary and handle the transfer of data between clients and servers.
When a remote procedure call is made from the client application code the call is actually made to the client stub. The client stub converts the call information into internal RPC format and passes the call, with the necessary information to find a server, to the client RPC run-time library which transmits it to the server system across the network. The server RPC run-time library receives the call and passes it to the server stub which converts the information from RPC format to application format.
Then the server stub passes the call to the server where it is executed, and the whole conversion process is reversed as the call response is returned to the client. Figure 2-2 shows the sequence of a remote procedure call.
*
Figure 2-2: Sequence of a Remote Procedure Call
2.2.2 Binding Methods
The relationship between a client process and a server process during a remote procedure call is called binding. Binding information tells a client how to find a particular server. It includes the following:
* A protocol sequence
* The server host
* The endpoint
A binding handle refers to the binding information for one binding process.
Binding information for DCE applications is usually stored on a name service database. The Cell Directory Service (CDS) is a name service particular to DCE. The RPC run-time library holds name service routines which are used to access the CDS.
There are three different possible binding methods:
* Automatic
* Implicit
* Explicit
These are described in the following sections.
2.2.2.1 Automatic Binding
When automatic binding is selected the client stub automatically manages bindings when a remote procedure call is made from an application. The client stub gets the binding handle from the name service database and passes it to the RPC run-time library. This is the most transparent form of binding and requires minimal changes to a client application.
2.2.2.2 Implicit Binding
When implicit binding is selected a binding handle is held in a global area of the client stub. When a remote procedure call is made from an application the stub passes the binding handle to the RPC run-time library. You must write application code to obtain the binding information and set the global binding handle with RPC run-time routine calls.
2.2.2.3 Explicit Binding
When explicit binding is selected a binding handle is passed explicitly as the first parameter when a remote procedure call is made from an application. You must write application code to obtain the binding information and set the binding handle with RPC run-time routine calls.
2.2.3 Micro Focus COBOL Support for DCE RPC
To define a DCE RPC interface an interface definition must be written using the IDL (Interface Definition Language). Currently the DCE IDL definition can only be used to define an RPC interface for C applications. To enable a DCE RPC interface to be defined for COBOL applications Micro Focus DCE support for COBOL applications provides COBOL IDL.
Once a DCE RPC interface has been defined the next step is the generation of stubs and files that provide the actual support for the defined RPC calls. For DCE C applications this is done by using the DCE IDL compiler which uses the DCE IDL definition as input. To provide similar support for COBOL IDL Micro Focus provides the COBIDL utility. This utility takes the COBOL IDL definition as input and generates COBOL copyfiles (instead of C header files) and stubs that provide the actual support for the defined RPC calls. These stubs can be linked to the COBOL application code.
For more information on the COBOL IDL utility COBIDL see the chapters, Introduction to COBOL IDL and COBOL DCE Application Development Using COBIDL.
Micro Focus also provides a utility, COBDAG, that enables the automatic generation of DCE RPC support for native COBOL applications. The only input required is the actual source code of the COBOL application. It generates an executable COBOL/DCE server and client as its output.
For more information on the COBDAG utility see the chapters, Introduction to COBDAG and COBOL DCE Application Development Using COBDAG.
Copyright © 1996 Micro Focus Limited. All rights reserved.
This document and the proprietary marks and names used herein are protected by international law.
link:http://www.docs.hp.com/en/64/ll/llrpci.htm
This chapter provides an overview of the Remote Procedure Call (RPC) model. For more information refer to your DCE publications.
2.1 Overview
A Remote Procedure Call is a mechanism which enables you to set up communication between the client and the server in a distributed application without involving you in the details of network communication. An essential part of the RPC mechanism is the definition of the interface between the client and the server. This is contained in an interface definition file . A remote procedure call in client source code is similar to a local procedure call, the difference being that the communication with the remote procedure is through DCE over the network.
2.2 Operation
An RPC distributed application is basically divided into two parts, the client side and the server side. The client side runs on one node and makes requests for services on behalf of the user. The server side runs on another node and services the client's requests. It can offer many remote procedures to an application.
2.2.1 RPC Interfaces and Stubs
The DCE RPC requires an interface definition which is used to generate the RPC stub files. These provide the actual DCE RPC support, as shown in Figure 2-1.
*
Figure 2-1: RPC Interface Structure
The interface definition describes the interface procedures and their associated parameters. Each version of an interface must be exactly the same for all implementations of that interface. As such, various clients from separate applications can call the same interface from remote locations.
Generated RPC stub files perform basic communication functions for remote procedure calls. They use RPC facilities to find servers for clients and send and receive remote procedure calls. They also perform data conversions if necessary and handle the transfer of data between clients and servers.
When a remote procedure call is made from the client application code the call is actually made to the client stub. The client stub converts the call information into internal RPC format and passes the call, with the necessary information to find a server, to the client RPC run-time library which transmits it to the server system across the network. The server RPC run-time library receives the call and passes it to the server stub which converts the information from RPC format to application format.
Then the server stub passes the call to the server where it is executed, and the whole conversion process is reversed as the call response is returned to the client. Figure 2-2 shows the sequence of a remote procedure call.
*
Figure 2-2: Sequence of a Remote Procedure Call
2.2.2 Binding Methods
The relationship between a client process and a server process during a remote procedure call is called binding. Binding information tells a client how to find a particular server. It includes the following:
* A protocol sequence
* The server host
* The endpoint
A binding handle refers to the binding information for one binding process.
Binding information for DCE applications is usually stored on a name service database. The Cell Directory Service (CDS) is a name service particular to DCE. The RPC run-time library holds name service routines which are used to access the CDS.
There are three different possible binding methods:
* Automatic
* Implicit
* Explicit
These are described in the following sections.
2.2.2.1 Automatic Binding
When automatic binding is selected the client stub automatically manages bindings when a remote procedure call is made from an application. The client stub gets the binding handle from the name service database and passes it to the RPC run-time library. This is the most transparent form of binding and requires minimal changes to a client application.
2.2.2.2 Implicit Binding
When implicit binding is selected a binding handle is held in a global area of the client stub. When a remote procedure call is made from an application the stub passes the binding handle to the RPC run-time library. You must write application code to obtain the binding information and set the global binding handle with RPC run-time routine calls.
2.2.2.3 Explicit Binding
When explicit binding is selected a binding handle is passed explicitly as the first parameter when a remote procedure call is made from an application. You must write application code to obtain the binding information and set the binding handle with RPC run-time routine calls.
2.2.3 Micro Focus COBOL Support for DCE RPC
To define a DCE RPC interface an interface definition must be written using the IDL (Interface Definition Language). Currently the DCE IDL definition can only be used to define an RPC interface for C applications. To enable a DCE RPC interface to be defined for COBOL applications Micro Focus DCE support for COBOL applications provides COBOL IDL.
Once a DCE RPC interface has been defined the next step is the generation of stubs and files that provide the actual support for the defined RPC calls. For DCE C applications this is done by using the DCE IDL compiler which uses the DCE IDL definition as input. To provide similar support for COBOL IDL Micro Focus provides the COBIDL utility. This utility takes the COBOL IDL definition as input and generates COBOL copyfiles (instead of C header files) and stubs that provide the actual support for the defined RPC calls. These stubs can be linked to the COBOL application code.
For more information on the COBOL IDL utility COBIDL see the chapters, Introduction to COBOL IDL and COBOL DCE Application Development Using COBIDL.
Micro Focus also provides a utility, COBDAG, that enables the automatic generation of DCE RPC support for native COBOL applications. The only input required is the actual source code of the COBOL application. It generates an executable COBOL/DCE server and client as its output.
For more information on the COBDAG utility see the chapters, Introduction to COBDAG and COBOL DCE Application Development Using COBDAG.
Copyright © 1996 Micro Focus Limited. All rights reserved.
This document and the proprietary marks and names used herein are protected by international law.
link:http://www.docs.hp.com/en/64/ll/llrpci.htm
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
