External Communications

We have a a few external business partner web services that we need to call from our WM IS server and we also have a few web services that we need to expose to business partners. We have decided to not go with the WM Reverser Invoke option due to the outbound requirement - our understanding is the RI does not support outbound calls (please correct me if I am wrong or recommend a better approach). The plan is to go with a normal proxy server solution through which we would go for outbound calls as well as inbound calls. However, we have one of our business partners, who happens to be on the same intranet but behind a firewall that requires IBM MQ messages to be sent directly to its MQ server. One option is to open up the firewall to this server and use the WM MQ adapter to send messages to it. Are there any other options?

This is incorrect. RI exists to provide a secure way for external partners to reach IS it does not address outbound communication initiated by IS. By implementing RI in your company’s DMZ, you can block all inbound traffic to the internal IS IP address. Outbound traffic is not affected, but may certainly be routed through an HTTP proxy server if desired.

Sending MQ messages to an external partner would require much coordination between your client’s network administrators and those at your company. It would not be enough to open your own firewall, the partner’s would also have to be open. In addition, there would quite likely be timeout issues as firewalls tend to close connections when not in use.

There are many, many options for sending information from IS to an external partner including plain ole HTTP post to a partner’s URL, SOAP, FTP and even email.



What are normally the best practice when having both inbound and outbound communications with external systems. IS RI or normal HTTP proxy? Does it perhaps also make sense to put a IS server with these services in the DMZ and have this IS server configured in the firewall to talk with backend systems behind the firewall. Passwords for these systems like DB connection strings could be encrypted on this server.

I dunno about “best practice” but here is what I’ve seen in multiple companies:

  • Outbound communication is done from one or more IS instances inside the firewall.

  • For inbound communications, I’ve seen two major approaches: 1) nothing outside the firewall initiates a connection to IS; either an FTP server within the DMZ is used or IS connects to an external FTP/HTTP server to retrieve documents; 2) an IS RI server is deployed in the DMZ; all the internal IS instances establish a connection to the RI–the RI never initiates a connection (firewall rules do not allow connection initiation from outside in).

I’ve not seen anyone use an HTTP proxy but IMO that’s a good way to go–it’s a well-known entity that can be managed by network and security teams. IS RI is a virtual unknown and would will likely require a commitment from someone on your wM team to manage and monitor in prod.

If you use IS RI, you should have at least two of them for fail-over purposes. Use a LB device in front of them to expose to the world. Each IS within the firewall will connect to each RI server (not going through the LB).

I’ve seen companies put a “complete” IS in the DMZ but I wouldn’t recommend it.