• On-Demand : Something in your application happens and it needs data. It specifically asks the server for that data upon encountering the need for that data. This is what most people think of as "pull" data.
• Push : This is where you need data sent to your application as the data becomes available and the overhead of setting up a timer on which you pull (or poll) for data is unacceptable to you. The main reason why this is unacceptable to people is because there may be frequent periods of time where the pull/poll has no data, which means your app will be occupying server resources every X seconds even when there is nothing to do.

The Polling Duplex channel is a solution to the push problem. It allows server-side code to "push" data down to the Silverlight application. Under the hood the channel is using "Comet"-style tricks keeping HTTP connections open in much the same way that the Gmail application is able to receive push notifications of new mail.

This is great and the programming model for communicating with the Polling Duplex channel is brain-dead simple. It does NOT get any easier to implement push data to a RIA - not in Flash, not in AIR, and certainly not in JavaFX. The problem is that this solution doesn't scale. On the server side, for each concurrently running Silverlight application (so probably one per concurrent user), there is a full live socket being consumed that will not be relinquished until the client disconnects/closes their browser.

Worse is that the Polling Duplex channel defaults to only allowing 10 concurrent connections. You can programmatically tweak that by configuring the throttling behavior (as shown in this blog post here ).Even if you do increase the amount of concurrent connections allowed, those concurrent connections are still going to beat the crap out of your servers and good luck getting that to work seamlessly in a cluster/farm scenario.

If you need more than a handful of concurrent users and you want to do it in a way that scales and doesn't abuse your servers, then I highly, highly recommend looking into some kind of messaging / open gateway server. The only one I've played with for more than a few minutes is Kaazing , but I have nothing but good things to say about it. It's based on HTML 5 Web Sockets so you will be in good shape for the future.

Web Sockets are freaking awesome but that's a topic for another post.

Bottom line here is that if you're looking at any of the Polling Duplex samples online like the "stock ticker" sample, don't be fooled. It looks easy, but especially in the financial industry, you need high concurrency, high speed, low latency - and you're not going to get that with the polling duplex channel. If there was one place where I see it fitting is in the creation of intranet applications internal to an organization with a limited number of concurrent users.

A couple of weeks ago my family and I started packing boxes in preparation for fleeing the great state of New Jersey. We packed everything up, threw as much as we could in the minivan and trekked up to Connecticut where I have taken a new position with a new company as a .NET Architect. As any of you who have moved before know, it's an incredibly stressful experience and the logistics involved are absolutely ridiculous. It's a miracle I still know where my car keys, sneakers, and computers are. At one point I was sure I'd left the cat on the roof of the minivan.

We're now in Connecticut, huddled into a small hotel room while we await the closing date on our new house. One of the rather unexpected side effects of moving was that, in relinquishing equipment belonging to my previous company, I suddenly realized that I do not actually own a machine capable of running Windows Vista or Windows 7, thereby preventing me from accessing Visual Studio 2008 or VS2010!! All of my addictions to things like Azure, Oslo, "M", and VS2010 are currently suffering horrible withdrawal symptoms.

Needless to say, while I currently only own a Macbook Air and a Macbook Pro 17" (without enough disk space remaining to boot camp Vista), I haven't had much in the way of ability to blog about my usual fare. I am using the iPhone 3.0 SDK which, I believe is still currently under NDA (though as of yesterday it might not be...).

So the plan is thus: I will acquire a Windows machine once we've closed on the house and paid for the essentials that are normally associated with moving into a new place. Then I will be able to go back to blogging about the finer points of WCF4, WF4, C#4, Azure, and all the other goodies coming up. Also, if I get a chance, I might even post some iPhone code samples for the new 3.0 SDK (which rocks, btw).

Please bear with me as I go through this transition and I will be back to blogging like my usual (old) self in no time!

The issue is that when you look at the unit tests for the AccountController, they are positively littered with manually mocked classes. I realize that this is because you don't want to make the default project template rely on a third party mocking library so in this blog post, I'm going to show how you can delete all of the manually implemented mocks for the identity, principal, membership service and forms auth service. The secret is using Moq. Moq is a lightweight mocking framework for .NET that was designed specifically for the .NET Framework 3.5 and LINQ. As such, definining mock expectations and mock return values is all done through lambdas in a ridiculously easy to read syntax, as you'll see below.

First, you want to add a reference to the Moq library. To get Moq, you can go to Moq's Google Code home page . Once you've got the Moq library on your machine, add a reference to it from your unit test project (you did choose to create a unit test project with your new ASP.NET MVC project, didn't you?). With that in place, you can replace the contents of the "GetAccountController()" method with the Moq-enabled one below:

private static AccountController GetAccountController()
{            
    var mockFormsAuth = new Mock<IFormsAuthentication>();
    var mockUser = new Mock<MembershipUser>();

    mockUser.Setup(u => u.ChangePassword(It.IsAny<string>(),
                   It.Is<string>(s => s == "newPass"))).Returns(true);

    var mockMembership = new Mock<MembershipProvider>();
    mockMembership.Setup(m => m.EnablePasswordReset).Returns(false);
    mockMembership.Setup(m => m.EnablePasswordRetrieval).Returns(false);
    mockMembership.Setup(m => m.MinRequiredNonAlphanumericCharacters).Returns(0);
    mockMembership.Setup(m => m.MinRequiredPasswordLength).Returns(6);
    mockMembership.Setup(m => m.ValidateUser(It.IsAny<string>(), 
       It.Is<string>(s => s == "goodPass"))).Returns(true);
    mockMembership.Setup(m => m.GetUser(It.IsAny<string>(), 
       It.IsAny<bool>())).Returns(mockUser.Object);

    // Registration success mock
    MembershipCreateStatus goodStatus = MembershipCreateStatus.Success;
    mockMembership.Setup(m => m.CreateUser(It.Is<string>(s => s == "someUser"),
        It.Is<string>(s => s == "goodPass"),
        It.Is<String>(s => s == "email"), It.IsAny<string>(), 
        It.IsAny<string>(),
        It.IsAny<bool>(),
        It.IsAny<object>(),
        out goodStatus)).Returns(mockUser.Object);

    // Registration failed mock (duplicate username)
    MembershipCreateStatus dupeStatus = MembershipCreateStatus.DuplicateUserName;
    mockMembership.Setup(m => m.CreateUser(It.Is<string>(s => s == "someUser"),
        It.Is<string>(s => s == "badPass"),
        It.Is<string>(s => s == "DuplicateUserName"),
        It.IsAny<string>(), It.IsAny<string>(), It.IsAny<bool>(), It.IsAny<object>(), out dupeStatus));

    AccountMembershipService mockService = 
      new AccountMembershipService(mockMembership.Object);

    AccountController controller = new AccountController(mockFormsAuth.Object, mockService);
    controller.SetFakeAuthenticatedControllerContext();
    return controller;
}

What you can then do is delete all of the manually created Mock classes. Additionally, there's a unit test that verifies whether or not the constructor has set the appropriate properties. You can remove that if you're using Unity to construct your objects (which I am, as indicated in the previous blog post).

The SetFakeAuthenticatedControllerContext() is an adaptation from one of Scott Hanselman's MvcMockHelpers.

What I like so much about this is that Moq lets me take the intent of the original code and reduce all that extra plumbing and "ceremony" and just get down to what is really important - what I want the Moq objects to provide to my objects under test. I can't imagine doing unit testing without a decent mock framework like this and again, what I like about Moq is its simplicity.

There are two main things that I wanted to accomplish with the Unity integration. The first was that I wanted my controllers to have the objects on which they depend injected into them in standard DI fashion. Secondly, I wanted the controllers themselves to be resolved through the IoC container rather than being tightly coupled by the routing rules. This would allow me to yank in and out different controller implementations if I need to (I figured this would come in quite handy for TDD and unit testing).

The first part is easy, just grab the Unity DLLs and reference them in your MVC project. At this point, you're now free to use Unity to inject whatever you feel like. Rigging up the controller factory so that it will use Unity to resolve controllers is equally easy because the mvc contrib codeplex site has already created a class called UnityControllerFactory that does just this. Once you've added references to Unity and Mvc.Contrib.Unity from your MVC project, you can change your global.asax.cs file to look something like this:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Mvc;
using System.Web.Routing;
using MvcContrib.Unity;
using Microsoft.Practices.Unity;
using UlyssesAgenda.Controllers;
using System.Web.Security;

namespace UlyssesAgenda
{
    // Note: For instructions on enabling IIS6 or IIS7 classic mode, 
    // visit http://go.microsoft.com/?LinkId=9394801

    public class UlyssesApplication : HttpApplication, IUnityContainerAccessor
    {
        public static void RegisterRoutes(RouteCollection routes)
        {
            routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

            routes.IgnoreRoute("{filename}.ico"); // IE8 requests this and it tries to hit a controller for it.
            //routes.IgnoreRoute("{filename}.png");

            routes.MapRoute(
                "Default",                                              // Route name
                "{controller}/{action}/{id}",                           // URL with parameters
                new { controller = "Home", action = "Index", id = "" }  // Parameter defaults
            );

        }

        protected void Application_Start()
        {
            InitializeContainer();
            RegisterRoutes(RouteTable.Routes);            
        }

        protected virtual void InitializeContainer()
        {
            if (_container == null)
            {
                _container = new UnityContainer();              
                ControllerBuilder.Current.SetControllerFactory(typeof(UnityControllerFactory));                                
                
                _container.RegisterType(typeof(HomeController), typeof(HomeController));
                _container.RegisterInstance(typeof(AccountController), new AccountController());                
            }
        }
        
        #region IUnityContainerAccessor Members

        private static UnityContainer _container;

        public static IUnityContainer Container
        {
            get { return _container; }
        }

        IUnityContainer IUnityContainerAccessor.Container
        {
            get { return Container; }
        }
        #endregion
    }
}

You'll notice that I mapped the HomeController type and allowed Unity to manage the instantiation of it. However, with AccountController I created my own instance. The main reason for this is that account controller relies directly upon a service which relies upon a SqlMembershipProvider instance. If I attempt to constructor-inject the AccountController, I get stuck in a quagmire where I have to register my own instances of SqlMembershipProvider and SqlProfileProvider and much more - and that removes the flexibility I get from defining that stuff in the Web.config file (and potentially breaks other ASP.NET functionality by not having it in that file).. So (just this once!) I am allowing the AccountController to be a manually created instance that is injected by Unity.

Next, I'll be posting about how to convert the default Unit Tests for the AccountController into tests that use Moq rather than hand-mocked POCOs.

I don't really know how this one slipped through the cracks and its more of a nitpick than a real bug, but it is application-breaking nonetheless. All you have to do in order to see the bug is attempt to log into the default ASP.NET MVC project after creating it and don't check the "remember me" box. I guess that edge case never got tested ;)

Anyway, the fix is quite easy. I just modified the signature of the LogOn method in AccountController to look like this:

public ActionResult LogOn(string userName, string password, bool? rememberMe, string returnUrl)

Notice that rememberMe is now a nullable parameter. Now you can't pass a nullable bool to the actual implementation of the LogOn method in the forms authentication service they provide, so you can just do something like this to pass along the appropriate information:

FormsAuth.SignIn(userName, rememberMe == true);

This will give you a meaningful default value of false.

Again, given the ridiculously high quality of ASP.NET MVC 1.0, I'm not really sure how this slipped through other than the idea that maybe most people yank out the default AccountController or all of the testers checked "remember me" :) Either way, it's a 30 second fix.

This got me thinking about Windows Azure, Microsoft's "cloud operating system". I'm not really sure I like that particular marketing slant on what Azure is, because at the same time Azure is so much more than an OS and yet doesn't function like what a lot of people would consider to be an OS. Regardless, the promise of Azure is that you can build your hosted services on your local machine and deploy them "to the cloud" quickly, easily, and simply. What Microsoft says you get in return for hosting your services is scalability, reliabiltiy, and ease of maintenance without having to have all of your own data center infrastructure.

There are plenty of other resources avaiable on Azure so I won't go on and on about it here but the main idea is that you can build your data-driven web application to work against a cloud-based data source, communicate with cloud-based services, and deploy to Microsoft's data center in the cloud (which now has configurable geography-based affinity). The main barrier to entry that I see here is how EASY things are. If an ASP.NET developer attempts to go build a web application that is based entirely on Azure services and they encounter road blocks, headaches, sources of frustration and places where "it's just broken" instead of "it just works", they aren't going to use it. In fact, they will probably start blogging about how bad the experience was.

What Microsoft needs to do is ensure that going forward, it is as easy to build and deploy Azure hosted services ASP.NET applications as it is to build and deploy Ruby applications with Heroku. I should be able to seamlessly build against a local version of the cloud data store that requires NO CHANGE on my part to work against the remote cloud store. Right now, this is broken and there are subtle incompatibilities between the local fabric simulator and the actual cloud fabric in Microsoft's cloud. This is annoying and a speed bump. When I'm satisfied that my local application works the way I want it to, I should be able to migrate that application from my machine to the cloud quickly, easily, and in a way that I can automate or control. This includes a way to migrate the data currently stored in my local fabric to the data stored in the cloud fabric. Right now Azure doesn't do this - your local fabric Azure Storage data has no way of being migrated to the remote storage unless you write code to do it.

So, to summarize - if Microsoft can make the process of developing Azure-based ASP.NET web applications as simple, easy, reliable, automatable and pleasant as the Heroku deployment process then they will find developers flocking to them in droves, begging to get their apps hosted in the cloud. On the other hand, if they make the process brittle, rigid, slow, painstaking, and what some people consider "Microsofty" then developers will universally cry "Meh" in response to Azure and possibly even pick up Ruby as a new tool just so they can take advantage of services like Heroku.

If you're following along, you can grab the "M" file that I created in the previous blog post or you can create your own. The repository is a central storage location for models. Not only does it contain the actual schemas generated by your model image, but it also contains a lot more like security and versioning information. In the interest of keeping this post as small as possible I won't go into too much detail, but you can find tons of Repository-related videos over on the Oslo Developer Center .

The first thing we need to do is compile our model. To do that, we'll use the command-line tool that ships with the CTP called m.exe. This tool can be used to generate regular T-SQL, repository SQL, and of interest to us: a repository image of the model. Sticking with the M file I created last time, I can open up a command prompt, make sure the Oslo SDK "bin" directory is in my path and issue the following command:

m UlyssesAgenda.m /p:image

The output is a file named UlyssesAgenda.mx. This is a compiled M file. Now we need to get the compiled M image into the repository. Using this CTP we can accomplish that from the command-line as well using the MX utility:

mx -i:UlyssesAgenda.mx -d:Repository -s:kev-win7\SQLEXPRESS

Depending on your configuraiton, you may not need the "-s" command line switch to indicate the server where the Repository database is stored. In my case, I have a full-blown installation of SQL Server 2008 and SQLEXPRESS is not my default instance so I've found that every now and then that means I have to modify connection strings or, in this case, pass the server/instance explicitly.

And now we can look at SQL Manager and we see that all of the tables that correspond to our high-level model were created:

Using the MX command-line tool we can also directly query the repository. I thought it worth showing the output of this because it illustrates one of the more valuable aspects of Oslo - model versioning:

>mx -l -d:Repository -s:kev-win7\SQLEXPRESS

Microsoft (R) code name "M" Command-line Utility version 1.0.1308.1
Copyright (C) Microsoft Corporation. All rights reserved.

Contents of the database
============================================================

Models.mx                 Models.mx;Version=1.0;Locale=neutral
UlyssesAgenda             UlyssesAgenda;Version=1.0;Locale=neutral

Models.mx is the compiled list of all of the stock models that Microsoft has provided and put into the database as part of the core Oslo offering. What I think is really important to keep track of is that the models themselves are versioned. There are no table versions - the versioning takes place at the model level which is, IMHO, where it should be. Also keep in mind that because at the lowest level we've also created a standard SQL schema, you can use any tool you like against this server, including LINQ to SQL or ADO.NET or the Entity Framework. 

So now we've created a model and put it in the repository. In upcoming blog posts, I'm going to cover some of the other interesting things that you can do with models.

What "M" allows us to do is model in text. But this isn't like typing XML (thank God). Instead, what you're typing is a clear representation of your intent. The end result is a clear, concise description of your model. More importantly, this textual description of your model can be reasoned on, passed around for comment, versioned, and stored. When you feel like creating SQL tables out of this model, you can do that. If you need to create new versions of the model that are compatible with old versions of the model then you also have that ability (though that topic is beyond the scope of this blog post).

I'm always a big fan of trying this stuff out myself. The problem with a lot of models is they're too simplistic. So, rather than enter in a model for a customer than their phone numbers or some other contrivance to suit a "Hello World" sample, I decided to model the data structures for a space-based trading/conquest game that I designed a long time ago and just never got around to implementing for various reasons. This game allows the player to create their own super-massive ship and this ship can carry cargo and it can also have a squadron of fighters associated with it. There are more details to the game but I won't bore you with those.

So I started off by creating a type that I called "Ship":

type Ship
    {
        Id : Integer32 = AutoNumber();        
        Sector: Integer32;
        X : Integer32;  
        Y : Integer32;
        Z : Integer32;
        CurrentFuel : Integer32;        
        Owner : Avatar where Owner in Avatars;
        HullType : HullType where HullType in HullTypes;
        DriveType: DriveType where DriveType in DriveTypes;  
        TacticalSystemType : TacticalSystemType where TacticalSystemType in TacticalSystemTypes;      
    } where identity (Id); 

What I like about this model is it is easy to read. You don't have to sift through a bunch of T-SQL crap to figure out that my ship objects (whether they be rows in a table or instances of CLR objects or whatever...) will have some kind of location (sector, X, Y, and Z), the ability to consume fuel, a configurable hull and engine type, as well as a configurable tactical system. All very straightforward, easy to read, easy to share, and easy to comment on and maintain. Also remember that this model can be visualized in Quadrant (we don't yet have a standalone CTP for Quadrant yet) and it can be stored in the repository for querying and safekeeping.

Take a look at the screenshot below. On the left you can see my "M" modeling code and on the right you can see IntelliPad giving me a preview of what the T-SQL is going to look like that generates this model:

When looking at your model, which would you rather see, a statement that indicates that a Fighter has a reference to the Ship entity in the Ships extent (M) or a whole bunch of stuff about foreign key constraints and database columns? When I'm architecting a solution, I want to look at the "M", especially if I don't yet know how I'm actually going to physically represent this model in my applicatoin code yet. There are two avenues: I could reprsent them in SQL and use the models to generate T-SQL or I could host the models in my own runtime and CLR instances from Mgraph instances from a DSL (I'll show that in a subsequent blog post).

For now, let's assume we're modeling for the database. The screenshot only gives you a small glimpse of the benefits you get by using "M". Anything more complex than my really simple game model would consume hundreds of tables and have thousands and thousands of foreign keys and constraints and other things... Other things that would be much easier to grasp when looking at "M" than looking at T-SQL or even the SQL design surface.

In the next blog post I will show how to interact with the Oslo repository using this model that I just created. If you want to see the entire model that I created for this fictitious game, click here .To see the SQL behavior, just click the "M Mode" menu in Intellipad and select the Generic SQL preview.

I don't claim that my information will be any more cohesive than Microsoft's, but I'm writing this post as much for my own edification as I am yours. I often gain better insight about things I'm working on by blogging about them or trying to explain them to others.

What is Oslo?

This is, of course, a loaded question. The fact that Oslo appears to be so many things is one of the big problems. In short, Oslo is all about modeling. Not just data modeling in the traditional sense of sketching out ERDs but in the abstract notion of simply creating models. More specifically, Oslo is what I would call a platform for model-driven development. Everything that Oslo has and does is designed to enable developers to do model-driven development.

Model-driven development is what a lot of us do without knowing it. We start with abstractions of the models on which our application needs to operate (whether these models become C# classes or tables in a database is irrelevant at this point). As work progresses the models become more refined until finally we're working with code. Some of the classic problems that come with model driven development are:

• Model Complexity - Not every application is a "Hello World" app. Real-world data-heavy applications have hundreds or even thousands of database tables. Now add to the mixture SOA and exchanging a subset of those models with customers or business partners over web services, through Biztalk, etc and simply managing and keeping track of all of your models can become a burden or even a nightmare.
• Model Versioning - Many environments are extremely rigid and brittle and make it very hard for us to version our models. If we're managing a model domain that is vastly complex (see previous bullet), making small changes to this model often involves weeks of "deployment on our knees" (deployment that involves more praying than deploying).
• Unified Language - Sure, we've all probably used UML for modeling but UML is over-hyped (IMHO) and not everybody understands it or worse, people think they understand it and use it incorrectly. Since everyone seems to have their own unique interpretation of how they should be doing UML ... it isn't very universal is it? Also, 99.9% of all UML tools I've used in the past have sucked.
• Model-to-Code Resistance - In most cases right now, model-driven development can seem like an awful lot of work. People usually give up because their abstractions are nice to look at and they give people a nice frame of reference, but there is often a herculean effort that goes into converting that model into executable code or store-able data. Because of this, people think it's not worth it.
  

Wouldn't it be awesome if we could do model-driven development in a way that allowed our developers, architects, designers, and business stakeholders to all communicate about that model using a unified language? Better still, wouldn't it be awesome if we could take that same shared model, store it in a repository of models that can be re-used throughout an enterprise, and then actually use that model directly to build data, generate code, or even execute the model directly? This is the crux of what Oslo is attempting to do.

What you get with Oslo is the following:

• "M" , the Modeling Language. It's syntax is very simple to read even if you're not a hardcore developer. This means that reasonably tech-savvy business analysts will be able to understand your model definitions even from the text you've written in "M". "M" allows you to define model schemas (types) as well as instances of models (extents). If you are using "M" to target SQL, this means the same language you use to define your table schemas can be used to define the contents of those tables, and it's a hell of a lot nicer to look at than SQL, T-SQL, or PL/SQL.
• "Mgrammar" or "Mg". This is a language that allows you to define your own DSLs (Domain-Specific Languages). A DSL is a language for declaring instances of models or model data. Mg takes a little getting used to, but it dramatically simplifies the process of making a DSL, so much so that people who used to think DSLs were too much work should reconsider that evaluation based solely on the existence of Oslo.
• Model Repository - SQL Server database to allow for storing, versioning, and querying models. Multiple blog posts could be written on this so I'll keep it brief here.
• "Quadrant" - A visual modeling tool written in WPF that allows you to visualize models defined by "M" and stored in the repository.
• IntelliPad - An incredibly extensible editor that you can use to write your models, your Mgrammar languages, and even test your DSL input and output dynamically.
• Visual Studio Integration - quite frankly this sucks (during this CTP) compared to just using IntelliPad and the command-line tools so I don't really have much to say about this.

Why should I Care?

The bottom line is if you build data-heavy applications or applications with large models or you are currently doing your development in a model-first fashion, then you should definitely be looking into Oslo and experimenting with it. I will be showing an example of what this looks like in an upcoming blog post, but the simple benefit of being able to define your model in the easy-to-read "M" instead of writing your own T-SQL directly is a beautiful thing. 

There are other things that are all worthy of their own blog posts like integration with Dublin (Microsoft's new Web Application Server Extensions... think of it as a container for WCF and WF services), using the repository to query and version shared models, and much more.

I've already experienced how different it feels to start with a simple .m text file to define my model. I can see what kind of SQL it would generate on the fly. Once I'm happy with the model, I can put it in the repository. Now if I want to I can create my own Domain-Specific Language (DSL) for defining instances of my models in a way that makes sense to the domain experts, not necessarily in a way that requires a programmer.

Anyway, this is just a quick overview of Oslo... the more lengthy I make this post the more I run the risk of confusing people with too much details too soon. I will be posting subsequent blog posts that go into the details of all the different parts of Oslo that interest me and that will hopefully interest you as well.

The basic idea behind the game, from the player's perspective is this: you get a magic wand (and potentially other stuff like a belt or holster for said wand, plus a "tome of knowledge" to help guide you on your quests). Nearly half of the hallway space in this hotel that would otherwise remain "just a hallway" was repurposed as the setting for this game. The kids (and many grownups) go to a special forest with touch-screen monitors in the trees where they can be given quests. Once they have an active quest, they go around scavenger-hunt style "gathering" ingredients by waving their magic wand at everything from paintings on the wall to stars in the ceiling to animatronic raccoons. The game keeps track of what quests you've done, where you've been, etc. You can even go around hunting gold by waving your wand at the locks on chests, some of which tell you that you've found gold when they open.

From a technology standpoint, what you have is this: The magic wand is an IR transmitter and there are various devices with varying levels of motion/lights/bling that respond to IR transmissions. The wand sends what amounts to a GUID to each device. The device then reads the GUID, checks back with the quest server to see where you are in terms of quests, etc and then responds accordingly. This can be anything from triggering a video playing on a wall-sized screen to opening a chest to making a statue's eyes glow.

The game itself has all the hallmarks of being awesome for kids to play: persistent state, measured progress, rewards for completing tasks, unlocking of new tasks when you reach a given level, very creative interface and an extremely high degree of interactivity. What I found fascinating about it was its novel take on user experience, which I review below.

What developers should pay particular attention to here is how universal some concepts of UX are and how integrated technology AND design are when it comes to producing both good and bad experiences. 

UX Review - The Good

What I found utterly fascinating was the use of what would otherwise be completely dead space in the hotel and turn it into a space that is not only useful, but revenue generating, fun for the kids and a space that creates fond memories that can increase customer loyalty and brand recognition.

The software that runs the system is somewhat forgettable. It actually is pretty cliche, most of the screens that users interact with look kind of like scrolls or unfurled maps and everything is done in a medieval font. But what I think developers should take note of is that nobody remembered the GUI. Everyone remembers the experience they had running around the hotel looking for hidden objects and solving puzzles and getting their parents help to decipher clues. It's all about the experience.

UX Review - The Bad

While this was a truly awesome User Experience, there were also a lot of pain points, many of which were visibly frustrating the kids and driving the parents insane (myself included).

Race Conditions

Just about everyone who has written server-side software or even many types of multi-threaded client applications is aware of the problems inherent with performing multiple tasks at the same time. These problems occur in software where two different requests occur at the same time (or nearly the same time). If the application is poorly designed, these types of requests can create inconsistent data at best or at worst cause ugly crashes. The hotel's game has this problem too : if two kids run up to a quest painting and wave their magic wands at it the painting lights up and gives the "congratulations" speech indicating that the kid got the item. The problems is, how do you know which wand triggered the painting? Kids have neither the patience nor the understanding of how crappy software works to be able to guess, "Hey wait. We should both try that again serially to ensure that we both got the quest reward." ... Hell no, the kids see the painting light up and both assume they got the reward. The kid who lost the race condition doesn't find out he lost until he goes to slay the dragon and finds out he doesn't have the Gem of Awesome or whatever.

Perceived Performance

There are few things you can do to screw up someone's impression of your application more than making it run slowly. This is especially true for non-technical users. "Regular" people don't give a crap about latency, network bandwidth, wireless radio interference, or any of the other excuses that us technical people can handle for poor performance. Regular people push a button and they want that button to do something, immediately. Kids are even less tolerant. Right around 9:30pm or so, about a half hour after the pool closes and every kid in the hotel has had a chance to change out of their bathing suits and into regular clothes - a swarming horde of kids descends upon the quest-enabled hallways. I've seen this bring the system to its knees. Kids wave their wand at the final encounter with the dragon. They know the dragon video is supposed to come up so they can start the routine to defeat him. But the dragon doesn't come up... So, the kids wait patiently until the request queue clears enough to allow the video cue request to come up, right? Hell no. The kids just start wanding the activation stone over and over again. Worse, multiple kids do it at the same time. So now when the system finally does unclog and is able to start servicing requests, instead of cutting the queue short, it processes them all, so the dragon spits, spasms, twists, contorts, makes a bunch of funny noises, and then 30 seconds later is congratulating the last kid to wave his wand... and nobody knows who got the reward.

The "Devil User"

Everybody has a different word or phrase for this user. This is the user that never pushes the right button, never waits for the system to finish doing what it's doing before pushing more buttons and always manages to find a way to completely screw up a system or put it in a totally confused state. The thing about this application that I can imagine was particularly difficult is that every single user of this application is a devil user. You cannot assume that anyone is going to "play nice" with the game... Especially when the interaction involves physically shaking a wand they're holding in their hands.

Summary

I think the single most important thing that stuck with me after this weekend was that the kids weren't talking about the cool screens in the application. None of them were talking about how awesome the back-end server infrastructure must've been. Nobody cared about the use of IR plus an accelerometer to "cast" the wand. Instead everyone remembers playing the game. They remember what it felt like to have their imagination stimulated, to solve puzzles, to experience the game. They do not remember interacting with the game unless the interaction was frustrating. You can screw up a User Experience very easily whether you are talking about a novelty live-action game at a hotel or whether you're talking about your company's corporate website.

The moral of the story here is that as developers, whether we're building iPhone apps or live-action interactive RPGs or enterprise websites, we should be thinking about how we can create a compelling experience and a truly forgetful user interface.

Think of it this way. I've got a toolbox with a bunch of tools in it. I know how to use the screwdriver and I know how to use the hammer. The security guy, however, can look at that toolbox and build a backyard BBQ complete with big-screen TV. I, on the other hand, would probably end up building a shaky birdhouse that makes all the nearby birds go, "WTF?!".

The point here is that when I talk to security people about Geneva, they usually only need one or two sentences of overview and they get it. Developers who have been working with applications secured using conventional/traditional means often don't have enough context to dive right into the Geneva documentation without feeling lost.

So I'm going to try and explain Geneva in terms that developers who have spent most of their time using various flavors of "credential passing" can easily digest. I think the most important thing to keep in mind while reading this is a conversation I had with a true security guy once. I said, "What's the safest way to send credentials so they can't be spoofed, re-directed, or stolen?" He responded with, "Don't send 'em".

A Brief History of Geneva

Disclaimer: This is the history as far as my involvement goes back. There could easily be many more months or years of history that I'm not aware of. I remember back as far as PDC 2003 (seriously, I can actually remember that far...). They handed out these nifty little flashlights that said "WinFX" on them (I still have it!). WinFX was then the codename for what would encompass the codenames for Avalon (WPF), Indigo (WCF), Workflow Foundation, and this other obscure and confusing thing called InfoCard.

What InfoCard set out to do was to allow the desktop GUI to present the user with a list of "Cards". These cards could then be sent to a website (that had suitable WCF + InfoCard coding on it) and the website would know who they were. The grand scheme was to eventually see things like your own VISA card in this list, issued to you by your credit card company. Whenever a website asked for a credit card, you could "show" them this card and the site would be able to make your purchase without ever having been given direct access to your credit card number.

There are a few hundred tangents I could go off onto here but the main thing that I felt was that InfoCard was ahead of its time. There were trust issues, issues with it requiring Longhorn (during the first preview we got to see anyway) and even more of a barrier was that every site would have to do extensive work just to support this thing that currently had 0 adoption rate.

Over the years InfoCard became CardSpace and it got better at doing what it did, but the adoption rate (at least within my circles) was limited to 0 commercial users and the rest were developers doing samples for blogs and conferences.

Then came a project called "Zermatt". Zermatt, in my opinion, was an attempt to decouple all of the various pieces that made up the CardSpace infrastructure and finally make the use of tokens (discussed below) more standardized, more open, and more importantly, easy for developers to adopt. I played with Zermatt, loved it, thought it was a great improvement over previous incarnations of CardSpace... but it still felt lacking. Sure, it was a nicer, friendlier, more accessible CardSpace but it didn't make the adoption of federated identity and claims-based authorization (again, discussed below) easier in an enterprise.

This is where Geneva comes in. Geneva is a suite of products consisting of: Geneva Server, Geneva Framework (.NET SDK that does not require a PhD in security to consume), and CardSpace "Geneva". The Geneva Server looks to be something that you can simply install, configure easily, and fire it up and you now have Geneva support in your enterprise. Let's hope it continues to aim for that target. Geneva is currently in Beta 1 and you can download it from Microsoft.

Claims vs. Credentials

If there was one thing that I thought you needed to be able to firmly grasp about Geneva it would be the concept of claims. Claims are something that may feel very new and very alien to developers used to the traditional model that looks something like this:

User hits your website (or your desktop app..) and is prompted for a username and password. The user then submits their credentials. Your website grabs those credentials and validates the user. If the user is valid, the website can then go fetch the user's profile information and other information about the user including the roles to which they belong for security purposes.

What Geneva (and other industry standard solutions that conform to the same set of protocols and languages that Geneva speaks (more on that later)) operates on are claims. A claim is really just a statement of fact. It could be anything from "my name is Kevin" to "my credit card number is 1111-1111-1111-1111". Claims are very special statements of fact, however. Every claim comes with a sort of guarantor - some entity that has certified that claim to be true. You, as a developer, also get some information about the entity certifying the claims.

Here are some more examples of claims (deliberately not showing what a claim looks like in code):

• My name: Kevin, Issuer: Me
• My e-mail address: alothien@gmail.com, Issuer: Gmail
• My security role: Administrator, Issuer: FantasticSite.com

As the developer of a site that accepts claims I realize that the "name" claim is self-certified which means it's pretty insecure (the user can pick anything they like). But, in a lot of cases, especially for sites like a message forum, I really don't care if the user is who they say they are. The e-mail address claim is interesting because (assuming Gmail was involved in this scenario) we can verify with 100% certainty that the e-mail address for that user did actually come from Gmail. Finally, we see that the user is also claiming to have administrative access on the site FantasticSite.com. If we have a trust relationship (federation anyone?) with FantasticSite.com, we can then know without a doubt that the user is actually an administrator.

Couple of things of note here... First - there are no credentials. There is no username and no password in this set of claims. Now, the user may have had to enter a username and a password in order to be given one of the claims (like the Gmail address), but that username and password was only ever sent to Google, not us. Second - we know who certified the claim and we also know how much we trust claims from that source and we can use that to make an informed decision about whether or not we're going to accept the claim. [Oversimplification Warning] basically the entity that certifies the claims digitally signs the claim with it's private key. We then use the public key to verify the signature. In this fashion, we know without a doubt that the claim came from that entity and hasn't been tampered with or faked.

Security Benefits

So now we have a basic idea that Geneva works by taking the authentication and authorization bits that are normally hand-rolled by your team and tightly coupled with your solution and abstracting it out to the use of external parties. So what exactly does this buy you from a security standpoint?

As I mentioned earlier, what this means is that no two relying parties (sites/applications that rely on a Geneva or Geneva-like infrastructure) need to share the same backing store for users. This means that secure user information is never stored outside the single authoritative location for that user information. More importantly, the user (or client application) will never need to submit credentials over the wire to parties who don't own those credentials. Think about the number of times you've seen in the news about hackers cracking into some website and stealing credit card numbers from purchase histories. What if the site never needed to know your credit card number? What if you could still securely and easily use that site, but that site was never given any information that could harm you if stolen.Obviously the site would have to be playing ball with the whole WS-Trust, WS-Policy, and WS-Security stuff but you get the idea.

To really simplify things down: Using Geneva, you can walk up to any website or web service built by any team or department within your organization and say "hey, I'm Bob and I'm going to be consuming your services tonight." and then the site/service can reliably, with certainty, be able to say "OK Bob we believe you. Enjoy your stay." This leads me to the organizational and Single-Sign-On (SSO hereafter) benefits.

Organizational & SSO Benefits

For me, as an architect and developer, this is where Geneva starts to get really appealing. Picture this scenario: In your organization you've got 5 different departments. Between those 5 departments they are creating 7 different applications. All of these applications have strict mid-tier requirements and so all of them have these back-end infrastructure services exposed that all other applications can consume to share data. It's an awesome architecture that involves cats and dogs living together in total harmony... except for authentication and authorization. This beautiful architecture typically degrades into multiple silos of user authentication. Each department has their own unique customer base. They have different information they need stored about different users. Worse, many of these applications use different types of credentials to log in.

So now let's say you're a developer on Team A and you want to use a service written by Team B that lets a customer of Team A's application create a new order in Team B's application. Great! Cross-sell opportunities FTW!!1 Here's the rub: Team B's application has no idea who the hell any of Team A's users are. Now things get really messy and people start creating these "bridge users" in each of their user silos to allow Team A apps to log in to Team B services. So now when Team A wants to create an order in Team B's app, Team A consumes the Team B services by logging in as "teama" with a password of "teama". If you've never been in this situation before...trust me, it smells bad and it's a downhill spiral that is really hard to escape.

This is where Geneva comes in. Let's refactor the previous scenario using Geneva. First we've got a Geneva server in the enterprise. There are trust relationships set up between the different teams and each team has a service that can certify claims made as to the user's identity and their security privileges.

Now a user of Team A wants to do something that will create an order in Team B's application. The Team A application walks up to the Team B service and says, "Hey my name is Bob. you don't know me, but (TeamA) says my name is Bob and that I'm allowed to use your service." The TeamB application responds with, "Sweet. Me and TeamA go WAY back. Oh, hey, your claims also have your billing address and other information that I couldn't possibly have known otherwise. Thanks."

So what just happened? Two applications with two completely different architectures that both rely on back-end web services that both have two completely isolated user databases were able to communicate securely. Without either app being aware of the other application's user information and without creating hacked "bridge users", one app was able to talk to the other app securely.

So if you have ever seen the situation where you've got multiple web services that need to talk to each other securely (regardless of whether or not there is a shared user base), then Geneva could come in really handy. Now when you add in the ability to federate with other organizations outside your building without needing to maintain remote user information locally... now you're starting to talk about real value-add and real savings in terms of cost, time, effort, and aspirin consumed.

The benefit of this engine is that it's available for code generation even if you're not working on a DSL. In fact I would go so far as to say that regardless of it's original intent, T4 probably has wider appeal among developers looking to code generate as a solution to the "boilerplate of spaghetti" problem than it does among the relative minority of people building DSLs. I'm not saying that it's less meaningful to DSL builders, I'm just saying that there are more devs who need code generation for their day-to-day tasks than there are devs who are building DSLs.

Before diving into a sample I just want to try and make it clear that T4 is a code eneration utility. It handles those situations where you cannot fix your redundant or tedious code problems with inheritance, DI, or Aspects.

One of the tasks that I do all of the time when building an application with a desktop (or Silverlight) GUI is build classes that implement INotifyPropertyChanged. This allows me to bind the GUI to those classes and have the GUI react when those properties change. The problem is that for every single property that I want the class to have, I have to manually type in the code that fires the NotifyPropertyChanged event. While I can factor out the 3 lines of code for the event firing into a base class, I'm still left with this huge stream of property definitions. The properties all have the same shape (this should be a good clue that we can use codegen here) and all behave the same way. The getter returns the backing variable and the setter sets the backing variable and invokes a method which fires the property changed notification.

So in this T4 introduction I'm going to build a T4 template that automatically generates these notifier properties on a ViewModel class for me. It's going to be a partial class so if I want to add custom methods to the already generated members, I can do that without worry of having the generation process wipe out my code.

First thing to do is simply create a new file with the ".tt" extension in your project. In my case, I'm going to create a template called StateNotifierClass.tt. Just add a new file to the project with the ".tt" extension. Set the code for this template to the following:

<#@ template language="C#" #>
<#@ output extension="cs" #>
<#@ import namespace="System.Collections" #>
<#@ import namespace="System.Collections.Generic" #>

using System;
using System.ComponentModel;

namespace <#= this.Namespace #>
{
  public partial class <#= this.ClassName #> : INotifyPropertyChanged
  {
<# for (int idx = 0; idx < this.properties.GetLength(0); idx++)
   {
        #>
    private <#= this.properties[idx,0] #> _<#= this.properties[idx,1].ToLower() #>;
<# 
}
#>

   public void DoHello()
   {
        Console.WriteLine("foo");
   }   

   <# for (int idx = 0; idx < this.properties.GetLength(0); idx++)
   {
        #>
    public <#= this.properties[idx,0] #> <#= this.properties[idx,1] #>
    {
        get
        {
            return _<#= this.properties[idx,1].ToLower() #>;
        }
        set
        {
            _<#= this.properties[idx,1].ToLower() #> = value;
            NotifyChange("<#= this.properties[idx,1]#>");
        }
    }

<#
   }
   #>   

   protected void NotifyChange(string propertyName)
   {
       if (PropertyChanged != null)
           PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
   }

   #region INotifyPropertyChanged Members

   public event PropertyChangedEventHandler PropertyChanged;

   #endregion
}
}

<#+
    string Namespace = "Demo";
    string ClassName = "DemoClass";

    string[,] properties = {
        {"int", "Property1"},
        {"string", "Property2"}};    
           
#>

With this template in place, you should see that your solution explorer has a new file beneath your template called StateNotifierClass.cs. Take a look at it, you'll see that it has a namespace, a classname, private member variables providing a backing store for the properties and public property definitions that are not only strongly typed without having to use generics but they also fire the property changed event notification.

This is great, but now what does it look like to build a real, live view model class using this template? Here is a view model class template for a stock quote that re-uses the previous template. As you can see, looking at this template is a LOT easier than looking at the huge pile of generated properties and you know immediately what simple, notification-enabled state members are exposed by that class:

<#
    this.Namespace = "DotNetAddict.Samples";
    this.ClassName = "StockQuote";
    this.properties = new string[,]{
        {"string", "Symbol"},
        {"decimal", "Price"},
        {"DateTime", "TimeStamp"},
        {"int", "Quantity"}};
 #>
<#@ include file="StateNotifierClass.tt" #>

That's it! Obviously there is a lot more to T4 than what I'm showing here and if I end up spending more time using it I will do some more blog posts about it. The bottom line here is that for lightweight code generation tasks, you no longer need to look outside Visual Studio for third party codegen products... It's all right there for you. 

Obviously your mileage may vary, but I know from experience that having this tool available on some of my previous projects would've saved me DAYS of work and the end result would've been cleaner, more elegant, and a lot easier to change.

Basically what a DI framework lets you do is decouple the dependencies within your application. Rather than a controller having code in it that is manually new'ing up a reference to the view and the model, a DI framework lets your controller simply state that it needs a view of a certain type and a model of a certain type. The wiring up is then done for you automatically either at compile-time or runtime (or a little of both, depending on what you're using).

The problem with this approach is that it requires developers and architects to actually figure out what dependencies each piece of their application needs. Worse, this often requires developers to do some hard thinking about how they want to split their application into components to maximise re-use, increase efficiency, and create a highly resilient application. These are all admirable goals but let's face it - it sounds an awful lot like work.

What we really need is the next level of Dependency Injection.... Predictive Dependency Injection. Instead of us having to be explicit about the code on which other code depends, Predictive Dependency Injection (PDI) works by figuring out what you're going to need and when you're going to need it, and putting it there.

Say, for example, you're building an online banking application that allows customers to look at their transaction history and perform basic transactions like withdrawals, transfers, etc. Rather than having to go through the tradiational (hard work!) process of figuring out what components you're planning on building and how they all inter-relate with each other, now you can let PDI do the work for you.

Basically it works like this:

var bankingApplication = PredictiveUnity.Resolve<WhatIWant>();
bankingApplication.DoWhatIWant();

The PDI container will figure out what kind of app you're building and, using a combination of an advanced code generation tool (acronym: ESP) and other predictive heuristics the PDI container will make available to you an instance of an object that provides the backing functionality for your application. It creates several methods on this generated object that will perform the tasks that you need.

This doesn't sound all that interesting, right? But here's where it becomes a useful tool: you don't need to figure out what you need at the time you're coding it. The DoWhatIWant() method will figure out what the app needs to do and do it. The developer no longer has to be burdened with the hard work of design, analysis, or the tedium of manually typing C# code.

I recommend PDI for every developer who is currently thinking that tasks like design and coding are old-school and there's something better out there.

You can download the first CTP of Predictive Dependency Injection here .

It is important to note that the MEWA stuff was available in CTP form for quite some time before Silverlight 3 was unveiled to the public with it's support for Out-of-Browser installation. So what are the key differences between a MEWA that was installed on your desktop by the Mesh and a Silverlight 3 application that you took offline by interacting with it?

Data

The Live Framework is all about data synchronization; making sure that no matter what you're doing or where you are running an application, your data follows you. Internally this is done by having all of the data in the mesh synchronize bi-directionally using the FeedSync protocol and the Atom Publishing Protocol (APP). The primary means by which a MEWA stores its data is by creating and manipulating entries in the various feeds that belong to its Mesh Object. This allows data changes made on your computer to automatically synchronize throughout your mesh so that the data is available to all other instances of that application (and potentially other applications as well). MEWAs also have access to Isolated Storage and can of course consume Web Services (provided the server has a valid cross-domain policy XML file because MEWAs do not have a site-of-origin domain that you can count on..they come from the Mesh).

A Silverlight 3 application was, at one point or another, accessed from someone's Web Site. Whether that site is hosted by Azure or by your corporation or by some third party hosting company is irrelevant. To bring the application offline, the user either right-clicked the SL3 app and chose "Install" or clicked a button in the app to take it offline. Once offline, the SL3 application can access traditional Web Services, can receive "Data Push" messages from it's site of origin, and can access Isolated Storage. It's worth keeping in mind that the SL3 application has a 25MB Iso Store quota whereas the MEWA only has 1MB. SL3 also has access to .NET RIA Services, which allow for multi-tier spreading of common models and business logic to abstract on top of Web Service calls.

In theory, you could have an offline SL3 application use the Local MOE to talk to the Mesh, but I won't get into that ;)

Summary:
   SL3 - IsoStore, Web Services, .NET RIA Services
   MEWA - IsoStore, Web Services, Mesh Objects/Feeds

Automatic Updates

When a new version of a MEWA is published to the Live Mesh by the application author it is then run through an approval pipeline. Once it comes out the other side of this pipeline, it is published on the Live Mesh and optionally made available in the Mesh's central Application Gallery. As soon as this publication occurs and you connect your computer with a Mesh that has an old version of this application, the new version of the application will be synchronized down to your machine. This happens for all your connected devices and the cloud-based Mesh portal will also get a new version of the MEWA. Upgrades to a MEWA application can often cause problems with existing data already in the Mesh feeds so the developer needs to be constantly aware of accessing "old" mesh data.

As the application author of an SL3 application, you publish a new version of this application onto your web site. The next time anyone runs their offline browser application, it will asynchronously check for new updates. Once found, the application can respond to this and notify the user that new updates have been downloaded. After a restart, the SL3 application will be updated to the new version.

Summary:
    MEWA - Passive feed-based synchronization of new application bundle
    SL3 - Automated poll of site of origin for new updates, can respond to "updates downloaded" event to notify user.

Network Connectivity

Mesh-Enabled Web Applications are synchronized to your Live Desktop and to all of your mesh-connected devices automatically by the Live Framework itself. As a result, MEWAs have the ability to access the Mesh URLs because those all have valid cross-domain policy files, but there is no real "site of origin" to speak of since the applications call from from "the mesh".

Silverlight 3 Out-of-Browser applications at some point begin their lives as traditional web-hosted Silverlight applications and as such have a known site-of-origin. They can access any network resources on both the origin site and any other site with a valid cross-domain policy XML file.

Summary:
    MEWA - Can access any site with a valid cross-domain policy file
    SL3 OOB - Site of origin automatically, plus any sites with cross-domain policy files.

Location on Disk

MEWAs are currently stored on your computer in a cryptic, semi-hidden location that involves a lot of directories with names that look like GUIDs. MEWAs are launched by a custom live framework chrome container that hosts the HTML necessary to launch a Silverlight application.

Silverlight 3 Out-of-Browser applications are launched by invoking the sllauncher.exe application with a parameter that usually looks something like localhost.0 which is a unique ID that is used to look up the downloaded XAP file. Also don't forget that Silverlight 3 applications have the ability to open files on your hard drive via an "Open File" dialog (returns a Stream for security reasons) as well as save files to disk using the same mechanism. These files are not managed by quotas as they reside wherever the user wants them to be. This is a very powerful new addition and creates some very exciting possibilities for file-based SL3 applications.

Summary:
   MEWA - Custom chrome container that launches the Mesh Object by reading it from the Local MOE
   SL3 OOB - Custom chrome container that launches the Silverlight 3 application by ID lookup into local cache

Should I Be Building a MEWA or an OOB SL3 App?

The bottom line really boils down to where the vast majority of your data is and how much infrastructure you plan to have. MEWAs are nice because if you write your application to exclusively use the Live Framework feeds for its data then you don't ever need to host your own website - everything is stored locally and then synchronized by the Live Framework. The downside is that MEWAs only synchronize within a single mesh, so to expand the reach of your application people need to invite other people to share the application data. This may or may not be exactly what you're looking for - but you will probably know immediately whether this is a model you want to support or embrace.

Silverlight 3 Out-of-Browser applications feel more like a Silverlight enhancement to the original concept of ClickOnce. You have a website (could be hosted by Azure, a third party, your own data center, etc) from which people access your Silverlight application. If they want, they can install an out-of-browser version of that application and run it offline. When running OOB, they can access data locally (IsoStore) or remotely (site of origin or other "trusted" (policy XML) sites.

Summary:
    MEWA - Isolated smallish groups of app instances sharing data via synchronization
    Silverlight 3 OOB - Central infrastructure w/ ability to run apps offline and store data locally

I think the real take-away here should be that MEWAs and Out-of-Browser Silverlight 3 applications are really designed to solve two entirely different problems. Right now there is some overlap in intent and in implementation and I'm hoping that in the near future you'll be able to build Silverlight 3-based MEWAs. In the end it really boils down to your infrastructure and what your application plans to do with it's data that will steer you toward MEWAs or toward SL3 OOBs. Now get coding!

Stay tuned for more posts related to SL3 and all the extremely exciting new stuff that comes along with it.

One of the bits of technology that didn't seem to get near enough attention relative to how valuable it is was .NET RIA Services. .NET RIA Services is a set of tools and libraries that make the life of a RIA (Rich Internet Application) developer much easier. Basically if you are writing a Silverlight application that will ever need to talk to your server, then .NET RIA Services is your new best friend. No, I'm not sugar coating it, it's that useful.

This is a huge oversimplification, but basically here's how it works: You expose some entities on the server using RIA Services. These entities can be LINQ to SQL, LINQ to Entities, or your own custom data (such as data you obtain by talking to another tier or more services). Once these entities are exposed, when you build your solution a client proxy is auto-generated and placed into your Silverlight application project. This allows you to use LINQ queries, maintain local state in Silverlight, manage dirty entities, perform batch updates, perform transactions, and even access authentication, authorization, and profiles all while hiding the underlying HTTP communication.

If you stop to think about this for a minute, this is bigger than it seems. The main reason is because typically every time you expose data via Web Services to a client, you have a server-side model and a client-side model. Anytime you change the server model it breaks the client model and you end up with this little anti-corruption layer on the client to allow you to communicate cleanly. People often get around this problem by creating a single shared library that contains the model... but this has other problems too, including enforcing too much tight coupling between the client and the server.

Having the client proxies generated in this manner means that you can have your server-side entity model and you can have a client-side local-state model that is _bindable_ (it publishes change events!) enables all sorts of possibilities. In addition, you can decorate the server model with validation attributes which will also be enforced in the client proxies, giving your GUI the capability of displaying rich validation messages while still maintaining server integrity by preventing "bad" commits.

Again, I'm horribly oversimplifying things (I will be posting some code walkthroughs later), but having this robust model to synchronize server and client models and share code between tiers saves the developer a flaming truckload of work. And because .NET RIA services embraces LINQ and the concept of entities, you can even supply a full LINQ query on the client side which will be serialized out, converted into URL parameters, and then invoked by the server. Try doing that with your own home-brewed service communication library.

The bottom line is that if you are writing a Silverlight application that will ever require reading or writing data on your server, then you absolutely need to check out .NET RIA Services.

An out-of-browser Silverlight 3 application is one that can be installed to the Start Menu and/or Desktop. These Silverlight applications can run with or without a network connection, they can detect changes to their network status, and they have increased storage quotas within Isolated Storage. If you've worked with ClickOnce, then the whole OOB experience should be very familiar... the difference is that the SL3 OOB experience is leaner, quicker, and most importantly, can be run by limited/restricted users!

So the first step in creating an OOB Silverlight application is creating a new SL3 application. The Out-of-Browser stuff is controlled almost entirely through the manifest properties in AppManifest.xml. The Deployment.ApplicationIdentity element is the element that enables "detaching" (separating the XAP from the browser), here's what my AppManifest.xml looks like:

<Deployment xmlns="http://schemas.microsoft.com/client/2007/deployment"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
            EntryPointAssembly="SilverlightOOB1"
    EntryPointType="SilverlightOOB1.App">  
  <Deployment.Parts>
  </Deployment.Parts>

  <Deployment.ApplicationIdentity>
    <ApplicationIdentity
        ShortName="App of Awesome"
        Title="Out-of-Browser Awesomeness">
      <ApplicationIdentity.Blurb>This is the best application ever built. It will give you an awesome overdose!</ApplicationIdentity.Blurb>
      <ApplicationIdentity.Icons>
        <Icon Size="128x128">transformers128.jpg</Icon>
        <Icon Size="64x64">transformers64.jpg</Icon>
        <Icon Size="32x32">transformers32.jpg</Icon>
        <Icon Size="16x16">transformers16.jpg</Icon>
      </ApplicationIdentity.Icons>
    </ApplicationIdentity>
  </Deployment.ApplicationIdentity>
</Deployment>

Now when you run the application, you will be able to right-click the Silverlight surface and see the option to install the application on the desktop or the start menu (or both). It will also pick up your 128x128 icon and use that in the installation dialog (the current bits don't set the desktop/start menu icons though...). This is where it gets good: you can detect whether the application was launched attached (in-browser) or detached (OOB). This allows you to do things like hide a region of the application until the app has been installed. In my case, I will display the "Install Me" button if the app is not yet detached, and I'll display the "real" application GUI if it is detached. Here is my page startup code in the MainPage.xaml.cs file:

namespace SilverlightOOB1
{
    public partial class MainPage : UserControl
    {
        public MainPage()
        {
            InitializeComponent();
      

            if (Application.Current.ExecutionState == ExecutionStates.Detached)
            {
                LayoutRoot.Visibility = Visibility.Visible;
                InstallPanel.Visibility = Visibility.Collapsed;
            }
            else
            {
                LayoutRoot.Visibility = Visibility.Collapsed;
                InstallPanel.Visibility = Visibility.Visible;
            }
        }

        private void mainButton_Click(object sender, RoutedEventArgs e)
        {
            if (Application.Current.ExecutionState != ExecutionStates.Detached)
            {
                Application.Current.Detach();
            }
        }
    }

Here's a screenshot of the application launching before it has been detached:

When you click the Install button or when you right-click and choose install, you will be prompted to install the application. Here's what my install prompt looks like (note the custom logo/image supplied for the install prompt):

After I choose to install the Silverlight application, I get an icon on my desktop and an icon in my start menu. When you click either of these to launch the application (there is currently some weirdness with localhost-based SL3 apps but if you use a full-on website to deploy these it seems to work properly) you will get the application but this time it will detect that it is running in detached mode and display the "real" app GUI and hide the install button:

Even cooler is that in order to make it so that applications launch instantly, they check for updates asynchronously _after_ launch. Your application can then respond to the "ExecutionStateChanged" event and check to see if the app is now in the ExecutionStates.DetachedUpdatesAvailable state. This means that a new version of your app has been downloaded and is ready to go. You can use this event to inform your users that the app should be restarted to take advantage of the new goodies.

This is just the tip of the iceberg for the things that you can do with SL3 and I will be posting tons more walkthroughs and more in-depth coverage of some of the new features, so stay tuned!

I will be doing several more detailed posts about various aspects of Silverlight 3 once I get back home and get a decent night's sleep, but for now, I wanted to touch on a few of the things that I think Silverlight and potential Silverlight developers need to keep an eye on.

• Hardware Acceleration. For things like stretches, transformations, and alpha blending Silverlight 3 will offload that work to the GPU. In some very informative and objective analysis given during a session yesterday, this can show over 50% speed improvement depending on the graphics your application is using.
• Element-to-Element binding. I know this may not seem like much if you've never used Silverlight, but to WPF developers this is like pure gold. Using E2E binding you can rig the value of one property to the value of another property on another XAML element... this can create some really great GUI quickly with very little code.
• Perspective 3D. They've taken the 80% case for why people need 3D (performing psuedo-3D transformations on 2D elements to create effects like cover flow, etc.
• Animation Easing - multiple built-in types of easing functions to make the animations you do in Silverlight seem more natural and smooth, including things like a standard exponential ease and little "bounces" to make your controls take on a more visceral feel.
• File Saving and Opening !! - Your SL3 application can now read and write to files anywhere on the user's disk, provided the user tells you where the file is. It's still secure because all the SL3 app gets is a stream and it can only operate on that stream.
• Pixel Shaders - I could write an entire blog post on this (and most likely I will), but SL3 now has the ability to use Pixel Shaders using the same HLSL 2 language that WPF 3.5 SP1 uses for it's pixel shaders. These can be used to create transitions, inversions, blends, blurs, and much more. Even cooler is that there are already huge treasure troves of publicly available pixel shaders that you can easily import into your application.
• Read/Write pixels. There is now a WriteableBitmap intermediate surface. It might seem a little unnecessary at first, but if you've ever needed to take control of low-level pixel blitting for your SL app, this is good news for you.
• Adaptive Streaming - this was demo'd multiple times and I won't go into too much detail. Basically it allows you to stream live video content directly to a SL3 application (not just pre-recorded) in VC1 or H.264 and it can dynamically switch up or down bitrates depending on various network factors. Also allows for "instant seek" behavior.
• We finally get a WrapPanel!! :)
• Pixel Shaders can be combined with layering, alpha blending, and media elements to perform live, on-the-fly "green screen" effects. Demo was putting static backgrounds behind a video of John McCain talking. The possibilities here for creating high-end, rich applications are endless.
• Local Messaging - We can now use named-pipe style communication channels to talk to other instances of Silverlight applications running on the same machine, even if they're not in the same browser.
• Some new controls - DockPanel, WrapPanel, Expander, Label, TreeView, ViewBox, ChildWindow, etc.
• Silverlight can now run out of the browser and install desktop icons similar to ClickOnce. I cannot possibly express how huge this is for Silverlight developers. Basically you can right-click a Silverlight app and choose the "Install" option (or hit a button coded by the app developer). This can put an icon on the desktop and/or in the start menu and will install the app. Installed apps can detect what their own state is (running offline, etc) and receive notifications when the network IP address changes, allowing apps to determine their own connectivity level. Again, this is HUGE.

As I said, I will be posting more about SL3 once things calm down a little bit (and I get some sleep), but this should whet your appetite. I think the key thing to realize here is that Silverlight 3 is quite possibly the single best zero-install-required cross-platform rich application development environment available given the list of supported features and the ease with which certain tasks are possible.

Stay tuned!

I realize that it is a designer and developer conference (hence the term "MIX") but it still feels kind of like Microsoft can't quite figure out what message they want to deliver. Some of the designer-focused sessions seemed too technical and some of the technical sessions seemed to designer-y, but otherwise I learned a lot and got a lot of really useful information yesterday.

First and foremost: the SWAG report: A leather-wrapped coffee travel mug, a plastic water bottle, a free copy of Buxton's book, a free copy of "First Look Silverlight 3", a DVD of Windows Web Server, a thumb drive, a t-shirt, a pretty flimsy tote (fell apart under the weight of the SWAG), and a really well-bound journal for taking notes.

OK, with that out of the way we can get to the content. I'm going to run through the major highlights from yesterday in bullet form because I plan on doing individual blog posts on some of the other technology that I saw (such as Silverlight 3).

• Buxton's keynote was very inspired and he was very excited about industrial design. He lost a few points by bringing up the Zune in the same context as bringing up past successes of industrial design, but otherwise the keynote was very informative and inspiring. The key take away is that you are building and selling an experience, not a product or a thing.
  • noteworthy quote: "If you don't have as much detail in transitions as in states, you're going to get it wrong" - said when talking about sketching out application states and flow.
• The HP touchsmart demo failed (monitor wouldn't respond to touches) :)
• Scott Guthrie was given a hero's welcome. His video about getting ready to present his keynote, including jokes about his red polo and him in full "stayin' alive" disco gear is sure to replace the infamous "Bill Gates retiring" video as an epic cheese-filled achievement.
• SuperPreview - a technology that is part of Expression Web 3 that allows you to view the baseline version of a web page, compare using overlay with other rendering engines, etc.
  • SP can even talk to a cloud service to get a page rendered for a particular target browser/engine even if that engine isn't on your computer. This means you can now SxS compare Ie6,7,8 as well as Firefox, Safari, and Chrome without having to have them all installed on your machine.
  • If you are building HTML and CSS stuff, SuperPreview will absolutely make your life easier.
• ASP.NET MVC 1.0 shipped yesterday (congratulations to all involved, this is a fantastic product and a testament to the idea that Microsoft actually can build lean, agile, bloat-free products)
• ASP.NET 4 and VS 2010 - velocity (distributed caching) will be rolled into ASP.NET 4. ASP.NET 4 also gets the dynamic routing engine built originally for MVC.
• Netflix - championed Silverlight and Silverlight 3 because it makes it so that their customers don't have an install experience ("Installers are Evil!" was his quote) and it runs on Windows and the Mac.
• Silverlight 3 has new codec support - H.264, AAC, MP4. To anybody who has considered using Silverlight for media and decided against it - this is HUGE.
• IIS Media Services - a new back-end for streaming media to Silverlight clients.
• 2010 Olympics is going to be in full 720p HD online using Silverlight 3, complete with DVR controls like pause, rewind, etc.
• Silverlight 3 and Blend 3 can now import assets directly from Photoshop and Illustrator. I cannot possibly make it clear enough how incredibly useful this is.
• Blend 3 is getting SketchFlow, a way to quickly go from idea to prototype.
• SL3 has client/server proxies and new libraries to make multi-tier apps using SL3 easier to build
• SL3 now has the ability to install offline and become aware of network changes (think of this as ClickOnce, next generation, for Silverlight). I will be posting more about this in my upcoming SL3 post. Again, this is HUGE HUGE HUGE.

I really dislike using the bullet form to do blog posts, but there was so much information crammed into the keynote that I just wouldn't be able to create some readable narration of it without making it so long that your eyes glazed over and you fell asleep before finishing reading the article.

The main takeaways for me from the keynote are that Microsoft is investing a LOT of time, effort, and marketing around Silverlight 3 and with good reason. Years and years ago, when IE4 came out, I remember saying how the line between the browser and the desktop was going to become irrelevant to the end user - their data comes from the Internet and people won't care if they are using a downloaded semi-offline RIA or a desktop app. That future is coming and SL3 is going to be right there at the forefront.

Noticeably (for me at least) absent from the keynote was a good overview of Windows Azure. Azure is huge and I was hoping it would get more "air time" as it were, but I can see how at a half-designer conference, ultra-geeky stuff like cloud storage, the ServiceBus, and SQL Data Services would bog down an otherwise glitzy and shiny bouncing keynote.

Again, stay tuned because I'll be posting more detailed blog posts related to the technology that I've been seeing.

As you may know, I'm somewhat of a people-watcher more by accient of my own particular symptoms of being unable to tune out white noise than anything else. I find it interesting what topics are being discussed near me as people eat breakfast and wait for the chance to go get seats for the keynote. A lot of people are talking about Silverlight... though those conversations actually sound like bragging matches to see which person at the table has used more Silverlight than the others.

Definitely a lot of excitement around here, though I am kind of dissappointed that there aren't as many people talking about Azure and Live Framework. Those things are completely underrated and, if you looked at my schedule, you'd see that it's almost entirely Azure-related with a little bit of Silverlight peppered in for good measure.

Anyway, I will be posting my thoughts on the conference and the different sessions I attend, so stay tuned. For now, I'm just going to try and find a small drab corner in which to hide from all the shiny, extremely over-the-top opulence here.

Support for Win7 is also included in these bits, which is timely, considering I just recently installed Win7 on my laptop. If you want all the gory details, you can find the complete API change list here. One of the things that was interesting while looking through the change list was the addition of the LiveQuery class. I'm going to have to experiment with that one as it could make app dev on the Mesh much easier/smoother.

LoopStatement is a new class that looks like it will ease the pain for people who were extensively using resource scripts, but as the bits were released yesterday I haven't had time to play with this class yet either.

And finally, quite possibly my favorite feature, is that the bug fix from the Jan CTP where they fixed the icon changing problem is well, still fixed. :) The only reason I mention it is because the bug fix came from one of my threads on the Live Framework forum.

Once I've had time (because I have oh so much spare time...) I will do some more playing with these new bits and post some code samples and my thoughts on the subject.

To recap, Velocity is Microsoft's distributed cache system. What sets it apart from other caches like memcached is that it has some pretty advanced features. Memcached has always struck me as a very useful distributed cache, if all you want is simple keyed put/get/delete. Velocity actually gives us a bit more than that.

Regions allow you to logically group keyed values next to each other. So if you have cached data items that you know are going to be stored and/or retrieved within a short time period of each other you can put them all in the same region. Those keys can have the same back-up policy and can be backed up together. This kind of thing can be used for application partitioning or even finer grained control within an individual application. Let's say you've got a shopping site you might create a region for all of your DVD cache data because if a user is flipping through DVD data on your site, optimizing the cache to feed those requests is a good thing.

Tags. I mentioned this before, and I'll mention it again. You folks all know what a freak I am about tags (even wrote a whitepaper about building tag clouds...) and the fact that not only can I create flat segmentation within my cache via tag, but that I can actually search and retrieve all cache items with a particular tag is awesome.

There are a whole bunch of other features that I am really excited about like auto-failover, backups, HA, load balancing that is not based on a fixed hash (take that memcached!), and much more.

Some of the stuff coming in CTP3 that I can't wait to find out about next week at MIX includes:

• Bulk operation APIs
• Security (including WCF channel security, simple token security, and domain credentials)
• Event Notifications - this is one that I begged for during CTP1. I want the ability for my app to be notified when the cache changes. Keeping in mind that Velocity can be used for more than just ASP.NET, this is a fantastically useful feature, especially if you've got a bunch of back-end stuff running on .NET that is supporting your ASP.NET tier.
• Read-Through/Write-Behind. Mmmmmmm...Performance...

I will post again about Velocity after I get my tech-obssessed hands on CTP3 so stay tuned :)

Now that confusion is gone. In an effort to drop the confusion levels, they are going to stop supporting the ACE model and will instead be exposing SQL Server (or something that looks, acts, and talks like it) in the cloud using TDS (Tabular Data Stream). So why is this a good thing? Well, with the "old" (funny how we say old for things that never made it out of beta...) ACE method the access method for your SQL data was proprietary (XML , sure, but still proprietary in the sense that it didn't work out of the box with anything else). By exposing SDS via TDS in the cloud, we automatically gain compatibility with:

• Visual Studio
• ADO.NET
• ODBC (though you shouldn't be using this if you are writing .NET client code)
• Tables, Triggers, Stored Procedures, Views, Indexes

What this really boils down to is that when you are building your cloud application, you should be able to flip a switch and go from on-premise SQL databases to off-premise SQL databases. Anybody who has tried to make a decent prototype using the ACE bits of SDS knows how much of a pain in the ass the whole dev->build->test->stage->prod life cycle was going to be. Now it should fit in nicely with your current tools and process.

An added bonus is that they are going to be using Astoria to expose REST endpoints on this. This is a good thing because in classic Microsoft form they had two teams working on essentially the same thing (SSDS was building their own REST endpoint system...even though Astoria has been around longer and works with the Entity Framework).

This leads to my final conclusion - If you can build locally against a local SQL server and then push your code to the cloud with Azure SDKs and flip a switch and point to your cloud-based SQL server, then you can also use Entity Framework code in your client for both on-premise and off-premise databases. Sweet.

So I figured, "What the hell..the drive's already empty anyway... might as well put Win7 on a fresh drive!"

So that's what I did. That process, in stark contrast to the Vista->Win7 upgrade, was ridiculously smooth. It's a fairly high-end laptop which typically means a crapload of OEM drivers that confuse Vista and prevent things like sound cards from working. Win7 recognized the 512MB laptop video card and it recognized the audio driver and the keyboard and trackpad worked...as did the WiFi and bluetooth and built-in camera. The only thing it didn't recognize out of the box was the custom keyboard functionality like the volume controls that trigger various HUD displays... 10 minutes after hitting the manufacturer website for the Vista drivers, that too was working.

My first impression was mixed. By default, Win7 gave me the crappy theme with no transparency. After changing to the good theme, things started looking up. The most completely surprising thing that happened to me is that after using Win7 for a couple of hours, I am absolutely addicted to the new taskbar. I absolutely hate all taskbars in comparison, including my beloved OS X dock.

The quick preview you get when you hover over an item in the task bar is really useful. But what makes it MORE useful is that if you hover over the preview, all windows on the desktop become transparent borders, allowing you to see the full contents of that window. If you then click the preview, that window becomes the foreground window. This is HUGE for me. I typically have 10+ windows open and can't find squat when I'm knee deep in some programming task with an IDE open, a couple command lines, two browser windows, an SDK manual, and various and sundry other gadgetry. IE8 even goes so far as to give me a preview of every single TAB in every single IE8 window in a nice grid format. I don't know about you, but seeing a quick preview of a browser window does me no good if I can't see all 15 tabs. Win7's taskbar + IE8 makes that possible...I only hope Firefox will eventually work the same way.

Couple other observations that people might find interesting:

• UAC prompts seem to be a little less frequent (though this could be entirely wrong... that's just how it felt)
• Win7 Beta 1 is noticeably and quantifiably faster and responsive than Vista SP1. Try copying a file from a network share to your local disk on Vista. Time it. Do the same on Win7. Rejoice.
• The "libraries" thing seems like a good feature. I know my wife would get a lot of use out of it because she has literally thousands of documents on her computer. Me, not so much but I'll have to see how it works when I start tagging code directories and the like.
• WiFi configuration seems to have MORE clicks required than Vista and somehow bends the laws of user experience physics to be MORE confusing than Vista's configuration. That said, once WiFi is configured, it doesn't seem to fail nearly as often as my Vista one. Also, I no longer have to reboot when the wireless router obtains a new IP... that one "feature" of Vista is enough to make me want to stab my eyes with rusty forks and I've already decided I shall never use Vista on my home router again...not when I've got Win7 available.
• Downloadable content. Even in Beta 1, there are like 10 additional desktop themes that you can download from the gallery website and they auto-install when you click on them. This is often underrated but dammit I love my extras and the fact that Vista's "ultimate extras" never added a single damn extra throughout the entire lifetime of the product was vastly dissappointing. The fact that Win7 already has downloadable extra goodies is a promising sign. Let's hope MS keeps it up and makes it so there's like 30 pages of fun crap people can download when they get Win7 on day 1.

Bottom line is that I've already removed Vista from the machines that I have that are not mission critical. I didn't do that to XP even after Vista SP1. Win7 (beta 1!) seems to be faster, smoother, more sturdy, and even looks a little better than Vista. All MS has to do is deliver what's in this beta and I'm sold.

Of course...I was sold when I used Longhorn and then they trashed Longhorn and turned it into Vista and it had none of the stuff I really wanted anymore, so I'm still a little leery. As I use Win7 beta 1 more I will post more blog entries if I find things that are really cool or really crappy :)

So this is when I found JAX-RS. You can find implementations of this in Metro, hosted by Java's GlassFish container...but you can also find a really good implementation of it in the latest snapshot of the CXF framework.

To create a RESTful Web Service using JAX-RS, all you really need to do is create a class that will be your service and then your container (in my case Tomcat) and CXF do the rest. Here's a snippet of a sample class from a CRM service that has been decorated with JAX-RS/RESTful attributes:

// misc imports
@Path("/")
@Produces("application/xml")
public class CustomerService implements ApplicationContextAware {

    // private member variables go here.

    @GET
    @Path("/customers")
    public CustomerList getCustomers() {
        // code to build customer list goes here
    }

    @GET
    @Path("/customers/{customerId}")
    public Customer getCustomer(@PathParam("customerId") String customerId) {
        // code to fetch individual customer goes here
    }
}

As you can see, there's a /customers URL and a /customers/### URL that allow you to retrieve either a full list of customers or a payload for a single customer. It's pretty self-explanatory from just looking at the code (which I like). One thing you'll notice is that the service class is application context aware, which means I'm going to be creating an instance of my JAX-RS server using spring. Below is a little snippet of the spring.xml file that instantiates (or injects, depending on who you ask) the JAX-RS server:

<bean id="crmService" class="com.dotnetaddict.samples.CustomerService"
    init-method="init"/>

<jaxrs:server id="customerServerJaxRs" address="/crm">
    <jaxrs:serviceBeans>
        <ref bean="crmService"/>
    </jaxrs:serviceBeans>
</jaxrs:server>

In short, this is yet another way that you can build RESTful Web Services using Java. I prefer the JAX-RS way of doing things over the JAX-WS way of doing things mostly because the syntax is specifically designed to be RESTful and RESTful isn't just some kind of add-on that you can tack on to an otherwise WSDL-type Web Service.

However, my quest for the simplest and easiest RESTful syntax that is also applicable in the enterprise isn't over yet :)