HttpContext in a distributed environment?

Jun 29, 2009 at 9:43 PM

Hi

I was wondering how the HttpContext works in a distribute environment. E.g.: The current project I'm working on has differents servers for web ,app and database.

So I was wondering how the datacontext gets managed per request in the app layer.

I'm guessing the  IIS on the web server manages the HttpContext. So can this be shared across different servers ?

Also, do all web servers have an implementation of HttpContext class (e.g. : apache, IIS) ?

Please advice.

Thanks

Kiran

Developer
Jun 30, 2009 at 8:38 AM
Edited Jun 30, 2009 at 8:40 AM

I think what you are looking for is a service layer. You can expose your service layer via web services so that it is accessible to web servers (then you can use any web server and any langauge that supports web services php, asp.net). Inside the service layer it will talk to the data layer. Lets have a look how the context is stored (GenericRepository.cs).

 public TDataContext DataContext
{
get
{
//We are in a web app, use a request scope
if (HttpContext.Current != null)
{
TDataContext dataContext = (TDataContext)HttpContext.Current.Items[DataContextKey];
if (dataContext == null)
{
dataContext = CreateDataContext();
HttpContext.Current.Items.Add(DataContextKey, dataContext);
}
return dataContext;
}
else
{
// Creates a Thread Scoped DataContext object that can be reused.
// The DataContext is stored in Thread local storage.
// See here http://code.msdn.microsoft.com/multitierlinqtosql/Thread/View.aspx?ThreadId=361
//for a discussion of this code.

LocalDataStoreSlot threadData = Thread.GetNamedDataSlot(DataContextKey);
object dataContext = null;

if (threadData != null)
dataContext = Thread.GetData(threadData);

if (dataContext == null)
{
dataContext = CreateDataContext();
if(threadData == null)
threadData = Thread.AllocateNamedDataSlot(DataContextKey);

Thread.SetData(threadData, dataContext);
}
return (TDataContext) dataContext;
}
}
}

As the service layer request if a web service we will have an HttpContext for each request. That means that it will be treated as an ordinary web site. Using web services forces you to design each service method as one complete unit of work.  So you could have multiple web servers connecting to one or more web services for data. You could also have many servers exposing duplicate web services, for load balancing, Its just like having multiple people connected to the same database.

An example project structure may look like this:

Test.Assembler (Translate Business Object to Domain Objects/Data Transfer Objects)
Test.Cms  (Windows Forms Application to control content on Website)
Test.Data  (Data Layer & Business Objects)
Test.Domain (Domain Objects / Data Transfer Objects)
Test.Service (Service Layer)
Test.Web   (WebSite)

The Test.Cms and Test.Web projects should only reference Test.Service and Test.Domain. It should never reference Test.Data or Test.Assembler. This forces your to program in an extensible way. So if you ever need to expose your service layer with web services it is easy to implement. WCF is an easy way to expose your service layer.

Jun 30, 2009 at 8:04 PM
Edited Jun 30, 2009 at 8:06 PM

Thanks a lot. 

>>As the service layer request if a web service we will have an HttpContext for each request. That means that it will be treated as an ordinary web site. Using web services forces you to design each service method as one complete unit of work

The structure ( service layer) you are talking about is available when we chose  WCF web service ?

ASP.NET Web Service:

public

class TestWebSvc : System.Web.Services.WebService

WCF Service:

public class TestWcfService : ITestWcfService

So, implementing ITestWcfService lets us access HTTPContext and if we need to do the same with a ASP.NET web service we have to create a service layer  ?

I'm currently using web service in the app tier, asp.net web app in web tier and sql server as database.

Thanks

 

kiran

Developer
Oct 1, 2009 at 9:42 AM

When moving using web services you will probably want to have a look at DTO's (Data Transfer Objects). Something which may help is AutoMapper ( http://www.codeplex.com/AutoMapper ).

You can easily get an object heirachy from a webservice but not easily update it. So try to keep all updates and edits to single objects. If you really need to do it rather use something like NHibernate.