0

Forgive me if this a duplicate, I didnt find the answer.

We have the following network setup

Internal | DMZ | Internet

I believe it is standard for security.

I then have an internal WCF service that has both business logic and persistence.

Since data should not ideally be hosted in the DMZ, I assume that the best solution would be having a "dumb" shell of that same service deployed to the DMZ and is passed parameters necessary to communicate with the Internet

I believe it would look something like this:

Internal | DMZ | Internet WCF_Full <---> | <-- WCF_Thin --> | <----> (Third party)

  1. What would be the best approach?

My solution is

  • having a service reference in WCF_Full that points to WCF_Thin.
  • both with identical interfaces, and WCF_Thin just passing on messages to the internet

The challenge came in that I have to pass more data(config+business messages) along the wire, to get WCF_Thin to work, which I wouldnt otherwise be doing if I had persistence on WCF_Thin.

  1. Is that a worthwhile trade-off, or am I doing it wrong?
tinonetic
  • 7,751
  • 11
  • 54
  • 79

1 Answers1

1

1) The "best approach" is subjective and it'll always depend on context

2) I have seen it done as you describe but only for externally initiated traffic. The DMZ hosted a 'Relay' version of the service and as you describe it simply passed the traffic onto the full version. In our case the full version was hosted on an 'internal' network which then accessed the data store and returned it back the chain. Not sure why you'd need to do this for internally initiated traffic though.

This 'Relay' solution added a fair amount of complexity and we eventually replaced it with a application layer gateway (ALG) that basically did the same thing albeit with less complexity. The ALG proxied the traffic to the full version of the service and the 'Relay' version was retired. If you Google 'application layer gateway' you'll find a bunch of info.

The same proxy-ing can be done for internally initiated calls destined for the outside. Consider a load test scenarios where you don't want to load your vendor's services or you pay per call. To help with this you can setup the ALG to recognizes the signature of the message and can respond in whatever way you determine.

HTH

Stephen McDowell
  • 839
  • 9
  • 21
  • Thanks for your feedback. Will mark it as an answer. Your last paragraph is exactly what we also did when we needed to load test our component. Only that we replaced real calls with a mock service – tinonetic Aug 10 '16 at 07:47