3 Simulating Dynamism

Consider one possible solution, in which there are two servers, one a ``primary" server, which is more desirable to use, but which may go down unexpectedly, and a ``secondary" server, which, while reliable, provides a lesser form of the service. One way to use these is to alter the architecture such that both servers are present, and when the primary server goes down, the client uses the secondary server until such time as the primary server returns to service. The topology of the system is shown in Figure 3, while a Wright description of a possible client is shown in Figure 4. In this description the server communicates with ``serverDown" and ``serverUp" when it is about to go down or come up (resp). (In practise, such events might be supplied by a time-out service.)

  

Figure 3: Static Topology: Fault Tolerant Client-Server

  

Figure 4: Static Wright Specification: Client Component (Fault Tolerant Client-Server)

While this accomplishes what we set out to do, the description of the new architecture has several disadvantages:

1.

The simple client-server functional pattern has been lost. In particular, its specification is now muddied by the need to consider the effects reconfiguration at almost each step.

2.

It has been necessary to significantly alter the client in order to accommodate a change that should occur on the server's side. Ideally, the client should be able to continue to operate as before, but have the system handle rerouting of requests to the new server.

3.

Changes to this system (e.g., adding a third backup, or permitting only the primary to go down once before abandoning it) require extensive changes to all parts of the system, thus reducing the reusability of the constituent elements.

Instead of rigid encoding of the dynamism in the steady state behavior of the components, what we would like is to provide constructs to describe the dynamics of the system explicitly. In this case, rather than using a fixed topology of two servers and hiding the changes inside the client components ``choice" about which server to use, we could describe the server's failures as triggers that change the topology during computation. In effect, instead of the single configuration shown in Figure 3, we would have two configurations, shown in Figure 5. These configurations, each simple in itself, alternate as the primary server goes down and comes back up.

  

Figure 5: Dynamic Topology: Alternating Configurations of a Fault Tolerant Client-Server System

In order to achieve this effect, we must introduce notations for characterizing changes in the architecture during a computation. Such a characterization includes: (a) what events in the computation trigger a re-configuration, and (b) what re-configuration is triggered by each event.