Both do the same job - spread HTTP requests over the cluster members and keep a user on the member that holds the coach session - they differ in who knows the cluster:
- IBM HTTP Server + WebSphere plug-in: the plug-in reads plugin-cfg.xml (generated from the cell, so it always knows the members, ports and the session cookie clone ids), balances with weights, retries on failure, and keeps affinity by the JSESSIONID clone id. It is free with WebSphere, terminates or passes through TLS, and is what IBM's topologies document.
- Hardware / software load balancer (F5 BIG-IP, Citrix ADC, NGINX, HAProxy, cloud LBs, the OpenShift router on CP4BA): knows nothing about WebSphere - you configure a pool with the member host:port pairs (or with the IHS servers, the usual two-tier setup), a health monitor (GET /ProcessPortal/login.jsp returning 200, or /rest/bpm/wle/v1/systems), and cookie-based persistence (insert its own cookie or persist on JSESSIONID) - without stickiness coaches lose their session on the next request.
Practical differences: the LB gives you TLS offload, WAF, geo / DR routing and a single VIP for several cells; the plug-in gives you accurate member state and no double hop. Most enterprises run LB → IHS (plug-in) → cluster; small ones run LB → members directly. Whatever you use, set ProxyPass-style header forwarding (X-Forwarded-For, X-Forwarded-Proto) and tell BAW its public URL (Server Admin > Process Server settings > public host / port, or 100Custom.xml <server><hostname>) so that portal links and REST URLs use the VIP.
# HAProxy example: sticky on JSESSIONID, health check on the login page
backend baw
balance roundrobin
cookie SRV insert indirect nocache
option httpchk GET /ProcessPortal/login.jsp
server m1 baw1.example.com:9443 ssl verify none check cookie m1
server m2 baw2.example.com:9443 ssl verify none check cookie m2
References