The Key Technology for Windows DNA Web Applications

To create Web Applications that meets today's requirements on scalability, throughput, maintainability, time-to-market and total cost of ownership, Microsoft offers everything needed with Windows DNA (Distributed interNet Application Architecture). But Windows DNA not just offers a complete set of services and applications like IIS, COM+, SQL Server, MSMQ, DTC but also specifies a special application design to meet the needs, called Three-Tier-Model. This model forces a strictly separation of the three application tiers: presentation layer, business logic and data storage.

This article will show you how to use XML as a key technology to improve Three-Tier applications to reach the goals.

- Three-Tier-Model Pros -

Just a word about some basic pros of the Three-Tier-Model. Because of the strictly separation of the three tiers, it is possible to get better usage of developer resources. The development team now can be split into three sub teams: One responsible for the UI, another for the business logic and the third for the data storage. When the interfaces between the tiers are well defined, every developer can focus on his/her task without worrying about the others tiers he/she is not involved in. So developers with special skills in data access programming don't need to think about ASP programming and the like.

And since the interfaces of the different layers are well defined, it is much more easier now to test the separate parts of the application.

So implementing the three-tier-model should not just increase time-to-market but also improve the quality.

- How to realize it -

To show you how to implement a Three-Tier-Web-Application, I will us asimple web shop as a sample. This web shop should offer the common services, means displaying the list of articles, managing the user's shopping cart and handling orders.

The first approach might look like this:

Active Server Pages will prepare the data sent to the HTML browser. These ASPs will also start the corresponding components of the business logic to retrieve the article information, manage the shopping cart and handle the order.

The business logic is separated into two parts. One part (means onecomponent) handles requests which requires transactions (like ordering), the other those which don't (like returning the list of articles). These two components are the only ones used by the ASPs. It is not visible to the ASPs which component is used at least to service the request. The business logic itself is not implemented in the components used by the ASPs! It is separated into several components for each aspect.

In the data layer, there will be one ore more components to access theunderlying SQL Server database.

Passing disconnected recordsets does the data transfer between the different tiers. So the ASPs have to prepare the HTML code programmatically.

The user's shopping cart, in this sample the session state, is kept by a session object, which is created by the IIS and will expire after a customizable time.

The order itself is not written to the database immediately. It is added to a message queue so it can be processed when server load is low. This helps to save server resources when lots of requests arrive which makes the application more scalable.

- Comparing Requirements / Realization -

Comparing the implementation of the web shop with the requirements defined by Windows DNA, the application seems to be well scalable and simple to maintain. So why is the title of this article 'XML - The Key Technology for Windows DNA Web Applications'? As said, it only seems. But having a closer look, there are two things that will destroy our illusions as soon as there is heavy load on the machine or we have to change the user interface.

First, look at the session object that keeps the session's state. Different web servers of a server farm cannot share a session object. It is bound to the server that created it. (Microsoft .NET promises to eliminate this drawback, but there will be a few web applications built until its release.) This means, the physically same machine must service a user during the whole session. Such behaviour torpedoes any load balancing systems of a server farm. A session object also needs system resources, say memory. The more users a server services, the more memory is required. And when all physicalmemory is used up, the machine will starts swapping to disk and can't reach the optimum response time any more. So keeping the session state inside of a session object clearly contradicts the need for scalability. Since the session object's lifetime have massive impact on the resources needed by the web application, the problem of the right chosen timeout arises. Choosing a time too short, it is possible a session object will be destroyed although the user hasn't finished yet and so have to refill the shopping cart again.Looking at the low tolerance level of Internet users according to badhandling you can be sure the customer is lost and will never come backagain. Setting the timeout too high, the system will need too much memory, which might lead to slower response time. So the session object not just contradicts the need for scalability but also the need for throughput.

The second point is the maintainability of the user interface. The ASPs generate the HTML code. As you know, ASPs are a mix of HTML and program code. (Microsoft .NET's 'code behind' concept in ASP+ will stop this, which is a big advantage beside others of ASP+.) So what happens when the complete design of the web shop user interface must be changed? Right! All ASPs have to be edited. And since they include a lot of programming logic, this is not an easy task. It will slow down maintenance time, which has a negative influence on the time-to-market factor.

- XML - The Solution -

Looking at the problem of keeping the state, there seems to be only one solution: manage it by the data layer. Putting the state management to the client's side will open up new questions according to browser independency and installation free applications. Now that the decision is made, how to keep the data? Using fixed structures, there are two problems: Changes in the structure and the need for different tables in the database for different state structures. Two points which affects the maintainability of the system. What's needed is something flexible in its structure and easy to store and transfer.This is where XML comes into play. XML is extreme flexible since it has easy to change data structures, it's easy to store in a database and transferring documents makes no problems. There are also comfortable ways to manage the documents programmatically. So by moving the state into the database and keeping it by XML documents two demands are met: The system is more scalable and easier to maintain.

Now that XML is already used, perhaps it can offer something else to improve the application.

The second problem was the generation of the HTML code by the ASPs, which affects maintainability. And here again XML, together with XSLT, brings us to a really satisfying solution. Instead of passing the results of the business logic to the ASPs as disconnected recordsets, now XML documents are used. The transformation now can be done independent on any program logic inside of the ASPs by XSLT. All the ASPs have to do now is to assign the right XSLT file to the according XML document, and pass the result to the client. Changes in the look and feel of the application only affects the XSLT files, without any influence on the running application. XML again improved maintainability of the application heavily.

XML is now used by the presentation and the data layer, but on different areas. So why not use it in all tiers of the app. XML offer some advantages. Because of the hierarchical data format the access to the different information is simplified. The interfaces of the different components can be extremely reduced because only XML Documents are passed. Also there is no more interface version and incompatibility problem. The complete usage of XML over all three tiers offers a big potential according to the maintainability of the system.

By showing the possibilities of XML it should be made clear that XML is not just a tool for platform independent data transfer. The extensive usage of XML has a strong influence on the complete design of an application and so should be taken into consideration as early as possible.

- Conclusion -

The usage of Windows DNA in conjunction with XML offers all the abilities today to build flexible, demanding distributed applications, which meets all market's demands. And using Windows DNA and XML today will make your applications ready for the next generation: Microsoft .NET.