Radical.Windows.Presentation: bootstrap conventions

I’ve released a new version of my Presentation and UI Composition toolkit: Radical.Windows.Presentation, the new feature is the first drop of the Castle Windsor integration package (Radical.Windows.Presentation.CastleWindsor), this first drop targets only WPF 4.0 (but it is a first drop, next to come will be WinRT, Silverlight 5.0 and Windows Phone 7.5).

The integration package simply adds support for the famous Invention of Control toolkit introducing the WindsorApplicationBootstrapper<TShellView> that is the concrete implementation of the abstract ApplicationBootstrapper base class. The role of bootstrapper is:

• attach the relevant application events;
• wire up stuff to configure the I.o.C. container;
• show the shell view (the application main window);

Frictionless: convention based

As I have already said my first aim is to remove friction, it is not always easy and cannot be done every single time, but one thing that can give a lot of benefits in this area is to move from a configuration based toolkit to a convention based toolkit, I suppose that this concept is widely accepted and is nothing new.

What happens when this lines of code are executed:

namespace Radical.Presentation.Samples
{
	public partial class App : Application
	{
		public App()
		{
			var bootstrapper = new WindsorApplicationBootstrapper<MainView>();
		}
	}
}

A lot of things:

1. The application Startup event is wired;
2. When the Startup event is fired:
   1. The Inversion of Control container is created;
   2. The MEF composition container is created;
   3. The composition container is composed against the bootstrapper itself (here is why, in Italian unfortunately);
   4. The Inversion of Control container is configured using the bootstrap conventions;
   5. The main window (the one identified by the TShellView generic parameter) is resolved and shown;

Bootstrap conventions

Bootstrap conventions are mainly related to the way components are registered into the container:

• every class the is defined in a namespace ending with “Services” (*.Services) will be considered a service and will be registered as singleton using as the service contract the first interface, if any, otherwise using the class type;
• every class the is defined in a namespace ending with “Presentation” (*.Presentation) and whose type name ends with “ViewModel” (*ViewModel) will be considered as a view model and registered as transient;
  • following the same logic every type in the same namespace whose name ends with “View” (*View) will be considered a view, a transient view;
  • if a view or a view model are a shell, type name beginning with Shell* or Main*, they will be registered as singleton
  • be default views and view models will be registered using as service contract the class type and no interface is searched along the way;
• every type defined in the “Messaging.Handler” namespace (*.Messaging.Handler) will be considered a message broker message handler and will be registered as singleton and automatically attached, as an handler, to the broker pipeline;

These are the main conventions used at boot time, there are a few more but less important. Obviously all these behaviors can be replaced or extended to accomplish the end user needs:

public App()
{
	var bootstrapper = new WindsorApplicationBootstrapper<MainView>();
 
	var conventions = bootstrapper.GetService<BootstrapConventions>();
 
	var original = conventions.IsService;
	conventions.IsService = t =>  {
		if( /* your logic to determine if “t” is a service */ )
		{
			return true;
		}
 
		return original( t );
	};
}

All the conventions are Func(s) or Predicate(s) and can be easily replaced as shown in the above sample, here is the list of the currently defined and used conventions:

• IsService: determines if a type should be considered a service or not;
• SelectServiceContracts: given the service type returns the list of contracts that should be used to register the given service;
• IsMessageHandler:determines if a type should be considered a message handler or not;
• SelectMessageHandlerContracts: given the message handler type returns the list of contracts that should be used to register the given message handler;
• IsView: determines if a type should be considered a view or not;
• IsViewModel: determines if a type should be considered a view model or not;
• IsShellView: determines if a type should be considered a shell view or not;
• IsShellViewModel: determines if a type should be considered a shell view or not;
• SelectViewContracts: given the view type returns the list of contracts that should be used to register the given view;
• SelectViewModelContracts: given the view model type returns the list of contracts that should be used to register the given view model;

In the next post will deal with runtime conventions.

.m

Frictionless MVVM

I love the concept of sustainable and frictionless development. This morning I started a new WPF project, it aims to be a base for the RavenDB training that we will hold in Perugia in June.
10 steps project bootstrap (5 minutes)
I’m loving it:

• Create the Visual Studio solution;
• Add a WPF project;
• Add some nuget references:
• Radical;
• Radical.Windows;
• Radical.Windows.Presentation;
• Radical.Extensions.CastleWindsor;
• Add a reference to the new kid on the block (not yet on nuget): Radical.Windows.Presentation.CastleWindsor;
• Delete the default MainWindow.xaml;
• Edit the app.xaml file to remove the StartupUri property;
• Add a Presentation folder to the project;
• Create to new items:
• A WPF window MainView.xaml (*View is important for the default conventions);
• A class MainViewModel (<ViewName>ViewModel is important for the default conventions);
• In the app.xaml.cs add a single line of code:

• Press F5 and you are up & running :

The application boots, all the default and required services (for MVVM and UI Composition) are wired into Castle Windsor, the MainView is designed as the main window, at boot time the MainView is resolved and using the conventions engine the MainViewModel is wired as the DataContext of the MainView, in the end the MainView is shown.
.m

Dealing with a lot of data: the problem

where “a lot” means 20+ mil “records/documents”.
Dealing with a lot of data is usually a problem, but the interesting stuff is that the main problem is not a technical problem. It is quite obvious that all the architectural choices we are used to are not guaranteed at all to work, it is obvious that generalization is much more evil than what generally generalization is, it is obvious that every single technical choice must be chosen with performance in mind because generally low performance with those numbers generally mean that nothing works.
But a much more interesting problem is the daily development workflow, dealing with those numbers means that:

• the size on disk of those data is something like 100Gb;
• generating test data takes a long time: hours;
• having more than one test environment on the same machine is a problem;
• changing the shape of the data to test a different scenario takes ages;
• changing the data indexing strategy takes a long time;

All these interesting problems when faced are a key driver for the application that must deal with those huge data.
.m

RavenDB: Training in Italy

This post is intended especially for the Italian audience, and will be in Italian. This post is about a RavenDB training class, organized with the official support of the Hibernating Rhinos guys, that will be delivered on the second weekend of June in Perugia (8-10).
------
Sono molto orgoglioso di poter annunciare che Andrea Balducci, Andrea Cruciani, Gian Maria Ricci e il sottoscritto, con la collaborazione e il supporto di Hibernating Rhinos, hanno organizzato il primo corso ufficiale in Italia su RavenDB.
Il corso si svolgerà a Perugia dal 8 giugno al 10 giugno, la prima edizione è di un giorno in più rispetto al programma ufficiale perché l’obiettivo è duale:

• Avere tempo per discutere ampiamente degli argomenti che tratteremo;
• Avere più tempo a disposizione per tarare e testare le prossima edizioni;

Per i dettagli organizzativi vi rimando alla scheda ufficiale del corso.
Ci tengo anche a sottolineare che la location scelta (grazie Andrea Cruciani e alla sua azienda) è l’equilibrio perfetto tra comodità logistica, passione culinaria e amenità paesaggistica.
Vi aspettiamo,
.m

#Guisa1: event logistic

The Guisa1 event is approaching, this post is to give some logistic details. The official event hash tag is #guisa1.
Event Location
The event is hosted by “Banca di Credito Cooperativo” (Aula "G. Carminati") Via C. Carcano 15, Treviglio (BG) the bank is located in the town center and can be easly reached by walking from the railway station in 10 minutes.

View Larger Map
For attendees coming by car the best (free) parking is located near the swimming pool:

View Larger Map
If someone is interested in staying in Treviglio the night before the event or the night after the event the best hotels in town are the following (in my order of preference);

1. Hotel “Treviglio”, near the railway station;
2. Hotel “Atlantic”;
3. Hotel “La Lepre”;

As usual the evening right after the event we have organized a dinner, as soon as I have more details about the location I’ll post an update.
.m

Identity Federation: who cares?

Today I twitted something like:

Mauro vs. ADFS + trusted custom identity provider: 1 - 0 :-) tomorrow will be harder :-)

And my dear friend Igor replied something like:

I’m really curious to know the usage scenario of ADFS

What does “Identity” mean?

Identity is a really simple concept that we face day by day in our life, each time we meet a friend we immediately recognize him, or her, given a set of well known criteria: face, voice, behavior, etc.…

We own the set of criteria that let us recognize our friends, but what happens when we meet someone we have never met before and that claims to be a specific person?

Identity Providers

We obviously need to rely on someone we trust, we can ask to the unknown party the identity card (with a photo ID, a first name and a last name) and since we trust the issuer od the identity card we can trust the person that claims to a specific person.

So far and so good…but…

What happens when we are in a foreign country and someone asks us about our identity? we can provide our own passport (with photo ID, first name, last name and issuer country)…but why the relying party should trust our passport? basically because she trusts her own government that itself trusts our government that is the issuer of the identity.

The relying party government and our government are federated by a trust relationship, this is identity federation :-)

So what?

Don’t you see the big picture? Let’s say that we work for an international shipment provider, the company delegates a lot of the work to partners outside of the company domain, but these partners need to have access to information secured behind the company domain based security infrastructure:

But there is no way to have an account for the partner created in the company domain, can we “steal” some concepts from the above passport sample?

1. One employee of one of the partners tries to access internal data;
2. The internal security system asks the employee for credentials;
1. obviously the partner employee credentials cannot be validated by the company domain controller;
2. the partner employee go to its own security system, authenticates and asks for a security token (the passport);
3. goes back to the company domain controller and presents the security token (the passport);
4. since the company domain controller trusts the partner security system the company domain controller:
1. goes back to the partner security system and verifies the validity of the issued token;
2. asks to the partner security system a set of information (first name, last name, photo in other words “claims”) required by the company to allow the access;

We obtained that the security credentials of the partner employee are stored in one single place and are managed by the organization that owns those credentials.

But…Active Directory does not provide all these features, so who is the orchestrator that can link together different security systems? (as you may have notice I’ve never said that the partner security system is Active Directory, too easy :-P)

Please welcome the A.ccess C.ontrol S.erver

The ACS in our scenario is something that can manage trust relationships between different security systems, is something that can translate the language spoken by Active Directory and the language spoken by the Asp.Net MembershipProvider into something common, that is based on a shared concept: claims.

So what happens is that our shipment company installs Active Directory Federation Services (ADFS) and configure two different trusted claims provider:

• The “Active Directory” claims provider is the company internal Active Directory;
• The “Partner IdentityServer” is the external trusted IdentityProvider (in this case a custom Security Token Service and Identity Provider based on Asp.Net Membership);

The last step

When an anonymous user tries to access the company internal application he is presented with the authentication procedure:

Where the use need to select the identity provider to use to start the authentication process.

We miss two steps:

1. the client application configuration;
2. the ability to automatically determine the identity provider without exposing to anonymous users the list of the supported providers;

but those are for another story :-P

.m