We have several ESB Processes exposed as web services.
With version 7, the client called the web service through the broker's http acceptor port, which forwarded the message to a Topic, on which 2 instances of the same process, in different containers, on different servers were listening with a shared subscription. Also, our primary broker has a backup so the client called the web service like this (pseudocode):
try
call http://primaryServer:primaryBrokerHTTPPort/WebService?WSDL
catch
call http://backupServer:backupBrokerHTTPPort/WebService?WSDL
This resulted in the exposed processes to be load balanced (round-robin) and always available as long as at least 1 broker + 1 ESB Container are active.
Now to my question, web services in version 8 use a completely different approach. From what I understand, they don't use the broker at all. There are threads in the ESB Container that listen on the address/port specified for the web service.
How can I achieve CAA and load balancing of the processing done by our exposed processes with version 8?
I thought of the following and I'd like to know if it's the best approach:
- Deploy 2 instances of the sonic connect service, in 2 different containers, on 2 different servers
- Deploy 2 instances of our exposed process, in 2 different containers, on 2 different servers
If the instances of the processes are not in the same containers as the Sonic Connect services, they will listen on a shared subcription Topic on a broker and there will be round-robin (load balancing)
Then the client will always try to call the web service on the server that we design as the primary:
try
call http://primaryServer:primaryWSAddress/WebService?WSDL
catch
call http://backupServer:backupWSAddress/WebService?WSDL
Unfortunately with this approach, the messaging will go through the JMS instead of staying intra-container.
Is this the best approach?
Thanks in advance!
Ideally, we recommend incorporation of Actional Intermediary (AI)for supplementing Sonic Connect for load-balancing or advanced WS-* requirements. But this may be overkill here.
From the HA angle only, either solution you present is reasonable. And if currently each of your redundant processes is contained in a single ESB container, and uses intracontainer, it sounds like adding SonicConnect to each redundant process container would avoid the shared subscription hop and be optimal.
However, sounds like you also want LB across the ESB processes, which is currently accomplished via a shared subscription. For LB you need to: i. preserve shared subscription entry into processes for distribution purposes(as you presented) ii. use AI for LB purposes or iii. apply a separate SC to each redundant ESB container described above, and change your client HTTP connect logic to randomize the HTTP url order.
Thank you Peter, I will go with the shared subscription first and see how it goes performance wise. I will also take a look at Actional Intermediary.
Jimmy, do you have the option to use any kind of a hardware load balancer in front of your Sonic platform/servers so the client need only ever hit one address? Most of the implementations I've positioned use a hardware http load balancer out in front.
I believe we have something like that. I didn't have time to test it though. I'm not sure how well that would monitor the health of all the components used by the web service. For instance, let's say the Sonic Connect service is deployed in 1 MF container and the process implementing it in another. If the container of the process crashes, would the hardware LB stop forwarding traffic to the affected address?
The hardware LB was intelligent enough to determine if the ports in the primary/backup broker CAA cluster were responding and would route http traffic only to the ports that were listening. It really just provides another means of load balancing the client requests into the Sonic platform. The only health monitoring it does is an intelligent sensing or testing of the http ports. These were broker provided http ports pre-v8.0.
With SonicConnect in v8.0 and newer, it's a bit different as you've noted because the http connection is opened at the ESB level, rather than the Broker level. What the LB would still allow is for a client to have to only publish to or be aware of one address:port, such as in a WSDL. The LB would handle getting the request to an active listening SonicConnect service - be it primary or backup (potentially an ESB CAA implementation). We used LBs intelligent enough to establish a port group or connection group such that address:port would point to something such as the following:
server1:port1
server2:port1
server2:port2
server1:port2
and always make sure the one the request was being routed to was active.
In your example, if the container of the process crashes, then presumably, the SonicConnect service in that container may not respond altogether as well. Thus the LB would route the next http request to the other SonicConnect service in the alternate container which is still functioning.