Stephen Kaufman's WebLog

Can you move a Virtual Machine from VirtualPC to Hyper-V?

Stephen Kaufman — Thu, 19 Jan 2012 00:31:43 GMT

I was recently asked if I could help move a virtual machine that had been setup and running in VirtualPC and move it to run under Hyper-V.

The answer is yes it can be done. Movement from Hyper-V to VirtualPC is not as easy (and many times not possible) but there are a number of blog posts on this topic already so I won’t cover that here. One of the reasons that it is easier to move from VirtualPC to Hyper-V is that VirtualPC is only 32 bit.

There are a number of steps that must be occur for a successful move.

First, start by uninstalling the integration components while the virtual machine is running in VirtualPC. You can do this through the Add/Remove programs feature in Windows in the Virtual Machine. The Hyper-V drivers and additions will not install over the VirtualPC additions and that is why you must remove them first.

Next, move the vhd file to a location where it can be accessed by your Hyper-V instance. Walk through the wizard to create a new virtual machine but when prompted to create a new drive or select and existing drive, pick select an existing drive and point it to your .vhd file.

Finally, once you have the virtual machine configured in your Hyper-V instance then start the machine. Go through the Settings Menu and install the Hyper-V additions. Once you do this, the Hyper-V additions installs a new HAL as well as new drivers for network, video and sound devices. The process of installing the new HAL is one of the reasons that a Hyper-V image is no longer portable back to VirtualPC.

However, at this point, you might think that everything is done and you are ready to use the virtual machine. Most of the time this is correct, however, there are situations that require additional steps. You will know that you have additional steps if your integration components aren’t working – you can tell really quickly if your mouse doesn’t move outside of the virtual machine.

You are more likely to have this occur if your virtual machine is running versions of Windows prior to Vista or if you are running Windows Server 2008 as these do not have the ability to dynamically detect the HAL at boot time.

So, to fix this run MSConfig.exe – by clicking the Start menu, selecting Run and typing msconfig. Once the utility launches, click on the Boot tab and click the Advanced Options Button. When the BOOT Advanced Options dialog appears, click the Detect HAL checkbox and hit ok. Restart the virtual machine and you should be good to go!

Composite Applications

Stephen Kaufman — Wed, 16 Mar 2011 20:49:09 GMT

It has been a long time since my last blog post. It certainly hasn’t been for a lack of content but it is amazing how fast time flies when you are busy. I have been spending a lot of time lately working on composite applications and will be posting a number of entries around this topic.

One of the first questions that people ask is what is a composite app?

Composite apps can take on many forms and use many differing technologies. Many times people will talk about composite Apps and will only be referring to the UI tier. While the concept of a UI composite can be compared to a mashup (a UI that combines publically available web based services to create a meaningful combination of information to a user) a UI composite is built to use business sources – in many scenarios these sources (assets) already exist within the organization from previous application development efforts.

A composite app can also refer to just the middle tier as well. Many companies have spend a lot of time and money over the past many years building out SOA services. A composite app can consist of orchestration services that draw on the functionality of these different services. One thing to keep in mind however, is that a composite app is not make a SOA architecture. Instead they they will build on top of the work that has already been done to create a SOA architecture.

The idea of a composite app is to build upon existing software assets to quickly bring data to consumers in new way.

Many of the articles and blogs on this subject talk a lot around the UI tier. While that is a very important part of a composite application, I am going to spend time over the next few posts talking about composites at the middle tier.

There is a very good all-up article titled What Are Composite Applications from Atanu Banerjee where he walks through the full composite application stack. In this article he outlines three steps that a solution architect must do to design a composite application. Those things are to:

Choose a composition stack. Pick one or more containers from each tier, and a set of component types that are deployable into those containers.
Choose components. Define the repository of assets that must be built from this set of component types, based on business needs.
Specify the composite application. Define the ways in which those assets will be connected, to provide a particular cross-functional process. The platform should enable these connections to be loosely coupled.

Each of these things are required so that the consumer can get the most benefit. Over and above this, the organization should start to benefit by realizing faster time-to-benefit turnaround as well as faster time-to-deployment. These two, along with exposing existing LOB data are the three driving factors that are making the idea of composite applications so popular.

In my next several posts, I will cover some of the technical choices, how to bring bridge between services that live in BizTalk and services that live in AppFabric, and some of the lessons learned.

Twin Cities Connected Systems User Group Meeting–March 17th, 2011

Stephen Kaufman — Wed, 16 Mar 2011 15:39:29 GMT

If you are in Minneapolis on Thursday March 17th please join us for the Twin Cities Connected Systems User Group Meeting.

The meeting takes place at 6:00 p.m. at the Microsoft offices at 8300 Norman Center Drive, Bloomington, MN 55437.

Andy Morrison will be presenting on a Lap Around BizTalk 2010 and the ESB Toolkit 2.1

Twin Cities Connected Systems User Group Meeting – September 16th, 2010

Stephen Kaufman — Fri, 10 Sep 2010 17:16:02 GMT

If you are in Minneapolis on Thursday September 16th please join us for the Twin Cities Connected Systems User Group Meeting.

The meeting takes place at 6:00 p.m. at the Microsoft offices at 8300 Norman Center Drive, Bloomington, MN 55437.

Eric Kraus and I will be speaking on: Composite Applications: Connecting and Building Workflow Applications

Here is the write-up:

Come learn about Composite Applications and how you can build chunks of functionality in different loosely-coupled technologies that can be used to make up a larger collective solution. We will discuss how you can use SharePoint, BizTalk, Windows Server AppFabric, .NET and the LOB Adapters to build these chunks of functionality as well as the applications that consume them.

Storing Application Configuration Information in SSO

Stephen Kaufman — Tue, 31 Aug 2010 15:59:12 GMT

For those using BizTalk, we have long had the need to store configuration information in a central location that is shared between each of the distributed BizTalk instances. BizTalk itself uses SSO for all of its internal configuration information. Unfortunately, we have not had a tool that allows us to take advantage of this functionality. Currently, in SSO there are three different utilities to perform SSO based tasks. These are the SSOConfig, SSOManage and the SSOClient utilities. All of these tools focus on managing credentials.

There has been a lack of tooling for the ability to create and manage configuration based applications. This has now changed with the creation of the SSO Configuration MMC Snap-In. This tool is an MMC based utility that allows developers to store name/value pairs in the the SSO configuration database. The tool can be downloaded from the Microsoft downloads site and includes three parts.

These are the MMC management tool, a C# class file that provides the code necessary to access and read the configuration information and lastly, an automated MSBuild task to use for deployment of your configuration information.

The MMC Snap-In provides an easy to use interface that allows you to add and manage applications, add and manage key value pairs as well as importing and exporting (in an encrypted format) configuration applications so that they can be deployed to different environments.

The C# client class can be used in your application or helper assembly to read the values stored in SSO.

And lastly, there is the MSBuild custom task that can be used to automate the deployment of your applications SSO configuration data. All that you need to do is export the application and use the MSBuild task to automatically import your settings into your new environment.

After all of this you might be asking “Why would you want to store your configuration data in SSO?”. Well, middle tier server based applications have the need to utilize configuration data that needs to be able to be read at runtime and changed without compiling. These applications also need the ability to have centrally managed and non repeated configuration information be available to all hosts in the middle tier. Typically, middle tier applications implement a custom solution and the architects/developers need to create a means to replicate this information to servers when a scale out solutions are implemented. Instead, this configuration can be stored directly in SSO and since SSO is already accessible to all servers in a scale out solution, we can take advantage of tools that we already use instead of creating custom solutions.

Using The Windows Server AppFabric Cache with ASP.NET

Stephen Kaufman — Mon, 30 Aug 2010 14:53:42 GMT

It appears that I have lost some of my blog posts. I am reposting this blog post which originally appeared back in May.

Did you know that you can use the AppFabric Cache with ASP.NET? AppFabric Cache provides an ASP.NET session state provider. There are a number of reasons that you would want to consider using the AppFabric Cache instead of other caching technologies, including the built in ASP.NET caching.

The AppFabric Cache provides a number of benefits to ASP.NET programmers. When web applications need to maintain state, especially across a Web Farm, or needs to maintain objects across restarts AppFabric Cache provides the out of process, distributed highly available functionality you require. In addition, because of the distributed nature of the cache you no longer need to worry about sticky routing (getting the client back to the same machine as their cached objects). You also no longer need to add additional code and incur the overhead of storing state in a database. By keeping activity oriented objects closer to the consuming logic you can eliminate the overhead and increase performance of your application.

To utilize the AppFabric Cache ASP.NET session state provider open your applications' Web.Config file and enter the following XML fragment.

<system.web>
    <sessionState mode="Custom" customProvider="SessionStoreProvider">
        <providers>
            <add name="SessionStoreProvider" type="Microsoft.ApplicationServer.Caching.DataCacheSessionStoreProvider,  Microsoft.ApplicationServer.Caching.Client, Version=1.0.0.0, Culture=neutral,  PublicKeyToken=31bf3856ad364e35" />
        </providers>
    </sessionState>
</system.web>

Tagging Objects in the AppFabric Cache

Stephen Kaufman — Fri, 23 Apr 2010 03:02:00 GMT

In two of my previous entries I outlined functionality and patterns used in the AppFabric Cache. In this entry I wanted to expand and look at another area of functionality that people have come to expect when working with cache technology.

This expectation is the ability to tag content with more information than just the key. As you start to examine this expectation you will soon find yourself asking if the tagged data can be related to each other and finally if it is possible to remove the related data.

One of the nice things about the AppFabric Cache is that it is so easy to work with and can be so simple. Then, if needed, like with this topic, you can take advantage of the addition functionality. This is where the real benefits of AppFabric Cache come into play over the other cache alternatives.

Lets take a deeper look at tagging. Tagging is essentially assigning one or more string values to an object contained in the cache. The object in the cache can then be retrieved by using the tag or multiple tags. When you tag an object, all of the tagged objects will reside within a region. A region is an additional container inside the cache. Because regions are optional, if you want to use them you need to explicitly create them at runtime within your application code. You can setup different regions for different types of related data. When you utilize regions, you have the option to retrieve all objects in that region and therefore by default have setup a solution that now provides you access to all the dependent data. We can take this one step further in that you can also delete all of the data within a region and not have to worry about looping through all entries to find the specific keys and their dependencies.

As an example we could create a region called 'Beverages' and then we could cache all of the beverages we sell and tag each item by the type of beverage such as Soft Drink, Wine, Beer. We could even go one step further and provide multiple tags so that we could further segment the Wine category into White or Red or Merlot, Zinfandel, Riesling, etc. At this point the application could retrieve all of the catalog items based on the search criteria that were entered.

Lets look at how we can setup the region and tags. We will also look at the methods that are available to interact with objects using tags and lastly, how we can manage the data in the cache; adding, retrieving and deleting.

Setting Up a Region:

The code that follows assumes that you already now how to create a cache (either through code or through the PowerShell cmdlets (as found in my previous post here)).

To create a region we already need to have the cache created. Once that is done, we can pass in the cache name, use the GetCache method and then call the CreateRegion method passing in a region name. We can create as many regions as we need based on the manner in which you wish to segment the data. One thing to keep in mind however is that there can be performance implications when using regions. The code below shows how we can create the region.

private void CreateRegion(string CacheName, string RegionName)
{

    //This can also be kept in a config file
    var config = new DataCacheFactoryConfiguration();
    config.Servers = new List<DataCacheServerEndpoint>
        {
            new DataCacheServerEndpoint(Environment.MachineName, 22233)
        };

    DataCacheFactory dcf = new DataCacheFactory(config);

    if (dcf != null)
    {
        var dataCache = dcf.GetCache(CacheName);
        dataCache.CreateRegion(RegionName);
    }
}

Now that we have a cache with a region created lets look at the methods that are available to interact with tags

Methods to work with tagging (from MSDN):

Method	Description
GetObjectsByTag	Provides a simple way to access objects that contain tags (exact match, intersection, or union). The region name is a required parameter.
GetObjectsByAnyTag	Returns a list of objects that have tags matching any of the tags provided in the parameter of this method.
GetObjectsByAllTags	Returns a list of objects that have tags matching all of the tags provided in the parameter of this method.
GetObjectsInRegion	Returns a list of all objects in a region. This method is useful when you do not know all the tags used in the region.
GetCacheItem	Returns a DataCacheItem object. In addition to the cached object and other information associated with the cached object, the DataCacheItem object also includes the associated tags.
Add	When adding an object to cache, this method supports associating tags with that item in the cache.
Put	When putting an object into cache, this method can be used to replace tags associated with a cached object.
Remove	This method deletes the cached object and any associated tags.

Managing the data in the cache

There are a number of methods to get objects out of the cache but logically I like to start in terms of adding to the cache first. So, lets take a look at the put method. The put method will update an object that already has a key that is contained in the cache (whereas the Add will return an exception if the key is already present). The put method can also update or add new tags to an existing object in the cache. As we look at the Put method signature below we can see that this version of the method accepts the key and value just as the other overrides of the Put method do but this one also adds on a collection of tags as well as the name of the region that the cached item will reside in.

public DataCacheItemVersion Put (
string key,
Object value,
IEnumerable<DataCacheTag> tags,
string region
)

The code below shows how we can use the Put method and include multiple tags

private void InsertCacheObjectWithTag(string CacheName, string RegionName)
{
    //This can also be kept in a config file

    var config = new DataCacheFactoryConfiguration();
    config.Servers = new List<DataCacheServerEndpoint>
    {
        new DataCacheServerEndpoint(Environment.MachineName, 22233)
    };

    DataCacheFactory dcf = new DataCacheFactory(config);

    if (dcf != null)
    {
        List<DataCacheTag> tags = new List<DataCacheTag>
            {
                new DataCacheTag("Wine"),
                new DataCacheTag("Red"),
                new DataCacheTag("Merlot")
            };

        var dataCache = dcf.GetCache(CacheName);

        dataCache.Put("WineKey", "WineValue", tags, RegionName);
    }
}

Now we can look at the methods to retrieve objects. There are four main Get methods. We can get by tag, any tag, all tags and finally any object that exists in the region no matter what tag. The GetObjectsInRegion method is what provides us the ability to implement a scenario in which all cached objects are related and can be treated as a group. The related data can also be removed by called dataCache.RemoveRegion(RegionName) just as we called the CreateRegion method above.

For people that have been working with Memcached you can delete dependent data through the cas (check and set) operation. The reason that I bring this up is that more people are familiar with Memcached and therefore I am asked if AppFabric Caching has this or that functionality. What I am finding is that it has the same functionality and more. It is just implemented a bit differently.

Anyways, if we want to retrieve all the objects in the cache that have a Wine tag we can use the GetObjectsByTag as shown below:

public IEnumerable<KeyValuePair<string, object>> GetLookUpCacheDataByTag(string TagValue)
{
    var config = new DataCacheFactoryConfiguration();
    config.Servers = new List<DataCacheServerEndpoint>
        {
            new DataCacheServerEndpoint(Environment.MachineName, 22233)
        };

    DataCacheFactory dcf = new DataCacheFactory(config);

    var cache = dcf.GetCache(cacheName);

    DataCacheTag dct = new DataCacheTag(TagValue);

    return cache.GetObjectsByTag(dct, regionName); //regionName could either be passed in or an internal variable
}

and lastly, we can remove items based on a tag. I already mentioned that we can call the RemoveRegion method to remove all the related data that is grouped together in a region. If there is a specific item that you want removed then you can call the Remove method and pass in the key. If you wanted to delete based on a tag value then you would have to call one of the GetXXX methods, obtain the key, and then call the Remove method by passing the returned key value.

Pre-Populate the AppFabric Cache

Stephen Kaufman — Wed, 07 Apr 2010 19:22:00 GMT

When I start talking to people about the caching functionality that is part of Windows Server AppFabric I am usually asked "What is the AppFabric Cache?" The MSDN page at http://msdn.microsoft.com/en-us/library/ee790954.aspx provides a great overview (below) as well as additional information. The Cache is defined as:

"Windows Server AppFabric caching features use a cluster of servers that communicate with each other to form a single, unified application cache system. As a distributed cache system, all cache operations are abstracted to single point of reference, referred to as the cache cluster. In other words, your client applications can work with a single logical unit of cache in the cluster regardless of how many computers make up the cache cluster. "

When you develop against the AppFabric Cache you utilize the cache-aside pattern. This pattern outlines the steps in which the application will first check to see if the data is in the cache. If not, then query a database (or other data source), load the cache, then return the value. The idea is that the cache will be populated over time as instances of the application call for data. The AppFabric Cache comes with a number of options around how long data should remain in the cache and provides you the flexibility to tune the performance to your needs.

One thing that the cache-aside pattern doesn't provide for is the pre-population of data in the cache. This entry will walk through how we can provide this functionality.

The first thing we need to do is to create the cache. I outline how to create a cache in .NET code in my previous entry. You can check that out but I will also include the code in the sample below. As you go about creating the cache you also need to decide if you want eviction to occur and if so how long the data will stay in the cache until it is evicted. For this example I am going to setup the cache so that eviction is turned off (Expirable is set to false). Since I am preloading the cache I want to the data to remain in the cache. If I read your mind, the next question will be how will the code handle when new data is entered into the database. Through the use of the SQL Dependency functionality we can setup an event handler to respond when an event is raised when there is a change at the database layer. Once this event is caught we can empty the cache and reload it. We could also add code to take advantage of the cache-aside pattern and if we don't the data in the cache then query the database and populate the cache on demand.

As we look at the code example below lets jump directly to the PopulateLookUpCache method. The first part of this method sets up the database connection, the SQL Dependency and loads the data into a dataset. The second part of the method focuses on the loading of the cache. This is the part that we will focus on.

Before we can use the cache we need to create an instance of the DataCacheFactory. This object requires configuration information. This can either be through entries in a config file as shown below:

or through code by creating a DataCacheFactoryConfiguration object and passing it to the DataCacheFactory as shown below:

var config = new DataCacheFactoryConfiguration();
config.Servers = new List<DataCacheServerEndpoint>
{
new DataCacheServerEndpoint(Environment.MachineName, 22233)
};

DataCacheFactory dcf = new DataCacheFactory(config);

We can now call the GetCache method which will return a cache object based on the name of the cache that is passed into the method. The Cache object has a number of methods which allow us to interact with the cache. I use the Put method as the Put will add or replace an object in the cache whereas the Add method only adds an entry. If there is already an object in the cache it will return an exception.

In the code below, I loop through the DataSet and call the Put method to populate the cache. The Put method takes two parameters. The first is the key that will be used and the second is the value. In this case, since I am using the AdventureWorks sample database, the Products table contains the product id and the product which works very nicely for this example.

Once the loop has been executed and the data is now in the cache we can double check that the cache has been populated through the use of a PowerShell cmdlet. Switch to a PowerShell command window and type in (without the quotes) "Get-CacheStatistics -CacheName <your cache name>" and hit enter. This will return a list of attributes related to the cache and will show you how many items are currently in the cache.

We now have a populated cache and a now can use the GetLookUpCacheData method to read data out of the cache for our application. Take a look at the code below to see how all of this was done as well as how to setup the SQL Dependency code to get events. As always this code is provided as is and there are a number of places that should be refactored - such as the repeating DataCacheFactory objects.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Data.SqlClient;
using System.Data;

using Microsoft.ApplicationServer.Caching;

using System.Management.Automation;
using System.Management.Automation.Runspaces;

namespace AppFabricCacheWrapper
{
    public class CacheHelper : IDisposable
    {
        private static DataSet lookUpDataset = null;
        private string connString = string.Empty;
        private string cacheName = "PreLoadSampleCache";

        public CacheHelper()
        {
            connString = "Data Source=(local);Initial Catalog=AdventureWorksLT;Integrated Security=SSPI;";
            SqlDependency.Start(connString);
            CreateCache(cacheName);
            PopulateLookUpCache(cacheName);
        }

        ~CacheHelper()
        {
            SqlDependency.Stop(connString);
            Dispose(false);
        }

        public void Dispose()
        {
            Dispose(true);
            GC.SuppressFinalize(this);
        }

        protected virtual void Dispose(bool disposing)
        {
        }

        public string GetLookUpCacheData(string keyValue)
        {

            var config = new DataCacheFactoryConfiguration();
            config.Servers = new List<DataCacheServerEndpoint>
            {
                new DataCacheServerEndpoint(Environment.MachineName, 22233)
            };

            DataCacheFactory dcf = new DataCacheFactory(config);

            var cache = dcf.GetCache(cacheName);
            string data = cache.Get(keyValue) as string;
            if (data == null)
            {
                //Determine if you are going to query the database
            }

            return data;
            }

        /// <summary> /// Retrieves look up data for the given key and type from database /// </summary>
        private void PopulateLookUpCache(string CacheName)
        {
            SqlConnection conn = null;
            SqlCommand comm = null;
            SqlCommand commDependency = null;
            SqlDataAdapter sqlAdapter = null;

            //populate DataSet
            try
            {
                //Connect to look up database and retrieve the names of the products.
                conn = new SqlConnection(connString);
                conn.Open();

                comm = new SqlCommand();
                comm.Connection = conn;
                comm.CommandText = "select ProductID, Name from SalesLT.Product";
                comm.CommandType = CommandType.Text;

                if (lookUpDataset == null)
                {
                    lookUpDataset = new DataSet();
                }
                else
                {
                    lookUpDataset.Clear();
                }

                sqlAdapter = new SqlDataAdapter(comm);
                sqlAdapter.Fill(lookUpDataset);

                //Command object used for subscribing to notifications
                commDependency = new SqlCommand();
                commDependency.Connection = conn;
                commDependency.CommandText = "select ProductID, Name from SalesLT.Product";
                commDependency.Notification = null;
                SqlDependency dependency = new SqlDependency(commDependency);
                dependency.OnChange += new OnChangeEventHandler(dependency_OnChange);
                commDependency.ExecuteNonQuery();
            }
            catch (Exception e)
            {
                throw new Exception(e.Message + e.StackTrace);
            }
            finally
            {
                sqlAdapter.Dispose();
                comm.Dispose();
                commDependency.Dispose();
                conn.Close();
                conn.Dispose();
            }

            //populate cache
            try
            {
                //This can also be kept in a config file
                var config = new DataCacheFactoryConfiguration();
                config.Servers = new List<DataCacheServerEndpoint>
                    {
                        new DataCacheServerEndpoint(Environment.MachineName, 22233)
                    };

                DataCacheFactory dcf = new DataCacheFactory(config);

                if (dcf != null)
                {
                    var cache = dcf.GetCache(CacheName);

                    foreach (DataRow product in lookUpDataset.Tables[0].Rows)
                    {
                        cache.Put(product["ProductID"].ToString(), product["Name"].ToString());
                    }
                }
            }
            catch (Exception e)
            {
                throw new Exception
            }
        }
    }
    /// <summary>
    /// Event which will be fired when there are any database changes done to the dependency query set
    /// </summary>
    private void dependency_OnChange(object sender, SqlNotificationEventArgs e)
    {
        if (e.Info != SqlNotificationInfo.Invalid)
        {
            PopulateLookUpCache(cacheName);
        }
    }

    private void(string CacheName)
    {
        //This can also be kept in a config file
        var config = new DataCacheFactoryConfiguration();
        config.Servers = new List<DataCacheServerEndpoint>
            {
                new DataCacheServerEndpoint(Environment.MachineName, 22233)
            };

        DataCacheFactory dcf = new DataCacheFactory(config);

        if (dcf != null)
        {
            var state = InitialSessionState.CreateDefault();
            state.ImportPSModule(new string[] { "DistributedCacheAdministration", "DistributedCacheConfiguration" });
            state.ThrowOnRunspaceOpenError = true;
            var rs = RunspaceFactory.CreateRunspace(state);
            rs.Open();
            var pipe = rs.CreatePipeline();
            pipe.Commands.Add(new Command("Use-CacheCluster"));

            var cmd = new Command("New-Cache");
            cmd.Parameters.Add(new CommandParameter("Name", CacheName));
            cmd.Parameters.Add(new CommandParameter("Expirable", false));
            pipe.Commands.Add(cmd);
            var output = pipe.Invoke();
        }
    }
}

Interview on Endpoint.TV

Stephen Kaufman — Thu, 01 Apr 2010 18:58:00 GMT

Danny Garber and I were interviewed for Endpoint.TV on Windows Server AppFabric and our upcoming book.

The interview has been published and is now available. Check it out at http://channel9.msdn.com/shows/Endpoint/endpointtv-Pro-Windows-Server-AppFabric/

Calling PowerShell from .NET

Stephen Kaufman — Wed, 31 Mar 2010 20:08:00 GMT

I have been working with Windows Server AppFabric caching lately and have found it to be very impressive. The more that I work with it the more that I can see areas that it can be utilized. One of the things that will become quite evident as you start using it is that much of the setup and configuration is done through PowerShell cmdlets.

I am in the process of putting together an application and I want the application to be able to create and pre-populate the cache. As I looked into creating the cache I knew that it could be created through PowerShell directly but I wanted to call the PowerShell cmdlets from .NET. So, lets look at what is needed to create the cache from PowerShell first and then we will look at the code to call the cmdlets from .NET.

This assumes that AppFabric has been installed and configured.

Open a PowerShell command window. The first thing that we are going to do is to import two modules and then we can start issuing commands. First, type "Import-Module DistributedCacheAdministration" (without the quotes) and hit enter. This will import the cache administration cmdlets. Next type "Import-Module DistributedCacheConfiguration" and hit enter. This will import the cache configuration cmdlets.

The next command will bring the current machines' cluster configuration into the PowerShell session context. So, type in Use-CacheCluster and hit enter. We have now entered all that we need to start interacting with the cache. The first thing that we need to do is to ensure that the cache service is running. Type "Get-CacheHost" and hit enter. Look on the screen and see if the Service Status show UP. If it shows DOWN then issue the following commands to start it. Type "$hostinfo = Get-CacheHost" and hit enter. Then type in "Start-CacheHost $hostinfo.HostName $hostinfo.PortNo".

At this point we are ready to create the cache using the New-Cache cmdlet. Type "New-Cache <your cache name here>" and hit enter. This will create a cache with your name that is ready to use.

If you want to see the configuration for your newly created cache type in "Get-CacheConfig <your cache name here>" and hit enter. You will see the following configuration attributes and their settings.

CacheName : MyCache
TimeToLive : 10 mins
CacheType : Partitioned
Secondaries : 0
IsExpirable : False
EvictionType : LRU
NotificationsEnabled : False

To do this all with code we need to add three references to our project. Add the System.Management.Automation assembly as well as the Microsoft.ApplicationServer.Caching.Core and Microsoft.ApplicationServer.Caching.Client assemblies. These two assemblies can be found in the Windows\System32\AppFabric directory.

To set up the environment in .NET to issue PowerShell commands we need to start with the InitialSessionState class. This will create a session with the PowerShell runspace. A PowerShell runspace is the operating environment where you can create pipelines which will run the cmdlets.

So, just as above we will need to start with importing the DistributedCacheAdministration and DistributedCacheConfiguration modules. This can be seen below in the source code with the state.ImportPSModule method. Once we have the session state created we can call the RunspaceFactory to create a new runspace. At this point we can call the Open method can now start creating commands through a pipeline.

In the code below we create two pipelines. The first is our Use-CacheCluster command. This is a command that doesn't take or return any arguments. The next command is the New-Cache command. This takes a set of arguments so we will create this a bit different. First, we will create a Command object and then set parameters on the command object for each of the arguments we want to pass in. In this example I am providing a name as well as telling the caching system that I don't want the cache items to expire. Next, we need to pass the command object to the pipe and lastly, call the Invoke method as shown in the code below:

private void CreateCache(string cacheName)
{
    //This can also be kept in a config file
    var config = new DataCacheFactoryConfiguration();
    config.Servers = new List<DataCacheServerEndpoint>
        {
            new DataCacheServerEndpoint(Environment.MachineName, 22233)
        };

    DataCacheFactory dcf = new DataCacheFactory(config);

    if (dcf != null)
    {
        var state = InitialSessionState.CreateDefault();
        state.ImportPSModule(new string[] { "DistributedCacheAdministration", "DistributedCacheConfiguration" });
        state.ThrowOnRunspaceOpenError = true;
        var rs = RunspaceFactory.CreateRunspace(state);
        rs.Open();
        var pipe = rs.CreatePipeline();
        pipe.Commands.Add(new Command("Use-CacheCluster"));

        var cmd = new Command("New-Cache");
        cmd.Parameters.Add(new CommandParameter("Name", cacheName));
        cmd.Parameters.Add(new CommandParameter("Expirable", false));
        pipe.Commands.Add(cmd);

        var output = pipe.Invoke();
    }
}

We now have a cache created for us from .NET code.

Twin Cities Connected Systems User Group Meeting - March 11th, 2010

Stephen Kaufman — Wed, 10 Mar 2010 15:08:00 GMT

If you are in are in Minneapolis on Thursday March 11th please join us for the Twin Cities Connected Systems User Group Meeting.

The meeting takes place at 6:00 p.m. at the Microsoft offices at 8300 Norman Center Drive, Bloomington, MN 55437.

I will be speaking on How to Create Windows Server AppFabric Applications

Here is a write-up of what will be covered:

You have heard about Dublin, now called Windows Server AppFabric, but do you know what it is and what it includes?

Do you know how to create WCF and WF applications/services that work better with AppFabric?

Come to the user group meeting and see how to write these applications and take advantage of AppFabric. We will show you how to use Visual Studio 2010 to create WCF and WF services and how to deploy, monitor, and control them with Windows Server AppFabric. In addition, we will also talk about what you need to know to start using AppFabric and what you need to do to optimize your existing applications and services to begin using AppFabric.

Pro Windows Server AppFabric Book

Stephen Kaufman — Mon, 18 Jan 2010 22:40:00 GMT

I have been spending my free time working on my next book. Danny Garber and I are co-authoring this book from APress.

The book will be available this spring and should coincide with the release of AppFabric.

Twin Cities Connected Systems User Group Meeting - January 21st, 2010

Stephen Kaufman — Thu, 14 Jan 2010 21:09:00 GMT

If you are in are in Minneapolis on Thursday January 21st please join us for the Twin Cities Connected Systems User Group Meeting.

The meeting takes place at the Microsoft offices at 8300 Norman Center Drive, Bloomington, MN 55437. This months meeting time has changed and we will be meeting from 5:00 to 6:30

Ed Jones from RBA will be presenting on Implementing a Service Bus Architecture with BizTalk 2009 and the BizTalk ESB Toolkit 2.0: A Real World Example

Here is a write-up of what will be covered:

Although BizTalk Server offers much in terms of flexibility and extensibility through the implementation of Service Oriented Architectures, most BizTalk applications are developed in “hub-and-spoke” models that are tightly coupled to specific points of functionality. Entire business processes are often represented as orchestration. As such, when business processes change, orchestrations also need to change, often requiring the reconstruction and redeployment of entire BizTalk solutions.

One way to alleviate this pain is to avoid the use of a “hub-and-spoke” model altogether in favor of a Service Bus approach. The BizTalk ESB Toolkit helps accomplish this by making the creation of a true Service Bus easier. One feature of the toolkit for example, itineraries, allows us to create capabilities that are independent of each other and independent of specific processes. This "Composition of Capabilities" method is preferred over the point-to-point solutions used in many BizTalk applications enabling more extensible and flexible Business Processes.

Our client required a system that would accept incoming shipment data in the form of flat-files in multiple formats, process that data through a series of resolutions, and then output the data in both its raw and processed form into an ERP system. Some data will be processed, while other data will be ignored. Over time it is expected that the various processes may change in size, scope, and sequential order. Our solution implements ESB Toolkit Itineraries to accomplish this composition of capabilities. We also use the Exception Management and other more traditional BizTalk functionalities such as Business Rules.

AppFabric and BizTalk

Stephen Kaufman — Tue, 24 Nov 2009 05:37:00 GMT

There have been lots of questions lately about AppFabric (code named Dublin). These questions have centered around why Microsoft needs another middle tier solution and will AppFabric replace BizTalk.

Lets take a look at these questions as well as two additional questions; What is AppFabric and why does Microsoft need another middle tier solution? First, AppFabric is a distributed application server. To answer the other questions, we need to go in a little more depth.

Before .NET was released, developers working with the Microsoft technologies used COM+ to host their middle tier objects. Back then, when we needed to scale out our object oriented and object based applications we created middle tier code libraries and ‘hosted’ them in COM+. The COM+ host provided instance management (just-in-time activation), role-based security, automated transaction management as well as better memory and processor management, distributed transactions and a number of other services.

When .NET was introduced, we moved away from COM components and also moved away from using COM+ as a hosting model. This left a vacuum that so far had gone unfilled.

In attempts to fill this vacuum, individual developers had to create their own hosts. These hosts typically were Windows Services. However, these services usually didn’t include multi threading, scale out capabilities, tracking, monitoring, etc. – the types of functionality that has been in BizTalk for years. As Microsoft looked at BizTalk, as well as the .NET Framework, it was determined that there are many great features in BizTalk that if a scaled down version was available it would address gaps in the framework. Thus AppFabric was born.

For .NET developers writing applications using WCF and WF, AppFabric will fill the middle tier hosting vacuum. AppFabric will provide the host and will provide scalability and support for building out your middle tier application components. It also will simplify deployment, configuration, management and scalability of composite applications. The goal of AppFabric is to provide a server infrastructure, on which business logic developed in WF can be executed and exposed via WCF endpoints, without the need to design, develop, and support the infrastructural code.

The next question I hear is will AppFabric replace BizTalk? The answer is very clearly no.

AppFabric should be used when your architecture calls for an application level code-first object based approach. This is the same approach that is used by WF and WCF programming models and is the one that can be hosted in AppFabric and the additional functionality that AppFabric provides. AppFabric will provide a number of management and scalability features through IIS and WAS to provide the server infrastructure without the need to write the plumbing as you did before. This is a different approach than that of the XML Schema first approach that is used in BizTalk.

Use BizTalk when your architecture calls for an enterprise level message based approach. Use BizTalk when you need to isolate disparate systems that need to be connected. In point-to-point integrations, changes made to the provider system can have a profound impact on the consuming application. BizTalk natively provides a hub-based integration model which eases this burden and allows organizations to provide business services that are isolated from the impact of changes made to the systems and processes on which these services are based. This is achieved through the use of separate schemas, and the associated ability to easily develop message transformation logic using BizTalk’s Mapper tool. Use BizTalk if you have business-to-business requirements and need to integrate using technologies such as EDI, SWIFT, RosettaNet, AS2 or HL7.

The reality is that businesses will utilize both of these technologies in their different application architectures. This is not an either or decision but instead a decision of where and when to use each.

Keep in mind, however, that many of the same terms are used to describe the functionality provided with both BizTalk and AppFabric. These terms are things like Content Based Routing, Correlation, long running transactions, etc. Although the terms are the same the implementation and functionality is different. With all decisions, make sure that you take a couple of minutes to look under the hood and ensure that you understand the differences.

Follow Up from TechEd Europe

Stephen Kaufman — Sat, 21 Nov 2009 05:46:00 GMT

Paolo Salvatori and I delivered a session titled 'Customizing and Extending the BizTalk WCF Adapters' and Paolo has created a number of fantastic blog entries around this subject. His latest entry goes through much of the content that was delivered in the session and he has included a number of links at the bottom for more WCF Adapter information and samples.

Speaking at TechEd Europe 2009

Stephen Kaufman — Tue, 13 Oct 2009 05:02:00 GMT

I will be speaking at TechEd Europe 2009 in Berlin Germany November 9th through the 13th.

I will be presenting two sessions. My first is a 'Deep Dive with Microsoft BizTalk Server 2009 Development Platform' and my second is 'Customizing and Extending the BizTalk WCF Adapters'.

If you are going to be there stop by and say hello.

The Architecture Journal - Edition 21

Stephen Kaufman — Mon, 12 Oct 2009 04:28:00 GMT

I co-authored an article titled 'Design Considerations for S+S and Cloud Computing' in this months Architecture Journal. I co-authored this along with 8 other architects at Microsoft. They were Fred Chong, Alejandro Miguel, Jason Hogg, Ulrich Homann, Brant Zwiefel, Danny Garber, Joshy Joseph and Scott Zimmerman.

Here is the summary: The purpose of this article is to share our thoughts about the design patterns for a new generation of applications that are referred to as Software plus Services, cloud computing, or hybrid computing. The article provides a view into S+S architectural considerations and patterns as they affect common architectural domains such as enterprise, software, and infrastructure architecture.

Check it out at http://msdn.microsoft.com/en-us/architecture/aa699439.aspx

Also be sure to check out the other great articles in the 21st edition of the magazine. This edition is focused on SOA today and tomorrow.

StreamInsight

Stephen Kaufman — Wed, 30 Sep 2009 07:04:00 GMT

You are probably asking what is StreamInsight. Well, it is the platform for performing Complex Event Processing (CEP) from Microsoft. Actually to quote exactly what it is - it is a "platform for the continuous and incremental processing of unending sequences of events (event streams) from multiple sources with near-zero latency".

There has been a need to deal with processing at near zero latency for some time. Many times existing products can perform at low latency and that has been acceptable, however, there are a number of situations where low latency wasn't sufficient. That is where Complex Event Processing comes in.

According to Wikipedia CEP is defined as: primarily an event processing concept that deals with the task of processing multiple events with the goal of identifying the meaningful events within the event cloud. CEP employs techniques such as detection of complex patterns of many events, event correlation and abstraction, event hierarchies, and relationships between events such as causality, membership, and timing, and event-driven processes. CEP is to discover information contained in the events happening across all the layers in an organization and then analyze its impact from the macro level as "complex event" and then take subsequent action plan in real time.

Some of the scenarios that call for CEP are:

Manufacturing: Sensors on the plant floor capturing data through device controllers and aggregating data consisting of tens of thousands of events per second with requirements to act on patterns detected to ensure product quality

Web analytics: Instrument server to capture click-stream data and determine online customer behavior

Financial services: Listening to data feeds like news or stocks. Use that data to run queries looking for patterns that find opportunities to buy or sell stock

Some of the features of StreamInsight listed on the download site are:

Derive meaningful and relevant information from data/events streams through complex patterns. These patterns can be defined using a declarative query paradigm based on well-defined streaming semantics with LINQ as query language.
For the development of applications, adapters, and analytics, the user can rely on well-established and powerful development frameworks and tools such as .NET, LINQ, and Microsoft Visual Studio.
The platform integrates with various data sources and sinks through input and output adapters. The framework to build domain-specific adapters utilizes a .NET API to make adoption of the platform easy. Independence between adapters and queries facilitates seamless integration of real-time and historical analysis.
The platform architecture supports a variety of deployment options, from scenarios with a low-footprint embedded option to high-end server deployments.
A rich set of manageability features such as a management interface, a diagnostic interface and a debugging tool are provided as part of the platform.

You can start working with the CTP by downloading it at: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=a3faa562-b6dc-4702-90c6-bf8e08df3b8b

WCF: Did you know?

Stephen Kaufman — Thu, 13 Aug 2009 01:15:00 GMT

Did you know that when doing contract first development and utilize a Boolean data type with a default value (lets just say the default value was set to true), WCF will not serialize out the default value in the message. WCF will only serialize out the value if it differs from the default.

This was an interesting scenario in BizTalk when we were trying to test for the Boolean to be true and we saw that it was actually empty.

Sometimes I wonder with these types of issues if I am the only one in the world that didn't know that. I am going to make the assumption that this will be news to more people then just me.

WSE, DIME; WCF, MTOM; OH My!

Stephen Kaufman — Mon, 20 Jul 2009 20:51:00 GMT

I was recently working on a proof of concept where we needed to interface to a repository that returned the documents using DIME attachments. I don't know if you have had the 'opportunity' to work with DIME attachments before but there isn't much that still supports that format. Since the manufacturer of the repository wasn't upgrading their software to take advantage of the new MTOM format we needed to consume the DIME attachments and convert them to MTOM attachments through an exposed WCF end point.

My client was putting this service on their ESB, which was built using BizTalk, and we utilized the WSE 2.0 extensions (yes, you can still download them) for the DIME support.

To do this we downloaded the WSE extensions and created a class that we would call from within our Orchestration. We added a Web Reference to point to the web service of the repository. We then replaced the default inherited class in the proxy with the WSE class, Microsoft.Web.Services2.WebServicesClientProtocol. At this point we were ready to start writing code to consume the attachments.

In the code below, we loop through the attachments in the ResponseSoapContext and then load them into a stream object. We then used the Convert class to convert the byte array to the properly converted Base64String and placed that as the value of the Attachment node. The schema node's data type in the schema in BizTalk for the attachment is set to Base64Binary. The best part about this whole POC is that by putting our attachment in the Base64Binary data type, all that we need to do is set the encoding on the WCF adapter to MTOM and BizTalk will do all the MTOM work for us. Also in the code below, you will notice that we used Linq to XML. The great part of POC's is that you can play with the new technology and in this case see just how easy it is to put together the XML message. Even though we were playing with Linq, I still needed to pass back an XML Document for the Orchestration to consume.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Drawing;
using System.Xml.Linq;
using Microsoft.Web.Services2.Dime;
using System.IO;
using System.Xml.Serialization;
using System.Xml;

namespace OrchestrationHelper
{
    [Serializable]
    public class OrchestrationHelperWrapper
    {
        MyService.Service svc = new MyService.Service();

        public XmlDocument RetrieveAttachment(int token, string name)
        {
            XElement xmlTree = null;

            int iResult = svc.RetrieveFile(token, name);
            XElement myNode;

           if (iResult == 0) //0 = successful retrieve
                {
                    if (svc.ResponseSoapContext.Attachments.Count > 0)
                    {
                        XNamespace ns = "http://POC.DimeReturnSchema";
                        xmlTree = new XElement(ns + "ReturnedAttachments");
                        XElement xmlAttachments = new XElement("Attachments");
                        xmlTree.Add(xmlAttachments);
                        for (int index = 0; index < svc.ResponseSoapContext.Attachments.Count; index++)
                        {
                            Stream myStream = svc.ResponseSoapContext.Attachments[index].Stream;
                            int length = (int)myStream.Length;

                            byte[] bytes = new byte[length];
                            myStream.Read(bytes, 0, length);

                            myNode = new XElement("Attachment", Convert.ToBase64String(bytes));
                            xmlAttachments.Add(myNode);
                        }
                    }
                }

                XmlDocument xdoc = new XmlDocument();
                xdoc.LoadXml(xmlTree.ToString());

                return xdoc;
        }
    }
}

Back in BizTalk, in our Orchestration, we called the OrchestrationHelper through the ConstructMessage shape and assigned the returned Xml Document to the Orchestration Message. We created a WCF endpoint and selected Mtom encoding on the Binding tab of the WCF Transport Properties dialog.

The best part is that BizTalk automatically encoded anything that was set to Base64Binary to the MTOM format and it can all be done through configuration in the WCF adapter settings. All that we needed to do was to consume the DIME attachment and place it in an element with the right data type.

Exposing Custom WCF Headers through WCF Behaviors - Part 3

Stephen Kaufman — Thu, 25 Jun 2009 03:51:00 GMT

In part 1, I covered how to create a custom behavior to inject headers into the dynamically created WSDL. In part 2, I showed how to either promote or write the header data to the BizTalk context.

What happens if I want different headers for different end points? What if I don't want to create a custom header component for each end point? What if I want to set, through configuration, weather I want to promote or write to the context? What if I want to add a new header item without the need to recompile?

In this part of the series we will look at the ability to create a behavior that exposes the properties through configuration to let you dynamically, per end point, set the header items. The configuration is not through a configuration file but instead will hook into the end point behavior dialog box that appears in the adapter configuration in BizTalk.

The finished configuration will look like this:

Let's start looking at code.

First we are going to look at a new class file that will represent the data that we need to set in the configuration section of the dialog box. The CustomHeader class is where much of the configuration dialog magic happens. The way you define the properties will define the way they appear in the configuration dialog box. If you define your property as a boolean or an enum then it will display as a drop down list box. If you define it as a class then you will get the ellipses.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace Services.WCF.Behavior
{
    public class CustomHeader
    {
        public string Name { get; set; }

        public string Namespace { get; set; }

        public bool Required { get; set; }

        public ContextAction Action { get; set; }
    }
}

Where the ContextAction type is the enum listed below:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace Services.WCF.Behavior
{
    public enum ContextAction
    {
        None = 0,
        Write = 1,
        Promote = 2
    }
}

The CustomHeader class is accessed and 'bound' to the dialog box through the CustomHeaderEndpointBehavior class. This class is just a renamed and modified version of the SoapHeaderEndpointBehavior class we saw in the previous two articles.

using System;
using System.Collections.Generic;
using System.Text;
using System.ServiceModel.Description;
using System.ServiceModel.Configuration;
using System.Configuration;
using System.ServiceModel;

namespace Services.WCF.Behavior
{
    public class CustomHeaderEndpointBehavior : BehaviorExtensionElement, IEndpointBehavior
    {
        #region BehaviorExtensionElement Methods

        public override Type BehaviorType
        {
            get { return typeof(CustomHeaderEndpointBehavior); }
        }

        protected override object CreateBehavior()
        {
            return new CustomHeaderEndpointBehavior(this.Headers);
        }

        //Copies the content of the specified configuration element to this configuration element
        public override void CopyFrom(ServiceModelExtensionElement extFrom)
        {
            base.CopyFrom(extFrom);
            CustomHeaderEndpointBehavior element = extFrom as CustomHeaderEndpointBehavior;
            if (element != null)
            {
                Headers = element.Headers;
            }
        }

        //Both properties are returned as a collection.
        protected override ConfigurationPropertyCollection Properties
        {
            get
            {
                if (_properties == null)
                {
                    _properties = new ConfigurationPropertyCollection();

                    _properties.Add(new ConfigurationProperty("Headers", typeof(List<CustomHeader>), null,
                    new SerializationConverter(typeof(List<CustomHeader>)), null, ConfigurationPropertyOptions.None));
                    base["Headers"] = new List<CustomHeader>();
                }
                return _properties;
            }
        }

        #endregion

        #region IEndpointBehavior Members

        public void AddBindingParameters(ServiceEndpoint endpoint, System.ServiceModel.Channels.BindingParameterCollection bindingParameters)
        {
            bindingParameters.Add(this);
        }

        public void ApplyClientBehavior(ServiceEndpoint endpoint, System.ServiceModel.Dispatcher.ClientRuntime clientRuntime)
        {
            //throw new NotImplementedException();
        }

        public void ApplyDispatchBehavior(ServiceEndpoint endpoint, System.ServiceModel.Dispatcher.EndpointDispatcher endpointDispatcher)
        {
            endpointDispatcher.DispatchRuntime.MessageInspectors.Add(new CustomHeaderMessageInspector());
        }

        public void Validate(ServiceEndpoint endpoint)
        {
            //throw new NotImplementedException();
        }

        #endregion

        #region Class properties
        [ConfigurationProperty("Headers")]
        public List<CustomHeader> Headers
        {
            get
            {
                return (List<CustomHeader>)base["Headers"];
            }
            set
            {
                base["Headers"] = value;
            }
        }

        #endregion

        #region Class Fields
        private ConfigurationPropertyCollection _properties;
        #endregion

        #region Constructors
        public CustomHeaderEndpointBehavior(List<CustomHeader> headers)
        {
            this.Headers = headers;
        }
        public CustomHeaderEndpointBehavior() : base()
        {}

        #endregion
    }
}

First you will notice that there is a number of new methods. The first is the CopyFrom method. This method is needed to copy the contents of the configuration data entered in the dialog box so that we can gain access to it within our class. We then override ConfigurationPropertyCollection since the header properties are returned as a collection. We will add the properties to our internal collection based on the List<CustomHeader> object. We also add the class to the AddBindingParamters method.

One thing to note when creating the configuration class (in our case the CustomHeader class) is that the default behavior of the Transport Properties dialog box and underlying code expects that all configuration information will be of type string. If you are using other types then you need to create your own type converter to convert to a string representation and back. I have the code for the type converter at the bottom of this post called SerializationConverter.

In the code above, in the CustomHeaderEndpointBehavior class, there were a couple of custom objects. The first one we will dig into is in the ApplyDispatchBehavior where we add a new CustomHeaderMessageInspector.

The class implementation for the CustomHeaderMessageInspector looks like:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.ServiceModel.Dispatcher;
using System.Diagnostics;
using System.ServiceModel;
using System.ServiceModel.Channels;
using System.Xml;

namespace Services.WCF.Behavior
{
    class CustomHeaderMessageInspector : IDispatchMessageInspector
    {
        #region IDispatchMessageInspector Members

        public object AfterReceiveRequest(ref System.ServiceModel.Channels.Message request, System.ServiceModel.IClientChannel channel, System.ServiceModel.InstanceContext instanceContext)
        {
            List<KeyValuePair<XmlQualifiedName, object>> writeProps = new List<KeyValuePair<XmlQualifiedName, object>>();
            List<KeyValuePair<XmlQualifiedName, object>> promoteProps = new List<KeyValuePair<XmlQualifiedName, object>>();
            string writeKey = "http://schemas.microsoft.com/BizTalk/2006/01/Adapters/WCF-properties/WriteToContext";
            string promoteKey = "http://schemas.microsoft.com/BizTalk/2006/01/Adapters/WCF-properties/Promote";

            CustomHeaderEndpointBehavior bhv = null;

            if (instanceContext.Host.Description.Endpoints.Find(channel.LocalAddress.Uri) != null)
                bhv = instanceContext.Host.Description.Endpoints.Find(channel.LocalAddress.Uri).Behaviors.Find<CustomHeaderEndpointBehavior>();

            if (bhv != null)
            {
                foreach (CustomHeader hdr in bhv.Headers)
                {
                    int headerPos = OperationContext.Current.IncomingMessageHeaders.FindHeader(hdr.Name, hdr.Namespace);

                    if (headerPos < 0)
                    {
                        if (hdr.Required)
                        {
                            //Fault Condition
                            throw new ArgumentNullException(hdr.Name, "Required soap header not found.");
                        }
                    }
                    else
                    {
                        if (hdr.Action != ContextAction.None)
                        {
                            // Get an XmlDictionaryReader to read the header content
                            XmlDictionaryReader reader = OperationContext.Current.IncomingMessageHeaders.GetReaderAtHeader(headerPos);
                            XmlDocument d = new XmlDocument();

                            d.LoadXml(reader.ReadOuterXml());
                            XmlQualifiedName PropName1 = new XmlQualifiedName(hdr.Name, hdr.Namespace);

                            if (hdr.Action == ContextAction.Write)
                            {
                                writeProps.Add(new KeyValuePair<XmlQualifiedName, object>(PropName1, d.DocumentElement.InnerText));
                            }
                            else if (hdr.Action == ContextAction.Promote)
                            {
                                promoteProps.Add(new KeyValuePair<XmlQualifiedName, object>(PropName1, d.DocumentElement.InnerText));
                            }
                        }
                    }
                }
            }
            else
            {
                //Debug.WriteLine("*****AfterReceiveRequest: No Behavior found of type CustomHeaderEndpointBehavior.*****");
            }

            if (writeProps.Count > 0)
            {
                request.Properties[writeKey] = writeProps;
            }

            if (promoteProps.Count > 0)
            {
                request.Properties[promoteKey] = promoteProps;
            }

            return null;
        }

        public void BeforeSendReply(ref System.ServiceModel.Channels.Message reply, object correlationState)
        {
        }

        #endregion
    }
}

As we look at this code, in the AfterReceiveRequest method we have included both the writeProps and the promoteProps variables as well as both namespaces. We then look in the instanceContext.Host.Description.Endpoints collection to find, within the behaviors collection, our CustomerHeaderEndPointBehavior object. Then we loop through each of the headers that was setup through configuration and look for them in the message headers collection. Finally, check if the header was required and if we need to write or promote the values.

Lastly, here is the code that does our type conversion from the CustomHeader class to a string representation (in our case this will be XML).

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.ComponentModel;
using System.Xml.Serialization;
using System.IO;
using System.Xml;
using System.Globalization;

namespace Services.WCF.Behavior
{
    public class SerializationConverter : TypeConverter
    {
        private Type _type;
        public SerializationConverter(Type type)
        {
            _type = type;
        }

        #region Helper Utilities

        private object Deserialize(object value)
        {
            if (_type == null) throw new ArgumentNullException("", "Serialization type was not set. Use the SerializationConvertor(Type) constructor.");
            return Deserialize(value, _type);
        }

        private object Deserialize(object value, Type destinationType)
        {
            StringReader strRdr = null;
            XmlReader xmlRdr = null;

            try
            {
                if (!(value is string))
                throw new ApplicationException("Expecting parameter 'value' to be of type string. 'Value' is of type " + value.GetType().ToString());

                XmlSerializer serializer = new XmlSerializer(destinationType);
                strRdr = new StringReader(value.ToString());
                xmlRdr = XmlReader.Create(strRdr);

                return serializer.Deserialize(xmlRdr);
            }
            finally
            {
                strRdr.Close();
                xmlRdr.Close();
            }
        }

        private object Serialize(object value)
        {
            StringWriter wtr = null;

            try
            {
                if (value == null)
                throw new ArgumentNullException("value");

                StringBuilder sb = new StringBuilder();
                XmlSerializer serializer = new XmlSerializer(value.GetType());
                wtr = new StringWriter(sb);
                serializer.Serialize(wtr, value);

                return sb.ToString();
            }
            finally
            {
                wtr.Close();
            }
        }

        #endregion

        #region Collection code.
        //Class to string
        public override object ConvertFrom(ITypeDescriptorContext context, CultureInfo culture, object value)
        {
            if (value is string)
            {
                return Deserialize(value);
            }
            else if (value.GetType() == _type)
            {
                return Serialize(value);
            }
            else
            {
                string msg = (_type == null ? "Value is not of type System.string and no type was specified at construction." : "Value is not of type System.string or " + _type.ToString() + ".");
                throw new ApplicationException(msg);
            }
        }

        //String to class
        public override object ConvertTo(ITypeDescriptorContext context, CultureInfo culture, object value, Type destinationType)
        {
            if (value is string)
            {
                return Deserialize(value, destinationType);
            }
            else if (value.GetType() == _type)
            {
                return Serialize(value);
            }
            else
            {
                string msg = (_type == null ? "Value is not of type System.string and no type was specified at construction." : "Value is not of type System.string or " + _type.ToString() + ".");
                throw new ApplicationException(msg);
            }
        }
        #endregion
    }
}

At this point we have all the code that is part of our project. Once this is compiled, we need to add the assembly to the machine config and add it to the BizTalk WCF endpoint. The process to implement this remains the same as that described at the bottom of part 1 of this series.

As always, the code in this post and this series are for reference only and are provided as is. Now that we have that out of the way, I hope that these posts have been helpful and have shown how to deal with header values in the WCF stack and shown the ability to create a behavior that exposes the properties through configuration to let you dynamically, per end point, set the header items.

Exposing Custom WCF Headers through WCF Behaviors - Part 2

Stephen Kaufman — Thu, 11 Jun 2009 07:03:00 GMT

In part 1 we covered how to create a custom behavior to inject header data into the dynamically created WSDL.

In this part we will look at consuming the header data passed in.

By default BizTalk will take any custom header it finds in the incoming WCF message and automatically map them to the Message Context.

If it were really this simple we wouldn't need this posting.

So, what is the issue. The issue is that when BizTalk maps the header to the context it posts an xml fragment. This fragment could certainly be used as is and parsed each time you need to use it but that gets tedious quickly and certainly doesn't do good things to the performance of your solution.

What we need is to be able to parse the key and value of the header data when the message is submitted to BizTalk so that it looks like all of the other context entries (a key and a value pair).

There are a number of options to enable you to do this including creating a pipeline component. We are not going to go that route. Instead, we are going to add code directly to our behavior. I want everything to be encapsulated inside the behavior so that if developers decide to use the behavior they don't have to also remember to place a pipeline in the mix. By having a separate pipeline component we are creating an error prone system that won't be caught until after deployment has occurred.

To promote or write to the context when the message arrives we will modify the AfterReceiveRequest method on the SoapHeaderMessageInspector class. This class was created in Part 1 of this series. If you go back and look at that method you will see that we originally implemented it by returning null.

First lets look at what is required to write or promote to the Message Context in code. MSDN has a sample of how this can be done which I put below.

const string PropertiesToPromoteKey="http://schemas.microsoft.com/BizTalk/2006/01/Adapters/WCF-properties/Promote";
const string PropertiesToWriteKey="http://schemas.microsoft.com/BizTalk/2006/01/Adapters/WCF-properties/WriteToContext";

XmlQualifiedName PropName1=new XmlQualifiedName("Destination", "http://tempuri.org/2007/sample-properties");
XmlQualifiedName PropName2=new XmlQualifiedName("Source", "http://tempuri.org/2007/sample-properties");

//Create a List of KeyValuePairs that indicate properties to be promoted to BizTalk message context. 
//A Property Schema must be deployed and string values have a limit of 256 characters
List<KeyValuePair<XmlQualifiedName, object>> promoteProps=new List<KeyValuePair<XmlQualifiedName, object>>();
promoteProps.Add(new KeyValuePair<XmlQualifiedName, object>(PropName1, "Property value"));
wcfMessage.Properties[PropertiesToPromoteKey]=promoteProps;

//Create a List of KeyValuePairs that indicate properties to be written to BizTalk message context
List<KeyValuePair<XmlQualifiedName, object>> writeProps=new List<KeyValuePair<XmlQualifiedName, object>>();
writeProps.Add(new KeyValuePair<XmlQualifiedName, object>(PropName2, "Property value"));
wcfMessage.Properties[PropertiesToWriteKey]=writeProps;

We are going to use this code but will format it a bit differently. As I said earlier we need to modify the AfterReceiveRequest method to incorporate this code.

Our method implementation will look like:

public object AfterReceiveRequest(ref System.ServiceModel.Channels.Message request, System.ServiceModel.IClientChannel channel, System.ServiceModel.InstanceContext instanceContext)
{
    List<KeyValuePair<XmlQualifiedName, object>> writeProps = new List<KeyValuePair<XmlQualifiedName, object>>();
    const string PropertiesToWriteKey = "http://schemas.microsoft.com/BizTalk/2006/01/Adapters/WCF-properties/WriteToContext";

    Int32 headerPosition = OperationContext.Current.IncomingMessageHeaders.FindHeader(SoapHeaderNames.SoapHeaderName, SoapHeaderNames.SoapHeaderNamespace);

    if (headerPosition < 0)
    {
        //Fault Condition
        throw new ArgumentNullException(SoapHeaderNames.SoapHeaderNamespace + "#" + SoapHeaderNames.SoapHeaderName, "SoapHeader not found.");
    }

    // Get an XmlDictionaryReader to read the header content
    XmlDictionaryReader reader = OperationContext.Current.IncomingMessageHeaders.GetReaderAtHeader(headerPosition);
    XmlDocument d = new XmlDocument();

    d.LoadXml(reader.ReadOuterXml());

    foreach (XmlNode node in d.DocumentElement.ChildNodes)
    {
        if ((node.Name.ToLower().Equals(SoapHeaderNames.AppName.ToLower()) || node.Name.ToLower().Equals(SoapHeaderNames.UserName.ToLower())) && String.IsNullOrEmpty(node.InnerText))
        {
            throw new ArgumentNullException(node.Name, "Header value cannot be null.");
        }

        XmlQualifiedName PropName1 = new XmlQualifiedName(node.Name, SoapHeaderNames.SoapHeaderNamespace);
        writeProps.Add(new KeyValuePair<XmlQualifiedName, object>(PropName1, node.InnerText));
    }

    if (writeProps.Count > 0)
    {
        request.Properties[PropertiesToWriteKey] = writeProps;
    }

    return null;
}

This code shows how we can select and read the header, and then loop through each element in the header and promote it.

In order to promote properties into the context you need to have a property schema. We took the SoapHeader.xsd that we created in Part 1 of this post and used that for our property schema.

When we take a look at the content of the incoming message after compiling and deploying our changes we can now see that our key name appears under the Name column and our value appears under the Value column of the Context dialog box. We no longer have an xml fragment and no longer have to deal with the need to parse the fragment each time we want to use it. Now that we have this data in the context we can utilize it in the same we would with any other data that appears in the context. The best part is that it was all done in one location, through one artifact, and won't require the developer to remember to utilize another artifact to make the solution work.

In the next post, we will cover the ability to create a behavior that exposes the properties through configuration to let you dynamically, per end point, set the header items as well as determine whether you want the values written or promoted dynamically as well.

Exposing Custom WCF Headers through WCF Behaviors

Stephen Kaufman — Sat, 30 May 2009 00:28:00 GMT

Since the WCF Publishing Wizard in BizTalk does not support adding custom headers defined at the server, we need to programmatically modify what gets created by the wizard to add custom headers. However, from the client you have the option to pass in header values at will. If you are passing in headers generated at the client BizTalk will take them and map them to the context. However, they show up as an XML fragment and not as individual data items. It becomes annoying to constantly parse the fragment each and every time you want to get to the data.

What we are really interested in is the ability to expose the end point with the header values already defined, accept the header values from the client and either promote or write the values to the context and lastly, be able to create a behavior that you can attach to your WCF endpoint that exposes the properties through configuration to let you dynamically, per end point, set the header items and what you want to do with them as they are submitted. This will be a three part posting with a post covering each of these features.

For this first post, we will focus on the ability to expose the end point with the header values already defined. What makes this even more interesting is that there is no WSDL file as this gets generated dynamically when you access the SVC file. If you wish you can create a static WSDL file and then use the externalMetadataLocation attribute of the element in the Web.config file that the wizard generates to specify the location of the WSDL file. Then the static WSDL file will be sent to the user in response to WSDL and metadata exchange (MEX) requests instead of the auto-generated WSDL.

In our solution, we did not want to have to create WSDL files for each of our endpoints, nor did we want to maintain them. We needed a way to hook in to the dynamic WSDL creation process.

There are a number of posts out there that talk about this but after reviewing them I found that none of them gave the whole picture. They were all very good and they provided enough information to fill in many missing pieces but there was enough missing that I though it warranted looking at the whole picture.

We are going to start by creating our own EndPointBehavior. The EndPointBehavior allows us to inject custom functionality in the WCF execution pipeline.

To create the EndPointBehavior we need to create a solution that references System.ServiceModel.dll and includes a class that derives from BehaviorExtensionElement, IWsdlExportExtension and IEndpointBehavior. We need the functionality of the BehaviorExtensionElement to implement the configuration of the behavior, the functionality of the IWsdlExportExtension to change the generated WSDL and the functionality of the IEndPointBehavior to define the endpoint and its behavior.

Lets add a class file to our solution called SoapHeaderEndpointBehavior. After we create the class and inherit from our objects we need to add the following line of code to the ExportEndPoint method

SoapHeaderWsdlExport.ExportEndpoint(exporter,context);

and we need to add the following two lines of code to the ApplyDispatchBehavior method.

SoapHeaderMessageInspector headerInspector = new SoapHeaderMessageInspector();
endpointDispatcher.DispatchRuntime.MessageInspectors.Add(headerInspector);

Our code should look like this:

using System;
using System.Collections.Generic;
using System.Collections;
using System.Configuration;
using System.Runtime.Serialization;
using System.ServiceModel;
using System.ServiceModel.Channels;
using System.ServiceModel.Configuration;
using System.ServiceModel.Description;
using System.ServiceModel.Dispatcher;
using System.Text;
using System.Xml;
using System.Xml.Schema;
using System.Web.Services;
using System.Web.Services.Description;
using WsdlDescription = System.Web.Services.Description.ServiceDescription;

namespace Services.WCF.ServiceBehavior
{
    public class SoapHeaderEndpointBehavior : BehaviorExtensionElement, IWsdlExportExtension, IEndpointBehavior
    {
        #region BehaviorExtensionElement Members

            public override Type BehaviorType
            {
                get
                {
                    return typeof(SoapHeaderEndpointBehavior);
                }
            }

            protected override object CreateBehavior()
            {
                return new SoapHeaderEndpointBehavior();
            }
        #endregion

        #region IWsdlExportExtension Members

            public void ExportContract(WsdlExporter exporter, WsdlContractConversionContext context)
            {
                //throw new NotImplementedException();
            }

            public void ExportEndpoint(WsdlExporter exporter, WsdlEndpointConversionContext context)
            {
                SoapHeaderWsdlExport.ExportEndpoint(exporter,context);
            }

        #endregion

        #region IEndpointBehavior Members

            public void AddBindingParameters(ServiceEndpoint endpoint, BindingParameterCollection bindingParameters)
            {
                //throw new NotImplementedException();
            }

            public void ApplyClientBehavior(ServiceEndpoint endpoint, ClientRuntime clientRuntime)
            {
                //throw new NotImplementedException();
            }

            public void ApplyDispatchBehavior(ServiceEndpoint endpoint, EndpointDispatcher endpointDispatcher)
            {
                SoapHeaderMessageInspector headerInspector = new SoapHeaderMessageInspector();
                endpointDispatcher.DispatchRuntime.MessageInspectors.Add(headerInspector);
            }

            public void Validate(ServiceEndpoint endpoint)
            {
               //throw new NotImplementedException();
            }

        #endregion
    }
}

When we added code to the ExportEndpoint method, we utilized a custom object. Let's add another class to our solution to implement the SoapHeaderWsdlExport. This class will add a header schema and its namespace, create and add a header message description and finally add the header to the operation.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Xml.Schema;
using System.Reflection;
using System.Web.Services.Description;
using System.Xml;
using System.ServiceModel.Description;
using WsdlDescription = System.Web.Services.Description.ServiceDescription;

namespace Services.WCF.ServiceBehavior
{
    class SoapHeaderWsdlExport
    {
        public static void ExportEndpoint(WsdlExporter exporter, WsdlEndpointConversionContext context)
        {
            // Read the schema of the custom header message
            XmlSchema customSoapHeaderSchema = XmlSchema.Read(Assembly.GetExecutingAssembly().GetManifestResourceStream("Services.WCF.ServiceBehavior.SoapHeader.xsd"),
                new ValidationEventHandler (SoapHeaderWsdlExport.ValidationCallBack));

            // Create the HeaderMessage to add to wsdl:message AND to refer to from wsdl:operation
            System.Web.Services.Description.Message headerMessage = CreateHeaderMessage();

            foreach (WsdlDescription wsdl in exporter.GeneratedWsdlDocuments)
            {
                // Add the schema of the CustomSoapHeader to the types AND add the namespace to the list of namespaces
                wsdl.Types.Schemas.Add(customSoapHeaderSchema);
                wsdl.Namespaces.Add("sh", SoapHeaderNames.SoapHeaderNamespace);

                // The actual adding of the message to the list of messages
                wsdl.Messages.Add(headerMessage);
            }

            addHeaderToOperations(headerMessage, context);
        }

        private static System.Web.Services.Description.Message CreateHeaderMessage()
        {
            // Create Message
            System.Web.Services.Description.Message headerMessage = new System.Web.Services.Description.Message();

            // Set the name of the header message
            headerMessage.Name = SoapHeaderNames.SoapHeaderName;

            // Create the messagepart and add to the header message
            MessagePart part = new MessagePart();
            part.Name = "Header";
            part.Element = new XmlQualifiedName(SoapHeaderNames.SoapHeaderName, SoapHeaderNames.SoapHeaderNamespace);
            headerMessage.Parts.Add(part);

            return headerMessage;
        }

        private static void addHeaderToOperations(System.Web.Services.Description.Message headerMessage, WsdlEndpointConversionContext context)
        {
            // Create a XmlQualifiedName based on the header message, this will be used for binding the header message and the SoapHeaderBinding
            XmlQualifiedName header = new XmlQualifiedName(headerMessage.Name, headerMessage.ServiceDescription.TargetNamespace);

            foreach (OperationBinding operation in context.WsdlBinding.Operations)
            {
                // Add the SoapHeaderBinding to the MessageBinding
                ExportMessageHeaderBinding(operation.Input, context, header, false);
                ExportMessageHeaderBinding(operation.Output, context, header, false);
            }
        }

        private static void ExportMessageHeaderBinding(MessageBinding messageBinding, WsdlEndpointConversionContext context, XmlQualifiedName header, bool isEncoded)
        {
            // For brevity, assume Soap12HeaderBinding for Soap 1.2
            SoapHeaderBinding binding = new Soap12HeaderBinding();
            binding.Part = "Header";
            binding.Message = header;
            binding.Use = isEncoded ? SoapBindingUse.Encoded : SoapBindingUse.Literal;

            messageBinding.Extensions.Add(binding);
        }

        private static void ValidationCallBack(object sender, ValidationEventArgs args)
        {
            if (args.Severity == XmlSeverityType.Warning)
                Console.WriteLine("\tWarning: Matching schema not found. No validation occurred." + args.Message);
            else
                Console.WriteLine("\tValidation error: " + args.Message);

        }

    }
}

In the addHeaderToOperations method there are two calls to the ExportMessageHeaderBinding method. The second call passes the operation.Output parameter which will pass the header back to the calling application with the response message. This also also means that the method signature at the client will be to pass in the header object by Ref. Since we needed the client to pass the header data into BizTalk we didn't need to echo the header back to the client so we deleted this line. If you want to echo it back then keep this line (as shown in the code above).

Also, in the code above, in the ExportEndpoint and CreateHeaderMessage methods there was another custom class called SoapHeaderNames. This class contained the values that we wanted to place in the custom header. By creating a class for this data we could limit the location of this information to one location. The code for the SoapHeaderNames class looks like this:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace Services.WCF.ServiceBehavior
{
    public static class SoapHeaderNames
    {
        public const String SoapHeaderName = "SoapHeader";

        public const String AppName = "App";
        public const String UserName = "User";

        public const String SoapHeaderNamespace = http://servicebehavior.mycompany.com;
    }
}

Way back at the top, in the ApplyDispatchBehavior method of the SoapHeaderEndpointBehavior class we have a custom object called SoapHeaderMessageInspector. Therefore, let's add another class for the SoapHeaderMessageInspector. There are two methods that we must implement on the IDispatchMessageInspector and they are the AfterReceiveRequest and the BeforeReceiveRequest. Since we are interested in applying the headers in the dynamic WSDL we will only need code in the BeforeReceiveRequest. The code will look like this:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.ServiceModel.Dispatcher;
using System.ServiceModel;
using System.Xml;

namespace Services.WCF.ServiceBehavior
{
    class SoapHeaderMessageInspector: IDispatchMessageInspector
    {

        #region IDispatchMessageInspector Members

            public object AfterReceiveRequest(ref System.ServiceModel.Channels.Message request, System.ServiceModel.IClientChannel channel, System.ServiceModel.InstanceContext instanceContext)
            {
                return null;
            }

            public void BeforeSendReply(ref System.ServiceModel.Channels.Message reply, object correlationState)
            {
                // Look for my custom header in the request
                Int32 headerPosition = OperationContext.Current.IncomingMessageHeaders.FindHeader(SoapHeaderNames.SoapHeaderName, SoapHeaderNames.SoapHeaderNamespace);

                // Get an XmlDictionaryReader to read the header content
                XmlDictionaryReader reader = OperationContext.Current.IncomingMessageHeaders.GetReaderAtHeader(headerPosition);

                // Read through its static method ReadHeader
                SoapHeader header = SoapHeader.ReadHeader(reader);

                if (header != null)
                {
                    // Add the header from the request
                    reply.Headers.Add(header);
                }
            }

        #endregion
    }
}

This code grabs the header section and will inject the header elements. In the BeforeSendReply method you will see we are using a SoapHeader object. This object contains the properties and methods to deal with the elements that we will be reading and writing to the header.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Xml;
using System.ServiceModel.Channels;

namespace Services.WCF.ServiceBehavior
{
    [Serializable]
    public class SoapHeader: MessageHeader
    {
        private string _app;
        private string _user;

        public string App
        {
            get
            {
                return (this._app);
            }
            set
            {
                this._app = value;
            }
        }

        public string User
        {
            get
            {
                return (this._user);
            }
            set
            {
                this._user = value;
            }
        }

        public SoapHeader()
        {
        }

        public SoapHeader(string app, string user)
        {
            this._app = app;
            this._user = user;
        }

        public override string Name
        {
            get { return (SoapHeaderNames.SoapHeaderName); }
        }

        public override string Namespace
        {
            get { return (SoapHeaderNames.SoapHeaderNamespace); }
        }

         protected override void OnWriteHeaderContents(System.Xml.XmlDictionaryWriter writer, MessageVersion messageVersion)
        {
            // Write the content of the header directly using the XmlDictionaryWriter
            writer.WriteElementString(SoapHeaderNames.AppName, this.App);
            writer.WriteElementString(SoapHeaderNames.UserName, this.User);
        }

        public static SoapHeader ReadHeader(XmlDictionaryReader reader)
        {
            String app = null;
            String user = null;

            // Read the header content (key) using the XmlDictionaryReader
            if (reader.ReadToDescendant(SoapHeaderNames.AppName, SoapHeaderNames.SoapHeaderNamespace))
            {
                app = reader.ReadElementString();
            }

            if (reader.ReadToDescendant(SoapHeaderNames.UserName, SoapHeaderNames.SoapHeaderNamespace))
            {
                user = reader.ReadElementString();
            }

            if (!String.IsNullOrEmpty(app) && !String.IsNullOrEmpty(user))
            {
                return new SoapHeader(app, user);
            }
            else
            {
                return null;
            }
        }

    }
}

There is also a schema, called SoapHeader.xsd, that needs to be added to the project as well. This schema defines the message contract for the header and is referenced and used in the ExportEndpoint method of the SoapHeaderWsdlExport class and looks like this:

<?xml version="1.0" encoding="utf-16"?>
<xs:schema xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:b="http://schemas.microsoft.com/BizTalk/2003" xmlns="http://servicebehavior.mycompany.com" attributeFormDefault="unqualified" elementFormDefault="qualified" targetNamespace="http://servicebehavior.mycompany.com" xmlns:xs="http://www.w3.org/2001/XMLSchema">
    <xs:element name="SoapHeader">
        <xs:complexType>
            <xs:sequence>
                <xs:element name="App" type="xs:string" />
                <xs:element name="User" type="xs:string" />
            </xs:sequence>
        </xs:complexType>
    </xs:element>
</xs:schema>

At this point we have all the code that is part of our project. Once this is compiled, we need to add the assembly to the machine config.

There is an easy way to add entries by using the SvcConfigEditor.exe tool. This tool is part of the Windows SDK and, if installed, can be found in the \Program Files\Microsoft SDKs\Windows\v6.0A\Bin directory.

Once this utility is open you can click on the File ->Open->Config File menu item. Open the machine.config file. At the bottom of the tree view on the left side you will see an Advanced folder. Expand that node and expand the the Extensions folder. Click on the the 'behavior element extensions' node. At the bottom right, click on the new button. This will bring up the Extension Configuration Element Editor dialog box. Enter the name you wish to give to your extension and then click on the ellipses next to type. This will bring up the Type Browser dialog box. Browse to your component (also note that you can select assemblies already placed in the GAC). Once selected, your fully qualified assembly name will be entered. Select Save under the File menu. You are now ready to start using the new behavior.

Up to this point everything we have done has been specifically WCF functionality. The next paragraph will outline how we can utilized this behavior in a BizTalk WCF endpoint.

Create a WCF endpoint in BizTalk (if you need more information on creating a WCF endpoint check out the docs on MSDN (Insert Link)). One thing to keep in mind is that when you create a WCF end point in BizTalk using one of the standard bindings you will not have the option to specify a behavior. In order to specify a behavior you need to specify either the WCF-Custom or WCF-CustomIsolated binding. Once you select the binding type, click on the Configure button and the Transport Properties dialog will appear. Select the Behavior tab and then right click on the the Endpoint Behavior node. Once the popup menu appears, select Add extension. Select your behavior from the Select Behavior Extensions dialog box and click OK. Enter the rest of the specific information you need for the end point and click OK to save your endpoint.

We have now done everything that is needed to create a custom behavior including the ability to link into the dynamic WSDL creation process at run time, register the behavior and finally to use the behavior.

Now, when you create a client against the end point you will see that there will be two parameters for the web method call. The first will be the custom header and the second will be the message body. When we look in the object browser for the header object we will see that the two items appear that we defined in our behavior.

As I said at the beginning of this post, this will be a three part series. What we have not covered is the ability to accept these header values from the client and promote or write the values to the context (part 2) and we have not covered the ability to create a behavior that exposes the properties through configuration to let you dynamically, per end point, set the header items (part 3).

Pro BizTalk 2009 Book

Stephen Kaufman — Thu, 07 May 2009 08:56:00 GMT

I have just submitted my chapters for the new Pro BizTalk 2009 book from APress. You can also find information about the book on Amazon.

I am co-authoring along with George Dunphy, Harold Campos, Peter Kelcey, Sergei Moukhnitski and David Peterson.

The book will be available this summer.

I will be speaking at TechEd 2009

Stephen Kaufman — Thu, 19 Mar 2009 04:30:00 GMT

I will be speaking at TechEd 2009 in Los Angeles.

I will be presenting two sessions and doing demos at a third.

My first presentation will be on 'Application Lifecycle Management Experience for BizTalk Server 2009 Developers'.

My second presentation will be a 'Deep Dive with Microsoft BizTalk Server 2009 Development Platform'.

The demo will be done with Danny Garber and will demo an application featuring the new capabilities of BizTalk Server 2009, Windows Azure Service Platform, the Live Framework, .NET Services, the new ESB Guidance v2.0 and the new Managed Services Engine (MSE) 7.0

If you are going to be there stop by and say hello.