Shannon,
So the WSDL is available on port 10043, but the service itself is on
10033. Right?
From the outside, do you request the WSDL from 10043, or some other
"external map" port or URL?
Here's a theory. As you suggested, if the IBM i's service listens on
10033, the reverse proxy would have to map to that. Even if the reverse
proxy already mapped to it (meaning that port 10033 isn't accessible from
the outside, but instead is mapped to some other external URL via the
reverse proxy), it sounds like the WSDL is oriented toward the INTERNAL
URL (10033). Therefore, you may have to edit the WSDL to point to the
external service URL, not the internal one (with 10033).
Hope that makes some sense. I'm up late working on a presentation, so we
can keep the discussion going if you want to.
Alan
On 3/4/2012 12:37 AM, Shannon ODonnell wrote:
Great suggestions Alan!
I see no errors in the iSeries Apache log and none in the iSeres Web
Services Server logs either.
I am unable to get onto the Reverse Proxy PC as another IT guy handles
access to that and he is not available so late at night.
I'm hoping he'll contact me tomorrow (I've sent him enough emails to get
his attention today!) so that he can look at that for me.
When testing the call to the Web Service through the public entry point
(Reverse Proxy Server PC) using SoapUI the error message I see is:
"Connection Refused".
To me that sounds like the two Apache servers cannot talk to each other
over under these conditions.
What is odd though is that I am able to retrieve the WSDL from the
iSeries, while NOT! On the VPN, and going THROUGH the Reverse Proxy
Server. So I can get the definition file, I just cannot get data
requests through.
Earlier today I was looking at the generated WSDL files that the IIS
server created and I saw one thing I was not expecting.
Our Web Services Server listens on Port 10043. But within the WSDL
file itself, it points to port 10033.
So I'm wondering now if the Reverse Proxy Server needs to also map to
port 10033 in addition to 10043 that it already maps to.
This stuff makes my head hurt trying to unravel it all.
From: Alan Seiden [[1]mailto:alan@xxxxxxxxxxxxxx]
Sent: Saturday, March 03, 2012 11:29 PM
To: Web Enabling the AS400 / iSeries
Cc: Shannon ODonnell
Subject: Re: [WEB400] Reverse Proxy Servers and Web Services
Shannon,
Two questions to start, checking the Apache logs on both servers.
1. What is shown in the reverse proxy server's Apache access log? Can
you tell if proxy Apache is receiving and forwarding the request
properly to the IBM i?
2. Is the IBM i receiving the request correctly? The IBM i's Apache
server logs may contain useful information, too.
Alan
--
Alan Seiden, PHP for IBM i Consultant and Developer
Zend Certified Engineer for Zend Framework
Strategic Business Systems, Inc. | phone: 201-327-8746 x144
[2]
http://www.alanseiden.com | [3]alan@xxxxxxxxxxxxxx
Twitter: @alanseiden
On 3/3/2012 11:46 PM, Shannon ODonnell wrote:
Hi,
I have a web service, created and installed into the iSeries Integrated Web
Services Server.
I have a PC that is outside the DMZ and which has Apache on it. The Apache
server there was set up as a Reverse Proxy server that interfaces with the
Apache server running on the iSeries which is behind the DMZ.
Now.if I get on the local VPN, and test calling that web service by going
through the Reverse Proxy, I am able to connect to the Web Service fine and
pull my data back.
However, if I get out of the VPN (or get on another non-VPN connected PC)
and try to contact that Web Service via the Reverse Proxy server, what I get
back instead is an error telling me that the Soap request cannot be decoded,
which makes sense as the value it returns to me is NULL.
I am wondering if this is an authority issue on the iSeries/Apache server.or
possibly an authority issue between the Reverse Proxy Server and the Apache
server on the iSeries.
Honestly I'm at a loss as to what to do next on this to try to narrow down
the problem.
I am open to any and all suggestions or thoughts on this.
Thanks!
Shannon O'Donnell
References
Visible links
1. mailto:alan@xxxxxxxxxxxxxx
2.
http://www.alanseiden.com/
3. mailto:alan@xxxxxxxxxxxxxx
midrange.com
