Distributed apps
Overview
Distributed systems take concurrent apps a step further. The single components of an app not only run concurrently-they are also located in different places. Boger [01] defines distribution as follows:
Distribution is the logical or physical spatial distance of objects in relation to each other. Two objects that cannot use the regular method invocation to communicate, but have to use mechanisms of the remote communication, are distributed in relation to each other. This is the case when they reside on different computers . . . but also when they reside in different address spaces on the same computer . . . .
In addition to the problems relating to concurrency (see ), distributed systems introduce further requirements and problems. From a tester's perspective, the following are most important:
- Finding other objects in the network (e.g., by using a "name service" that allows us to register objects under unique names). In the testing context, this means that a client's behavior has to be considered even when the server object cannot be found.
- Insecure communication. The sender of a message has to be prepared that something may go wrong when sending the message or receiving a reply. Consequently, we should try to prevent the sending object from being able to take an undefined state or, more seriously, prevent dead-locks from occurring.
The theoretical objective here is to distribute objects as transparently as possible. This means that the actual location and invocation mechanism of a remote object should be hidden from the caller. In practice, however, distribution requires the explicit handling of potential communication problems. And other properties of local systems (e.g., automatic garbage collection) can reach their limits. For this reason, real transparency can only be achieved if local objects are treated like remote objects. Naturally, the significantly higher effort this involves is found to be a burden in most cases.