More than one Rules Service can serve your (web) application. This improves the scalabilty of your (web) application: the application does not depend on a single Rules Service, or on a single machine.
Peer Rules Services that serve one application work together, and all client requests are distributed automatically amongst the running Peer Rules Services. You can add and remove a Peer Rules Service 'on the fly' in the production environment. At any time, the Peer Rules Services are aware of the other Peer Rules Services that serve your application, and decide which one will handle a client request.
When installing and starting a new Rules Service, you can specify the host name and port number of an already running Peer Rules Service. Both Rules Services then become Peer Rules Services of each other.
The Rules Service then starts using the parameters of the peer Rules Service configuration. A peer Rules Service informs all running Rules Services of its existence. When a new client request comes in, one of the peer Rules Services gets the request and handles it. If one peer stops, requests are still handled by another peer.
The client needs to know the address of only one of the Peer Rules Services. The assignment of the request to one among the peer Rules Services is transparant (= not known by, and not relevant for) the client.
|
