Practicing Patterns

Announcing the Enterprise Library Integration Pack for Windows Azure

noreply@blogger.com (Erwin van der Valk) — Wed, 21 Dec 2011 14:22:00 +0000

Last week, we released a new integration pack for Enterprise Library, specifically targeting Windows Azure.

Most of Enterprise Library just works on Windows Azure so the focus for this integration pack was to add support for additional azure specific scenarios by providing two additional blocks:

· Autoscaling application block (codename WASABI)

· Transient Fault Handling Application Block (codename TOPAZ)

Tailspin Surveys reference implementation

To demonstrate the Windows Azure Integration Pack in a real world like application, we extended an existing reference implementation called Tailspin Surveys to now use Enteprise Library.

Tailspin Surveys is a multi-tenant cloud application that allows tenants to create surveys and analyze survey results. To accommodate fluctuations in load, that’s inherit to such applications, the tailspin surveys application uses the Enterprise Library Autoscaling Application Block to adjust the number of instances to accommodate the load.

Tailspin IT Operators can use the management application to monitor the Tailspin Surveys application and adjust the autoscaling rules.

Wasabi can gather a lot of information about the target environment, such as performance counter values, log messages etc. By turning this information into a graphical display, you can easily see how the load progressed over time and how the number of instances has been adjusted to accommodate these fluctuations.

For example, you can see the number of instances as it changes over time. You can also see when the number of instances was adjusted.

When you click on a scaling event, you can see all the log messages associated with that scaling event. For example, which rules were considered and which rule finally caused the scaling event.

You can also see the values for all the metrics that are gathered. For example, if you decide to monitor the CPU levels, memory pressure and queue lengths, you can see the values for these metrics as they change over time. This allows you to gain insight into how the load of your application progresses over time.

Running the Tailspin reference application.

The Autoscaling block doesn’t work against the development fabric. You can’t autoscale your development environment. So the most realistic way of exploring the Tailspin reference application is to deploy the application to Azure and actually run it there. There is an extensive installation document in the developer guide: http://go.microsoft.com/fwlink/?LinkID=234660

However, if you don’t wish to run it in the cloud, you can also run it in simulated mode. In simulated mode, the autoscaling application block is hosted in memory in the management web application and all the data that the autoscaling application block uses is also stored in memory. The interactions with the Windows Azure Management API are simulated.

Simulated mode allows you to play with the management application, without having to deploy it. You can edit rules, simulate load and then see the results reflected in the graphs.

Windows Azure Autoscaling Block Beta out now

noreply@blogger.com (Erwin van der Valk) — Fri, 14 Oct 2011 08:07:00 +0000

Today, we shipped the Beta for the first new block in the Enterprise Library Windows Azure Integration Pack, called the Windows Azure Autoscaling Block.

This block allows you to use your Windows Azure instances more effectively by automatically scaling or changing your applications configuration as the load changes.

By providing a set of configurable rules, you can closely control how your application should handle varying levels of load. For example, you can have the autoscaling block monitor several metrics, such as the CPU level and memory usage of your web roles, or the number of messages in a Queue and increase or decrease the number of instances when certain threshold values are exceeded.

There are basically 2 types of rules you can configure:

Constraint rules, which set explicit boundaries on the number of instances. These rules guard your SLA (by ensuring there is a minimum number of instances) and your wallet (to ensure there will never be more than the maximum number of instances).
Reactive rules, which monitor a set of metrics (such as performance counters) and take actions when threshold values are exceeded.

The autoscaling block supports a new concept, called Application Throttling. This feature allows you to switch to define several modes of operation in your application and switch between these modes as the load of your application varies. For example, you can create a rich and a lightweight version of your application. When the load increases beyond certain threshold values, you can automatically switch to the lightweight version of your application.

The Enterprise Library Windows Azure Integration Pack Beta also ships with a reference implementation, called Tailspin Surveys. This example application has been used by other patterns & practices projects in the past and has now been adapted do demonstrate features from the Enterprise Library Azure Integration Pack.

The Tailspin Surveys reference implementation contains:

A sample rule editor, which can be used to edit the rules configuration file.
A sample service information editor, which can be used to edit the service information file that describes your windows azure environment.
Monitoring through several graphs, that allows you to visualize the information gathered by the autoscaling block. For example, you can see the actual, minimum and maximum number of instances as it changes over time. You will also see the scaling actions and be able to retrieve detailed log messages explaining which rules triggered the scaling actions.

A sample Log viewer, that provides a more readable way to view the log messages generated by the autoscaling block.
A sample load generator, which simulates load on the application and easily allows you to see the autoscaling block in action.

For more information about the Windows Azure Autoscaling Block, check out the public anouncement, or grab the binaries from codeplex.

Enterprise Library Azure Integration Pack Public Feature Voting

noreply@blogger.com (Erwin van der Valk) — Wed, 20 Jul 2011 06:55:00 +0000

Hi All!

Patterns & practices is about to start a new Enterpise Library Integration pack, called the Azure Integration Pack. The goal of this integration pack is to make developing enterprise scale applications on Windows Azure easier by either modifying the current application blocks, or by creating new application blocks.

Since we only want to address problems that you as a developer are facing right now, we need your input!

Your opinion matters!

Go to http://entlib.uservoice.com. On this website, you’ll find a list of all the stories that we are thinking of addressing. You can vote for your favorite stories or even submit stories of your own. We’ll do our best to address the stories with the most votes. On this website, you’ll get (only) 20 votes to do with as you please, so use them wisely.

This is a great opportunity to influence the direction for the Azure Integration Pack, so I’d say: Happy voting!

Enterprise Library 5.0 Windows Azure Integration pack coming

noreply@blogger.com (Erwin van der Valk) — Mon, 27 Jun 2011 19:49:00 +0000

I’m working for patterns & practices again! Though this time as a freelancer!

Right now, we’re starting work on the Enteprise Library 5.0 Windows Azure Integration Pack!

Windows Azure integration pack

Enterprise Library 5.0 already works very well in Windows Azure. Most of the blocks can easily be used within Windows Azure.

The Goal for the Windows Azure Integration Pack is to adapt Enterprise Library to support many Azure only scenario’s. This might mean making changes to the current blocks, but also creating new blocks.

We’re still figuring out which scenario’s the Azure Integration Pack should support. And you can help us to frame this effort.

Your input is welcome

We have created a survey to determine how you are using Windows Azure and how Enteprise Library can help you to build even better Azure applications.

Go to the survey!

The plans for the near future

In the near future, we’ll put up a list of scenario’s and user stories that Enteprise Library so you can vote on their priorities.

SharePointServiceLocator + Unity

noreply@blogger.com (Erwin van der Valk) — Mon, 26 Apr 2010 13:50:00 +0000

I Love dependency Injection. It’s a great technique that can help you to build flexible and testable applications.

The SharePoint Service Locator

When I was working on the SharePoint Guidance v2 at patterns & practices, I also worked on something called the SharePointServiceLocator.

The SharePoint Guidance Library includes an implementation of the service locator pattern named the SharePoint service locator. The SharePoint service locator is a reusable component that you can include in your own SharePoint applications. It allows you to decouple consumers of an interface from the implementations of that interface. Instead of creating an object by invoking the constructor of a class, you request an object with a specified interface from the service locator. Decoupling your code from a concrete implementation makes your code easier to test and more modular.

The SharePoint ServiceLocator is a very handy component that allows you to achieve Inversion of Control. But it’s not a dependency Injection container such as Microsoft Unity.

When I was building the SharePoint ServiceLocator, I really wanted to use Microsoft Unity for it. Microsoft Unity is a great Dependency Injection Container. However, at that time, our advisors recommended that we should NOT use Unity, because it is quite complex. The advisors worried that most SharePoint developers would have a hard time understanding Unity.

The problem here is obviously, if you are unfamiliar with dependency injection as a technique, then using a very simple service locator is already a big step. However, if you are comfortable with dependency injection, then you can’t live without the capabilities that such a component provides.

Plugging Unity into the SharePoint ServiceLocator

When I was building the SharePoint ServiceLocator, I did keep in mind that someday I’d like to plug in a different dependency injection container, such as Unity. Now that I’m working for a company that’s actually using the SharePoint Guidance, I figured it would be time to create the components required to plug in Unity as a Dependency Injection Container.

Below is a diagram that describes the design of the SharePoint ServiceLocator:

As you can see, the SharePoint ServiceLocator is not the actual ServiceLocator…. It’s more of a ServiceLocatorLocator, but that name just sounds silly. But it does locate the actual ServiceLocator for you, which by default is the ActivatingServiceLocator.

Now what we want to do, is use Unity instead of using the Activating ServiceLocator. To do that, we need to create two components:

UnityServiceLocatorAdapter

The Unity container does not implement the IServiceLocator interface. This interface comes from the Common ServiceLocator project and has the goal to create a common interface that library builders can use abstract away dependencies from a specific DI container. So what we need, is an adapter that adapts Unity to the IServiceLocator interface. And the nice thing is.. that component already exists here.

But for completeness, here’s the source code for that:

        1: /// <summary>

       2: /// Adapter that maps Unity to the Commmon Service Locator interface <see cref="IServiceLocator"/>

       3: /// </summary>

       4: public class UnityServiceLocatorAdapter : ServiceLocatorImplBase

       5: {

       6:     private readonly IUnityContainer _unityContainer;

       7:  

       8:     /// <summary>

       9:     /// Creates an instance of the service locator

    /// </summary>

    /// <param name="unityContainer"></param>

    public UnityServiceLocatorAdapter(IUnityContainer unityContainer)

    {

        _unityContainer = unityContainer;

    }

  

    /// <summary>

    /// The unity container that's used by this adapter

    /// </summary>

    public IUnityContainer UnityContainer

    {

        get { return _unityContainer; }

    }

  

    /// <summary>

    ///             When implemented by inheriting classes, this method will do the actual work of resolving

    ///             the requested service instance.

    /// </summary>

    /// <param name="serviceType">Type of instance requested.</param>

    /// <param name="key">Name of registered service you want. May be null.</param>

    /// <returns>

    /// The requested service instance.

    /// </returns>

    protected override object DoGetInstance(Type serviceType, string key)

    {

        return UnityContainer.Resolve(serviceType, key);

    }

  

    /// <summary>

    ///             When implemented by inheriting classes, this method will do the actual work of

    ///             resolving all the requested service instances.

    /// </summary>

    /// <param name="serviceType">Type of service requested.</param>

    /// <returns>

    /// Sequence of service instance objects.

    /// </returns>

    protected override IEnumerable<object> DoGetAllInstances(Type serviceType)

    {

        return UnityContainer.ResolveAll(serviceType);

    }

}

Note that this class derrives from ServiceLocatorImplBase, which comes from the Microsoft.Practices.ServiceLocation.dll assembly (the common servicelocator project).

UnityServiceLocatorFactory

Secondly, we need a component that can acually create the UnityServiceLocatorAdapter and fill it with the typemappings that are stored in Config.

Here’s the source code for that component:

       1: /// <summary>

       2: /// Factory that can create the unity service locator and fill it with typemappings

       3: /// </summary>

       4: public class UnityServiceLocatorFactory : IServiceLocatorFactory

       5: {

       6:     /// <summary>

       7:     /// Create the service locator

       8:     /// </summary>

       9:     /// <returns></returns>

    public IServiceLocator Create()

    {

        return new UnityServiceLocatorAdapter(new UnityContainer());

    }

  

    /// <summary>

    /// Load typemappings into the service locator

    /// </summary>

    /// <param name="serviceLocator">The service lcoator to load typemappings into</param>

    /// <param name="typeMappings">The typemappings to load</param>

    public void LoadTypeMappings(IServiceLocator serviceLocator, IEnumerable<TypeMapping> typeMappings)

    {

        if (serviceLocator == null) throw new ArgumentNullException("serviceLocator");

        if (typeMappings == null) throw new ArgumentNullException("typeMappings");

  

        var unityServiceLocator = serviceLocator as UnityServiceLocatorAdapter;

        if (null == unityServiceLocator) throw new ArgumentException("ServiceLocator must be of type UnityServiceLocatorAdapter", "serviceLocator");

  

        IUnityContainer container = unityServiceLocator.UnityContainer;

  

        foreach(TypeMapping mapping in typeMappings)

        {

            Type fromType = GetTypeFromStrings(mapping.FromAssembly, mapping.FromType);

            Type toType = GetTypeFromStrings(mapping.ToAssembly, mapping.ToType);

  

            if (fromType == null)

            {

                throw new InvalidOperationException(string.Format(CultureInfo.InvariantCulture, "Could not get type for '{0}'", mapping.FromType));

            }

  

            if (toType == null)

            {

                throw new InvalidOperationException(string.Format(CultureInfo.InvariantCulture, "Could not get type for '{0}'", mapping.ToType));

            }

  

  

            container.RegisterType(fromType, toType);

        }

    }

  

    private static Type GetTypeFromStrings(string assemblyName, string typeName)

    {

        Assembly assembly = Assembly.Load(assemblyName);

        return assembly.GetType(typeName, true, false);

    }

}

Configuring the SharePoint ServiceLocator to use the new factory

Now that we have both the factory and the adapter, we need a way to tell the SharePointServiceLocator to actually use these components. You simply do that by registering a typemapping between the IServiceLocatorFactory and the UnityServiceLocatorFactory from a farm scoped feature receiver, like this:

new ServiceLocatorConfig()
    .RegisterTypeMapping<IServiceLocatorFactory, UnityServiceLocatorFactory>();

Changes you’ll have to make to the SharePoint Guidance Library

When we built the functionality to plug in different service locators, we tested of course if you could actually plug in a different service locator. And you can.. which is nice. However, we never had the time to actually create this Unity plugin. And since we never tried this.. it doesn’t work nicely out of the box.

So you’ll have to make 2 small changes to the library to get it to work nicely.

The first change I made is to remove the new() operator from all generic methods that create or register typemapings, such as the ServiceLocatorConfig.RegisterTypeMapping or TypeMapping.Create<>() methods. The new() operator defines that all physical classes that are used as typemappings have a default constructor. This seemed like a good idea with the ActivatingServiceLocator, but with unity, I like to use constructor injection, so the new() operator doesn’t make sense.

The second change was in the TypeMappings.Create<> method. I changed the ToType from the AssemblyQualifiedName of a type to the Full typename of a type. For some reason, on my machine, using the AssemblyQualifiedName doesn’t work. I don’t know what the reason for this is.. but using the Full typename works. So that’s something else I changed.

Hope you’ll find this useful.

_Erwin

Devdays 2010 - Vote for me!

noreply@blogger.com (Erwin van der Valk) — Thu, 04 Feb 2010 15:30:00 +0000

Hi all..

I'm not opposed to fair elections, but a bit of campaigning never hurts. ;)

I've proposed 2 WildCard sessions for the dutch DevDays Convention, next may. Now I'd love to present there, but as of today, i'm a bit back in the polls.

So I'd like to ask

Even if you can't make it...
Even if you don't live in The Netherlands..
Even if you don't want anything to do with IT, computer programming or anything like it..

Your life will be (ever so slightly) better if I get to present there! So hereby a call to action! Please vote for my sessions at:

http://www.devdays.nl/WildCardSessions.aspx?pid=69&lang=nl

I'll be forever grateful (and hopefully blog a bit more in the future)

take care!
Erwin

First Post

noreply@blogger.com (Erwin van der Valk) — Thu, 14 Jan 2010 08:55:00 +0000

Hi all,

Since I've left patterns & practices at Microsoft and started my new position as principal architect at Achmea in The Netherlands, I needed to find a new place to host my blog. This is where I'm hoping to continue blogging for the foreseeable future.

My old blog will still be available at http://blogs.msdn.com/erwinvandervalk.

Hope you enjoy my blog!
Take care and keep practicing,

Erwin