Overview of the RPC Manager Service

RPC Manager enables VTScada to operate within a domain distributed across multiple machines, by providing the ability to remotely execute a VTScada subroutine.

The RPC Manager provides the cornerstone of a comprehensive server/client architecture, which enables tags and other VTScada services running on physically separate workstations to coordinate their activities and share data. VTScada contains a number of services, (such as the Alarm Manager, Log Manager, Modem Manager), and enables these services, all of the I/O drivers and other network-aware software components to share their data using the RPC Manager.

A VTScada service is simply a VTScada module that registers itself as a named component with the RPC Manager. A VTScada service encapsulates the data and processing logic that provides a specific function within the application. Each service should be regarded as a separate entity whose service name is unique within the application. Different applications running on the same workstation can contain a service of the same name as a service in another application, That is, two standard VTScada applications will, for example, each contain a service called AlarmManager.

A service running within an application instance is termed a service instance. A distributed system contains many instances of the same service, each one running on a separate physical machine. At any given time, for each service, there is exactly one service instance that has "server" status. All other instances of the same service (running on machines other than the server instance) are either clients to that server or have not yet determined what their status should be. A brief moment may exist when there is no server for a service, but there will never be more than one server.

Server status can shift from one service instance to another at any time. Such shifts are normally the result of some failure of the server or failure of the server to communicate with an external device. When such shifts occur, each service must arbitrate which service instance is going to assume server status. All other service instances must then resynchronize to the new server and so become clients of it.

The RPC Manager provides the code that performs service synchronization and manages servers and service instances. The service code need only provide a few, simple methods that will be invoked by RPC Manager to achieve this. A simple, yet functional service example that supports all the essential RPC Manager methods is discussed in "Create a Simple Service".

RPC Manager also provides a set of methods that provide services with the ability to make RPCs, as well as a number of useful, ancillary methods. All the methods available are documented in the Application Control of Servership

In normal operation, RPCManager controls which service instance is currently the server for a service. The system is simply configured to instruct RPCManager how its servership control algorithms should operate.

In rare cases, it may be necessary to control the servership of one or more services by the application itself. Consider, for example, a system where maintenance of the system is necessary while the application is running. For operational reasons, the system owners do not want a number of key services to have servership held by the machine undergoing maintenance, but do want the application to be running.

In such circumstances the application needs to either be able to disable a particular machine from owning servership of the key services or, more generally, be able to control which machine is the server for those services. More complex situations could arise where, for example, a specific machine does not want to be considered a candidate for servership.

References in this document to version 4 of RPCManager  refer to the RPCManager capable of using version 4 RPCManager protocol. This applies to VTS version 10 onwards.