I have developed a distributed test automation system which consists of two different entities. One entity is responsible for triggering tests runs and monitoring/displaying their progress. The other is responsible for carrying out tests on that host. Both of these entities retrieve data from a central DB.

Now, my first thought is that this is clearly a server-client architecture. After all, you have exactly one organizing entity and many entities that communicate with said entity.

However, while the supposed clients to communicate to the server via RPC, they are not actually requesting services or information, rather they are simply reporting back test progress, in fact, once the test run has been triggered they can complete their tasks without connection to the server. The request for a service is actually made by the supposed server which triggers the clients to carry out tests.

So would this still be considered a server-client architecture or is this something different?


The test triggering system is definitely not a server since it makes the request. I wouldn't say the test runners are servers either since they are tightly coupled in purpose.

What you have sounds like a mix between a Cluster with master/slave nodes and an Agent-based model depending on the purpose for the nodes. If the purpose is simply to balance load, then you have a cluster. If the purpose is to distribute tasks to multiple runners to test how your system behaves with all of them acting at the same time, then it's more like a multi-agent system.

See http://en.wikipedia.org/wiki/Distributed_application#Architectures for a list of architecture types - you'll see that yours is most clearly connected to cluster, because it sounds like it is tightly coupled

  • I think I agree. – Pemdas Jan 7 '11 at 2:37

If this where a Client/Server Architecture you would have it backwards. The entity triggering the test is the client and the the entities running the tests are the servers. The database itself would actually be another server. However, I agree with Renesis.


Have you considered using 0MQ (Zero Message Queue)?

They demonstrate the use of a parallel processing model using a ventilator/sink.

The ventilator pushes tasks to a collection of workers that handle tasks in parallel. When a worker finishes it pushes the result to the sink.

Here's the diagram:

Parallel processing using a ventilator/sink model

Source: 0MQ - The Guide

The library supports communications over most/all of the common interfaces (ex sockets, pipes, IPC, etc) and the examples have working code for all of the most common languages.

A server-client architecture doesn't really work here, as that would require a lot of unnecessary overhead to maintain the connection streams. A pub/sub (ie publisher/subscriber) model fits a lot better.


It fits the definition of Client-Server architecture as Wikipedia says:

The client–server model is a distributed application structure in computing that partitions tasks or workloads between the providers of a resource or service, called servers, and service requesters, called clients. Often clients and servers communicate over a computer network on separate hardware, but both client and server may reside in the same system. A server is a host that is running one or more server programs which share their resources with clients. A client does not share any of its resources, but requests a server's content or service function. Clients therefore initiate communication sessions with servers which await incoming requests...