|
|
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.
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.
|
|