Optional and Named Parameters: http://www.infoq.com/news/2008/10/CSharp-Optional
Dynamically Typed Objects and Duck Typing: http://www.infoq.com/news/2008/10/CSharp-Dynamic

Thank you, Anders.

Okay, the Keynotes are over and everyone is flashed... What have we seen in the last 24 hours?

Windows Azure & Azure Services - Microsoft's Cloud Operating Platform with several enhancements for .NET developers like .NET Services, Live Services and SQL Services.

Oslo - The next generation modeling platform for service-oriented applications.

Windows 7 - How Windows Vista should have been: Fast, reliable and with new productivity features.

Microsoft Office Web Applications - Microsoft has finally brought his Office suite to the web and added a couple of synchronization and integration features.

Windows Live ID with OpenID support - Finally you can use your Windows Live ID to login to OpenID sites.

.NET Framework 4.0 and ASP.NET 4.0 - A couple of cool new features, especially around the MVC Framework and Silverlight, but also extend VS2010 functionality and new programming language features.

These are in my opinion the really huge things from PDC and there are a lot of more. I just registered for the Azure and the Live Services SDK and I will try it out today.

Microsoft's cloud operating system running the infrastructure of Live Mesh will most likely be named Windows Azure in the future. Check our the following Channel 9 videos:

Introducing Windows Azure
Windows Azure for Developers

Enjoy.

(Version 1.2 - October 28th, 2008)

I'm following Microsoft's Cloud Computing project, Windows Azure and Azure Services, and especially a particular part of it, the Live Services Platform and the Mesh Services components, for about six months now and the more I see, the more excited I am. But let's start at the beginning:

So, what is "Windows Azure"? Well, it is basically Microsoft's response to Amazon's EC2 and Google's AppEngine, but it seems to go a bit further. Windows Azure (formerly known as project "Red Dog") is a cloud computing platform and a corner stone of Microsoft's S+S (Software + Service) initiative. It is hosted on top of a pretty large server network, which offers basic system services (processing, storage, networking, etc.). On top of Windows Azure, Microsoft has built a collection of application services, called the Azure Services Platform. Azure Services is composed out of several hosting features and interfaces to SaaS applications developed by Microsoft, including, but not limited to, .NET Services, SQL Services, Live Services and some others.

Read more about the Azure Platform and how all the pieces fit together in this article from Mary-Jo Foley. Microsoft has also launched a new portal at microsoft.com/azure.

One of the application services collections, Microsoft is building into the Azure Services Platform, are Live Services. Live Services is the name for a couple of features for integrating various live.com offerings into your own applications. A core piece for building and "Live-enabling" your own applications is the Mesh Services Platform (formerly known as "Live Mesh"). The Mesh Services Platform is more or less an integration platform in the cloud, used to manage and synchronize information and devices.

To access Mesh Services, a developer can use a unified data and communication API based on feeds. Microsoft makes it easy for developers to do that by providing several SDKs, one of which is the Live Framework for .NET developers.

Everything you store inside Mesh Services within the Cloud is not only available all over the internet but also constantly synced to your local device. This allows developers to use the Live Framework without worrying about where the application is running or whether there is an Internet connection or not. The API itself is responsible for choosing the best option.

The basic entity in the Mesh is a MeshObject. It can be represented as Feed (or more accurate: as Feed of Feeds), as JSON, as POX, as RSS or as one of several other standard data formats.

If you're a Sitecore developer, you might find some familiarities here... Looking at Sitecore, the basic information entity is an Sitecore Item. It can also be represented in various formats, most obviously in XML and as .NET object.

The system is also creating a map of all your devices and applications, that are currently connected to "your" Mesh. Beside your usual desktop or notebook PC, this could be a mobile phone, a MediaCenter or even a Mac.

Something that has currently not been revealed is a server-side "device" provided by the Mesh network itself. Although I saw it on several C9 videos, I could not find any additional information in on of the Keynotes. Microsoft is very secretive about the whole project, but maybe this is the real "Windows Cloud" a lot of Microsoft folks were talking about lately. I'm just going to call it "Live Desktop" for now, because to me it looks like a browser based Desktop environment, rendered using Web 2.0 technology and using the Live Mesh as data storage and synchronization platform.

Sounds familiar? I hope so... The Sitecore Desktop is a pretty good example for a great web desktop and a whole eco system for applications and services. I'm not suggesting here, that Microsoft is building something Sitecore already offers, but the concepts in both products are at least similar and so is the underlying philosophy.

I will definitely deep dive into the Mesh and Windows Azure when more information become available after PDC and I will talk to Sitecore about possible ways to integrate these concepts and features. There is indeed a huge potential in these technologies, especially as it brings your web applications to your desktop by providing a synchronized location-transparent storage - on your local device as well as in the cloud.

If Windows Azure and the Live Services Platform can live up to my expectations, it might become the number one cloud computing environment, something like a combination of Amazon EC2, AdobeAir, Sync Framework, Google Gears and several other great products.

By the way, the first two Mesh-enabled application Microsoft is currently working on are a file sync application and a remote desktop application. The file sync application will most likely synchronize your files between all your devices and even with the Live Desktop - sounds like the combination of Windows Live FolderShare (which Microsoft acquired a couple of months ago, but hasn't really started to advertise or improve yet) and Windows Live Folders.

If you haven't seen it by now, I strongly suggest you take a look at this video about Mesh applications with Ori from April 2008.

Based on our updated strategy, we are are currently focusing our efforts on .NET as future enterprise platform at netzkern.systems. I for myself will remain a "jumper", switching between .NET, Java EE and the Ruby on Rails space, as I like to work with all three platforms and to get the best of all worlds, but our business unit has made a decision and we will stick to it.

One particular "problem" that we need to solve now, is to choose a new primary ESB solution for our service portfolio, namely for "Service-oriented Business Process Management (SOA/BPM)" and "Enterprise Application and Business Component Integration (EAI/BI)". Currently, there is a large number of great Java EE products out there that would provide a lot of the features we need: Apache ServiceMix, Mule, OpenESB, Apache Synapse, and JBoss ESB, as well as several commercial products like BEA AquaLogic, SAP XI, Sonic ESB, TIBCO, Oracle ESB and some others. Unfortunately there are much fewer options in the .NET space right now. Of course there is BizTalk, but besides the fact that is is really huge, pricey and somewhat clumsy, it is also based heavily on C++ and COM, making it necessary to program against several Interop assemblies. We also took a look at ESB.NET, but for the time being, it does not seem to be the right choice.
Microsoft is going to release beta version of a couple of important components at the PDC2008, one of which is "Dublin", a service container for WCF and WF. Sounds promising, but it is neither a full-features ESB solution in .NET basis, nor is it available in the near future. It might serve as framework and building block for a couple of future SOA products from Microsoft, but I'm not sure whether it is suitable for us or not.

At the moment we are discussing about building our own solution based on WCF and Spring.NET and creating essentially a lightweight SOA-based ESB solution with an extensible workflow engine interface, suitable for using either our Spring.NET-based approach (which we may publish separately) but also a WF-based engine in the future.

I will keep you posted about our project.

(Version 1.1.1 - October 19th, 2008)

In this series, I'm going to compare the functionality of SharePoint and Sitecore from a developer perspective in each area and both candidates can collect "points" from 0 (has nothing to contribute) to 10 (great integration and functionality).

This series will cover the following areas:
- Introduction (Part 1)
- Installation and General Architecture (Part 2)
- Configuration (Part 3)
- Customization and Designer Experience (Part 4)
- Integration with Developer Tools (Part 5)
- Feature Deployment (Part 6)
- API und Data Model (Part 7)
- Integration with other systems (Part 8)
- Conclusion (Part 9)

Customization and Designer Experience

The term "customization" is used in SharePoint to describe the work of creating solutions without actually writing code or using the API. The work can either be done using features of the SharePoint Browser Interface or the Microsoft Office SharePoint Designer application. The result of this work is stored inside the content database of a SharePoint site collection, it is not deployed in form of compiled DLLs and additional resources.
In Sitecore, a similar kind of work is performed by a Sitecore XML Developer (sometimes referred to as Sitecore HTML Developer or SCD1, in contrast to the Sitecore API Developer, sometimes also called Sitecore .NET Developer or SCD2). Sitecore XML Developers create conceptual artifacts (Layouts, Templates, Renderings, Items) using the Sitecore Client (a superior Desktop-like web-based UI) and external XML Development Tools of their choice (e.g. Notepad, UltraEdit, Dreamweaver, Altova, VisualStudio, Expression Web, etc.).
This article refers to this content-centric development process in both products as "customization" - real "development" using the API by writing code is covered in a later part of this series.

SharePoint provides a lot of customization functionality out of the box. As stated earlier, both WSS 3.0 and MOSS 2007 come with a couple of ready-to-run features for endusers. Most of these features are based on Lists, one of the main building blocks of SharePoint. Nearly everything related to content in SharePoint comes in form of some kind of lists or as an extended version of this concept, be it calendars, document libraries, task lists or even webpages. Users can create lists with the SharePoint Browser Interface, define fields, attach basic workflows, versioning and use other options. Developers can go a bit further and create so called "site columns" and "content types" which are basically global definitions of fields and (partial) list types. To display contents of lists, there are several options. I will not cover all of them here but I'm going to mention some of the most common approaches.
But before I do that, there is another functionality I want to mention briefly. It's called the Web Part Framework and should sound familiar to every ASP.NET 2.0 developer. In fact, Web Parts are essentially the same in SharePoint as they are in ASP.NET (actually, the Web Parts concept has been introduced with SharePoint 2.0 and was adopted by ASP.NET 2.0). The main difference is that Web Parts in SharePoint are placed in Web Part Zones on Site Pages, which are located in the SharePoint content database, not in the file system. To learn more about Web Parts click here.
The first and simplest option to store and display structured data in SharePoint is to create a list, add some content and create additional views using the SharePoint Browser Interface. Views can be created using pre-defined templates and by specifying filters and other options. They can afterwards be placed on customized Site Pages and page layouts using the Web Parts Framework. SharePoint provides a couple of customizable Web Parts to display data from lists. These include the Content Query Web Part, the Data View Web Part and the XML Web Part.
A second and more advanced option is to use the customization settings the Content Query Web Part. In this approach developers use the existing XSLT capabilities of the CQWP to render the content of a list based on a XSLT Stylesheet. This can be done by creating customized XSLT Stylesheet and upload it to the Style library of a SharePoint site, which in turn makes it available for the CQWP settings dialog.
In addition to this structured approach (data is stored separately in lists, presentation is configured using web parts), the Web Part Framework does provide some Web Parts creating unstructured, discrete content, for example to place a styled HTML text and an images on a web page. From my perspective as Software and Information Architect, I have to strongly advice everyone against adopting this approach. It does not only intermixes content and presentation, but it also creates volatile content which in turn will lead to an unmanageable mud of information islands, detached from the overall information architecture.
Unfortunately, these content Web Parts are not the only way to create "sloppy" pages in SharePoint. Using SharePoint Designer, you can also create simple Content Pages (at least they are based on existing Master Pages, which define the overall layout of several pages in a Site) that can contain Text, Images and other HTML elements. Sounds familiar? Of course, it's only "unmanaged" HTML, hopefully at least based on central styles and encapsulated by a MasterPage. This approach violates the same principle as the way mentioned before and I strongly discourage everyone from using it.
A much better way is the possibility to use the Web Content Management capabilities of SharePoint by using the Publishing Site functionality of MOSS 2007. To utilize its features, a developer has to create site columns and content types, which define a basic content structure for information that are going to be processed within a SharePoint Site. Having done that, he can create list items based on those content types and display them using SharePoint Page Layouts. Page Layouts are basically ASPX pages with controls. "Pages" (which are essentially list items based on Content Types in this case) use them to display their field values by "filling" the controls in those Page Layouts. SharePoint automatically combines them with one of a few pre-defined MasterPages, managed as part of the Publishing Site to ensure a common look and feel across pages.
This is by far the most structured approach to create web pages in SharePoint, but unfortunately there a couple of drawbacks.
Every list in SharePoint can also be accessed using RSS and other defined protocols, for example using Microsoft Access or web services.

SharePoint comes with a couple of out-of-the-box Features. Most of the configuration necessary to use those Features is performed automatically when a user creates a new Site based on an appropriate Site Definition (not to confuse with a Site Template... *urks*). The Site Definition activates certain Features right after it has been provisioned in the SharePoint Content Database. These Features do not only create additional functionality, they also change the behavior of the whole SharePoint Site, add pre-defined content and structures, extend menus and perform several other tasks.
This behavior is essentially a good idea, except for the fact that in some cases, there are no "clean" Site Definitions available for certain kinds of Sites. That means, you often get a couple of sample content, pre-defined lists and a couple of unnecessary customizations with every Site.
Unfortunately, one bad example for this situation is the "Publishing Portal" Site Definition (often just referred to as "Publishing Site"). It automatically activates all WCM (Web Content Management) Features in a SharePoint Site, but it also creates a couple of useless and even annoying things inside your newly created project workspace. Well, there are two options how to deal with that. The first option is to delete all that stuff by hand, hoping that you do not destroy any of the necessary functionality of a Publishing Portal (e.g. the TasksList and the WorkflowHistoryList which are necessary for certain automatic workflows activated by Publishing Site). The other option is to create a minimal Publishing Site Definition yourself - and it's not exactly a pretty easy task.
This problem is so common that some SharePoint authors devote complete chapters to the creation of Site Definitions, just to have a "clean" starting point for their sample projects (e.g. "Professional SharePoint 2007 Web Content Management Developement" by Andrew Connell, Chapter 5: "Minimal Publishing Site Definition", WROX Press, 2008).
Another main drawback in customizing SharePoint is the integration with existing SCCM infrastructure and release management procedures - basically because it is not possible. Using either the SharePoint Browser Interface or the SharePoint Designer application, changes are generally performed directly in the SharePoint content database, which makes it difficult (if not impossible) to use it with source code management tools and in staged testing environments. Of course it is possible to create deployable SharePoint Features as part of "Solution Packages" (more about that later) which can contain all those things (lists, list templates, site columns, content types, page layouts, XSLT Stylesheets, etc.) in VisualStudio, but this is really a pretty heavy development task just to create some structured content that can be managed using Subversion or TFS. Nevertheless, that approach makes it possible to use source code management tools, although it is much more complicated and it lacks the nice usability that is provided by the SharePoint Browser Interface and the SharePoint Designer.

Advantages

1. SharePoint delivers a lot of relatively easy-to-use out-of-the-box features. Some of them can be customized using the SharePoint Browser Interface, others using the SharePoint Designer.
2. Using pre-defined Site Definitions, SharePoint users can easily create new SharePoint Sites based on a list of pre-defined Features and containing several customization.
3. Structured pages in SharePoint can be customized using either the Web Part Framework or by defining Page Layouts, Content Types and creating Site Pages based on list items.
4. Some Web Parts provide additional styling and customization options using XSLT and settings.
5. Developers can use most of their knowledge about MasterPages and WebForms to create a common look and feel, although they need to be aware of certain limitations.

Drawbacks

1. From a developers perspective, customizing SharePoint is not a consistent experience. There are several levels of customization with certain limitations, as well as different approaches and tools.
2. Using a combination of the SharePoint Browser Interface, SharePoint Designer and some external tools, customizing SharePoint basically means re-arranging pre-packed snippets of functionality. Sometimes this pre-defined features are even getting in the way of the developer, for example if he wants to start with a fresh and clean project.
3. The development task itself is a mix of using features of a web-based browser interface with some editing controls (SharePoint Browser Interface), a desktop application (SharePoint Designer), writing some XSLT (maybe using Expression Web), defining some CSS classes and creating HTML pages with placeholders. There is little guidance about where to start and no continuous workflow for creating content structures and presentation elements.
4. SharePoint has some features that support the creation of unstructured content, without separation of content and presentation, bypassing the overall information architecture and decreasing manageability and maintainability. Unfortunately by not disabling these features (which is not that easy), users tend to use them a lot, primarily because they are easier to find and to understand than most structured approaches in SharePoint.
5. From the perspective of this article (which is focusing on "customization" and not on "development"), SharePoint is limited to create page-driven content, which means that most data can not easily be re-used in the same Site or across Sites. This often leads to inconsistencies caused by duplicate information. The introduction of Site Columns and Content Types is an important step forward from SharePoint 2.0 and demonstrates Microsoft's efforts to integrate functionality of MCMS 2002 into MOSS 2007. But the fact that site pages can only (or at least without additional development effort) be created based on the fields of a single list item is still a huge drawback. Although lists can have relationships to other lists, using those relationship during customization (again, we're not talking about development here) is not trivial.
6. SharePoint Designer and the SharePoint Browser Interface perform their changes always directly in the SharePoint Content Database. Besides some other drawbacks there is currently no support for SCCM tools. At the moment it is also not possible to use SharePoint Designer with files in the file system without creating some strange side effects that can even kill your complete SharePoint installation (hint: you should never open and save an application-level MasterPage in the "12hive" with SharePoint Designer).

In contrast to SharePoint, Sitecore does not aim to provide a handful of pre-defined "content snippets" and a relatively fixed site design for immediate user activities right after the installation has finished. From an architectural point of view, there are several good reasons for that.
First of all, building an information architecture and a decent taxonomy is not anything you should do lightheaded. Even if you have a pretty small site, you should definitely give some thought to what you want to present to your users and how do you want to do that - at least, if you want to create something, that is built to last.
Secondly, how can anyone else know how your users and customers are going to work? Of course there are several "common features" on a website or in an intranet project, but the question is: Do you want pre-defined functionality, limited to a specific solution based on a pre-defined perspective of a common problem -or- do you want a flexible eco-system with everything you need to rapidly build everything you want?
Thirdly, I don't know any developer who really likes it to re-arrange stuff someone outside of his own team created. Human brains do not work the same way and to follow the line of thoughts of someone you don't even know is not only complicated, error-prone and inefficient - it is also not much fun.
What Sitecore gives you as a developer or as information architect is intentionally not a bunch of tools and features to create a bunch of inflexible web pages based on "pre-packed" pieces of code. Instead it provides you with a full-featured framework for building a web based structure of your information, your processes and your organizational reality, enriched by an API that makes it a fully-fledged web application framework.
Heaving said that, there are some folks out there that might say: But that's exactly what I want, I need some things right out of the box. Does that mean, Sitecore is not for you? Absolutely not... In fact, you CAN use existing functionality, modules, information structures and even content, built by experienced Sitecore partners and Sitecore itself. Go to SDN, download a predefined site package (packages are deployment units in Sitecore, like an MSI package for Windows) and install it into your fresh Sitecore system: Tadaa. If you want to, you can get a complete website with design, structure, additional functionality and sample content. And it's your choice to select which demo site, starter kit, intranet package or whatever else to use as basis for your site.
The question is: If you are more and more becoming and experienced Sitecore developer, to you really want to start your projects by deleting and re-structuring demo content? I wouldn't...
What you can do instead is to build your own "starter kits" and "toolboxes" right in your own Sitecore and use the package mechanism to move it to your next project. And that is really powerful. So powerful that we will talk about this in-depth in a later part of the series.

Sitecore's architecture is one of the best-designed software architectures in terms of Content Management Systems I've ever seen. The main concept of the architecture is an universal piece of structured information, named Item. This concept is simple, but very powerful. In fact, everything in Sitecore is based on Items - even Sitecore itself. Sitecore Items live inside a hierarchical structure named the Content Tree. In contrast to SharePoint where you can take a look at your Site Collection in a hierarchical view called the "SiteManager" (you can find it at different locations under the name "Site Content and Structure"), Sitecore's Content Tree is not only an aggregated view of database content, re-arranged to get a comprehensive view, it is really the way the whole system is structured. Browsing Sitecore's Content Tree using the Content Editor (Sitecore's "Windows Explorer") as administrator gives you the ability to see and access every piece of information within the application.
Sitecore's XML development features (which we call "customization" in this article series) are based on a so called "content-driven" approach to content management. "Content-driven" means, you are goind to structure your information first and then you decide, how and where to display it to your users.
To define the structure of the data used in your site, a developer defines a couple of blueprints for the data, similar, but more powerful then Site Columns and Content Types in SharePoint. To be honest, these blueprints have a very misleading name. In Sitecore terms they are called Templates. A Template is the definition of a certain type of structured data within Sitecore, like a class in OOP or a table definition in SQL. It contains definitions for various fields based on certain types, similar to properties in object-oriented languages like C# or columns in a SQL Server table. This concept has something in common with content types, lists and list items in SharePoint, although there are several differences. I will not go into detail here, but here are some important distinctions:

1. Sitecore Templates can be chained and they allow "multiple inheritance".
2. Sitecore Templates allow additional options per field.
3. Sitecore Items are hierarchically structured and can have complex relationships to other Items or complete structures of Items.

After you have designed the structure of your data and some content, the next thing to do is to present that content to your users. In Sitecore, this procedure is called "rendering". There are several options how to render content in Sitecore as it comes out-of-the-box with a bunch of technologies for that purpose. The one we are going to talk about is named "XSL Rendering" and it is by far the most common way. The rendering framework of Sitecore can be extend and at netzkern we are currently discussing a couple of ideas how to do that (e.g. providing support for Ruby on Rails-style templates, for XQuery, HAML and MVC Views).
I'm not going to explain exactly how to develop with XSLT in Sitecore, because that topic is covered in-depth in several tutorials on SDN and (of course) in every Sitecore training. What I'm going to do is to give you an impression of how customization works with XSLT in Sitecore (remember, it is not the only option for customization) and why it is so powerful.
In an earlier article I described the way Sitecore handles requests and we are going to extend the explanation here a bit further. After Sitecore has dispatched the request to ASP.NET, the .NET framework opens the requested ASPX and (if necessary) compiles it together with its code-behind file (actually, in Web Application Projects, there is also a second partial code-behind file that is merged with the ASPX markup file). The result is a HTTP Handler component, which receives and handles the request by executing a combination of framework code and custom code hooked into the processing pipeline using events (PageLoad, PreRender, OnClick, and so on).
This ASPX file usually defines the overall layout of a Sitecore page and of course you can use MasterPages and all other ASP.NET WebForms features. In Sitecore terms, this file is called a "Layout" and it is also managed by Sitecore. The Layout can contain a couple of Sitecore controls. Again, in contrast to SharePoint that handles controls on customized site pages a little different than pure ASP.NET, Sitecore controls are just powerful .NET components, completely in harmony with the ASP.NET WebForms framework.
Depending on the architecture of your site, you can choose whether a Sitecore Rendering is placed directly on the Layout or if you want to use the Sitecore Presentation framework to load it dynamically into a placeholder. I will not go further into detail here, but please don't hesitate to consult your local Sitecore partner, the forum at SDN or to drop me a line.
What I want to mention is a feature this article will refer to as "layout composition". In Sitecore, you can dynamically combine different Layouts, based on the page or type of pages being delivered. In Sitecore, you can create independent parts of Layouts, called Sublayouts. Sublayouts are basically ASCX controls, derived from a special base class. The rendering engine of Sitecore uses placeholders in to dynamically arrange Sublayouts, Renderings and Controls on a Sitecore Layout and merges them together, even with MasterPages. That way, you can dynamically assemble your pages which dramatically reduces the number of Layouts necessary and by that means the amount of work to create and maintain a consistent look and feel. For example, to build 5 slightly different designs, accessible not only using a Desktop browser but also a mobile device, you need to build 10 Page Layouts in SharePoint. You achieve the same result in Sitecore with two Layouts and two Sublayouts.
This feature alone increases your productivity significantly and it is one of the main reasons, why Sitecore was appointed "cool vendor of the year" by Gartner.
At some point, Sitecore calls your XSL Rendering with the structure of the Sitecore Content Tree as parameter. You can now use the whole power of XSLT and additional Sitecore Extension Functions to transform your content into HTML or - if you want to - into some other kind of XML or non-XML structure. XSLT is in its capacity as functional, transformational language a perfect fit for the Sitecore Content Tree, the Items Concept, the way humans think and (most importantly) nearly all information architectures and websites are structured.
If you have not worked with functional programming languages or transformation DSLs before, it might at first feel a little strange, but XSLT is known for a very steep learning-curve. If you are not comfortable working with XSLT at all (although you should at least try to), no problem! As I mentioned earlier, there are several other rendering technologies already available and more to come (especially using the ASP.NET MVC View template language is in my opinion a very promising candidate for the future).

As you can already see from the way this part of the article has been written, creating Sitecore-based sites and applications is pretty straightforward and your course of action is based on a defined process with additional guidelines. Pages in Sitecore are essentially the combination of layouts as dynamic containers for information coming from the Content Tree. Page Layouts and MasterPages provide a common look and feel as well as advanced functionality, if necessary (we will cover that in a later part of this series). But let's summarize what we have learned.

Advantages

1. Sitecore provides a simple, well-integrated and very powerful Software Architecture with a universal concept named Sitecore Items.
2. Developers can use the Sitecore Installer to install pre-defined Sitecore packages to use as starting points for your development -or- to create their own toolbox.
3. Sitecore provides strong separation of content and presentation. In fact, creating presentation artifacts is also separated into designer responsibilities (MasterPages and ASPX Pages) and developer tasks (Templates and Renderings), so each group can work usually work without influencing the other groups work.
4. The Sitecore Item concept is much more flexible and advanced than the SharePoint list concept. It is additionally easier to understand and to use, if explained properly (e.g. by reading the documentation or attending a SCD1 or a SHD training).
5. Developers are presented with a clear guidance on how to create Sitecore sites.
6. As Sitecore Renderings are living in the file system, a developer can select his tool of choice and orientate oneself by the nature of the task at hand. It also depends on the type of rendering being created.
7. Sitecore's Content Tree usually reflects your individual information architecture.
8. Sitecore is completely "content-driven" which makes it possible to re-use content across pages and sites without any additional effort.

Drawbacks

1. Sitecore does not provide the same amount of out-of-the-box functionality as SharePoint, therefor It is not a plug'n'play system. It is up to the developer to install a complete pre-designed site, partial site templates or additional features using the Sitecore Installer within the Sitecore Client web interface.
2. Sitecore is more developer-centric than SharePoint. You have to learn about the Items concept and you have to learn at least one rendering engine, preferably XSLT.
3. To provide all the table-centric features of SharePoint lists with all filters and options, a Sitecore developer has to create a certain amount of customizations, especially templates and renderings. This might be a good place for future improvement, especially for intranet scenarios (and yes, we're currently working on a concept).

This article covers a lot of features in both products and should provide a pretty complete overview of the customization a developer usually performs in both platforms. Unfortunately for Microsoft, SharePoint lacks the transparency and clarity of Sitecore and makes it difficult for developers to use all the pre-defined SharePoint features productively. Sitecore also surpasses SharePoint in terms of flexibility and it is better integrated with the ASP.NET framework. Because of that, working with Sitecore feels much more natural for a developer. SharePoint provides more out-of-the-box features, but developers often stumble upon the complexity of these pre-packed components. Sitecore, on the other hand, can be easily extended with additional functionality and even complete sites.

These facts lead to the following verdict from a developer perspective:

Sitecore: +8 points = 24 points total
SharePoint: +5 points = 17 points total

Read more about developer experience in part 5.

(Version 1.1 - October 11th, 2008)

In this series, I'm going to compare the functionality of SharePoint and Sitecore from a developer perspective in each area and both candidates can collect "points" from 0 (has nothing to contribute) to 10 (great integration and functionality).

This series will cover the following areas:
- Introduction (Part 1)
- Installation and General Architecture (Part 2)
- Configuration (Part 3)
- Customization and Designer Experience (Part 4)
- Integration with Developer Tools (Part 5)
- Feature Deployment (Part 6)
- API und Data Model (Part 7)
- Integration with other systems (Part 8)
- Conclusion (Part 9)

Configuration

SharePoint and Sitecore both are platforms built with extensibility in mind to allow organizations to create their own functionality and integrate them into the product. This article will cover one aspect of this process by giving an overview of the way a developer has to configure different settings during the setup of a new project within an existing SharePoint or Sitecore installation. Of course there are several other "configuration tasks" a developer has to perform within SharePoint and Sitecore to develop additional features, for example to configure individual lists (SP) or to change what Rich Text options to show in an Rich Text Editor (SC), but those topics will be covered in a later part of this series.

To configure SharePoint, you usually have to take a couple of steps in different locations all over your server to setup a new project. Usually your journey starts in a special SharePoint site called "Central Administration". It is installed by the SharePoint installer and provides you with a task-oriented web interface to perform several operations: Configuring farm options, creating and configuring new "web applications" and "site collections", changing server parameters and so on. The settings that can be changed by Central Administration are either settings in one of several config files on disc (some of them in the "12 hive", some others in local config file of the selected SharePoint site collection) or in different SharePoint databases (global settings are stored in the administration database, other settings are stored in the content database of the selected SharePoint site collection).
Central Administration is also the main entry point to jump to another configuration portal for configuring so called "Shared Services Providers" (SSPs). SSPs are special SharePoint applications providing features that can be shared across multiple SharePoint web applications and site collections, like global search, user profiles, audiences and so on. Although it is relatively comfortable to reach, it is not always clear whether to look for a particular setting in the Central Administration web or in the configuration web of a particular SSP. As that configuration web is really a separate SharePoint site at its own URL, we have to count it as separate interface (which makes two places to look for settings in total).
When the administrator creates a new web app and a new site collection within a SharePoint content database, and before he (or she) can connect it with an appropriate SSP, SharePoint creates a new IIS web and a folder in the file system. This folder contains the Web.config responsible for configuring a lot of "local" options for the site collection - it is that file which tells the ASP.NET ISAPI module of the IIS Worker Process what to do with a request to this web application. Although you can change some options of that Web.config file using the Central Administration web site, there are other options you may have to configure by hand in the Web.config file. For example, you can change the way authentication works for a particular SharePoint site collection in Central Administration, but really fine tuning it is a task you should perform manually in the Web.config file. Makes three so far.
Now that you have created your SharePoint site collection you can access it at its own URL. The first site in the site collection, called the "root site", has an extended settings page. You can use that settings page to configure various options for the site collection and the site itself. Four.
Every site that you create underneath the root site using one of several site templates has of course its own settings page. It has not as many settings as the root site, because it cannot change site collection options, but some settings you changed at the root site do not influence other sites in the site collection, so you have to change them in the settings section of the particular site. That's number five.
I already mentioned in the introduction that SharePoints functionality is packaged into deployment units named "features". Features are configured and deployed by the server administrator and can afterwards be activated for the whole farm, the server, the web application, the site collection or an individual site. To configure features and some other advanced options there is currently no web interface and no configuration file available. The only way to do this is using a command line utility named STSADM.EXE. This command line utility can in addition change a lot of advanced configuration options that cannot be changed using one of the web interfaces or configuration files, which makes it number six.

Okay, let's wrap up this summary. SharePoint is targeted towards mid-sized and large organizations. In those organization there are theoretically several levels of system administration and that is what the SharePoint team tried to consider when they created different kinds of configuration interfaces. From that point of view it makes sense to have settings for the local site in a configuration panel at the local site, so that the site collection administrator (in contrast to the server or even the farm administrator) can configure some settings for his own people. Unfortunately in reality this concept is a little edgy. First of all, in practice there are seldom "administration levels" - usually there is a group of administrators and developers responsible for operations and maintenance of a SharePoint farm (or even a single server) and they perform the majority of work in terms of configuration and customization (We know that from enterprise customers like Siemens and others). Secondly, the concept is not consistently implemented. There are still features that need to be activated manually in config files somewhere over the server or by using some "external" utilities. Thirdly, I have to ask the question: Why not make one single well-designed web interface for all configuration options and use the security subsystem to decide, what option to show to or hide from the current user?

Advantages

1. A lot of features and settings can be configured using web interfaces.
2. SharePoint has an "administration hierarchy" which allows server- or farm-wide administrators to configure other options than site collection or site administrators.
3. SharePoint Central Administration handles all server-wide (or "global") configuration options as well as some individual settings for every SharePoint web application or site collection.

Drawbacks

1. Different places for similar settings make it sometimes difficult to know where to search for a particular option. It is even more confusing for non-administrators who has been granted some permissions to change certain options.
2. Although most features can be configured using one of several web interfaces, it is sometimes necessary to change some configuration files manually or to use the command line utility STSADM.EXE.
3. The intended separation of administrative levels is seldom reality in most companies. Because of that, administrators have to switch between several web interfaces to complete one operations request.

If you are a .NET Web Developer or an administrator who is familiar with IIS 7.0 on Windows Server 2008, configuring Sitecore is pretty straightforward. After you have installed Sitecore, there is basically one file where you can configure each and every aspect of the system: The Web.config file in the root folder of your Sitecore web.
Sitecore's Web.config is a really big file with literally hundreds of settings in dozens of sections - but it is surprisingly easy to understand. There are several ways to learn about the Web.config: You can take part on one of several Sitecore Trainings (for example at Germany's Top Sitecore Training Center) or you just take a look at the Sitecore Developer Network (SDN), but you can even just open the file and take a look for yourself. There are of course a lot of things you may not fully understand at first, but these are usually the options you won't need in the beginning of your Sitecore journey.
As the Web.config has grown to some extend in the past, the developer team at Sitecore has started to move some settings from the main Web.config file to some smaller config files in the configuration directory named /App_Config (as intended by the ASP.NET 2.0 framework). The reason for this is basically to provide a better overview of all configuration options by grouping similar settings into separate files instead of one large file -and- to make it possible to switch between different configurations by just pointing to another file in the /App_Config folder.
Although Sitecore has only one single configuration file with some external extensions in the /App_Config folder, you can configure nearly every part of the system. It is even possible to extend, change, remove and replace core components, as well as to add your own. I will explain more about that in a later part of the series.
Well, that's basically all you need to know about configuration in Sitecore.

Advantages

1. Configuring Sitecore is a very familiar task for .NET Web Developers and Windows Server 2008 Administrators.
2. There is only one place to look for configuring settings in a Sitecore installation.
3. Each Sitecore installation can be individually configured.
4. It is possible to point to central configuration files from more than one Sitecore installation.
5. It is possible to manage the configuration with SCCM (source code management) tools, and to copy it in a whole or in parts as necessary.

Drawbacks

1. Configuring Sitecore is indeed a developer or administrator task because there is no configuration web interface.
2. To provide a hierarchy of "administration levels" where some administrators can change more settings than others, you have to write custom code that enables changing options from the Sitecore UI -or- you have to split the Web.config into several configuration files and use the security features of the Windows file system to provide different levels of access.

Again, this article demonstrates two very different approaches. SharePoint tries to play nicely with organizational hierarchies and to provide web-based user interfaces to simplify tasks that would otherwise be very complex, because the settings that are changed by various configuration pages are indeed distributed over half a dozen files and databases. Sitecore, on the other hand, is very well integrated with the way ASP.NET handles configuration and provides a familiar interface for developers and administrators in form of XML-based configuration files. It has, however, no web-based administration interface to handle certain those tasks. As this is a series that covers both products from a developer perspective (and not from an administrator or an endusers point of view), Sitecore's way seems to be more transparent and consistent.

Sitecore: +7 points = 16 points total
SharePoint: +6 points = 11 points total

For the next part of the series covering customization just click here.

(Version 1.1 - October 11th, 2008)

In this series, I'm going to compare the functionality of SharePoint and Sitecore from a developer perspective in each area and both candidates can collect "points" from 0 (has nothing to contribute) to 10 (great integration and functionality).

This series will cover the following areas:
- Introduction (Part 1)
- Installation and General Architecture (Part 2)
- Configuration (Part 3)
- Customization and Designer Experience (Part 4)
- Integration with Developer Tools (Part 5)
- Feature Deployment (Part 6)
- API und Data Model (Part 7)
- Integration with other systems (Part 8)
- Conclusion (Part 9)

Installation and General Architecture

Sitecore and SharePoint both come with a lot of out-of-the-box functionality but the main reason for choosing one of them as platform is extensibility of the core features. Both products are based on .NET, SQL Server and Windows Server / IIS. They both are basically also additional layer of functionality on top of ASP.NET 2.0, but this is already the first big difference in the overall architecture.

SharePoint is automatically installed by the SharePoint installation package (MSI) into the "Programs" folder of the system hard drive, some levels inside folders named "web server extensions" and so on. Because of the name of the last folder hierarchy level, developers usually refer to it as the "12 hive". All assemblies living somewhere in that directory tree are registered with the GAC (Global Assembly Cache), so every application in the system does not need to have a copy in their local /bin folder. When installing a first web application, SharePoint creates usually a new web inside IIS and places a few files in the related file folder on disc. It also registers several virtual directories linked to folders underneath the "12 hive". When the ASP.NET worker process (w3wp.exe using ASP.NET ISAPI) is starting up, it reads the contents of the Web.config in the configured IIS web folder. The Web.config refers to several assemblies available from the GAC which are loaded and initialized during startup (HTTP Modules, HTTP Handlers, some lifecycle components and so on). When a user requests a URL from SharePoint, a component named SPVirtualPathProvider is responsible for fulfilling the request as it has been registered as VirtualPathProvider. The component either ignores the request if it targets one of the virtual directories or "redirects" it to a HTTP handler that reads pages from the SharePoint content database.

Advantages

1. Multiple SharePoint sites are using the same assemblies and functionality. Simplifies updates and development of global features.
2. SharePoint pages are located in a central location on the file system or in the SharePoint content database. This enables an optimized handling of customized pages (SharePoint refers to pages that were changed by users and stored in the content database as "customized" pages) within a SharePoint farm where more than one web server is handling the request as the pages are instantly available to all webfarm servers by accessing the database. It also enables versioning and integration with other SharePoint features (workflows, etc.).

Drawbacks

1. Multiple SharePoint sites are using the same assemblies and functionality. Running different or more than one highly customized versions on the same server is nearly impossible.
2. Administrators cannot choose the location SharePoint is installed in. Complicates separation of responsibilities on the server with respect to security.
3. SharePoint pages are located in a central location on the file system or in the SharePoint content database. This may lead to some confusion if developing new features for SharePoint or customizing existing pages, because it is different from the usual way developers interact with the ASP.NET WebForms framework. It also complicates integration with VisualStudio, but we will cover that later in this series.
4. SharePoint heavily customizes the ASP.NET pipeline to integrate its database-centric concept. It also dynamically decides based on several parameters where to look for the requested resource (in the local IIS web folder, in the central SharePoint installation directory or in the content database), which is not trivial and at first not easy to understand.

Sitecore can be installed in two different ways. The first way is to install it using the Sitecore Installer, a MSI package that needs to be executed on the server, similar to a SharePoint installation. The installer asks you a few questions and is doing all the work for you, including installing the database and creating a new IIS web. There is, however, a second option: You also can install Sitecore "by hand". I will not go into detail here as the documentation at SDN (Sitecore Developer Network) provides you with all necessary information. Generally speaking, you can upload and install Sitecore even with a simple FTP account and remote access to your database.
That means, from an ASP.NET perspective, Sitecore is just like any other ASP.NET application with no special treatment or "special" IIS configuration. Any Sitecore installation creates some additional folders that are usually placed outside of the configured IIS web folder, but - if necessary - you can move them everywhere you want.
No matter which way you choose, you can have multiple installations of Sitecore on a single Windows installation. In contrast to SharePoint, you can even install Sitecore on Windows XP and Windows Vista, and you can not only run it using IIS, but also using VisualStudio's WebDevelopment server - but we will cover that in more detail in a later part of the series.
Of course no one can keep you from moving all Sitecore assemblies from the /bin folder to another location and register them in the GAC, so you can share the assemblies across multiple Sitecore installations. I for myself have actually never done that (because updating Sitecore is pretty easy), but it should be no big deal.
Every request to the application is handled by Sitecore using a lot of customized components (especially HTTP Modules and HTTP Handlers) that are registered in the Web.config file. The current version of Sitecore (6.0) performs a lot of initialization and routing operations before it hands off the request to the ASP.NET PageHandler, which then in turn opens an ASPX page with several Sitecore controls from the file system. It is no problem at all to replace the PageHandler with another HTTP Handler and store all the ASPX pages in another location (for example a database), or to do something totally different, but as far as ASP.NET is concerned, a request to a Sitecore application is just an ordinary HTTP request with some rewriting and an extended lifecycle.

Advantages

1. Two possible installation routines, Sitecore Installer and Manual Installation.
2. Multiple Sitecore installations CAN use the same assemblies and functionality.
3. Administrators have full control over where to install Sitecore.
4. Installing Sitecore is even possible with simple FTP und SQL accounts (although in a corporate environment, that may not be the most productive way).
5. Sitecore Layouts (Sitecore refers to ASPX pages as "layouts") are stored in the file folder of the IIS web. This makes it easy for developers to extend and customize pages as well as develop additional features as this way of handling files is aligned with the way the ASP.NET WebForms framework works. It also enables a nearly perfect integration with VisualStudio (see a later part).
6. Sitecore uses advanced ASP.NET features to extend the request pipeline and other components, but it does not change the way the framework is basically working that dramatically. This enables easy integration with other frameworks (e.g. Spring.NET) and libraries.

Drawbacks

1. Sitecore layouts (Sitecore refers to ASPX pages as "layouts") are stored in the file folder of the IIS web. In theory, this may lead to some problems with multiple Sitecore servers (content staging) and when it is necessary to extend layouts with versioning and workflows. In practice, there are several simple mechanisms available to handle those situations very effectively.

Okay, let's wrap up part two. Both frameworks are essentially ASP.NET 2.0-based, but SharePoint '07 changes the way the ASP.NET WebForms framework usually handles things pretty dramatically, although it is much better integrated with IIS and ASP.NET than its predecessor (SharePoint 2.0). Sitecore is more or less a simple ASP.NET web application with advanced functionality, deeply integrated with the .NET Web Platform. Especially from a developer perspective, Sitecore definitely deserves some extra credit for transparency and architecture.

Sitecore: +9 points = 9 points total
SharePoint: +5 points = 5 points total

The next part of this series covers the topic Configuration.

Because the ASP.NET WebForms framework is an emulation layer on top of the request / response architecture of the web and the stateless HTTP protocol, its behavior is sometime a little awkward, especially when dealing with state. A lot of people seem to have trouble mastering PostBack, ViewState, Context.Items, Server.Transfer, Session, HiddenField Values, QueryString Parameters, Response.Redirect, Request.Form and PreviousPage correctly - and who could blame them? All that stuff is pretty confusing if you do not know for sure how these things work.

Actually, these things are the main reasons why "ASP.NET WebForms" is in my opinion somewhat "dirty" from an architectural perspective and why I do not list it under "Really great libraries and frameworks". All those things seem to be so simple to use, but in fact everyone, especially inexperienced developers, has problems with them. The incorrect use of those features leads to very ugly solutions, error-prone applications and unmaintainable code. For example if someone stores parameters in the session that are relevant for the display of the current page only and the user opens a second web browser window, navigating in the first window also leads to server-side changes in the second window and invalidates the state of the application.

To handle postbacks correctly when dealing with state, I created a helper library called netzkern.Web.TransitionScope. It contains a control called TransitionManager which can be placed on an ASP.NET WebForms page (<nk:TransitionManager />). TransitionManager is basically a best-practices implementation for storing state of the current page and (optionally) transferring it between pages during a postback.

Let's assume we're building a simple webshop application. The first page we're going to create is a catalog page that lists all the items we want to sell. By clicking on one of the items on the catalog page, the server displays a details page with additional information about the item. First of all let me say, the first thing you should consider in scenarios like this is the use of QueryString parameters (e.g. http://shop.com/Details.aspx?Item=12546). The reason is that they are easy to use and you have URLs that can be opened directly without using the catalog page. There are, however, situations in which you may want to transfer additional information to the next page, you do not want the user to see the information, the information are to complex to be serialized to a QueryString parameter (or a Form) or you have to determine the next page after the user has already clicked a button without using Response.Redirect.

ASP.NET provides you with a method named Server.Transfer which "switches" the execution of the current to another page. The key to using it successfully is to know how to handle Context.Items, ViewState (or ControlState) and Session, especially if you want to manipulate and access the transferred data on the next page during several postbacks. This is where TransitionManager steps in.

Let's assume you have placed a TransitionManager on the catalog page and named it "TransMngr". To transfer information about the clicked item to the details page you just do the following:

TransMngr.NextPageItems.Add("ItemID", clickedItemID);
TransMngr.Transfer("~/Details.aspx", TransitionItems.NextPageItems);

To access the information on the details page you just do the following:

string itemID = TransMngr.CurrentPageItems["ItemID"];

The really great thing about this is that the information you just retrieved from TransMngr is available even after a postback of Details.aspx. You do not need to add anything to the ViewState or place it in a hidden field. Now, let's assume you created another page called Availability.aspx which checks the availability of the item you have currently selected. To transfer the execution from Detail.aspx to Availability.aspx after the user has clicked the "Check Availability" button and keep the information about the ID of the current item, just do the following:

TransMngr.Transfer("~/Availability.aspx", TransitionItems.CurrentPageItems);

Done. You do not need to re-register the information prior to the transfer if you already have them on your page. Just access the information on Availability.aspx using (again) this simple line of code:

string itemID = TransMngr.CurrentPageItems["ItemID"];

One important thing about this library is that it does not store any information you added to one of the PageItems collection on the client - it only stores the identifier for the current transition. Therefor it can also be used for sensitive information without any risk.

You can find the binaries and the source code at CodePlex. Please feel free to provide feedback and suggestions. Enjoy!

(Version 1.3 - October 19th, 2008)

In this series, I'm going to compare the functionality of SharePoint and Sitecore from a developer perspective in each area and both candidates can collect "points" from 0 (has nothing to contribute) to 10 (great integration and functionality).

This series will cover the following areas:
- Introduction (Part 1)
- Installation and General Architecture (Part 2)
- Configuration (Part 3)
- Customization and Designer Experience (Part 4)
- Integration with Developer Tools (Part 5)
- Feature Deployment (Part 6)
- API und Data Model (Part 7)
- Integration with other systems (Part 8)
- Conclusion (Part 9)

Introduction

I already mentioned it before, but I'm going to repeat this here for the sake of clarity: I'm very a pragmatic software architect and engineer and the decisions about my tools, frameworks and products are always efficiency-driven and focused on the task at hand. I would never use a product just because "it is such a great product" and I prefer tools that get the jobs done in a clean, well-designed and sustainable way. There are (from a developers viewpoint) some really beautiful, well-designed products and libraries out there (e.g. the .NET Framework in most namespaces, ASP.NET MVC, JSF, JQuery, WCF, Sitecore, IIS7, Spring (Java EE + .NET), Ruby on Rails, (N)Hibernate, LINQ, Microsoft AJAX Library, and some more), there are some products which deserve the label "okay to work with, gets the job done without causing to much confusing" (like ASP.NET WebForms, EJB3, BizTalk) but there are also some pieces of code that are responsible for a lot of confusion and inconsistency in software solutions (I have to mention WF and Outlook 2007 here, although they are based on some great ideas)...

Over the last 1.5 years I developed several applications and a lot of customizations for SharePoint '07 (MOSS 2007 and WSS 3.0) and gained a deep inside into the platform. Based on that experience, I have to say: From a developer perspective, SharePoint sucks. That does not mean that SharePoint is inherently a bad product. It isn't. But there are some things about this really huge piece of information infrastructure that drives me crazy and makes it very difficult for me as Software Architect and Lead Developer to really, really like it.

First of all, the overall software design of the product is at some parts really suboptimal. To really customize a SharePoint installation you need to work with pre-defined folder hierarchies in different locations on the harddrive, a huge content database, VisualStudio, SharePoint Designer, INI files, C# code, XSL, CSS, MasterPages, an inconsistent API, several XML dialects and so on... assuming that you know where to look and what to change. Beside that fact, the whole "naming thing" is really bad - some things are named differently in the API than they are in the Site Administrator documentation and the Frontend UI (because of several changes just before the release of SP '07), and even if you are aware of those traps, you are constantly struggling with the fact that SharePoint has no consistent "appearance" from a developer perspective. It seems like every "feature" (which is some kind of deployment unit in SP '07) was developed by an independent group of developers. There are numerous deployment descriptors, extended ASP.NET 2.0 features, config settings in files and databases and (of course) some things that do not work correctly if you change them.

Of course, SharePoint adds value to your organisation. That is because it has some really great capabilities like strong document management features, dynamic lists, workflow integration with WF (even if you have to work with another questionable piece of software here), search, integration with line of business apps, the BDC, record management and of course it plays well with Office 2007.

Everyone knows that a sophisticated Content Management System like Sitecore is the better choice for Content Delivery sites, but for the time being it is often also the better option in many Intranet scenarios, especially as gateway system for heavyweight ECM solutions like SharePoint, in those areas where a lot of structured content is produced and managed as well as in projects where individual features and application development is planned. At netzkern we are currently developing several additional modules to provide some of the SharePoint features mentioned earlier (especially document management and dynamic lists), and we are currently developing concepts to integrate both products as far as possible. This is because we want to leverage all the advanced ECM features of SharePoint without having to deal to much with the unnecessary complexity it adds to our development process. The idea for this series is based on that fact that there are several areas in which SharePoint could learn a lot of things from Sitecore, especially from a developers perspective.

I am a fan of a lot of Microsoft products and the quality as well as the inventive talent is constantly growing since the start of .NET in 2001, but there are some areas where they really could improve some of their products, especially if its such an important and strategic product as SharePoint.

This article series will explain why Sitecore is a really great development platform for web applications in intranet, extranet and internet and where SharePoint has (sometimes a lot of) space for improvement.

For part two of the series click here.

I just read some new information about the upcoming extension to IIS (codenamed "Dublin") that some people refer to as the "Oslo Application Host". As far as I know it is going to be a host for WF and WCF, integrated into IIS 7.0.
More information at http://www.microsoft.com/net/Dublin.aspx.