Separating business og presentation logic on different servers / tiers

Question

I am forced to use a hosting company, which are forcing me to separate my (web) presentation logic and my business logic on two different servers/tiers, separated by a firewall. Only the server with presentation logic will be exposed to the internet. The justification is security. I have a third server/tier with the DB, but that's trivial. I am looking for an architectural model / design patterns that is useful in this scenario.

I found a description from Microsoft on a 3 tier web architecture: Improving Web Application Security: Threats and Countermeasures, but it's about what to do, not how to do it. Microsoft's own hosting uses a two tier architecture: Windows Azure Security Guidance.

Eg. if I use the MVC pattern, I can put the Controller and the View on the presentation logic server and the Model on the business logic server. Then I can put a servicelayer on each server for the communication, but the I have to share sessions, user authentications etc. between the servers.

What is the smart way to do it? Can anyone give me a link to an article etc.?

Answer 1

Session state should be orthogonal to domain state. You most likely want to keep your session state in your view layer, and keep your service/domain layer stateless if at all possible. This means you will need to pass any user information into your service layer from your controller.

If this becomes an issue, and you need long-running session state, externalize it to a separate store, and link it to the passed in session information. This keeps the "session" for the domain layer separate from the "session" in the view layer. Thus preserving the abstraction between model and view.

You will start incurring business logic bleed into the view/controller layers, as the session state is much more conveniently located there. Be aware of it, and work to control it.

The MVVM pattern might fit this a lot closer than MVC will, and it does a better job of encapsulating the view state on the business server side. Sessions are still at issue though. You will need/want separate sessions on the view / business layer, but the one on the view layer ends up being very light. It basically just needs to handle authentication, and then have a key (sessionid) which it can pass to the service layer to allow the viewmodel to link up with.