ANSA RPC is used in a straightforward way to support the Interfaces
exported by each of the servers described in section 2.
The source code is divided into a set of sub-directories of a
top-level source tree on a Unix development machine following normal ;SPM_quot;C
and Unix;SPM_quot; software engineering practice.
Each service
is defined in a separate module, with the code that implements the service
in one C module, the actual procedures in a second (separate from the bulk
of the service just so that it might be possible later to cleanly replace on
RPC mechanism with another). This latter module is in DPL. This is a
form of annotated C that an ANSA pre-processor parses and replaces the
annotated sections with:
-
Calls to Remote Procedures from the correct Interface.
-
Calls to ANSA run time support to do exception handling (a remote
procedure invocation can result in more exceptions than a local one.
The definitions of the Interfaces (Global Types and Procedures)
(OPERATIONS in ANSA Terminology) are in a separate IDL module in the
same sub-directory as the service source and DPL. These are parsed by
another pre-processor to generate:
-
Client Stub C modules - the Client program(s) will be linked with
these modules which marshal and unmarshal call and response messages
and call ANSA runtime support and communications primitives to
transmit and receive these to (remote) servers.
-
Server Stub C modules - the Server program(s) will be linked with
these to provide the complementary tasks to the Client stubs.
At the server end, there is also the question of the main entry point
to a program. This could either be in the stub, with a dispatch table to
service calls, or else can be in the server DPL or C, in which
case, the dispatcher must be called from there. In the ANSA system as
used in CAR, the former approach is used.
-
C type definitions for the types referenced in the last two modules
and in the DPL modules (and in the service C modules).
Since there are a number of types in common across all of the
services, there is a sub-directory with both a C type definition
module, and an IDL type definition.
Each sub-directory has its own makefile [#make##1#]
This leads to an initial pair of problem - makefiles for clients now
have to reference IDL files in the server sub-directories. And many
the dependencies are heavily entwined to and fro across the
subdirectories.