views:

164

answers:

4

I have two servers, one in a seperate domain and the other on the primary domain, that need to pass web service calls back and forth to each other. For security and various other reasons, I don't want these machines to talk directly to each other.

I would like to have a server that sits between them to route these web service requests through to the other server.

I started writing a .net web service application that mirrors the signatures of every possible web service call, but this doesn't seem very practical, and will need to be updated whenever a signature changes.

The built in IIS forwarding doesn't seem to do what I want as it just redirects the calls to the other machine, which isn't what I want.

These web services are passing serialized .net objects as input/output parameters.

Do I have any options for just generically forwarding a web service call to another server?

-EDIT-

To answer some of the questions regarding the need for this:

I mis-spoke when I said it was a DMZ, I should have said it was just a separate domain. I updated the question with this.

The "various other reasons" I mentioned above for this architecture is because I'm dealing with a child company that accesses small parts of our network via secured VPN. This child company has no direct access at all to the sub domain. However, they do need to access the web services on a server in the sub domain. They way I was getting around this was to have a server that can communicate to their server, as well as to our server in the sub domain.

+2  A: 

Architecturally speaking this is a redundancy. You should be looking to implement any security on the firewall.

Your web service (sitting in the DMZ) should be allowed to do what it needs via appropriately secured ports on the firewall.

I am confused as to why you need to do this?

Without more detail on the security reasons for not allowing two machines to talk directly, or more detail on why these two web services need to pass calls for identical functionality between one another it seems like it will be hard to help.

UPDATE

So you would have the child company calling functions on an appropriately configured web service (see above) which was in the DMZ for your core domain.

This way they would not need access to the sub-domain as the web-service would be calling into your domain not the child domain users per-se.

Same architecture applies doesn't it?

Charlie
Thanks for the information. I updated the question to reflect more of the real reason for needing this.
AaronS
Updated answer above, well I say answer...
Charlie
The basic idea is that they need to access webservices that are in place which they don't have direct access to. Opening firewall ports to allow them direct access isn't an option for this. I do have the option of adding a new server with access to both locations.
AaronS
A: 

WCF has routing abilities and WCF speaks SOAP over HTTP as ASP.NET WebServices. So maybe a search for "WCF routing" in google will get you some usefull info...

Arjan Einbu
A: 

I think what you're really looking for is a Proxy Server. Microsoft have their own product called Microsoft Internet Security & Acceleration (ISA) Server but you could probably find a free/open source offering that will handle your fairly simple requirements.

Although I kind of agree with Charles and fail to see why you need to do this?

Kev

Kev
+1  A: 

WCF supports WS-Addressing. Check out the MSDN on how to setup a WCF router.

Pontus Gagge