Architecting a CMS in ASP.NET

ASP.NET offers a wide range of integrated functionality to support in-house content management system solutions. We discuss the basics of tiered CMS architectural models.

You just left the weekly meeting with your boss tasked with a new assignment. It shouldn’t be too hard; all you have to do is create a “simple” Microsoft .NET-based Content Management System (CMS) for your company’s Web site. As you walk down the hall to your cube, it dawns on you: No one else even tried to get the assignment. You even remember seeing a few colleagues trying to hide when the project was announced.

Little did you know that your new assignment will force you to learn many different technologies, like HTML, JavaScript, ASP.NET, C#, SQL, XML, ADO.NET, .NET remoting, and Web services. You'll also have to master concepts like n-tier architecture, database development, version control, workflow, personalization, and security.

Believe it or not, you did get the plum assignment, precisely because you’ll have to learn a lot to bring in the deliverable. The problem is that few people will realize just how knowledgeable you’ve become while getting your company’s “simple” .NET CMS up and running.

This series of articles will discuss much of what you'll need to build your “simple” CMS. Along the way, we'll explore the many technologies and concepts associated with CMS development. We'll also walk though implementations of many technologies we'll discuss in our overview articles. We'll begin the series by looking at two underlying architectures: 3-tier and n-tier.

The CMS 3-tier architecture
I’d like to take credit for developing the CMS 3-tier architecture but, unfortunately, it has been around for quite a while. Basically, a CMS 3-tier architecture mirrors the standard 3-tier client/server architecture. There's nothing difficult about a CMS 3-tier architecture; it's just common sense. Each tier corresponds directly to one of the three elements needed in an architecture: interaction, manipulation, and storage. The three tiers are:

• Presentation tier--handles external interaction with the user.
  
• Business logic tier--manipulates the information required by the user.
  
• Database tier--stores all the data handled by the system.

Visually, the CMS 3-tier architecture is just as simple, as you can see in Figure A. Our diagram shows the tiers broken onto separate machines. Multiple tiers can reside on a single computer, but by distributing tiers on multiple machines, you can better distribute the CMS's workload.

Figure A: The CMS 3-tier architecture

The CMS n-tier architecture
A simple explanation of CMS n-tier architecture is that it is just a CMS 3-tier architecture with the tiers split up into more tiers, as you can see in Figure B. Breaking up the tiers enables improved fine-tuning of performance and distribution of the system onto more computers. This will make more computer horsepower available, causing fewer bottlenecks due to the computation time of any given computer.

Figure B: The CMS n-tier architecture

What is the presentation tier?
Though not really any more important than the other tiers, the presentation tier gets all the glory, since it's the only tier seen by the CMS user. This tier is responsible for all user interaction with the CMS.

The presentation tier is actually made up of two parts: the Web client and the Web Server. The Web client sits on the user’s computer and usually takes the form of a Web browser. The Web server resides at the Web host site. Its purpose is to generate all the dynamic Web pages and forms that make up the CMS.

Communication between the Web client and Web server is handled using request/response pairs. The Web client creates requests to the Web server, which then figures out what the request is and replies with a response.

Web client requests are made using the HTTP request. For example:

GET /index.html HTTP/1.0
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows NT)
Host: www.contentmgr.com
Web servers respond using the HTTP response. For example:
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Thu, 12 Jul 2002 19:19:52 GMT
Connection: Keep-Alive
Content-Length: 1270
Content-Type: text/html
Set-Cookie: ASPSESSIONIDQQQGQGDC=MOFPDBPCPNIBACIBDCIOFCCL; path=/
Cache-control: private

<HTML>
<BODY>
...
</BODY>
</HTML>

HTML imbedded within the response tells the browser what to visually display in the browser; JavaScript handles rudimentary client functionality. Recently, other technologies like Java applets and ActiveX components have become the norm. However, HTML is still present on most initial responses, even if used only as a means of letting the Web client know that a different technology is going to take over the execution.

What is the business logic tier?
Again, the functionality of the business logic tier can be placed on a single server (making the architecture 3-tier) or distributed across many servers (making it n-tier). The business logic functionality of this tier is broken into three parts:

• Get and send data to the database tier.
  
• Get and receive data from the presentation tier.
  
• Perform necessary calculations and/or data manipulations.

The business logic tier gets data from the database tier and manipulates it according to the needs of the presentation tier. The business logic tier also takes data provided by the presentation tier and manipulates it to the needs of the database tier.

Much of the logic associated with many CMS business logic tiers relates to interfacing with the other two tiers. With Microsoft .NET, much of the complexity of doing this has been reduced due to ADO.NET, .NET remoting, and Web services. With .NET, the most complex logic performed by this tier is now the calculation and manipulation of data (in C# or Managed C++) to handle business logic.

What is the database tier?
The tier’s name kind of gives away what it does; it handles the CMS's data. What isn’t obvious is that the storage and retrieval of data is not restricted to a database. It could be a flat file or a set of flat files, maybe in XML format. However, data is usually stored in a database. The type of database is usually immaterial, because Microsoft SQL Server 2000 works just as well as Oracle or Sybase for most CMSs (if you are working in a Windows environment, anyway). That being said, Microsoft has optimized the .NET interface to its Microsoft SQL Server 2000 database, possibly giving it a slight edge. But as managed providers for the other databases are developed, this edge will quickly disappear.

If you don’t have any preference about which database to use, you may want to code in a generic fashion that allows any database to plug into your CMS. Who knows what the future may bring? The database you choose now may not be what you want to use next year.

The database tier is usually loaded and accessed from its own computer and, in larger CMSs, a mirror copy often is maintained on another computer in case problems occur with the master copy.

The internal workings of this tier, and the database itself, are usually a mystery to the average programmer. The most that developers have to do with this tier is set up the database, create and load the database schemas, occasionally generate reports, and regularly back up the database.

Which architecture?
Which architecture you choose (3-tier or n-tier) depends on a number of factors, including:

• Desired functionality within the CMS
  
• Amount of data
  
• Number of concurrent users
  
• Expected growth
  

Basically, if the CMS is going to remain small, a 3-tier architecture will usually be fine. If, on the other hand, you suspect the CMS will become large, an n-tier architecture is advisable.

The 3-tier is easier to build because it requires less interserver communications. But with .NET, this is not a compelling issue. Since 3-tier architectures are easier to build, they should be able to be released sooner. So, if time to market is a big issue, 3-tier as a temporary solution might be the way to go even for a large CMS; it's possible to code a 3-tier solution in such a way that migration to n-tier is nearly painless. However, be aware that a large 3-tier CMS with a lot of users may suffer outages.

Wrap up
You should now have a basic understanding of the two architectures predominately used for CMSs. You should also be able to make an educated guess on which architecture is right for you.