I spent most of the last year building out the new MTC in Dallas and we just recently moved in. It's an awesome place to work and I'll be blogging about that more in the weeks to come. I also plan to blog about the various technologies we have at the MTC as well as some of the new technologies Microsoft is announcing. Thanks for reading!

One of the technologies I'm (re)learning is BizTalk Server. So I looked around for a short and accurate description of what BizTalk is. I knew what it was, but I wanted a 2 - 3 sentence description. I found some interesting documents like the BizTalk Overview and David Chappell's excellent Understanding BizTalk Server 2006 (a must read). While those docs offered valuable information, I couldn't find the sentences I was looking for. This is probably due in part to my coming from a development background and wanting to relate things back to the developer world. So I came up with this short and, in my opinion, accurate description:

BizTalk is to business process automation what Visual Studio and the .NET Framework are to application development. It is a runtime and tools that enable you to automate and manage business processes more productively.

That's basically it. If I only get 10 seconds to explain what BizTalk is to a customer, the above description is what I'm most comfortable with. If I have more time, I would elaborate on that description as follows. 

The term "application development" is worth further exploration. Looking at the kinds of applications that people build with Visual Studio and the .NET Framework today, the vast majority are focused on specific tasks rather than end to end processes. Not to say that such applications are isolated, they're actually often connected to other apps or data sources via Web services or other means. But the focus of the app is to automate a particular task or set of related tasks and the connectivity serves that purpose. However the business reality is that businesses run on processes which span multiple tasks and of course people. So to automate a business process end-to-end you wind up wanting to connect some of the applications that were written to automate the tasks that make up that business process. As an example, consider the task of updating contact information in the company's address book for a newly hired employee. That employee may launch a .NET desktop app or go to an intranet Web site and enter they home address, cell phone number, emergency contact etc. Now zoom out and look at the big picture and what you see is an end-to-end on-boarding process that includes things like provisioning credentials, certificates, smart card, automatic deposit setup, hardware procurement, office furniture procurement, 401K account setup, setting up a mentor, and the variety of other things a new employee needs to get/set up. The address book update app automates one task in the end to end process but there's no app that automates the entire process.  BizTalk Server allows you to connect existing apps that automate the various tasks of this process and automate the tasks or parts that don't yet have automation to form a complete end-to-end process automation solution. It also gives you an operational or runtime view of that automation allowing you to see all the moving parts from one vantage point and start/stop/change/maintain them.

While it's certainly possible to build VS and .NET apps that automate end-to-end business processes, it's not the most productive use of the customer's/developer's time because they'd have to reinvent (or re-implement) several wheels in the process. It's a bit like building an document management Web site using nothing but ASP.NET: You can do it, but you can do it a lot better and faster if you used Windows SharePoint Services (WSS). The operations folks would also love you for it because of the management features they get out of the box with WSS.

1. To explore/prototype RSS/Atom support in WCF and get customer feedback
2. Provide a sample to show WCF developers how to expose a service as RSS and Atom over HTTP GET using WCF v1

Note the “and” not “or” in #2, meaning the same service implementation can be exposed as RSS, Atom, or any other format simultaneously. If you know WCF, you’ll know this means generating multiple wire formats (RSS, Atom, whatever) from the same contract which can be done with some extensibility. The key is to not rely on the contract projecting the desired info set, rather to transform whatever info set projected by the contract to the desired info set. That transformation would be different depending on the desired wire format.

 To make it easier for developers to emit RSS and Atom, I defined a DataContract with some of the commonly used RSS/Atom data and I defined a transform from that DataContract’s info set to RSS and another transform to Atom. All of this is pluggable/replaceable: You can use your own DataContract if you like, the transforms will transform what they recognize and copy the rest out as extension elements. You can also plug in your own transform to support new formats. Since it’s source, it’s also customizable so you can modify the DataContract and/or the transform if you don’t like how I make DataContract members to RSS/Atom elements.

 There was also the HTTP GET part of the equation. WCF’s HTTP transport supports GET out of the box but there are other places in the stack that need to be extended for the scenarios I had in mind. For example, dispatching to the right operation based on the path segment following the endpoint’s address in the request URL. Also, parsing the request query string and decoding parameters from it. And of course, supporting ETag and Last-Modified HTTP header. All of these are commonly needed in RSS/Atom scenarios and when we do build RSS/Atom support into WCF, we will have these features. For the sample however, the first two are included in the sample but the last one isn’t. The good news is that the WCF HTTP transport gives you full read/write access to HTTP headers via the Message properties HttpRequestMessageProperty and HttpResponseMessageProperty so you could build ETag support on top of the current WCF bits. In fact, one of the benefits of having the RSS toolkit sample source code is it gives you a starting point that you can take and modify with ETag support and other features you want. You can even publish you modified sample for the community to learn from and use.

An example service:

using System;
using System.ServiceModel;
using System.Collections.Generic;
using Microsoft.ServiceModel.Samples.Syndication;
namespace Microsoft.ServiceModel.Samples.Syndication
{

    [ServiceContract]
    public class ItemListService
    {
       [OperationContract]
       ContentFeed<FeedItem> GetItemList()
       {

            //instantiate the feed
            ContentFeed<FeedItem> feed = new ContentFeed<FeedItem>();

            //populate the list of feed items
            feed.FeedItems = GenerateItemList();

            //set some feed-level properties
            feed.FeedAuthor = wcfuser@contoso.com;
            feed.FeedTitle = "WCF Item List!";

            ...

            //return the feed
            return feed;       

        }

        ItemList<FeedItem> GenerateItemList()

        {

            ItemList<FeedItem> list = new ItemList<FeedItem>(); 

            FeedItem item1 = new FeedItem();
            item1.ItemTitle = "This is item 1";

            ...

            list.Add(item1);

            ...

            return list;

        }

    }

}

            host.Open();

            Console.WriteLine("Service started ...");
            Console.WriteLine("Press [Enter] to exit");
            Console.ReadLine();

            host.Close();

        }

    }

}

Enjoy!