How to make Reverse Invoke Work

Hello, All,

I am a beginner of webMethods. And now I want to use the Reverse Invoke feature of webMethods. I have gone through the chapter ‘Protecting Your Internal Integration Server with Reverse Invoke’ in file ‘ISAdministratorsGuide.pdf’. And I have configured the Proxy Server and Internal Server according to that PDF. But I have no idea how to call services in Internal Server through Proxy Server.
Shall I use services like ‘pub.client.http’ or ‘pub.remote:invoke’ ?





Its better to use this service ‘pub.remote:invoke’ and ping the InternalServer.Ofcourse http service will also do the job.


Hello, RMG,

Thank you very much for you reply. But I am still confused with how to call internal service from Proxy Server.

‘Remote Invoke’ need Internal server open a public port. But reverse invoke do not need Internal server to open any public port.

For example, on Proxy server, I open port 8888 as proxy port and 9999 as register port. How can I call a service named ‘internalService’ on Internal server ? If I use ‘Remote Invoke’ on Proxy Server to call that internal service on Internal Server, I think I need to configure ‘Remote Server’ and its port on Proxy Server, then I need to know an public port of Internal Server, which conflicts with the idea of Reverse Invoke.

Would you please give some more detail explanation ?

Thank you.


Gu Song


Use the search functionality of this site look on keyword “Reverse Invoke” and you will see the hits…it saves time and this procedure might have already discussed in other threads.


To give you an idea of how reverse invoke works:

There are two machines involved: the “internal” integration server which has your actual code on it, and the “proxy” integration server, which sits in the DMZ and has no code to speak of on it.

So what you do on the proxy IS is open up a proxy port (“forwarding port” if you like) for external systems to connect to. You also need a registration port open for the internal IS to connect to and keep connections open.

What happens is that when you “register reverse connections” on the internal IS’s web admin UI: the internal IS opens a connection from within the safety of a “hard firewall” (one which doesn’t allow any outside connections to hit your internal IS’s machine). It connects to the registration port on the “proxy” IS. Once this connection (or many connections generally) is established, it keeps the socket(s) open which allows the proxy IS to relay any requests that come in on the proxy port from the outside world.

So all the outside world has to do is to invoke your services through the reverse invoke server is to make the call on that proxy port on the reverse invoke proxy IS.

To put some numbers in to clarify:

On the proxy IS on machine MY-PROXY-IN-DMZ:

  • normal admin port open 5555
  • change mode to be a proxy IS
  • create a registration port (6666), and a proxy port (7777)

On the internal IS on machine MY-INTERNAL-IS

  • create a remote server alias for your proxy IS (to host MY-PROXY-IN-DMZ, port 6666)
  • register reverse connections (to the alias above, say 10-20 connections)

On the external business:

  • invoke the service using MY-PROXY-IN-DMZ, port 7777

Figured I’d stop this from being one of those posts that people come across and then find it unanswered.

Nathan Lee
WmUnit - The webMethods testing framework.

Got inspired and fleshed it out a bit: webMethods reverse invoke explained at

Nathan Lee
WmUnit - The webMethods testing framework.