J
Jason Shohet
I've got web services that work fine on a machine on our network, but not a
single IIS box in our DMZ, neither 2003 or 2000. I don't have remote access
to these machines, so I have to deploye with a floppy disk and copy all the
folders & files in the web service 'site' to a site on the new box, except
for the underscore folders (vti_ etc). I'm using framework 1.1 and VS.net
v2 to build the ws's.
On the DMZ machine I can browse to the asmx file, from the internet. Great,
so I know the site is 'working'. I can run a function on the ws that writes
to a text file on that server (I did that as a test and this indicates that
web services 'can' work on that server). But a function which has a using
com.xxx -- calls a COM object -- and that COM object hits some IP address of
a mainframe outside our network (another company) doesn't work. (But
remember it does from boxes internal on our network). I'm thinking there
are 2 possibilities:
1. manually copying over the folders (ie bin) & files in the web service to
the new subweb on the dmz is enough to get the asmx page to come up, but not
enough to get the function that wraps a COM object (which hits a static IP
address that returns some data) to work properly. Perhaps something else
needs to be done? I can't recall if I had to somehow register that com dll?
I mean, its in the bin directory of the web service that should be enough
(??).
2. Could be some flaky cisco firewall issue that weeds out specifically
certain soap calls that want to call other servers by IP address?
I'm definately not a cisco guy but I'm learning about access lists etc.
Since I'm able to call that test function that writes a text file to the
local IIS box in the DMZ, that indicates that its not a firewall issue
(since I'm going from the outside thru the firewall to call that function),
right???
Thanks for helping me out w/ the confusion
Jason Shohet
single IIS box in our DMZ, neither 2003 or 2000. I don't have remote access
to these machines, so I have to deploye with a floppy disk and copy all the
folders & files in the web service 'site' to a site on the new box, except
for the underscore folders (vti_ etc). I'm using framework 1.1 and VS.net
v2 to build the ws's.
On the DMZ machine I can browse to the asmx file, from the internet. Great,
so I know the site is 'working'. I can run a function on the ws that writes
to a text file on that server (I did that as a test and this indicates that
web services 'can' work on that server). But a function which has a using
com.xxx -- calls a COM object -- and that COM object hits some IP address of
a mainframe outside our network (another company) doesn't work. (But
remember it does from boxes internal on our network). I'm thinking there
are 2 possibilities:
1. manually copying over the folders (ie bin) & files in the web service to
the new subweb on the dmz is enough to get the asmx page to come up, but not
enough to get the function that wraps a COM object (which hits a static IP
address that returns some data) to work properly. Perhaps something else
needs to be done? I can't recall if I had to somehow register that com dll?
I mean, its in the bin directory of the web service that should be enough
(??).
2. Could be some flaky cisco firewall issue that weeds out specifically
certain soap calls that want to call other servers by IP address?
I'm definately not a cisco guy but I'm learning about access lists etc.
Since I'm able to call that test function that writes a text file to the
local IIS box in the DMZ, that indicates that its not a firewall issue
(since I'm going from the outside thru the firewall to call that function),
right???
Thanks for helping me out w/ the confusion
Jason Shohet