Sunday, April 25, 2010

Windows Communication Foundation

If you are familiar with web services, this should be easy. But let us start with the basics.

We know about object oriented programming concept. In object oriented programming concept, we create an instance of a component in form of an object and work with it. As we see, objects are tightly coupled to the component and hence controls the component's lifetime.

In contrary, service oriented applications are loosely coupled. In service oriented architecture, there exists a host (call it a server) that hosts a service and there exist clients to consume the service. The host publishes a contract, which is a template that defines methods and objects that can be called/used by clients. All communications between the host and clients take place in form of messages. SOAP is one of the protocols that defines the format of the message, and it uses XML.

Service oriented architecture is mostly implemented in distributed applications. In .NET, distributed architecture can be implemented using one of the four options: web services, .NET remoting, message queuing or COM+ services. Windows Communication Foundation is a framework that allows you to use all these features at one place and most importantly, it allows you to use these features interchangeably. For example, if you have implemented .NET remoting (that uses TCP as protocol since it is in LAN environment) and want to launch it as a web service (which is accessed using HTTP protocol), all you need to do is just alter the configuration. No rework required. That is why it is often referred to as Unified Programming Model.

When we talk of WCF, we should be familiar with basic terminologies like services, service hosts, communication protocols, messaging, end points etc. I will put a few of them in short here, and leave the rest to you and google.

A host that launches a service exposes one or more endpoints for the service. Think of an endpoint as a hook. To consume a service, a client should have hook to the endpoint of the service and then it can use the service. Similarly, to be able to receive a response from the server, the client should expose an endpoint that the host will hook to. In simple terms, two endpoints always exists when a client and a host are communicating. That makes a service as a collection of endpoints. A client has to connect to the correct endpoint to consume the service it wants to.

HTTP and TCP, as discussed above, are just two examples of communication protocols. And we already know what a contract and a message is. Remember, message is an XML string here. It should have already struck you that the objects and methods are serialized into XML and passed as a message, and de-serialization occurs to get them back in form. Sounds logical?

You will find more terms on WCF and short description here.

This tutorial will tell you how to go about creating a service using WCF. It is very simple to follow. At some points, it is bit confusing since the text formatting is not done properly...but you can easily figure it out.

I will talk about WCF more in posts to come.

Tuesday, April 6, 2010

State management in ASP.NET

A web application runs over HTTP, a stateless communication mode. That means, each request for a page is a new request for the server, no matter if the same page is being requested again. When a page makes a round trip to the server (for example when you fill up a form and submit it), you can naturally expect the data you filled in to be lost when the page loads back...unless you somehow manage to save the data somewhere and fill them back in the controls when the page loads back. This is called "maintaining the state".

In traditional environments like classic ASP, it was a painful responsibility of the developer to maintain state using Request collection. ASP.NET realized the pain and has come up with multiple ways to maintain state for an ASP.NET page.

State management can be done either client side or server side. In this article and the following ones, we will look at possible state management techniques and also talk about when best to use what.

In case of ASP.NET, the features available for preserving data across page or application are as follows:
  • View state
  • Control state
  • Hidden fields
  • Cookies
  • Query strings
  • Session state
  • Application state
  • Profile properties
  • Database
We will also evaluate each of these features in terms of implementation overhead, resource requirements, client side support (for client side methods), performance and security.

Managing state client side

Client side state management mostly involves storing state either in the page's HTML, the client browser's session or some physical location on the client machine.

View state

View state is the default mechanism provided by ASP.NET to maintain the value of controls in a page across a round trip i.e. postback. When a page is being rendered on the server, the values in all controls that have view state enabled (by default all controls have view state enabled) are serialized into XML and then encoded using base64 encoding. This value is then stored in a hidden field named "__VIEWSTATE". You can view this field using the "view source" option in the browser. A typical example would be:

<input type="hidden" name="__VIEWSTATE" value="dDwtNTI0ODU5MDE1Ozs+ZBCF2ryjMpeVgUrY2eTj79HNl4Q=" />

So, view state is typically an encoded string containing IDs and values of controls in a page so that when the page is posted back, the server automatically puts the values back into the controls before sending the page back to client (rather than developers required to do it themselves in traditional environment).

Besides storing control's values, the view state collection (which is nothing but a dictionary object) can be used to store other values as well, as shown below:

ViewState("MyPostBackCount") = 2;

A view state can store data of multiple data types, viz. strings, integers, boolean values, arrays, array lists and hash tables.

However, in case of large amount of data being loaded in controls e.g. in case of grids, view state can result into a huge string and can have negative impact on performance by slowing down page load on the browser. Huge view state also means huge amount of data flowing between the client and the server. ASP.NET provides an option to disable view state at the page level and also at control level. When it is a choice between comfort and performance, disabling view state can be an option; however the developer will then have to implement an alternative for maintaining the state. Also, in case of data bound grids, disabling view state can create problems in default paging and sorting behaviour.

Implementation - View state is maintained by default and hence needs no specific programming to be done.
Resource requirements - Since the view state is maintained in a hidden field, it does not consume server resources. There is an overhead involved in encryption and decryption but it is so insignificant that you don't need to bother about it.
Client side support - Hidden fields are allowed by most browsers and do not need specific permission from users. However, for devices that have constraints loading huge data (e.g. mobile devices) or if there are firewall restrictions on the limit of data allowed in hidden fields, large amount of data in view state can create problems.
Performance - As discussed, large amount of view state data can be a serious bottleneck. If view state can result into performance issues, it is wise to disable view state and implement an alternative.
Security - View state is an encrypted string. It provided optimum security, but still there is a risk of view state data being tampered because it is after all hidden in the form itself and can be viewed on browser end.

Control state

Like view state, control state is also an encrypted string generated at server and stored in a hidden field to persist data across postbacks. But control state only contains critical data about controls for the controls to function properly and unlike view state, control state cannot be disabled. If you were wondering, how could controls function properly if view state was disabled...control state is your answer, but this is very simply put. The truth gets worse if we dive deep...glad, we won't ;-).

Controls state is a separate object than view state and is initialized by the PageStatePersister class while view state is an instance of the StateBag class.

Implementation - Control state is custom state persistence mechanism and hence requires some programming to be done. We will look at control state with example in a later article.
Resource requirements - Like view state, the control state is also maintained in a hidden field and does not consume server resources.
Client side support - It's just a hidden field!
Performance - Unlike view state, data in custom state never gets large enough to pose a worry.
Security - No worries...custom state is an encrypted string and it does not store user provided data.

Hidden fields

A hidden field is a control that renders a hidden input control that can store some value and can be used for persisting data across postback. Unlike view state and control state that is handled by ASP.NET, hidden strings are to be added by the developer wherever required. Hidden fields are visible on client and not encrypted either. Hence they should never be used for storing sensitive data.

An .aspx page can contain,

<asp:HiddenField ID="MyPostBackCount" runat="server" />

and this can be accessed in codebehind as:

HiddenField1.Value = "2";

Implementation - Hidden fields are easy to implement as shown in example above.
Resource requirements - The hidden field control generates an equivalent input control that is hidden and not displayed on browser. No server resource required.
Client side support - This is also just a hidden field!
Performance - Issues related to amount of data stored in the hidden field can pose similar problems as with the view state. Hidden fields are never advised for large amount of data.
Security - As mentioned, hidden fields are visible on client using the "view source" option in browser and the stored values are not encrypted either. They can be easily tampered with and are strictly not suggested for storing sensitive data.


Cookies are well known in state management world. They are small bunch of data stored on client side either in browser memory or text files. Cookies are not ASP.NET specific but since they are also state management measures, let us evaluate cookies as an option. Cookies can be temporary or permanent (persistent). Also, cookies can have multiple values in a single cookie. We will discuss cookies in a separate discussion.

In ASP.NET, cookies are accessed through the Response object.

Response.Cookies["UserName"].Value = "guest";
Response.Cookies["UserName"].Expires = DateTime.Now.AddDays(1);

Implementation - Cookies are simple collections and easy to use with less programming required.
Resource requirements - Cookies are client side storage option, hence they either consume space in the client browser's memory or physical disk. They do not pose any demand on server resources.
Client side support - Cookies can be disabled by client and hence has restricted applicability. Also, cookies have limited allowed size on client, often up to 4 KB.
Performance - Cookies have size limits and hence do not contribute to performance bottlenecks
Security - Cookies can be easily tampered with and is a known threat area. It is strongly advised to use encryption and decryption with cookies and not to store sensitive data either.

Query strings

Query string is another option and a traditional one for persisting data. It is data appended to an URL in a pre-defined form that can be read as parameters. ASP.NET exposes the parameter collection through Request object.

Implementation - Query strings are well known and simple to implement.
Resource requirements - Since parameters are appended to URL, it has nothing to do with serer or client resources. However, the larger the data, the more the packets transferred.
Client side support - Query strings are well supported but fall within the size limit of about 2083 characters for URLs.
Performance - Query strings do not contribute to performance bottlenecks for obvious reasons.
Security - Query strings are the easiest to play around with and tamper. It is visible with the URL and should only be used for limited non-sensitive data.

Maintaining state server side

Maintaining state server side often means storing data in server memory or some data store.

Session state

Session state is a server side data storage mechanism that stores data in key-value pair format in server memory and is maintained by server. This state is maintained as long as the browser session is active, i.e. data persists in memory across multiple page requests as long as the session is active. Each user connected to the server has its own session id and its own session state. Session state should be used only for data that need to persist across multiple page requests or throughout the session.

Session["UserName"] = "guest";

Implementation - Session state is easy to use as shown in example above.
Resource requirements - Session state resides in memory on server. If large amount of data or objects are stored in session state, it will end up consuming a lot of memory on server and badly degrade server performance.
Performance - Large amount of data in server state can be a performance issue since the server will have to resort to virtual memory paging in absence of the memory consumed by server state.
Security - Session state is maintained in memory on server. Security is not an issue.

Application state

Application state is a global storage mechanism that stores data in key-value pair format and is maintained by server, like session state. However, this state is maintained at application level, i.e. data persists across multiple page requests and even multiple sessions. It should be obvious that application state is a very precious store and has the longest life span among the methods we know. Use it wisely!

Application["ClickCounter"] = clickCounter + 1;

Implementation - Application state is easy to use as shown in example above.
Resource requirements - Like session state, application state consumes server memory. Worse, it persists across multiple sessions as well. If large amount of data is stored in application state, it will end up consuming a lot of memory on server and hence degrade server performance.
Performance - Large amount of data in application state can choke up server memory and degrade server performance.
Security - Application state is maintained in memory on server. Security is not an issue.

Profile properties

Profile properties use external storage medium (data store) to persist data rather than in memory. This feature uses ASP.NET profile to maintain user specific data that requires to be stored and used across multiple sessions of an individual user. We will talk about profile properties in a separate article in detail.

Implementation - Profile properties are easy to use, given that the developer can configure the profile provider.
Resource requirements - Since data is stored in data store rather than memory, it does not consume any resource in server memory at least. And since the storage is done in an external medium, there is no limit on data storage.
Performance - Since data is stored in data store than memory, storage and retrieval of data is relatively slower than other server side methods. But this should not be a concern.
Security - Well, it is not as secure as other server side methods, but it does not pose huge threat either.


Often, database is also used along with cookies or session states to store data in order to persist it. In simple terms, if you think that you need to store some data in your database related to user's authentication or preferences or whatever, you can store it in database as well.

Implementation - Maintaining state in database is as simple as performing normal database operations. Of course, it is not automatic and requires programming.
Resource requirements - Database gives you an unlimited storage and there is no server memory in concern here.
Performance - Obvious as it is, database operations would consume some time and hence this method is not as quick as the rest. I would say, performance here is specific to implementation.
Security - Security relies on what measures are taken to secure database. Adequate authentication and authorization can introduce required security factor.

We are now familiar with the possible methods of maintaining state in ASP.NET. In the next article, we will talk about which method is best in what circumstances.

Monday, April 5, 2010

ASP.NET Page Life Cycle

By understanding the details of how an ASP.NET page runs on the server before the rendered HTML is sent to the browser, one can realize how many significant stages a page goes through and how much control it releases to the developer. While the page runs through its life cycle, while the methods of the page’s base class can be overridden, a number of events are also raised that can be handled and exploited.

I wanted to write in detail about the life cycle, but time know. But, everything about the life cycle can be found here, put in simple terms and details.

Recently a diagram was also added in this article, that makes it really clear. Here is a direct link to the image if needed. This sketch seems to be influenced by a diagram by some "Andrianarivony Leon" that has been on the web for a while. But the diagram in the link above is a better version, I wont post the original here. Have a look...the diagram is a must have for a .NET developer for his/her dashboard.

Update on June 12, 2010:
I found a video on the ASP.NET site that might be helpful to understand the life cycle. You can access the video here.