.NET Framework 4 together with Visual Studio 2010 are major milestones in the lifecycle of Microsoft’s complex application platform. Unlike the Java world which is currently experiencing fragmentation (Oracle’s Java EE 6, Spring, others) the .NET world seems to be holding together. Version 4, backed by a strong Visual Studio with a brand new shell written entirely in WPF, looks very solid and appealing from both the architectural and the development perspectives. Well … is it?

It seems to me one can find in almost any situation that leads to software development conflicting perceptions between developers and decision makers. When I say decision makers I’m thinking about those who have to accept and ultimately assume the technical decisions taken during the ALM (Application Lifecycle Management) process. While the former become rather easily enthusiastic about any new technology as well as about as more control as possible, the latter are much more inclined towards stability and, much more important, clear and measurable technology roadmaps. This is why I think that the fragmentation we see today in the Java world is not necessarily a good thing. .NET needs a strong Java as much as Java needs a strong .NET. History says loud and clear that the only way forward is strong and fierce competition.

The interesting question here is whether having a single driver behind guarantees or not reduced complexity in addition to platform stability. Seems to me the answer is closer to no than to yes. Despite being pushed by a single vendor, .NET exhibits many (if not all) of the unknowns that exist in fragmented worlds. Probably the most common unknown is “what’s the right technology to choose here since I have several alternatives?”. It’s true, most technologies that are present in .NET have a pretty clear area of coverage. The problem is that sometimes these areas overlap and it’s not always clear what the right choice should be. Just think about desktop user experience for a moment. Should I bet on Windows Forms, Windows Presentation Foundation, or even Silverlight? Or take the web: ASP.NET Web Forms, ASP.NET MVC, ASP.NET with AJAX, or Silverlight? Sometimes, it’s obvious. But sometimes it is not, and this is why I feel there’s an ever increasing need for guidance here. With .NET Framework 4 especially, the game is not only about learning how every single technology works. It’s also about tradeoffs, compromises, and especially implications resulting from choosing one option over the other.

With newcomers like LINQ, Parallel LINQ, cloud computing, dynamic languages, functional programming, and modeling (to name just a few) we’re now very far from what .NET used to be in its early years. We’re at the dawn of an era where the complexity of the platform becomes a fact of life. Most problems we have to solve have at least two or three different solutions, with conflicting consequences. It’s a world where knowing a programming language and a few basic technologies is not the recipe for success anymore.

To make myself very clear I have to say that .NET’s complexity is not due to any kind of architectural, design, or execution flaw. Au contraire, I think Microsoft .NET Framework (especially version 4) is a fantastic feat of engineering, a living example on how to design and implement complex functionality. The complexity of .NET comes from the fact that it spans an amazing array of technologies, environments, and approaches to build software. For us architects and developers it means that knowing to write .NET code is just not enough anymore. It means we need to dedicate serious time to understand every single option .NET has to offer, to learn the tradeoffs, and to know where the compromise lies in every choice we make. It means to accept a simple fact of life: the power and versatility of .NET comes at the price of increased complexity, and we need to deal with it.

I have to admit I was a little bit worried about the overall performance of the new Visual Studio 2010 shell based on the Windows Presentation Foundation technology. I had some mixed feelings while using the preliminary releases like Beta 1 and Beta 2. Don’t get me wrong, I am a big fan of the new VS simply because WPF opens a whole new range of possibilities for it. My concerns were focused around its performance on mid-sized machines. I am perfectly aware of the fact that not all developers are going to code using VS 2010 on quad/octo-core hardware with 16/32 gigs of RAM. This is why I am using my Acer Aspire 1420P notebook as a benchmark to measure the quality of the development experience with VS 2010 (to make things clear, the machine has 4 gigs of RAM and a dual-core Intel Celeron CPU running at 1.2 GHz).

After one and a half day of use in heavy coding I have to say I am impressed and many of my original performance concerns are now things of the past. True, I haven’t had yet the chance to try all the different designers and project templates, but I can say there is a significant improvement in performance when compared to Beta 2. Jason Zander does an excellent reviewon Channel 9 related to the significant changes made in VS 2010 RC.

It certainly looks like VS 2010 together with .NET Framework 4 are on the right track to rock the world of developers once they hit RTM.

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.