Mauro and the sustainable development

Expanding Radical IoC/DI support

2013-05-22T09:30:00.000+02:00

We are pretty proud of the work we are doing with Radical and now we are even pretty happy with the overall architecture of the whole toolkit. The reason is pretty simple we have decided (due to some requests) to add support for 2 new Inversion of Control containers: Autofac and Unity.

We are proud because it has been a really easy task, that does not require any change to the toolkit proving that the architectural choices made some years ago to isolate the IoC infrastructure were pretty good choices.

We have now support for: Windsor, Puzzle (Radical built-in IoC container), Autofac and Unity (both v2 and v3).

Nuget packages:

NServiceBus: error queues

2013-05-06T15:08:00.000+02:00

NServiceBus has the concept of error queue, that is used, as the name implies, when an error occurs; given this behavior the debate should move to:

What is an error?

Many things can be categorized as an error:

pure bugs such as unhandled exceptions;
validation failures: the incoming message does not satisfies the business validation rules;
security violations: the incoming message, due the current security context, cannot be handled;
etc.;

What we get for free in NServiceBus is that if our message handler does something like this:

class SampleHandler : IHandleMessages<SampleMessage>
{
    public void Handle( SampleMessage message )
    {
        if( !this.IsValid( message ) )
        {
             throw new ArgumentException( "Invalid message" );
        }

        //message handling if validation succeed
    }
}

and an invalid message comes in the retry logic retries for 5 times (by default) and then if the message is still invalid moves the message to the error queue.

But…

Some legitimate questions arise from the above sample:

is it possible that if message A is considered invalid at the first attempt can be considered valid at a subsequent attempt?
is a validation failure the same as an unhandled exception?
does it make sense to have message failed due to a validation failure in the same can as a message failed due to a bug?
do they have the same business meaning?

Do all the above questions mean that the default NServiceBus behavior is wrong? absolutely not, period.

The above questions simply put evidence on the fact that every little thing that happens in the world we are modeling has a meaning, from the business perspective, and that meaning must be magnified to deeply understand how to treat it.

Next time we’ll see how we can leverage the message handling pipeline to change the default above behavior to satisfy our needs.

RavenDB: Worker Role vs. Virtual Machine

2013-05-03T10:35:00.001+02:00

We have seen that in order to deploy RavenDB on Windows Azure we 2 main options:

Which is the best bet?

Now that Azure Virtual Machines are a fully supported feature I have to say that they are the preferred solution, or even the only real solution.

Why?

Control is the keyword. Scaling a database is not just a matter of adding power (vertical scaling) or instances (horizontal scaling), scaling a database requires full control over the scaling topology and the Azure worker roles are not thought with control over topology in mind, it is simply not their role to give us control, they are here to give us a really, and powerful, easy way to scale.

Worker roles live behind, and there is no way to avoid this, a network load balancer that hides from the outside the roles topology, preventing upfront to have a master-slave relation within database instances hosted in different role instances.

The only concrete way to host RavenDB (any db?) is to have full control over the network topology, and have full knowledge of the topology from the client perspective, for example we need to know that from a certain point on we are connected to a slave and not anymore to the master, and to have full control we need to leverage the power of the Azure Virtual Machines where we can do quite all we want in term of machine configuration and of network configuration.

Without loosing to much in term of time-to-react to scale requests, like we already said.

NServiceBus, Windsor and message scopes

2013-04-30T18:05:00.001+02:00

if you are working with NServiceBus, using as backend IoC container Castle Windsor, remember that under the hood NServiceBus utilizes the Windsor scope feature to create a scope “around” messages in order to isolate dependencies required by each message handler.

In this case if you need to have a component, registered in Windsor, that has its lifestyle bound to the message lifecycle it is enough to register the component using the “LifestyleScope”:

container.Register
(
    Component.For<MyAmazingComponent>().LifestyleScoped()
);

Jason v0.2.1.0: retry policies

2013-04-18T15:04:00.000+02:00

As promised here we are :-)

One of our customer, using Jason, has a requirement to implement the concept of retry during the standard command execution flow. basically they have a situation where some infrastructure/transient exceptions can be raised during the command execution request and they want to be able to retry without bothering the client if not needed.

Retry Policy

In Jason v0.2.1.0, at the time of this writing in beta, we introduced the concept of retry policy; a retry policy is something that implements the ICommandExecutionRetryPolicy interface:

public interface ICommandExecutionRetryPolicy
{
    object Execute( Object command, Func<ICommandHandler> handlerFactory );
}

And can be injected into the Jason configuration in the following way:

jasonConfig.UsingAsRetryPolicy<MyCustomPolicy>();

Where MyCustomPolicy is a class that implements ICommandExecutionRetryPolicy. In the above sample the policy is registered in the container at initialization time and used by the various Jason entry point to handle all the retry logic.

There is one built-in retry policy in Jason that can be used to handle retries in case of failure:

jasonConfig.UsingAsRetryPolicy( new DelegateCommandExecutionRetryPolicy()
{
    DefaultRetryDelay = 200,
    ShouldRetry = e => e.Retry = ( e.Error is NotSupportedException && e.CurrentRetryCount < 5 )
} );

In this case the policy is still registered in the container using the supplied instance, at runtime if a failure occurs the policy is queried to determine if a retry should be attempted.

Jason v0.2: configuration improvements and breaking changes

2013-04-16T10:45:00.001+02:00

As we have already discussed Jason is an infrastructure framework to handle the “Command” portion of the CQRS pattern, due to some customer feedback and requests today we released a brand new version of the whole toolkit adding a lot of improvements and, unfortunately, some breaking changes.

One configuration to rule them all

In the previous Jason version there was one different configuration per hosting type, basically in order to host Jason as a WCF service the developer needed to build a specific configuration that was different from the one required to host Jason as a WebAPI controller. This difference leaded to one big issue: you simply cannot host, in the same application, a Jason API controller and a Jason WCF service.

In v0.2 we solved this scenario rebuilding the whole configuration stuff:

var jasonConfig = new DefaultJasonServerConfiguration
(
    pathToScanForAssemblies: Path.Combine( AppDomain.CurrentDomain.BaseDirectory, "bin" ),
    assemblySelectPattern: assemblySelectPattern
);

jasonConfig.AddEndpoint( new Jason.WebAPI.JasonWebAPIEndpoint() 
{
    TypeNameHandling = TypeNameHandling.Objects
} );

jasonConfig.AddEndpoint( new Jason.Server.JasonWcfEndpoint()
{
    CommandsSelector = t =>
    {
        return t.IsAttributeDefined<DataContractAttribute>()
            && ( t.Name.EndsWith( "Command" ) || t.Name.EndsWith( "CommandResponse" ) );
    }
} );

jasonConfig.Initialize();

We are building just one single configuration adding 2 different endpoints each one with its own configuration peculiarities.

Inversion of control support

Jason heavily relies on the Inversion of Control pattern to work and depends on an Inversion of Control container but we do not want, as in previous versions, to force the user to introduce an IoC container in the solution only to support Jason and we especially do not want you to remember to register the internal Jason type that are required to work.

In v0.2 we leverage the power of the Radical built-in PuzzleContainer (that is now available in all Radical versions) to support the IoC Jason needs, the internal container is exposed by the configuration via the Container property and can be used to register custom types required during the Jason usage.

Obviously the default internal container can be easily replaced in order to integrate Jason in your development lifecycle using your favorite container of choice. In order to achieve that it is enough to replace the built-in container via the configuration Container property where the IJasonContainer is just a proxy interface to abstract the container concept.

Here is a sample implementation to inject Castle Windsor:

public class WindsorJasonContainerProxy : Jason.Configuration.IJasonContainer
{
    IWindsorContainer container;

    public WindsorJasonContainerProxy( IWindsorContainer container )
    {
        this.container = container;
    }

    public void RegisterAsTransient( IEnumerable<Type> contracts, Type implementation )
    {
        this.container.Register( Component.For( contracts ).ImplementedBy( implementation ).LifestyleTransient() );
    }

    public void RegisterAsSingleton( IEnumerable<Type> contracts, Type implementation )
    {
        this.container.Register( Component.For( contracts ).ImplementedBy( implementation ).LifestyleSingleton() );
    }

    public void RegisterInstance( IEnumerable<Type> contracts, object instance )
    {
        this.container.Register( Component.For( contracts ).Instance( instance ).LifestyleSingleton() );
    }

    public void RegisterTypeAsTransient( Type implementation )
    {
        this.container.Register( Component.For( implementation ).LifestyleTransient() );
    }

    public void RegisterTypeAsSingleton( Type implementation )
    {
        this.container.Register( Component.For( implementation ).LifestyleSingleton() );
    }

    public IEnumerable<T> ResolveAll<T>()
    {
        return this.container.ResolveAll<T>();
    }

    public T Resolve<T>()
    {
        return this.container.Resolve<T>();
    }

    public IEnumerable<object> ResolveAll( Type t )
    {
        return this.container.ResolveAll( t ).Cast<Object>();
    }

    public object Resolve( Type t )
    {
        return this.container.Resolve( t );
    }

    public void Release( object instance )
    {
        this.container.Release( instance );
    }
}

As said just a trivial proxy that can be used in the following manner:

var jasonConfig = new DefaultJasonServerConfiguration( Path.Combine( AppDomain.CurrentDomain.BaseDirectory, "bin" ) )
{
    Container = new WindsorJasonContainerProxy( yourWindsorInstance )
};

After that Jason will use your container to register its own required types and to resolve at runtime the required components.

Next time: Jason retry policies.

RavenDB: Integrated Windows Authentication

2013-04-12T10:53:00.000+02:00

A couple of days ago I was at a customer and one of the raised issues, when dealing with RavenDB Windows authentication, was how to use a real “Integrated Windows Authentication” in order to have the credentials of the user currently running the client process flow to the server through the HTTP protocol.

After a bit of digging in the .net documentation the solution is trivial:

Uri uri = new Uri( "http://localhost:8080/" );
ICredentials credentials = CredentialCache.DefaultCredentials;
NetworkCredential credential = credentials.GetCredential( uri, "Basic" );

var store = new DocumentStore()
{
    Url = "http://localhost:8080/",
    DefaultDatabase = "database-name",
    Credentials = credential
}.Initialize();

The above snipped creates a new DocumentStore whose credentials are ready to transport the current user credentials.

RavenDB Worker Role on Windows Azure: create service users

2013-04-03T13:54:00.000+02:00

When creating a Worker Role on Windows Azure, due to the nature of the worker role, we need to be fully auto-consistent: each time the role is deployed (or re-imaged) into the Azure infrastructure a brand new virtual machine is created to host the role thus if the role needs, in order to work, some OS customization we need to do those customizations at role startup.

Startup tasks are provided exactly to achieve that.

In order to setup RavenDB, when using Windows Authentication, you need at least 2 users:

An administrator to perform administrative tasks, such as backups or system level operations;
A standard user in order to connect and operate on a database;

Each time the role is deployed users must be created on the newly deployed virtual machine.

A startup task is a separate process that can be launched at role startup, the task definition is created in the “ServiceDefinition.csdef” file:

<Startup>
      <Task commandLine="Startup\CreateWindowsUser.exe" executionContext="elevated" taskType="simple">
        <Environment>
          <Variable name="emulated">
            <RoleInstanceValue xpath="/RoleEnvironment/Deployment/@emulated" />
          </Variable>
          <Variable name="username">
            <RoleInstanceValue xpath="/RoleEnvironment/CurrentInstance/ConfigurationSettings/ConfigurationSetting[@name='RavenUserUsername']/@value" />
          </Variable>
          <Variable name="password">
            <RoleInstanceValue xpath="/RoleEnvironment/CurrentInstance/ConfigurationSettings/ConfigurationSetting[@name='RavenUserPassword']/@value" />
          </Variable>
          <Variable name="admin" value="False" />
        </Environment>
      </Task>
</Startup>

As you can see we are calling an external process, with elevation, and we’ll wait for the process to complete before moving on (simple taskType); if we need to pass information, defined in the role settings, to the external task the only way, as far as I know, is to use a shared environment variable. In this sample we are passing to the external task the username and password of the user we need to create, a flag that indicates if the user should be an administrator or not, and a flag that tells to the external process if we are running in the Azure emulator or not.

We can launch as many tasks as we want, and in the real scenario we are launching the above task 2 times, with different parameters, in order to create the 2 required users.

The external process does nothing special, it just creates a user, using the provided info, via the System.DirectoryServices.AccountManagement namespace classes.

Radical: focus management (preview)

2013-03-05T09:46:00.000+01:00

In Radical we just introduced (package: http://nuget.org/packages/Radical.Windows.Presentation) the focus management.

Here is the docs: http://radical.codeplex.com/wikipage?title=Managing%20Focus%20from%20the%20ViewModel

Radical Presentation: validation support

2013-01-18T10:00:00.000+01:00

The validation support documentation is live on the Radical CodePlex web site.

Radical: customer improvement program

2013-01-15T10:18:00.000+01:00

There is a new nice and interesting feature, at least from my point of view, built-in in Radical: Official documentation

Customer Improvement Program

Have you ever thought how important is, from the perspective of an application producer, us, to know what our end users do with the application they use?

we plan a feature;
we invest money in building a feature;
we deploy a feature;

…and we do not know nothing about how the user utilizes the feature we invested on, we do not even know if the user utilizes it.

AnalyticsServices.UserActionTrackingHandler = evt =>
{
    //every user action will be dispatched here asynchronously    
};

AnalyticsServices.IsEnabled = true;

Writing the above code at the application startup enables the Radical AnalyticsServices what happens is that all the code that in some way invokes a DelegateCommand, in a WPF MVVM based application, will be tracked and we have the opportunity to “save” what the user is doing in order to analyze it later.

What the UserActionTrackingHandler receives is an AnalyticsEvent with the following shape:

public class AnalyticsEvent
{
    public AnalyticsEvent()
    {
        this.ExecutedOn = DateTimeOffset.Now;
        this.Identity = Thread.CurrentPrincipal.Identity;
    }

    public DateTimeOffset ExecutedOn { get; set; }

    public String Name { get; set; }

    public Object Data { get; set; }

    public IIdentity Identity { get; set; }
}

If you need you can define your own events inheriting from the AnalyticsEvent class and in order to plugin your events you only need to declare a dependency on the IAnalyticsServices service:

public interface IAnalyticsServices
{
    Boolean IsEnabled { get; set; }
    void TrackUserActionAsync( Analytics.AnalyticsEvent action );
}

And each time you call TrackUserActionAsync your UserActionTrackingHandler will be invoked.

Be aware that this is still a preview subject to change.

Radical: Message broker support for POCO messages

2013-01-10T12:34:00.000+01:00

Here we are finally the Radical message broker now supports POCO messages:

From the Radical documentation on CodePlex:

RavenDB install options

2013-01-08T10:35:00.000+01:00

We have several options to install RavenDB, the following is a brief recap.

As a IIS application

this is the easiest way to setup RavenDB, just create a new web application and point to the “web” folder of the RavenDB install directory. The only important tweak is to tell to IIS the the application pool should be a “always running” application pool: http://ravendb.net/docs/server/deployment/as-iis-application

Advantages of this approach are clearly that the deployment is really easy, we can leverage the support of IIS and whenever RavenDB should crash IIS will take care of restart everything for US without any human intervention.

As a Windows Service

We can install RavenDB as windows service using its internal web server to expose the http endpoint on a preconfigured port, the advantages of this approach are basically that we have time to startup and especially to shutdown, the latter is the most important: when RavenDB gets shutdown needs to cleanly shutdowns all the indexes and that operation takes some time. If the cleanup/shutdown is not done correctly at startup RavenDB needs to check the healthy state of all the indexes and that takes a relative important amount of time, during which the database is not yet accessible.

Embedded directly in our application

Obviously this type of deployment is an option even if has nothing to do with the above options. We can build an application where everything is self contained in the application itself without the need of a separate RavenDB installation, this is the favorite solution for a typical single-user app.

What do I suggest?

Go with a Windows Service, especially if you have several huge indexes, because the health of RavenDB indexes if one of the core key point of the power of RavenDB.

Important note

Starting with RavenDB 2.0, that at the time of this writing is still under preview/unstable release, the whole startup/shutdown story has been addressed and drastically simplified, so if you have huge indexes with 2.0 is not such a big deal anymore.

See you next year

2012-12-21T12:30:00.000+01:00

Never trust Environment.CurrentDirectory

2012-12-18T10:38:00.000+01:00

If your code relies on “Environment.CurrentDirectory” to get the directory your application is “running in” you can get really surprising behaviors.

Environment.CurrentDirectory can be changed at any time by any piece of code, even by code not directly under your control, it is much better to build your own logic to get the “startup” directory, such as:

public static class FileSystem
{
    public static String GetCurrentDirectory() 
    {
        return Path.GetDirectoryName( Assembly.GetEntryAssembly().Location );
    }
}

WIF custom login pages and cookie path…

2012-12-14T09:14:00.000+01:00

…do not try this at home…well do not try this anywhere :-)

Today I lost half of the day dealing with a nasty and horrible error, on a staging environment, trying to host Azure login pages locally instead that on the Azure ACS portal.

It was not working, even if it should be really, really trivial to setup. After dealing with the trace recorded by fiddler for a couple of hours I realized that the whole problem is related to the WIF configuration of the web application:

<system.identityModel>
    <identityConfiguration>
        <audienceUris>
            <add value="https://localhost/MyWebApp/" />
        </audienceUris>
        <issuerNameRegistry type="System.IdentityModel.Tokens.ConfigurationBasedIssuerNameRegistry, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
            <trustedIssuers>
                <add thumbprint="---" name="---" />
            </trustedIssuers>
        </issuerNameRegistry>
        <certificateValidation certificateValidationMode="None" />
    </identityConfiguration>
</system.identityModel>
<system.identityModel.services>
    <federationConfiguration>
        <cookieHandler requireSsl="false" path="/MyWebApp" />
        <wsFederation passiveRedirectEnabled="true" issuer="http://----/wsFederationSTS/Issue" realm="https://localhost/MyWebApp/" requireHttps="false" />
    </federationConfiguration>
</system.identityModel.services>

Removing the “path” attribute from the “cookieHandler” element solved the problem immediately.

Developer advised… :-)

UserPrincipal.GetAuthorizationGroups()…oh my!

2012-12-11T09:09:00.000+01:00

The problem

There is a really convenient method that can be used to retrieve a flat list of all the groups (event nested) given a known UserPrincipal, e.g. the current user, the really amazing thing is that the method saves you from doing a group recursion to retrieve the groups relationships in order to detect that a user belongs to a group A that belongs to a group B.

The above method utilizes, as far as I know, the security tokens attached to a given user principal and then resolves the group names given the group SID.

The problem is that that method can fail with a really strange exception “NoMatchingPrincipalException” (the group cannot be found) that is typically related to 2 different scenarios:

One, or more, of the group has SID History enabled;
In a complex domain topology one of the DC is not available at the moment of the query;

To make a long story short: we simply cannot rely on that method, period.

The solution

IEnumerable<String> GetGroups( String samAccountName )
{
    var userNestedMembership = new List<string>();

    var domainConnection = new DirectoryEntry();
    domainConnection.AuthenticationType = System.DirectoryServices.AuthenticationTypes.Secure;

    var samSearcher = new DirectorySearcher();

    samSearcher.SearchRoot = domainConnection;
    samSearcher.Filter = "(samAccountName=" + samAccountName + ")";
    samSearcher.PropertiesToLoad.Add( "displayName" );

    var samResult = samSearcher.FindOne();

    if ( samResult != null )
    {
        var theUser = samResult.GetDirectoryEntry();
        theUser.RefreshCache( new string[] { "tokenGroups" } );

        foreach ( byte[] resultBytes in theUser.Properties[ "tokenGroups" ] )
        {
            var SID = new SecurityIdentifier( resultBytes, 0 );
            var sidSearcher = new DirectorySearcher();

            sidSearcher.SearchRoot = domainConnection;
            sidSearcher.Filter = "(objectSid=" + SID.Value + ")";
            sidSearcher.PropertiesToLoad.Add( "name" );

            var sidResult = sidSearcher.FindOne();
            if ( sidResult != null )
            {
                userNestedMembership.Add( ( string )sidResult.Properties[ "name" ][ 0 ] );
            }
        }
    }

    return userNestedMembership;
}

A bunch of old good directory services related code :-) where the really really really, have I said really?, important piece is the following:

theUser.RefreshCache( new string[] { "tokenGroups" } );

That asks to the underlying system to refresh the cache of the groups security tokens attached to the given user.

Radical “Handle” behavior

2012-12-06T12:40:00.000+01:00

Imagine that you need to handle from the ViewModel the SelectedIndexChanged of a WPF TreeView, currently the only way (without using any particular framework) is to build your own Behavior to achieve that, or bind, via a style the IsSelected property of the node to a property of the view model, but in this second case the side effect is that to find the selected item you need to visit the whole tree.

Enter Radical “Handle”

<TreeView Margin="5"
          HorizontalAlignment="Stretch" 
          VerticalAlignment="Stretch" 
          ItemsSource="{Binding Path=Accounts}">
    <i:Interaction.Behaviors>
        <behaviors:Handle RoutedEvent="TreeView.SelectedItemChanged" 
                    WithCommand="{Binding Path=SelectOutlookPath}"
                    PassingIn="$args.NewValue" />
    </i:Interaction.Behaviors>
    <TreeView.ItemTemplate>
        <!-- omitted -->
    </TreeView.ItemTemplate>
</TreeView>

As you can imagine the value of the NewValue property of the event arguments is passed as the command parameter to the command, we currently support to placeholder:

$args: the routed event arguments;
$this: the WPF element the behavior is attached to;
$source: the source of the routed event;
$originalSource: the original source of the routed event;

Obviously the event we need to handle must be a RoutedEvent.

Available in the Nuget package “Radical.Windows”

RavenDB: index management options

2012-12-04T13:52:00.000+01:00

We have recently introduced the basic concepts about indexing in RavenDB. We left without saying nothing about the options we, as developers, have to manage indexes:

Manually via the RavenDB Studio;
Programmatically directly within the application;

Index overview

If we take a look at the Indexes tab in the Studio and we edit one of the indexes we can see something that we, as .net developers, are really familiar with: linq.

An index is defined using a linq expression, wow, but as we may suspect the server has no knowledge at all of what a linq expression is, what we see in the index editor is basically text, familiar to us, but text that the server can understand and use to “run” the index.

Manual index management

So…as we can imagine we can use the Studio to create and manage indexes, creating a new index is just a matter of defining the correct lambda expression that defines what we want to index, basically nothing more.

As we can imagine as the index complexity grows the manual management can become cumbersome.

Programmatic index management

The following map/reduce index is a good starting point:

it is still a fairly simple index (a sort of tag cloud) but is a good sample of the manual management complexity we can achieve quickly. The above index can be fully managed by code:

public class Genres_Count : AbstractIndexCreationTask<Album, Genres_Count.GenresCloud>
{
    public class GenresCloud
    {
        public string Id { get; set; }
        public string Name { get; set; }
        public int Count { get; set; }
    }

    public Genres_Count()
    {
        this.Map = albums => from album in albums
                        select new
                        {
                            Id = album.Genre.Id,
                            Name = album.Genre.Name,
                            Count = 1
                        };

        this.Reduce = results => from genreCount in results
                            group genreCount by genreCount.Id into g
                            select new
                            {
                                Id = g.Key,
                                Name = g.First().Name,
                                Count = g.Sum( x => x.Count )
                            };

        this.IndexSortOptions.Add( i => i.Count, Raven.Abstractions.Indexing.SortOptions.Int );
    }
}

The above C# code is exactly equal to the index we have seen in the studio, in fact the index in the studio has been generated at application startup time using the following one line of code:

//ds is an instance of IDocumentStore
IndexCreation.CreateIndexes( Assembly.GetExecutingAssembly(), ds );

We have defined in a single class, inheriting from the RavenDB AbstractIndexCreationTask<TDocument, TReduceResult>:

the name of the index, the convention is that My_Sample_Index is translated by the server into a index named My/Sample/Index;
The map logic;
The reduce logic;
Some index options;
And the shape of the reduce result;

Having a strongly typed index definition allows us to write some strongly typed C# code to use it:

var cloud = await Task.Factory.StartNew<IEnumerable<Genres_Count.GenresCloud>>( () =>
{
    using( var session = this.documentStore.OpenSession() )
    {
        var data = session.Query<Genres_Count.GenresCloud, Genres_Count>()
            .OrderByDescending( c => c.Count );

        return data;
    }
} );

Windows 8 app: application bootstrap

2012-11-30T10:34:00.000+01:00

First of all it is important to understand the ~~Metro~~ Windows Store app lifecycle and Jeremy Likeness has perfectly covered the topic, go and read it.

As you can see there are a lot of details that should be taken into account:

is it a resume or a cold start?
the application state should be restored?

at which point?

is it a “charm” request?
is it a custom tile request?
is it a toast notification request?

So the question should be: is my role, as app developer, to handle all those possibilities? or my role should be to handle the application business logic?

Using Radical you can forget the most part of the question above and concentrate on the cool part of your application:

The boot process: http://radical.codeplex.com/wikipage?title=The%20boot%20process%20demystified
WinRT peculiarities: http://radical.codeplex.com/wikipage?title=WinRT%20boot%20process%20peculiarities

Any feedback is really appreciated.

Running RavenDB on Windows Azure with Replica

2012-11-28T13:10:00.000+01:00

We have seen how easy is to setup RavenDB on Azure using a Virtual Machine, nothing so different from what we would do on a regular on premise VM/bare metal.

The funniest thing is that the RavenDB configuration for replica is just a matter of seconds, the time consuming part is the Azure configuration.

Service Level Agreement

One of the key point of providing a service in the cloud is to give to our customer a SLA, a guarantee that the service we provide with our application will be available whenever the customer needs it.

Using Azure Web/Worker Role(s) it is a trivial stuff, just deploy more instance of the same role, but with VM is up to us to manage the whole topology of the network and to setup VM balancing, if required, and redundancy.

Why running in a VM?

We have seen that we can easily setup RavenDB using a Worker Role but

RavenDB Replica support

Using RavenDB we can leverage the power and simplicity of the Replication Bundle so set up a replica-set, let’s say that we want to setup the simplest possible scenario: master-slave.

First of all we need another virtual machine, can we “copy” the already existing one: yes, but wait a minute.

Azure networking

The first problem we have is to understand how we can allow communication between virtual machines laying in an Azure datacenter. There a re a couple of possible approach:

Availability Set: Azure has the concept of availability set, a sort of logical grouping, and the documentation states that virtual machines (and so also web and worker roles) living in the same availability set, or defined in the same cloud service, are able to communicate without any configuration (other than the machine on board firewall that obviously should be configured to accomplish your needs)…I have tried everything without any success… :-/
Virtual Network: Azure has recently introduced the concept of virtual networks, it is basically a network definition that guarantees isolation and communication to the machines defined in the virtual network, the amazing thing, even if out of our current scope, is that we can use virtual networks to create a network between the cloud network and our on premise network.

The main difference, as per the documentation, between the two is that in the first one we get name resolution for free and in the second one we should provide our own DNS service to have name resolution, but in order to setup the replica we can use machine IP addresses and the Virtual Network gives us something called persistent IP, a sort of a DHCP infinite lease; so we do not need any DNS to setup the replica.

At the time of this writing the biggest problem of the Virtual Networks is that there is no support to add an existing VM to a virtual network, we need to add the VM to the network at creation time.

Create the Virtual Network

Since we need to define the Virtual Network before creating the VMs the first step is to create di network, via the Azure management portal go to the network tab:

And create a new network, I skip the 2 creation steps since they are just a network definition made of a name, an address space and a optional subnet.

Shutdown the VM and Capture it

Now…we have a running VM that cannot be added to the virtual network and we need another VM with exactly the same configuration, the easiest approach is:

“Sysprep” the OS, running sysprep.exe from Windows\System32\Sysprep, choosing the following options:
Wait for the sysprep process to complete, wait, wait, wait…I waited for 15 minutes…it’s along way to the top…;
Use the capture function of the Azure portal to create a image of the VM, once the capture is completed:

The original VM is deleted;
You have a new image in the gallery ready to use to create ne VMs;

Create 2 VMs based on the captured image

Create 2 new VMs using the previously created image and be sure to add the VM the existing virtual network:

Once the VM is up & running and the installed RavenDB is accessible from the internet (be sure as in the single machine installation to add the both the VMs an http endpoint as usual) go to the Azure portal and take a look at the network configuration of the machines:

Both machines have an internal IP address that belongs to the subnet mask defined in the virtual network.

Setup RavenDB replica

Install the Replication Bundle on both machines adding the Raven.Bundles.Replication assembly to the Plugins directory, now go to the RavenDB Studio of the machine that will be the master server, select the database you want to replicate the the slave server and create the replica setup document:

We also add credentials info the the document since we are using Windows Authentication, there is also a option to specify a connection string in the web config and thus encrypt the config section for security purpose.

As soon as you save the document if you move to the Logs tab of the Studio you can see that RavenDB has immediately noticed that something interesting has happened:

The final step is to test everything, pop up a new browser pointing to the slave server, go back to the master and create a new document:

A couple of seconds after we created the new document (with id “Users/3”) on the primary server the same document pops up on the slave one, and the log on the master server confirms that everything is running as expected:

Amazing, all this stuff is simply amazing :-P

RavenDB: map index

2012-11-26T09:46:00.000+01:00

it’s long time that I left this topic alone, last time I promised we will discuss about the way document database let you get your data back to life, here we are.
Indexing
As we already said, I hope :-), the only way to search/query data in a document database is to use an index, let see what happens using a really trivial example:

static void Main( string[] args )
{
    var uri = new Uri( "http://localhost:8181" );

    var store = new DocumentStore()
    {
        DefaultDatabase = "Spike",
        Url = uri.ToString(),
        Credentials = CredentialCache.DefaultCredentials.GetCredential( uri, "Basic" )
    }.Initialize();
    using ( var session = store.OpenSession() )
    {
        session.Store( new Person() { FirstName = "Mauro", LastName = "Servienti" } );
        session.Store( new Person() { FirstName = "Guido", LastName = "Rossi" } );
        session.Store( new Person() { FirstName = "Giorgio", LastName = "Verdi" } );
        session.Store( new Person() { FirstName = "Samuele", LastName = "Bianchi" } );

        session.SaveChanges();
    }
}

The first thing we need is to load some test data, and then we can try to search for some of them:

using ( var session = store.OpenSession() )
{
    var query = session.Query<Person>().Where( p => p.FirstName.StartsWith( "G" ) );
    var persons = query.ToList();
}

The interesting stuff is that if we execute the above query we get back the expected 2 persons (Giorgio and Guido): how can it be? haven’t we said that we need an index to query for data? we have created nothing.
The most amazing feature (in my humble opinion)
If we fire up the RavenDB Studio and go to the Indexes tab we notice the following:

RavenDB has created a brand new index (a temporary index) for us automatically as soon as the query engine has noticed that there is no index that is capable to satisfy the query we issued.
But…what is the shape of the index?

RavenDB has just created what is called a “Map Index” whose role is to map fields that can be searched so to let the Lucene search engine have something to work on.
What happens if we issue a new query that involves different fields? Once again we get back the expected results, but:

We have now 2 indexes…let’s try one thing, manually delete the first index and re-execute the first query, what happens? No index is created, the query engine realizes that the existing index can be used to satisfy the incoming query, so far so good. The new question now is: is a good practice to let RavenDB auto-magically create indexes? in my opinion the answer is no.
The basic idea is that since we know how we are going to use our data we can create indexes upfront and use the amazing auto-index creation feature only at development time when for example in order to understand which is the best way to create an index that satisfies a specific query.
Next time we’ll see options we have out-of-the-box to create and manage indexes.
.m

logging…what a mess…

2012-11-23T10:38:00.000+01:00

During my daily work I’m currently using nuget a lot and after adding some dependencies the references of one of my projects looks like the following:

everyone tends to use its own favorite logging framework with the consequence that if you are the user of other’s framework you finally end up with something that is really like a traffic jam…

I deeply think that a framework should not impose nothing more then the framework functionalities to the user, but in those cases it was imposed to me also the dependency on 2 different logging framework.

I have nothing against both logging infrastructure, what I only want to point out is that now in order to have logs in one single place I am forced to adapt the output of one to the other, or, much better (or worse), of both to System.Diagnostics.Trace.

WPF hosting an Adorner in a template

2012-11-21T07:46:00.000+01:00

take a look at this Xaml:

<Grid>
    <behaviors:Overlay.Content>
        <TextBlock Text="Logon failed, please check your username and password."
                   Foreground="Red" FontWeight="Bold" FontSize="30" />
    </behaviors:Overlay.Content>
</Grid>

it utilizes a feature built-in in Radical: overlay adorners, that under the hood utilize a WPF Adorner and AdornerLayer to host the given content on top, as a layer, of the adorned element, in this sample a Grid.

Now, everything works fine and you can use all the WPF features inside an adorner, such as data binding:

<Grid>
    <behaviors:Overlay.Content>
        <TextBlock Text="{Binding Path=ErrorMessage}"
                   Visibility="{Binding Path=IsErrorMessageVisible, Converter={StaticResource boolToVisibilityConverter}}"
                   Foreground="Red" FontWeight="Bold" FontSize="30" />
    </behaviors:Overlay.Content>
</Grid>

but the fanny thing is that if everything (in this case the Grid element) is hosted inside template (e.g. a DataTemplate) bindings tend to fail at runtime…

Take a look at this more detailed sample Xaml:

<Window DataContext="{Binding Path=Source}">
    <Grid>
        <ContentControl Content="{Binding Path=ChildOfSource}">
            <ContentControl.ContentTemplate>
                <DataTemplate>
                    <behaviors:Overlay.Content>
                        <TextBlock Text="{Binding Path=ErrorMessage}"
                                   Visibility="{Binding Path=IsErrorMessageVisible, Converter={StaticResource boolToVisibilityConverter}}"
                                   Foreground="Red" FontWeight="Bold" FontSize="30" />
                    </behaviors:Overlay.Content>
                </DataTemplate>
            </ContentControl.ContentTemplate>
        </ContentControl>
    </Grid>
</Window>

in this case the expected behavior is that ErrorMessage and IsErrorMessageVisible properties can be found on the object identified by the ChildOfSource property exposed, and bound as the Content of the ContentControl, by the Source element bound as the DataContext of the root Window.

It does not work, period. The data binding engine looks for the 2 bound properties on the object identified by the Source property bound on the Window element…why?

The problem is that the adorner content, the TextBlock in this sample, is a child (in term of visual tree) of the Adorner element but the adorner element is not child of the adorned element but is child of the first AdornerLayer found in the logical tree…and in the sample above the first AdornerLayer that can be found is the implicit one, always created by WPF, child of the root Window, thus our TextBlock is a visual child of the Window and not of the Grid and this explains why the data binding engine looks for properties in a place we think is the wrong place.

The solution is fairly simple:

directly bind the DataContext of the elements in the template using the element name of the outer control;
explicitly wraps the content of the DataTemplate within an AdornerLayer;

Jason: MVC WebAPI Hosting

2012-11-19T14:15:00.000+01:00

Last time we have seen what Jason is, the big picture, but we still miss a lot of details and as you may have noticed even the samples of the introduction post miss some important details.

The important things we discovered can be summarized as follows:

we have understood the commanding pattern exposed by Jason;
we have understood how Jason behaves from the client perspective;
we have understood that we can host Jason in a WebAPI controller or using a WCF service;

Jason setup in MVC WebAPI

Let us start from the newest stuff but much simpler WebAPI implementation, first of all create a new MVC WebAPI project and grab a reference to the Jason.WebAPI package from nuget.

What do you get in the package?

A built-in JasonController WebAPI controller;
The default configuration implementation;
The default command handler provider;
1 built-in command (EchoCommand) for testing purpose and its related command handler;

2, 3, go… (cit.)

One you have added the nuget package all we have to do is to configure Jason, I’d like to improve the configuration so if you have nay idea let me know.

Open up the Global.asax file of your project and:

Jason relies on a Inversion of Control framework to work but has no explicit dependency on any specific IoC container, since the requirements are really basic I preferred to expose a simple API to let the user wire Jason with his favorite tool:

var windsor = new WindsorContainer();

windsor.Register( Component.For<IServiceProvider>().Instance( new ServiceProviderWrapper( windsor ) ) );
windsor.Register( Component.For<ICommandHandlersProvider>().ImplementedBy<DefaultCommandHandlersProvider>() );
windsor.Register( Component.For<JasonController>().LifeStyle.Is( LifestyleType.Transient ) );

Right after the MVC initialization code we are creating a new instance of Castle Windsor adding a bunch of components.

After setting up the IoC container we can setup the Jason configuration:

var jasonConfig = new JasonWebAPIConfiguration
(
    pathToScanForAssemblies: Path.Combine( AppDomain.CurrentDomain.BaseDirectory, "bin" ),
    jsonTypeNameHandling: TypeNameHandling.Objects
)
{
    RegisterAsTransient = ( c, i ) =>
    {
        windsor.Register
        (
            Component.For( c )
                .ImplementedBy( i )
                .LifeStyle.Is( Castle.Core.LifestyleType.Transient )
        );
    }
};

jasonConfig.Initialize();

The configuration needs 3 different things:

a path that the internal type scan engine utilizes to find all the commands and all the handlers;

A type name handling behavior to handle json commands deserialization (only used if incoming content-type is application/json);

A Func<Object, Object> used to ask to the external IoC container to register something in a transient manner;

The call to Initialize wires up everything and prepares Jason for the first run.

The last thing to do is to instruct the WebAPI framework to use our IoC implementation to resolve dependencies:

GlobalConfiguration.Configuration.DependencyResolver = new DelegateDependencyResolver()
{
    OnGetService = t =>
    {
        if ( windsor.Kernel.HasComponent( t ) )
        {
            return windsor.Resolve( t );
        }

        return null;
    },
    OnGetServices = t =>
    {
        if ( windsor.Kernel.HasComponent( t ) )
        {
            return windsor.ResolveAll( t ).OfType<Object>();
        }

        return new List<Object>();
    }
};

here I am using a really trivial IDependencyResolver implementation to delegate to the user code the dependency resolve process and let the resolver only handle the wiring between the WebAPI infrastructure and our favorite IoC container.

Now that everything is set up we can test our brand new Jason infrastructure:

Startup the newly created WebAPI application pressing F5 in Visual Studio;
fire up a new instance of Fiddler and go to the “composer”:

Add a call to Jason controller and remember to set the post content type, in our sample json but also xml is fully supported.

Finally add a boy to the posted http request:

Execute

As soon as you press the execute button the Jason infrastructure is invoked from the WebAPI application and you get the expected response:

Server side what is happening is that the specialized command handler for the EchoCommand is invoked by the Jason infrastructure, and has the opportunity to do some work and provide a response:

public class EchoCommandHandler : AbstractCommandHandler<EchoCommand>
{
    protected override object OnExecute( EchoCommand command )
    {
        return new EchoCommandResponse()
        {
            Message = String.Format( "Echo: {0}", command.Message )
        };
    }
}

The cool thing is that the whole wiring is done by the infrastructure, thus we can:

Create a bunch of commands in your assemblies;
Create the dedicated command handler for each command;
drop all the stuff in the bin folder of the WebAPI application and restart the application;

We can now use the newly created commands directly from our really cool JavaScript application using WebAPI as a backhand to host command handlers.