Simple Reverse Invoke not working

, ,
1

Hello, we have a RIP and Hub 6.5 setup consistent with the webMethods Administrative Documentation for Reverse Invoke proxies, blog guidelines eg [URL=“Best Online Casino in Australia | Top Licensed Casinos for Gamblers”]Best Online Casino in Australia | Top Licensed Casinos for Gamblers etc
From the Hub Admin Console I can see about 20 connections from the hub back to the RIP have been successfully established att startup on port 6666 The primary port for the RIP is 4848 and for the HUB is 5555
The target service deployed on the hub has been added to the ‘Allowed List’ on the hub and the right now the inner firewall is open to this port and ip etc etc

My question is how do i setup a service on the RIP to successfully call this HUB Service. I generated two RPC WSDLs from the hub service, one for port 5555 and on for port 6666, and generated Connectors deployed on the RIP. When I run them, it just times out…

        <webM:message xml:lang="">java.net.ConnectException: Connection timed out</webM:message>
    </webM:exception>

How should the RIP service instance be setup to gain access to the Hub service via the reverse invoke connection ?

all replies appreciated ! :confused:

2

“My question is how do i setup a service on the RIP to successfully call this HUB Service…and generated Connectors deployed on the RIP. When I run them, it just times out…”

Right, because your firewall doesn’t (and shouldn’t) have any open ports to your hub.

The RIP is just a traffic cop. There is no need to deploy services on it. Say you have a service on the hub that would be invoked internally using [URL=“http://hub:5555/invoke/myFolder.subFolder/myService”]http://hub:5555/invoke/myFolder.subFolder/myService[/URL]. To invoke this from the Internet via the RIP you’d do the same thing with a slightly different URL: [URL=“http://rip:4848/invoke/myFolder.subFolder/myService”]http://rip:4848/invoke/myFolder.subFolder/myService[/URL]. You don’t need to do anything on RIP to make RIP call the service on hub. It will just do it. Of course for SOAP calls, the URL will be different from this example but the concept is the same.

I hope I understood your question.

P.S. You shouldn’t use SOAP RPC. Too many interoperability issues. Use doc/literal instead.

3

thanks for the speedy reply, ok this makes sense since the point of the reverse invoke server is to allow the inner firewall between RIP and HUB to be configured to prevent inbound connections.

If we are exposing the WSDL for the hub service to another external webMethods partner, i should ensure the host and port references are RIP and 4848 respectively, then their webm web service connector will work ? is this best practice, say rather than a pub.remote:invoke or a (direct) soapHttp call ?

Our convention too is to use doc lit…

4

Yup and yup.

Definitely avoid using pub.remote:invoke. You shouldn’t know or care that your external partner is also using IS. They could just as easily be using Java, perl, .net, whatever.

Whether to use soapHttp directly or use the Web Service Connector wizard is up to your partner. Both approaches can work. Keep in mind that the wizard just generates a FLOW service which uses soapHttp. It is pretty straightforward to create an equivalent service by hand. Search the forums for “web service connector wizard” for threads on the topic.

5

ok yep, but i am finding the doc lit web service connector is not resolving the service when i change the address url from [URL=“http://hub:5555/soap/default”]http://hub:5555/soap/default[/URL] to [URL=“http://rip:4848/soap/default”]http://rip:4848/soap/default[/URL]

giving the usual message when the webm doc lit convention not setup correctly, eg
[ISS.0088.9122] Service [URL=“http://www.xxx.com.au/xxx/yyy:serviceName”]http://www.xxx.com.au/xxx/yyy:serviceName[/URL] does not exist

is the url for doc lit right ?

6

just realised the hostname and port to use is the rip hostname and the rip-defined ‘Proxy’ port number, (not the hub primary port nor the actual port number in use by the hub in the establishment of the reverse invoke connections) !
In other words as the man said the rip automagically does the conversion of both host and port number in order to connect to the hub via the reverse invoke connection.