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)
My solution is
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) 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