During the task of porting the application to a newer RPC system, we
learned that there are ways in which an RPC implementation permits
the programmer more flexibility than a strict remote emulation of
local procedure call implies. We call this 'weaker' RPC:
-
Call Back
A client calls an RPC and normally blocks until there is a response.
Some systems permit servers to make calls to the client process
while it is blocked awaiting their response. This role reversal may continue,
providing mutual recursion of RPCs. This is called <#1816#> Call Back<#1816#>.
Since many newer RPC systems supports Call Back, we can dispense with the
Notification Service as a separate process, and merge it in the
Library. We simply replace reading the pipe between separate
processes, by polling on the RPC socket, followed by the
dispatch table call if any data is present.
This makes the system simpler, more robust and possibly more responsive.
-
Broadcast
Some RPC systems provide a form of Broadcast. At the moment several of the servers, the
Conference Server, Directory Server, Switch Controller and Switching Servers, are
bound to particular hosts, and are found through global knowledge of their
host location. Broadcast [or better still, multicast] RPC could
provide a discovery based approach, where no bootstrapping information
at all is required. A trader or intelligent dynamic (run-time) binding service
could also play a role here.
-
Streaming
More recent RPC provides a streaming service, where RPCs do not block at the
client, and a number of calls may be made successively without
awaiting a response for each. This may
be used to make the system robust in the face of link outages. For
example, notifications can be streamed to applications, instead of the
Conference Server blocking unnecessarily for responses.
ANSAWare 4.0 has many of these new mechanisms, based on
a system of Tokens that permit call back and streaming and so on. In
addition, it provides a threads package, which permits lightweight concurrency
within servers. These capabilities would permit a similar restructuring of the
system, but would
make the Conferencing System further dependent on a less commonly available
RPC
system. We would also be more dependent on its annotation approach
to enhancing C. This is felt to be inappropriate because the maintenance
of the system would be greatly complicated by having to track ANSA
releases as well.
In a related piece of work, we are
designing a compiler for the GDMO language (Guidelines for the Definition of
Managed Objects, an ITU standard) to produce C++ code to provide easy
access to new Managed Objects in a large system. Programmers reported that they
were happier with a scripting approach than with an annotation
approach to this type of problem. The script approach entails the
programmer writing scripts that direct the actions of the stub
compiler in a special purpose compiler directive language, as opposed
to adding notes in the actual RPC code in a hybrid language.
Thus the distributed application is kept one step removed from the
communications software.