See information about the latest product version
Configuring your HTTP topology
Learn about how you can integrate WebSphere® Message Broker into your HTTP topology, and the consequences of different configurations for load-balancing, failover, and administration.
- Scenario one: single machine, single broker; ease of use is the
highest priority; load-balancing is relatively important; machine
failover and high throughput are not high priorities
This scenario uses a broker-wide listener, listening on port 7080, and all HTTP communication from the clients is processed by that listener. Load-balancing is achieved by having additional instances of message flows within execution groups, and by using the same URL in message flows across execution groups.
Strengths:- Simplicity of administration and web service discovery: all inbound requests (and any responses) are routed through a single port for HTTP (and a second for HTTPS, if required).
- Load-balancing across message flows and execution groups: a request to a specific web service (URL) can be processed by any message flow registered to handle that URL. The message flows (MF1, MF2) can be in separate execution groups (ExGp1, ExGp2), and the requests are load balanced between them. As usual, within each execution group you can deploy additional instances of each flow, as required. This configuration offers a scalable load-balanced solution with some degree of failover; if one execution group fails, the others continue to process the workload while the first execution group restarts.
- Failover: there is a single point of failure (broker or machine). If machine failover is implemented, it is complicated: the secondary machine must take over the IP address of the primary machine.
- Activity partitioning: there is no partitioning between activities managed by the broker.
- Throughput: a single listener handles all HTTP and all HTTPS messages sent through two ports on the broker. This single point of processing and error handling can cause bottlenecks if high message throughput is required.
- Scenario two: single machine, single broker; high throughput is
the highest priority; machine failover and load-balancing are not
high priorities
This scenario uses execution group listeners to improve message throughput.
Strengths:
- High throughput: you can deploy message flows to different execution groups so that the HTTP (or HTTPS) messages can be handled by multiple listeners on multiple ports to meet high throughput requirements
- Simple configuration: these listeners communicate directly with the HTTP transport network; no intermediate queues are required
- Activity partitioning: activities managed by the broker are partitioned into separate execution groups
- Failover: there is a single point of failure (execution group, broker, or machine). If machine failover is implemented, it is complicated, and involves the secondary machine taking over the IP address of the primary machine
- You must include both the input and the reply nodes in the same message flow, or deploy separate message flows to the same execution group, so that they use the same listener; matching input and reply messages must be processed by the same port
- Scenario three: multiple machines, multiple brokers, failover
the highest priority; load-balancing and security are also important
This scenario uses broker-wide listeners. There is also a server that acts as a load balancer and a network dispatcher, thus simplifying the client interface. The configuration of message flows and execution groups is replicated across multiple brokers, and the load-balancing server is configured to manage high availability cluster multiprocessing (HACMP™) across the brokers.
Strengths:
- Load balancing: having a server that acts as a network dispatcher and load balancer provides additional load-balancing capability to this scenario
- Failover: the distribution of brokers across systems allows for both machine and broker failover
- Simplified client configuration: the load-balancing server provides a single point of contact for clients
- Complexity: the scenario is complex, although the complexity can be hidden from clients and managed in centralized locations