Over the last few years the Web has been going through another round of changes. Not only has the consumer Web sprung up with the Web 2.0 phenomenon, driven by new technologies such as AJAX and the philosophy of participation, but enterprise Web initiatives have also morphed. The information that businesses are publishing online is no longer limited to marketing collateral. Brochure-ware sites are quickly changing from static to dynamic and internal applications are being incorporated into corporate sites. As the Web touches every department from product development to finance, it has become an essential part of doing business for any organization.

On the technology side, this means that new tools are needed to manage the internal information and efficiently deliver it to the presentation layer, viewed both on the desktop and via wireless devices. Webmasters are presented with a variety of Web content management solutions that help separate content from presentation, allow non-technical personnel to engage in site updates, and provide a mechanism for online template creation. However, many developers choose to build their own systems, finding off-the-shelf products inflexible or unusable by non-technical personnel. This approach is commonly taken to retain maximum control and flexibility. However, it's not only time consuming but can be very expensive in the long run.

While Microsoft's .NET Framework offers a number of advantages for building Web applications, including systems for managing content, developers face a set of challenges not specifically addressed by Microsoft Visual Studio or its Internet Information Services (IIS), which is generally used for the ultimate delivery of .NET applications. These challenges primarily deal with (i) solution architecture; (ii) code management; and (iii) application performance.

These challenges aren't addressed by traditional content management solutions and require a new type of a framework. Developers faced with either internal build-outs or challenges in integrating multiple internal content management solutions aren't expected to create their own IDE as a viable first step in creating a Web application. By the same token, they should look into adopting off-the-shelf content application servers with a strong focus on content delivery to address the challenges outlined above.

Architecture
As more users, departments, and applications come online, corporate Web solutions become increasingly complex. In many situations, IT personnel find themselves constrained by the existing software and seek alternate or additional solutions. Other teams choose the "build" route and need to re-architect and then redevelop the existing code base. The process generally involves incorporating new and existing applications in a common framework that's capable of publishing as well as receiving information.

As an example, suppose the HR department creates a policy that should appear on the intranet and extranet, in the document repository, and be distributed in shortened form to the sales and product development groups.

Access to this document should be limited to a select set of users. Of course, the data shouldn't be re-entered multiple times for each department and there has to be a simple process of specifying where and how the data should appear.

Planning, implementing, and testing this application alone in a multi-user, multi-department, multi-role environment can be a process that spans weeks, if not months.

Architecting the database and then the SQL calls is part of the overall process that can be addressed by a content application server. A solution that provides out-of-the-box solution architecture support can help address:

• Data layer pre-generation and data exposure
• System flexibility as business requirements change and expand
• Handling various types of data sources and databases
• Logic flaw and bug management
• Permissions and access controls

Code Management
The .NET framework offers a good templating platform, but providing a code management solution isn't one of its core features. This creates a problem for developers who want to maximize their productivity through complete code reuse. So a content application server must provide a solid templating engine that emphasizes the separation of interface and logic components, component override, inheritances, etc.

The solution should also take advantage of, and be able to rely on, off-the-shelf components already available for the .NET platform. In fact, a good content application server should show little differentiation between the way it manages its native components and third-party applications. Incorporating such applications into the interface logic construction statements and treating them on a par with internal interface components will further foster reuse and ultimately lower the cost of developing and deploying Web solutions.

Speed and Performance
There's a saying in the media world that, "if content is king, distribution is King Kong." The same applies to the content management space. While content creation and data entry may be handled through the user's solution of choice, whether native to the content management platform or not, efficient content publishing should be managed through a single solution. As mentioned above, this is virtually a prerequisite for eliminating code duplication, but it's also necessary to ensure that publishing speed and overall solution performance are at optimal levels.

In this respect the role of the content application server would be that of a delivery platform and will require the solution to provide performance optimization and caching capabilities on several levels. First of all, caching on the data layer is a must to optimize database access and ensure that the solution itself doesn't become a bottleneck in the publishing process. In addition, caching on the object or the logic layer, which is provided by the .NET Framework, must be used in pre-compiling page code. The solution should also integrate well with IIS to enable and facilitate HTML caching on the Web server itself.

In Lieu of a Conclusion
Even with the newest additions like WinFx in Avalon, Indigo, Workflow Foundation Server, and others, it's still cumbersome to build systems using disparate .NET applications, so higher-level products that build on these technologies and add a set of interconnected engines (e.g., for templating, logic management, scheduling, and delivery) are absolutely essential.

So the question is not really whether a content delivery platform or a content application server are needed in the development process, but whether it's a good idea to build one internally or to buy a commercial product.

If your company is a software developer, in the industry classification sense of the world, perhaps the "build" approach is the answer. However, most companies aren't and internal build-outs usually result in highly custom and often tightly coupled systems, which become extremely time-consuming to expand as business requirements change or grow.

For those teams, there are market-tested commercial solutions available off-the-shelf.