Special care must be taken when reliable services are to be load balanced. This is because each WS-RM Sequence of messages corresponds to a session (services invoked reliably become stateful). All messages of a sequence therefore must be handled by the same node of the cluster – this node is called a sequence owner. The sequence owner creates the sequence and handles WS-RM functions such as storing and resending messages. For a description of reliable messaging as implemented in WSO2 SOA Enablement Server for Java, please see WS-ReliableMessaging).
Session affinity is maintained by cookies. With WS-RM this affinity must be assured even after client or node restart. To do so, the following methods are employed:
Cookie persistence Every cookie received during reliable messaging is stored into an appropriate WS-RM sequence. Since sequence data is persistent and the cookie value persists with the sequence, the cookie value remains on the client after it restarts. Cookie expiration depends on sequence expiration.
Message refusal Under certain circumstances (a node of the cluster is not reachable, a client loses its cookie, etc.), the load balancer may send a message of a sequence to a node other than the sequence owner. In this case there is a danger that the same sequence could be served by two different nodes. Thus, every node first checks whether the incoming sequence really belongs to this node and if not, the node refuses the message. It also adds the correct cookie value to the outgoing connection so the next client request will be re-directed correctly.
Node uniqueness Every node of the cluster has a unique, well-defined name. This name also serves as the unique cookie value returned by the node. The name can be set by the wasp.instance.name property.
The functionality described in Session Affinity and Cookies is included in lb_wsrm.jar. The relevant package must be deployed into the SSJ server or client if and only if WS-RM invocation is to be used in a clustered environment. Since the lb_wsrm.jar package is dependent on both lb_cookies_interceptor.jar and wsrm.jar you must not deploy the package if one or both of these packages are missing.
The following conditions must also be met:
The package lb_cookies_interceptor.jar must be in cookie passive sticky mode.
The load balancer must be statically configured.
The nodes of the cluster share the same database, so every node must have a unique name.
Cookie passive sticky mode Since not the load balancer but the node itself must insert cookie values into the outgoing connections, the package lb_cookies_interceptor.jar must work in the cookie passive sticky mode. To enable this, the default configuration must be changed in the deployment descriptor of the lb_cookies_interceptor.jar package.
Static configuration Because the load balancer is in cookie passive sticky mode, it does not put any cookies into the outgoing connections. Neither should it store the cookies coming from nodes, or a node may return a cookie value belonging to another node (cf. Message refusal). Instead, the load balancer should be statically configured, so it knows the mapping of cookie values and node addresses in advance.
Shared database Since a node needs to recognize sequence owners in order to refuse messages sent in sequences this node hasn't created (see Message refusal), all the nodes must share the same DB. This requirement does not have to be met if there is no danger that a load balancer will send a sequence's message to a node that is not the sequence owner (when there is a special load balancer configuration, every node is always reachable, etc.). However, it is recommended to always fulfil this requirement regardless.