A service is a unit of processing called by an RPC and is the facility that a server UAP provides to a client UAP. A server UAP can execute more than one service. The group of services provided by one server UAP is called a service group.

When a programmer codes a client UAP so that it can make a request for a service from a service-providing program, the programmer must specify in the RPC function parameters (e.g., dc_rpc_call() parameters) the various RPC items required for the service request. Among these items are the service-group name and the service name. The programmer, however, does not need to code server network addresses into the parameters because the OpenTP1 name service manages the service names and network addresses of nodes containing server UAPs.

RPCs are categorized as either a response-type RPC or a non-response RPC, according to whether a response is received. Figure 3-11 illustrates RPC types.

Figure 3-11 RPC types

Figure 3-12 summarizes the processing for each RPC type.

Figure 3-12 Overview of processing for each RPC type

(a) Synchronous-response RPCs

Response RPCs, which consist of synchronous-response RPCs (simple RPCs) and asynchronous-response RPCs (no-wait RPCs)

(b) Asynchronous-response RPCs

After making a service request, an asynchronous-response RPC continues processing without waiting for a response. A function (dc_rpc_poll_any_replies) must be issued to receive a response. This function waits for a response, and returns an error if the response wait time set in the function is exceeded.

Asynchronous-response RPCs are also known as no-wait RPCs.

(c) Non-response RPCs

A non-response RPC is an RPC to which no processing result is returned. No response is received when a service request is made using a non-response RPC. The UAP that made the request continues processing.

Further services can be requested of a server UAP after it has received one service request (thus creating an RPC nest).

The OpenTP1 Multiserver facility can reduce the time it takes to process multiple requests for a service. The Multiserver facility enables the same server UAP to start multiple processes at the same time.

A possible drawback to this facility is that a process is started for each service of a server UAP that uses the Multiserver facility; thus, when a client UAP calls the same service group two or more times, the server UAP of that service group might not be executed in the same process as previously. OpenTP1, however, can handle this problem by preventing an unnecessary increase in the number of processes, and thereby reduce the load required for processing a transaction. OpenTP1 does this by using chained RPCs, which are a group of RPCs using the same process. Chaining is specified in the dc_rpc_call() parameters. A programmer can use chained RPCs so that when a synchronous-response RPC requests the services belonging to the same service group two or more times, OpenTP1 executes the service by the same process.

Figure 3-13 compares a normal RPC with a chained RPC.

Figure 3-13 Comparison of a normal RPC and a chained RPC

The use of chained RPCs can reduce the number of user processes required for processing one transaction and can reduce the load required for transaction processing. When executing chained RPCs as a transaction, operate the chained RPCs in one transaction branch. (Global transactions are described in 3.1 Transaction Control.)

Chained RPCs are guaranteed for each UAP process. Even in the same global transaction, if the client UAPs are different, it can not be guaranteed that a service that is called multiple times will be started in the same process.

(a) Time monitoring of chained RPCs

In a UAP from which a service is requested, OpenTP1 can monitor chained RPCs from the time a response is returned to the client UAP, until the time the next service request comes or until the time that transaction synchronization point processing occurs. In the user service definition, you can specify a limit for this monitoring time. If the monitored time exceeds the limit or if the next request for a service or for synchronization point processing does not come, OpenTP1 assumes that an error occurred in the client UAP and the server UAP abnormally terminates.

To reduce the LAN network load, RPC can compress the send and receive data. For compressing data, specify the following values in the system definitions.

• TP1/Server Base
  Specify a Y for the rpc_datacomp operand in the system common definition.
  
• TP1/Client
  Specify data compression for the client environment definition.
  

If the system at the client specifies the data compression, OpenTP1 of the server automatically restores the compressed data to process regardless of the rpc_datacomp operand specification. After that, OpenTP1 re-compresses the data and returns a response to the client.

Even if the network load is reduced by the send data compression, the communication time may be lengthy because of compression and decompression of data in a node. Determine whether data compression is specified or not, according to the job types and the communication configurations.

(a) Overview of the domain name system

In a network system via a WAN or an inter-department system of a company, searching for a name or managing the system names is time-consuming work. When using remote procedure calls in such a large-scale distributed system, the user can solve these problems by configuring a domain name system (DNS).

In a domain name system, the user does not have to manage the entire system and can manage it in groups as domains. Systems of departments are domains. Service names and other names are managed within each domain individually. Therefore, the user does not have to manage the names in the entire system. Figure 3-14 shows an overview of domain-based management.

Figure 3-14 Overview of domain-based management

(b) Service request method

The following describes how to request a service.

Specifying a service group name and service name

Normally, to request a service, specify a service group name and service name in the dc_rpc_call() function.

For a large-scale distributed system, you cannot use a service across domains by specifying a service group name and service name in the dc_rpc_call() function.

Specifying a service group name + domain name and service name

To use a service across domains in a large-scale distributed system, specify service group name + domain name and service name in the dc_rpc_call() function.

When the domain name is added to the service group name in this function, the service request is passed to a domain-alternate schedule service that has access to the requested domain. The domain-alternate schedule service allocates a request to a server UAP among the servers of the domain.

The request is allocated to a server UAP of the specified domain and is not allocated to a server UAP of another domain. When the domain-alternate schedule service is used, the name service does not need to manage the network addresses of all the nodes.

When the server UAP is a server that receives requests from the socket, you cannot add the domain name to the service group name in the dc_rpc_call() function. For details of the server that receives requests from the socket, see 3.4.1(1) Schedule queues for SPPs.

Specifying the destination of a service request

While the dc_rpc_call() function does not recognize a location, a user can identify the location of a desired server for requesting a service, and then use the service with the dc_rpc_call_to() function. The following describes how to specify the destination to issue a service request.

• Specifying the host name
  This method specifies the machine where the desired service exists by specifying the host name that is specified in /etc/hosts for network management. To use this method, the specification of name_port of the system common definition must be the same for the OpenTP1 system in the specified host and for the OpenTP1 system that issued the dc_rpc_call_to() function.
  
• Specifying the node identifier
  This method specifies the OpenTP1 system by specifying the node identifier that is specified in node_id of the system common definition.
  To use this method, the global domain^# must contain the host name of the OpenTP1 node to which the service is requested, with the node identifier specified.
  

#

The global domain means a set of the following node names:

• When N is specified in the name_domain_file_use operand of the system common definition
  The global domain is the set of node names specified in the all_node and all_node_ex operands in the system common definition.
  
• When Y is specified in the name_domain_file_use operand of the system common definition
  The global domain is the set of node names specified in the domain definition files. The domain definition files are stored at the following locations:
  Domain definition file for all_node:
  - Under the $DCCONFPATH/dcnamnd directory
  Domain definition file for all_node_ex:
  - Under the $DCCONFPATH/dcnamndex directory
  

• Specifying the host name + port number
  This method specifies the service request destination by specifying:
  - The host name that is specified in /etc/hosts.
  - Port number of the name service that is specified in name_port of the system common definition for the OpenTP1 system contained in the host specified above.
  The specification of the name_port operand of the system to which the service is requested may differ from the specification of the name_port operand for the system that issued the service request.
  

This facility requires TP1/Extension 1 installed. If TP1/Extension 1 is not installed, the operation is not guaranteed.

(c) Setting up the environment of a large-scale distributed system

The nodes that make up a domain must be specified by all_node in the system common definition.

To specify the domain-alternate schedule service, specify, in the namdomainsetup command, the name of the host where the domain-alternate schedule service exists. Then, specify, in /etc/services, the port number of the domain-alternate schedule service and a service name OpenTP1scd.

When using a domain name system, more time may be needed to complete the system startup because each node address is inquired during startup of the server system. In this case, specify a domain name and host name beforehand in the domain_masters_addr operand and specify a port number of the domain-alternate schedule service to the domain_masters_port operand in the system common definition. Specifying these operands reduces the time it takes to inquire about each node address while starting a service.

The normal RPC uses the service information of the server UAP managed by the name service of each node to perform communication. The name services of nodes exchange service information to manage at which node of the network the target server UAP exists. In a large-scale system connecting many nodes, the exchange of service information by name services may tax the network.

When you have defined service information in a definition file, you can execute an RPC without using a name service. This method does not require querying the name service for service information to reduce the load on the network.

Define the service group name and service information (host name and port number) in the user service network definition file. Specify whether to use the name service or the service information in the definition file with the rpc_destination_mode operand of the user service definition at issuance of the function dc_rpc_call(). When the function dc_rpc_call() is called from a UAP for which the user service definition specifies using the service information in the definition file, OpenTP1 references the user service network definition file. When the server UAP information is defined, OpenTP1 calls the server UAP by using the definition. When the server UAP information is not defined, OpenTP1 calls the server UAP by using the name service. Note that the server UAP in the user service network definition must be a UAP the user service definition specifies receive_from=queue (server that receives requests from the queue).

If you specify multiple service information items (host names) in the user service network definition file, the service request destination is selected at random from the specified hosts, and a service request is sent to the selected host. Once sending of a service request is successful, the subsequent dc_rpc_call invocations made in the UAP to the same service group continue to send service requests to the same host.

Note that a destination host is randomly selected again if the destination reselection interval is specified in the -t option of the dcsvgdef definition command and the following time exceeds the specified interval:

• Time since selection of the current service-request destination host used by multiple dc_rpc_call invocations made in the UAP to the same service group