On my current project, we have a requirement to provide HTTP load balancing of requests to IBM Integration Bus, which we have realized using IBM HTTP Server and the WebSphere Plugin. This excellent developerWorks article "Load balancing WebSphere Message Broker HTTP traffic: Part 1: Load balancing with IBM HTTP Server" provided the insight that we needed to configure this.
Again, we're using IBM HTTP Server 18.104.22.168 in front of IBM Integration Bus 22.214.171.124, in order to allow requests ( SOAP over HTTP in this particular case ) to be routed to one of a number of Integration Nodes ( aka Brokers in the old tongue ). This is partly to improve performance ( more engines to service requests ) and partly for resilience ( service can be maintained in the event of the loss of one Integration Node ). So I have learned
three four new things today ( what's the bon mot about impossible things and breakfast? Well, mine is learn new stuff before AND after breakfast!! ).
Firstly, one can report on the IIB configuration to see what ports an Integration Node is listening for HTTP connections, as follows:
mqsireportproperties <<NAME OF INTEGRATION NODE>> -b httplistener -o HTTPConnector -a
that returns something like this:
It's worth noting that the port ( 7122 in the above example ) isn't the port on which the Integration Server ( formerly Execution Group) listens ( see below ).
Secondly, in order for IHS to route HTTP requests to IIB, there needs to be another, different, port configured, specifically at the Integration Server ( formerly Execution Group) level, as evidenced by a modified mqsireportproperties command:
mqsireportproperties <<NAME OF INTEGRATION NODE>> -e default -o HTTPConnector -a
In this example, port 8220 is explicitly set for this Integration Server. That's the port that I needed to know about in order to configure IBM HTTP Server / WebSphere Plugin to route requests to that particular Integration Server ( one of many ).
Thirdly, and importantly, this port will NOT come up until the Integration Server is started. I'd assumed that IIB was similar to WAS in that the TCP/IP ports come up as soon as the container ( IIB instead of a WAS JVM ) starts, but that is NOT the case. Bottom line, one needs to start the Integration Server ( which hosts the flow(s) running on IIB, before the port will show up). This surprised us, as we were busy using netstat and telnet but couldn't find out why the port wasn't listening.(
Finally, and fourthly, the IBM Integration Bus Toolkit allows one to export a plugin configuration file suitable for the WebSphere Plugin. Therefore, I could've simply asked my IIB admin guru to generate the file, rather than my having to hand-code it, or use Java™. However, that's the point of learning .........
Thanks to this IBM Technote for some guidance on mqsireportproperties: "Using the mqsireportproperties command in IBM Integration Bus or WebSphere Message Broker for a single message flow"
title image (modified) credit: (cc) Some rights reserved by owoc