by ciprian.jichici@genisoft.eu
2. February 2010 11:53
Most complex applications will rely on certain types of functionalities that are not tied to a certain layer or tier. Since they affect entire applications it is highly desirable to place these functionalities in a centralized location in code in order to avoid unnecessary duplication. The certain advantage you gain with this approach has its own Achilles' heel: you’ve just created the perfect location for high-impact design mistakes. Because of these interesting characteristics these functionalities are commonly referred among software architects as crosscutting concerns. Some of the most common crosscutting concerns are:
- Authentication and authorization
- Caching
- Communication
- Configuration management
- Exception Management
- Logging and instrumentation
- State management
- Validation
The 2nd edition of the Microsoft Application Architecture Guide has an excellent discussion about crosscutting concerns.
Since they are so common among software applications, it’s no surprise that every single application deals with (hopefully all of) them in its own way. Fortunately, most application platforms offer support to architects and developers in order to address the crosscutting concerns. The .NET Framework 4 in particular and the Microsoft Application Platform in general are no exception. But there’s a catch here: at the core level there is no integrated approach. Take .NET configuration files for services for instance. There are tons of things that you can do with configuration files in the development environment but there’s not much out-of-the-box functionality to handle them once they are deployed.
From the point of view of software architecture, one of the very interesting developments in Windows Server is the Application Server role. Indeed, Windows Server has come a very long way from being a platform providing fundamental APIs to being a true application server. At the heart of this journey there are two fundamental parts: the Microsoft .NET Framework and the Internet Information Services. Today, .NET Framework 4 provides all the necessary building blocks for the development of robust and scalable distributed solutions. IIS on the other hand evolved from a HTTP-based web server to a multi-purpose, multi-protocol, secure and robust hosting environment for application services. Add WAS (Windows Process Activation Service) to the mix and what you get is a pretty strong and scalable application server.
Building on top of the existing functions in .NET Framework 4 and the WAS/IIS environment, Windows Server AppFabric brings the Application Server to the next level. And by next level I mean that in addition to existing fundamental APIs and hosting environment the AppFabric brings out-of-the-box, robust, and scalable solutions for the following crosscutting concerns:
- Caching
- Communication
- Configuration management
- Logging and instrumentation
- State management
These concerns are addressed via the following categories of functionalities:
- Better deployment, management, and configuration for WCF and WF services hosted in WAS
- Persistence management for workflows
- Tracking profiles (together with dedicated, queryable storage)
- Monitoring of hosted services
- PowerShell integration (custom management scripts)
- Caching of any serializable CLR object and caching APIs at enterprise scale
- Caching available as a service
- High availability and automatic load balancing
It is very important to understand that Windows Server AppFabric will not provide comprehensive solutions to the concerns mentioned above. Nevertheless, it is an excellent and powerful piece of the puzzle that software architects can take into consideration when designing software solutions.
For more details about Windows Server AppFabric you can check the dedicated section from the Windows Server Developer Center.