Alternative to Reverse Gateway Setup for B2B Integrations

Is there any alternative way we can setup the B2B Integration’s other than RG setup ?

Any alternative product we can use for secured load balancing and HA ?


I believe there are third party tools for load balancing and HA like BigIP,Citrix etc… to name few but not very sure if SAG has certified it or encouraged.

Here are some hot topics for LB/HA:

Thanks RMG …

Hi Prashanth,

Load balancing and Reverse Gateway are different concepts(Please note that you cant use both AFIK). I presume you are referring to load balancing for clustered environment(HA). Load balancing is an optimizing feature you can use with clustered integration servers. A third party load balancer can also be helpful, if you have other servers(Web, App) than WM servers. Products like F5 also provides virtual IP support, blacklisting, algorithms(Ex: Round Robin…etc).

My $.02

We have good load balancing solution in place for clustered Integration Servers.

I am more interested in if there is any alternative way where we have a secured gateway to internal netwokk as supported by Reverse Gateway concepts.


No other alternative i can think of, but is there any particular reason for deviating from existing Load balancer? If properly implemented(IP whitelisting and port access in LB,SSL), load balancers will shield servers pretty well from outside world(As you mentioned “a secured gateway to internal netwok”).


There is no alternate way other than listed above solutions and as Niteesh mentioned.

Some of our Integration patterns requires RG servers in sync. Since we can not cluster them, I want to explore any other options we can have on product level.

Did you go with your network team and if they can do LB to your webM servers (non cluster)?

Terminology exploration:

“Cluster” - a way to view multiple servers as though they are one

“Load balance cluster” - Multiple servers behind a common name. Which node traffic is routed to is unknown to the caller (and the caller doesn’t care)

“IS cluster” - a specific software feature of IS, which provides coordination of execution of some components (e.g. JDBC notifcations, scheduled tasks, etc.) such that only one node runs them at a given time. People usually over-estimate what IS clustering provides.

“Broker client cluster” - Multiple Broker clients (such as IS) connecting to a single Broker, achieving load balancing/HA for processing messages from queues.

“TN cluster” - Multiple TN servers (on IS servers) sharing a TN DB and communicating to each other to share set up info.

Multiple RG servers can be behind an LB device.

IS instances can connect to each of the RGs.

Thus, LB and RG can exist together.

LB cluster and IS cluster are independent. One does not need to have an IS cluster to have an LB cluster. If one has an IS cluster, it typically also has an LB cluster but technically it is not required.

Broker client cluster can exist without any of the other cluster types.

TN cluster can exist without any of the other cluster types. (or at least it used to be able to–I haven’t looked at 8.x)

Hope this helps.

Yes. We are in touch with our networking team and exploring different options available.

There are multiple options to consider. Looking at option to avoid RG servers.

Thanks for the replies.

OK cool.

“Looking at option to avoid RG servers.”


Prashant Pai Wrote:
Some of our Integration patterns requires RG servers in sync. Since we can not cluster them, I want to explore any other options we can have on product level.

I’m not sure what “pattern” would require “RG servers in sync.”

They can be put in an LB cluster.

If by “since we can not cluster them” he means cannot configure IS clustering then that is not applicable. An IS cluster does not sync anything. In an IS cluster, one must manually make sure each instance is identical to the others manually.

So the question is back to: What does RG cluster not do that Prashant is trying to achieve?

His question points to when the IS (non-cluster mode) in some of their scenarios…per his note above based on what I understood.

One of FTP patterns we have external partners send file using FTP on RG servers. Files are copied to directory on each RG server. Another scheduled job runs on each server to send files to internal servers. Now since RG servers are not in cluster scheduled job runs independently. If we store the file at common location then it creates conflict sometimes if both scheduled job try to pick same file. We store them in different directory. So if one of the RG server fails then files will have to be copied manually to another directory for processing if its taking time to resolve the issue.Its old implementation.

We are planning to change it. Instead of saving files on RG servers we will send them directly to internal servers. This solution has some advantages and disadvantages.

I was looking is there any alternative way its implemented without using RG servers.

We have another product in company mainly used for portals but not sure we can use it for SAG products and partners sending files via FTP. I think we have to do more investigation internally on it.

Thanks for the thoughts …

Is there any way your RG/Internal server get/pull file instead of having external partners ftp push the file and then feed the internal apps at your own schedule? I am just asking with out fully knowing your env access policies.

Thanks for sharing the details.

As you probably know, the “Reverse HTTP Gateway” does not support any protocol other than HTTP for its “reverse gateway” function.

Thus, you’re using the RG server for something it was not intended for. And using it as an IS instance rather than an RG. This has a variety of security concerns. I’m somewhat surprised that the security folks have allowed the holes in the internal firewall to be opened.

In any case, there are several approaches to consider. Below, I’ll use the term “DMZ server” instead of RG to make it clear that the RG function is not being used for this.

  • As RMG suggested, have the internal IS retrieve from the DMZ server instead of DMZ server pushing in.
  • Have the internal IS retrieve the files from your partner instead of them pushing to you.
  • Use a “real” FTP server for the partners to push to. Then have your internal IS instances pull files from there.
  • Have them use HTTP to post the data. This is workable only if the data size is reasonable.
  • Have you checked if the DMZ server IS instances can be IS clustered? Since RG per se isn’t involved here, perhaps that would resolve the scheduler issue.
  • Implement a “poor man’s” scheduling cluster. I described this in another thread on the forums. Basically, you customize your services to be “cluster” aware. When the task starts, it checks a config file holding a list of the servers. It checks each entry in the list. For each entry: if it is itself, then continue; else check if the other server is “up”. If so, done. If not, continue ot the next entry. This provides for just one server running the scheduled task.

Hope this helps.