The EntireX RPC-ACI Bridge allows standard RPC clients to communicate with an ACI server. The RPC-ACI Bridge transforms RPC requests from clients into ACI messages. This document covers the following topics:
The RPC-ACI Bridge
acts on one side as an RPC server and on the other side as an ACI client. In
this documentation we distinguish between the Broker for RPC, which sends the
RPCs from the client to the server side of the RPC-ACI Bridge
and the Broker for ACI, which sends the messages to the ACI server. These two
brokers can be the same instance. Use distinct CLASS/SERVER/SERVICE broker attributes for the RPC requests and ACI messages.
The RPC-ACI Bridge can connect to ACI servers written in programming languages where the ACI is supported, such as Natural | Assembler | C | COBOL | Java | PL/I. More detailed information is given on writing ACI servers for the RPC-ACI Bridge in COBOL and Natural.
For existing server programs, use an extractor to generate the Software AG IDL File for the RPC clients.
For COBOL, use the IDL Extractor for COBOL
For PL/I, use the IDL Extractor for PL/I
RPC requests are worked off inside the RPC server in worker threads. Every RPC request occupies during its processing a worker thread. If you are using RPC conversations, each RPC conversation requires its own thread during the lifetime of the conversation. The RPC-ACI Bridge can adjust the number of worker threads to the number of parallel requests. The RPC-ACI Bridge provides two worker models:
FIXED
The fixed model creates a fixed number of worker threads. The number of worker threads does not increase or decrease during the lifetime
of an RPC server instance.
DYNAMIC
The dynamic model creates worker threads depending on the incoming load of RPC requests.
For configuration and technical details, see property entirex.server.fixedservers under Administering the RPC-ACI Bridge.