Create multiple Server Farms in one IIS ARR (Application Request Routing)

Most people use ARR to increase web applications' scalability and reliability by leveraging rule-based routing, load balancing, shared hosting and disk caching, etc. In my case, I found it a very good solution for medium sized corporations to expose their data via RESTful, OData or SOAP based web services if they already have the infrastructure in place and do not intend to go Cloud at the moment.

In our business scenario, there are a few implicit requirements:

1. We should be able to use existing infrastructure without adding new hardware/servers.
2. We should be able to expose all services using only one endpoint, which is the gateway. Furthermore, we expose the services as standard HTTP port 80 while the actual ports for our internal services are not disclosed.
3. We must have the least number of holes in firewall for all services, ideally the number would be one.
4. We should have a consistent and clean URL pattern for all services. For example: http://greatplace.org/Services/thisService?param1=x and http://greatplace.org/Services/thatService/, etc.
5. We may also use this gateway to expose other resources than web services, e.g. reports.
6. The server farms can support different authentications, e.g. reports farm does not allow anonymous access.
7. The solution must be reliable and easy to maintain though load balancing and redundancy are not big concerns at present.

A simple practical design is like this:

For big enterprises, multiple ARRs can be utilised for routing specific types of requests to different server farms, for example one ARR for reporting server farm and one for general web services, etc. But what I am sharing here is how to use one ARR to dispatch requests to multiple server farms based on rule-based routing.

So first we create two server farms, add servers (and port mappings if any) in each farm:

Then we add the URL Rewrite rules

For the Reports Farm, we would like the original URL http://internal.server.ip:port/Reports/Pages/Report.aspx?ItemPath=SomePath to be routed to the servers in the reports farm with the exposed URL being http://external.server.ip/Reports/Pages/Report.aspx?ItemPath=SomePath, so the rule is like:

For the Services Farm, we would like the original URL, e.g. http://internal.server.ip:port/Services/Service1/Odata.svc/Products(5) to be routed to the servers in the services farm with the exposed URL being http://external.server.ip/Service1/Odata.svc/Products(5), so the rule is like:

And there we go. We can then configure the load balance and caching stuff as usual. It's awesome that ARR provides such great flexibility and capability in IIS.

Ref:

1. ARR
2. Using the URL Rewrite Module

Prevent IIS Session Timeout in ASP .NET

There are scenarios that a user may want to keep a long session alive. For example, a help desk operator logs into a web application and takes phone calls and in between submits changes to the backend systems. The phone call may last over an hour and the operator may stay in one web page and need that session to be valid when she submits the changes.
In ASP.NET, there are several common simple solutions for that. One of them is to set the session timeout attribute (minutes) in web.config.

<sessionState mode ="InProc" timeout="xxx"/>

Some people are confused at the timeout setting in web.config and another in IIS and ask which overwrites which. A simple experiment shows that the setting in web.config always overwrites the setting in IIS.
However, this is not complete for ASP .NET 2.0+. Open IIS->Application Pools->Select the Application pool for your application->Properties->Performance, set the idle timeout for "Shutdown worker processes after being idle for xxx minutes".
Otherwise, the worker process is still stopped after 20 minutes(default) and your session state will be lost.
Another way, if we do not want to rely on the settings in IIS, is to keep the session alive by ourselves in the application. Some people use an invisible frame and set auto refresh in http header, but if you are using a master page, that behavior will be propagated to all ASP pages. With .NET 2.0+ and a little bit Ajax, we have a simpler solution - add a timer in UpdatePanel. The timer will trigger a partial postback periodically, thus prods the session to be alive.

<asp:Content ID="ct" ContentPlaceHolderID="cphMain" runat="Server">
  <asp:ScriptManager ID="scriptMgr" runat="server" />

  <%-- Your content here --%>

  <%-- Heartbeat every 15min to keep session alive --%>
  <asp:UpdatePanel ID="updatePanel" runat="server">
    <ContentTemplate>
      <asp:Timer ID="timerPing" runat="server" Interval="900000">
      </asp:Timer>
    </ContentTemplate>
  </asp:UpdatePanel>
</asp:Content>

Ref:
1. Managing Session TimeOut using Web.Config
2. Preventing Session Timeouts in C# ASP .NET