Peer Rules Services

See Also

More than one Rules Service can serve your (web) application. This improves the scalabilty of your (web) application: the application does not depend on one Rules Service, or on one machine.

All 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. Then the Peer Rules Service informs all running Rules Services that a new Peer Rules Service is running. When a new client request comes up, one of the Peer Rules Services gets the request and handles it. When a Rules Service stops, the other Rules Services get this information.

The client part of your (web) application has to know the address of only one of the Peer Rules Services.

For example, in your web application, when publishing it from the Web Designer, only one address of a Rules Service has to be specified. At run time, the Peer Rules Services determine which one handles the next client request, and inform the client part of your application (in fact the JDBC client), what Rules Service it has to connect to. Later, even if the Rules Service mentioned in the publication of the Web Designer does not work anymore, the application still works.