Caught this article on the Morning Brew today, on making web service calls in Silverlight synchronous (which is fine as long as they're not running on the UI thread). Had a quick look through the code, including the CodeProject article which provided the base, and thought it seemed a little complicated.

I've recently discovered that you can use the Reactive Framework extensions to wrap the event-based async pattern and make it synchronous; so far, I've just used it for unit testing, but I thought I'd try to apply it to this situation.

The basic pattern goes like this:

• Use Observable.FromEvent to get an IObservable from the XyzCompleted event.
• Use the ToEnumerable extension method to convert the asynchronous IObservable to a blocking IEnumerable.
• Call the XyzAsync method.
• Get the First element off the IEnumerable.

You see, when you create an IEnumerable from an IObservable, and then start to iterate it, it creates an enumerator which blocks on the current thread until it gets an OnNext from the Observable. (Disclaimer: I don't know for sure how it actually does that, I just know that's how it works on the outside. If I was implementing it, I'd probably be using some sort of queuing and polling algorithm.)

WebClient.DownloadString(Uri uri)

To start off with, I added an extension method to WebClient which implemented the pattern around DownloadStringAsync/DownloadStringCompleted:

public static string DownloadString(this WebClient webClient, Uri address)
{
    // Convert event to blocking IEnumerable
    var blocker = Observable.FromEvent<DownloadStringCompletedEventArgs>
        (webClient, "DownloadStringCompleted")
        .SubscribeOnDispatcher()
        .ToEnumerable();

    // Call the Async method
    webClient.DownloadStringAsync(address);

    // Get the first element off the blocking Enumerable
    var eventArgs = blocker.First().EventArgs;

    // Throw exception?
    if (eventArgs.Error != null)
    {
        throw eventArgs.Error;
    }

    return eventArgs.Result;
}

That's pretty straightforward.

Genericising the pattern

In fact, looked at through functional goggles, there are only four variables:

• the object with the Async method on it;
• the name of the Completed event;
• the Async method being invoked;
• the extraction of the actual result from the EventArgs.

So we should be able to wrap this pattern up in a helper method with four parameters. And indeed we can:

public static TResult Execute<TEventArgs, TResult>(object obj,
    string eventName,
    Action<object> asyncMethodInvoker,
    Func<TEventArgs, TResult> resultSelector)
        where TEventArgs : AsyncCompletedEventArgs
{
    // Convert event to blocking IEnumerable
    var blocker = Observable.FromEvent<TEventArgs>(obj, eventName)
        .SubscribeOnDispatcher()
        .ToEnumerable();

    // Use Guid to identify our call 

    var guid = Guid.NewGuid();

    // Call the Async method
    asyncMethodInvoker(guid);

    // Get our element off the blocking Enumerable
    var eventArgs = blocker
        .First(e => e.EventArgs.UserState.Equals(guid))
        .EventArgs;

    // Throw exception?
    if (eventArgs.Error != null)
    {
        throw eventArgs.Error;
    }

    // Return result from EventArgs
    return resultSelector(eventArgs);
}

Woo. OK, we've got two generic parameters, one for the type of EventArgs involved, and one for the final return type. We don't need to know the type of the object which holds the Async method, because we're only using it for the Rx FromEvent call, and that just takes object.

We've wrapped up the actual invocation of the Async method in an Action delegate which we can just call; the consumer of this method can include any parameters, such as Uri, in the Action body as closures. But we've added a parameter to the delegate, just an object, for which we're going to supply a Guid to identify the Completed event.

By adding the generic constraint to say we only deal with AsyncCompletedEventArgs and its derivatives, we can handle the exception cases because we know we've got the Error property available to us.

And we can call the supplied Func delegate which takes whatever the actual completed EventArgs is and returns the Result bit of it.

So, you can call this helper method from anywhere to dynamically make any Async Event Pattern synchronous, but it's a bit messy, so I think the better approach is to use it inside an extension method like the WebClient.DownloadString method above. Here's that method reimplemented using the helper method:

public static string DownloadString(this WebClient webClient, Uri address)
{
    return Sync.Execute
        <DownloadStringCompletedEventArgs, string>
        (webClient, "DownloadStringCompleted",
         (o) => webClient.DownloadStringAsync(address, o),
         (e) => e.Result);
}

Caveat lector: I've only hacked this together quickly and run a couple of tests, so if you try it and find problems, please let me know.

One of the nice things about Microsoft Windows Azure services is that they have a very well-defined and consistent REST API, meaning that they can be accessed from any language which can formulate an HTTP request; pretty much any language you can realistically expect to build an application in today. So as well as accessing the storage services from .NET/Silverlight CLR (or DLR) languages via the official SDK, you can access them from Rich Internet Applications written in HTML5 and Javascript, or from mobile phone services using Compact Framework, Java, or even Objective-C if you're doing penance for past-life atrocities against entire galaxies.

The only slight catch is that you have to authenticate the request, which involves some slightly complicated hashing of certain values with certain keys and which, if done in the wrong order, won't work. So I hope here to present a definitively working process for anybody else who is having bother and for me the next time I need to implement this in another language or framework.

Before signing, you need to make sure you've got the request headers right. You will need

There are two levels of signing: Shared Key, which involves the full set of headers and canonicalized headers and the resource being acted upon; and Shared Key Lite, which involves hashing a subset of headers and the resource being acted upon. We are going to use Shared Key Lite, because it is easier and because it works. Don't feel bad about not using the "real" Shared Key; the .NET Client Library for ADO.NET uses Shared Key Lite, so it must be OK.

The headers you need to include before signing are:

• content-length: either the length of the XML body of the request, or 0 if there is no body.
• x-ms-date: the current date and UTC time, formatted like this - "Thu, 11 Mar 2010 15:35:12 GMT". This time must be within the last 15 minutes when Azure processes the request.

If there is content in the body of the request then you need a content type header:

• content-type: application/atom+xml

If you are doing an Update against a Table entity (i.e. a PUT request) then you should also include:

• If-Match: *

This forces an unconditional update; if you wish for a conditional update, replace "*" with some criteria in the same format you would use for a query.

You are now ready to sign your request. You will need:

• The Shared Access Key from your Azure Storage project, which will probably be a base-64 encoded string;
• An implementation of the SHA256 algorithm.

The signing process involves constructing a Hash-based Message Authentication Code, or HMAC, by hashing together the Shared Access Key and a string made of bits of the request using the SHA256 algorithm. If you are using .NET, you can use System.Security.Cryptography.HMACSHA256 to do this quite easily. If you are using something else, it might have a standard library class to handle it. If not, and you need to roll your own, you can find pseudocode describing the HMAC algorithm here.

The string made of bits of the request is, more accurately:

• the date as it appears in the x-ms-date header
• a newline character (\n, not the CRLF combo)
• your account name
• the path (and any query parameters) of the REST resource URI

For example, for an insert:

Thu, 11 Mar 2010 15:35:12 GMT
myazureaccount/mytable

or for a query:

Thu, 11 Mar 2010 15:35:12 GMT
myazureaccount/mytable?$filter=(foo eq 'bar')

Calculate the HMAC for this string, convert to Base 64 encoding, and then add it as a header to your request in the form:

• Authorization: SharedKeyLite myazureaccount:q9324jr0+93qwfk+4ou93r8wsrf89owuj3f==

Your request is now signed and good to be accepted by the Windows Azure Table Storage service for the next 15 minutes.

The Blob and Queue services use similar authentication, but with more headers. I haven't yet implemented these services as direct REST calls yet, but when I do I'll post an update.

Part 2 of this series of posts will cover creating the body of requests for Insert and Update operation, and parsing the body of responses for all operations.

(Yes, again.)

There's an awful lot of buzz around new-fangled "NoSQL" or "non-relational" databases at the moment. I'm hearing a lot of people asking why they'd choose one of these new-fangled storage models over the relational databases they know and (mostly) like. This post aims to shed some light on the choices available, and to maybe give some guidance if you're trying to make a decision.

Let's define some terms

I find it always helps to make sure you're talking about the same thing if you think you might be arguing.

Relational database management system (RDBMS)

When I say "relational database", I'm referring to an application or service which stores information in tables. Tables are divided into columns, and columns have a type, such as integer, date, text etc. The data held in the tables is divided into rows, and each row contains a value (possibly including NULL) for each of the columns. The RDBMS can maintain and enforce "master-detail" relationships between rows in different tables using primary and foreign keys.

The big commercial relational database systems are Microsoft SQL Server and Oracle; the main open-source alternatives are MySQL, PostgreSQL and SQLite.

New-fangled data stores (NoSQL)

I'm going to use the term NoSQL to cover everything else, which is a massive generalisation and therefore inevitably inaccurate (several new-fangled data stores actually support a SQL-like syntax). However, in the interests of a bit of clarity, I'll try to outline some of the distinct types here, although the distinctions can be a bit vague.

Key/Value Stores are the most basic NoSQL databases, and are essentially hashes with disk persistence. In some cases the value is a single binary or text object; in others it is a tuple with named properties, sometimes with searching supported against those properties. These solutions are schema-less: entities within a collection, domain or table may have completely different properties. Microsoft's Azure Table Storage and Amazon's SimpleDB are both cloud-based, pay-as-you-go Key/Value stores. Open-source implementations include BerkeleyDB, MemcacheDB, Redis and TokyoCabinet.

Wide Column, Tabular or Column Family Stores are scalable, distributed systems that support a defined schema for each "table", but not relationships between tables. Google's BigTable database, which is the storage solution for their AppEngine cloud platform, is a Wide Column store. Open-source alternatives include Cassandra and Hypertable.

Document Stores work with data structured using Object Notation, usually JSON or BSON. Not to be confused with SharePoint, Domino etc. This format allows complex data structures, including arrays and hashes, to be represented within a single entity that can be retrieved in one read operation; they also often support complex update operations such as adding elements to an array within a document. Some popular Document Stores are CouchDB, MongoDB and Riak.

Object Databases are superficially similar to Document Stores, but have predefined schema and inheritance hierarchies. In an Object Database, graphs are persisted using pointers between objects rather than by embedding graphs within other graphs. The most popular Object Database is db4o.

So which is best?

<SocraticDialectic>

Hello.

Hello.

Right, so. Why should I use any of these new-fangled "stores" instead of a relational database?

Mu.

Beg pardon?

I said "mu". I keep hearing this question, and I submit that the answer is "mu", which means "your question cannot be answered because it depends on incorrect assumptions."

What incorrect assumption is that?

The assumption that the relational database is axiomatically the correct storage solution in all situations, and that the onus is on all other options to prove that they are better.

Is that not right then?

No, it isn't. Have you heard of doing the simplest thing that could possibly work? Or YAGNI? It's possible to add unnecessary features to a system without coding them yourself. The first thing you should rule out as a storage medium is the file-system.

What, text files? Isn't that a bit 1980s?

Not at all. Let me ask you a question: what requirements or properties of your application preclude using one or more flat text files to persist your data?

I need structured data.

What's wrong with tab-delimited, CSV or even fixed-length field files?

I need master-detail structured data.

In which case, you could use XML, YAML or even JSON. Let's say we're using XML, even though it's quite the worst of those three options.

I need details with many masters.

You mean lookups? Why on earth would you want to use those?

To save space.

Right, because storage space is so expensive these days. You can buy a 2-terabyte hard disk and get change from £120 (or $150US). Keeping a gigabyte in the cloud'll cost you 15 cents a month.

OK, I don't need to save space. But I still need one copy of each piece of data, so I only have to update it in one place.

That's fine, but does that need to be supported by your persistence layer? Are you going to re-read those lookup descriptions every time you pull a record? Add multiple joins to every SELECT statement just to read back those varchar(40) descriptions?

As opposed to…?

As opposed to reading those lookups into memory once the first time they're needed, and maybe refreshing them in background every now and then if you're in a multi-user smart-client system and they're particularly dynamic, which they're probably not. How often does somebody add a new country to the system? Or a new type of customer, or method of payment, or whatever?

OK. I accept that lookups are not a valid reason to use a relational database.

Good. So, next requirement or property?

I need many-to-many relationships. For example, in my library application, each customer can borrow many books, and each book (over time) can be borrowed by many customers.

Well, we're still using XML, so you can have a list of child elements in your customer record detailing the books they've borrowed, and a list of child elements in the book record detailing the customers who have borrowed it.

So when somebody borrows a book, I have to update two records? That's bad, isn't it?

I don't know; it's your application. Do both records have to get updated in the same split second? Is it likely that another user will do a read that could get inaccurate information while the two updates are happening? Or is it enough that the customer and book records should be eventually consistent (for a given value of eventually)?

But then I'd have to read a bunch of files individually to get the details of those books, or the names of those customers.

Not at all.

Well how would you display sensible data on the screen? Are you going to cache the entire book catalogue and customer list in memory as well?

It's an option. But no, I would probably just decide which details about the book I need in the customer views, and which details about the customer I need in the book views, and then I'd include those details in the child records.

You'd duplicate the data?

Oh, yes.

[Shocked gasps from enthralled onlookers]

You're mad.

Not a bit of it. Books don't change their titles, or authors. Customers don't change their names very often; certainly not so often that it's beyond reason to bulk-update a bunch of book records when they do.

So you just duplicate the data?

Absolutely. Saves a whole bunch of extra disk reads, and those join tables you keep using in many-to-many relationships, well, let's be honest: they're a kludge, and they're one of the most common causes of performance issues due to volume of data.

I remain unconvinced.

OK. Let's take your library example. Let's say your library is in a particularly literate part of the world and has 10,000 active customers, and 100,000 books. And let's say that each customer borrows two books a week. After one year, your many-to-many join table has 1,000,000 rows in it. Meanwhile, each of my customers' records have 100 book record keys, titles, author names, publishers, and loan start- and end-dates, and each of my book records have, on average, 10 customer record keys, names, maybe addresses, and loan start- and end-dates. In storage terms, let's say you've used probably 32 bytes per row (two 32-bit keys and two 64-bit date/times, plus overhead), so that's 32MB, plus the same again for indexing. Meanwhile, let's just hazard a guess and say I've used a whole gigabyte with all my duplicated data.

Exactly. Look at all that storage you're wasting.

My goodness, you're right! That's 0.1% of a £120 hard-disk I've just frittered away! Or nearly $2 a year for the cloud storage.

There's no need to be sarcastic.

I wasn't; I was being ironic. Anyway, my point is, pulling a customer record and displaying the complete list of books they've borrowed for me is a single read operation; for you it's a three-table join with one of those tables containing a million records for each year your software's been in use.

I-

Actually, scratch that.

Really?

Yes, I was wrong.

I thought you were.

I forgot that you'll have normalised out your book catalogue into a book table with a many-to-many join to an author table, and another many-to-many join to a publisher table, so you've actually got seven tables totalling a few million rows that you need to reference to get the same information that I can get in a single read operation. How's your EXPLAIN output looking, by the way?

I'm not sure. What does DEPENDENT SUBQUERY mean?

No idea, but it sounds nasty. You can fix it later. You're supposed to be giving me reasons you need a relational database.

So I am. OK, well, I need to search the data.

Aha! Very good. Much closer. That would be a reason for a database management system, but not necessarily a relational one. There are lots of NoSQL solutions that will let you run queries against your datasets, with varying degrees of performance. I've written queries in MongoDB that run against massive datasets so fast it'd make your eyes bleed.

[Suddenly, a heavenly light shines down upon the pupil. Or some scales fall from his eyes.]

I've been such a fool! I drank the relational database kool-aid and no mistake! Thank you for showing me the error of my ways. I'm going NoSQL all the way for my next project.

What? No, wait, come back.

Why? I'm convinced. You made your case.

No, I haven't. I've just stopped you from being one kind of wrong and you've immediately started being another, completely different, but equally bad kind of wrong.

No need to be rude.

Sorry. But flat text files and  NoSQL databases aren't the solution to every persistence problem. There are perfectly good reasons to use a SQL database.

Such as?

You might need the whole ACID thing: Atomicity, Consistency, Isolation and Durability. If your system deals with financial data, or medical records, or other sensitive information, you're going to want a robust transaction system.

True.

And if you've got a lot of concurrent users who might try to update the same bit of data at the same time, like an entry in a Stock table in an e-commerce system, then isolation and locking could be very handy.

And NoSQL systems can't do ACID and locking and so on?

Oh, they can, one way or another. But a lot of the time you end up writing extra code in your data access layer to do stuff that a decent RDBMS will do for you. And if you've got a room-full of developers who are dead good with SQL Server or Entity Framework or whatever, why force them to learn a new technology?

I would have a hard time justifying the time and money required for our developers to learn the new skills.

Then again, in the cloud the NoSQL storage can be much, much cheaper than the RDBMS. For example, Windows Azure storage costs $0.15 per gigabyte per month, whereas a 1GB SQL Azure instance is $9.99 per month; 10GB is $99.99 per month.

So Windows Azure storage is cheaper than SQL Azure storage?

Not necessarily. With Windows Azure Storage you also pay for transactions, at the rate of $0.01 for every ten thousand. SQL Azure doesn't charge for transactions. So if you're storing less than a gigabyte but running more than ten million transactions per month, SQL Azure would be cheaper. Or if you're storing less than ten gigabytes but running more than a hundred million transactions-

Stop! I'm all confused. Please, just tell me, what should I use?

You want a definite answer?

Yes.

OK.

There really is one?

There really is one.

And are you going to tell me what it is?

I am.

Now?

Now.

Wow.

Although I don't think you're going to like it*.

It doesn't matter! I must know!

Now?

Yes, now!

Alright.

Well?

You're really not going to like it.

Tell me!

The answer is…

Yes?

The answer is: It All Depends.

…

I want the last 5 minutes of my life back.

5 minutes? I've spent hours writing this.

</SocraticDialectic>

Anyway, the point is…

…every system is different. Which persistence paradigm is best depends on the project and its requirements and properties. All I want to say is that you shouldn't start with RDBMS and then look for reasons not to use it; at the same time, don't start with Project Voldemort or CouchDB just because they're new and exciting. Approach every project with no preconceptions about what you're going to use; or have "flat text files" as the default choice.

A non-exhaustive list of things to consider:

• If constant consistency is a key requirement then you should probably use an RDBMS.
• If horizontal scalability is important and eventual consistency is good enough, then a NoSQL solution might be better.
• If you're deploying an application to Windows Azure or Amazon Web Services, then you should probably compare the costs of Windows Azure Storage Services or SimpleDB to SQL Azure or Elastic RDBMS for your particular application.
• If you're writing an application for a mobile platform, you're back to limited storage space so you might get back to RDBMS and normalising for efficient use of that space.
• If you're writing a small application you want to knock out quickly using Entity Framework or NHibernate or ActiveRecord then use SQL Server Compact or SQLite, or skip that stuff altogether and serialise object graphs to files on the hard-disk.

In fact, if you really design your architecture with an open mind (or beginner's mind), you'll come up with a combination of technologies and paradigms that properly meet different parts of the requirements; maybe use SQL Server 2008 R2 for stock control, invoicing and geo-spatial search operations, but Azure Table Storage for auditing, text files for logging. And why not evaluate distributed Document Stores for the awesome customer review and discussion features that you're adding in phase two?

Most important of all, before making any decisions, take the time to do some apples-to-apples comparisons of potential solutions, with use cases,  data volumes and loads that are representative of your system. I recently chose MongoDB for a personal project, but I started out comparing SQL Server, MySQL and PostgreSQL and finding them all wanting, which is how I ended up looking at NoSQL databases in the first place.

(Just for the record, the most important query and most frequently-run query for the application took nearly 15 seconds on the fastest relational database (even after some violent denormalization); MongoDB can retrieve the same information in under half a second.)

Further reading

A comprehensive – and very balanced – list of articles on NoSQL databases: http://nosql-database.org/links.html

*All apologies to Douglas Adams.

Why?

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<entry xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices"
xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata"
xmlns="http://www.w3.org/2005/Atom">
<title />
<updated>2008-09-18T23:46:19.3857256Z</updated>
<author><name /></author>
<id />
<content type="application/xml">
<m:properties>
<d:Address>Mountain View</d:Address>
<d:PartitionKey>mypartitionkey</d:PartitionKey>
<d:RowKey>myrowkey1</d:RowKey>
<d:Timestamp m:type="Edm.DateTime">0001-01-01T00:00:00</d:Timestamp>
</m:properties>
</content>
</entry>

If you don't like an interface, wrap it

<numbers>
<number>One</number>
<number>Two</number>
</numbers>

XmlElementAsDictionary

var entry = new XmlElementAsDictionary("entry", "http://www.w3.org/2005/Atom");

entry.AddPrefixedNamespace("d", "http://schemas.microsoft.com/ado/2007/08/dataservices");
entry.AddPrefixedNamespace("m", "http://schemas.microsoft.com/ado/2007/08/dataservices/metadata");

entry["title"].Clear();
entry["updated"].Value = DateTime.Now.ToString("s");
entry["author"]["name"].Clear();
entry["id"].Clear();
entry["content"].Attributes["type"] = "application/xml";
entry["content"]["m:properties"]["d:Address"].Value = "Mountain View";
entry["content"]["m:properties"]["d:PartitionKey"].Value = "mypartitionkey";
entry["content"]["m:properties"]["d:RowKey"].Value = "myrowkey1";
entry["content"]["m:properties"]["d:Timestamp"].Value = DateTime.MinValue.ToString("s");
entry["content"]["m:properties"]["d:Timestamp"].Attributes["m:type"] = "Edm.DateTime";

Limitations

Availability

Feedback

Overview

Reactive Extensions (Rx) is the hot new toy out of Microsoft's DevLabs, which is included in Silverlight 4 and .NET 4, and is available as a download for Silverlight 3 and .NET 3.5. It provides a new LINQish way of managing and handling events. More information and downloads available at the DevLabs project page.

I'd read quite a bit about Rx but hadn't taken the time to have a play with it until today, when I found myself looking at the code for a Model-View-ViewModel messaging implementation. The MVVM Messaging pattern consists of a static/global class through which separate parts of the application can communicate without requiring knowledge of each other. Classes can register to receive messages from the Messenger/Mediator, or send messages through the Messenger/Mediator for consumption elsewhere.

Hang on, I thought, that's the Rx pattern pair. I wonder if the two sit well together. So I had a go.

The basics

The Messaging Dispatcher pattern implementation, at its simplest, requires a method for registering to receive messages, and a method to send messages. The IObservable<T> interface consists of a single method, Subscribe, which takes an instance of IObserver<T>. The Messenger interface popularly provides a Subscribe method which takes an Action<TMessage> delegate, but that will be provided by the Rx extension methods if we implement IObservable<T>, so let's just include that in the IMessenger interface:

public interface IMessenger : IObservable<IMessage>
{
    void Send(IMessage message);
}

The Messenger class can be implemented as a very simple wrapper around the Rx Subject<T> class, which is both an IObservable<T> and an IObserver<T>; essentially, calling OnNext on the Subject causes it to call OnNext on its own observers.

public class Messenger : IMessenger{
    private readonly Subject<IMessage> _subject = new Subject<IMessage>();

    public IDisposable Subscribe(IObserver<IMessage> observer)
    {
        return _subject.Subscribe(observer);
    }

    public void Send(IMessage message)
    {
        _subject.OnNext(message);
    }

    private static readonly Messenger _default = new Messenger();

    public static Messenger Default
    {
        get { return _default; }
    }
}

That was easy. That can't be it, can it?

Well, we get a lot of stuff for free with Rx. For example, the Subscribe method in the class above takes an instance of a class which implements IObserver<T>, but the System.Reactive.dll assembly provides a fistful of extension methods which accept one or more Action delegates and dynamically construct a class to implement the interface.

Specifying which messages to receive

One of the key features of a Messaging Dispatcher is the ability to register to receive only messages of specific types. I initially looked for an OfType<T> method on IObservable<T> (to match the OfType<T> on IEnumerable) but there is none, possibly because OfType<T> is implemented on the non-generic IEnumerable and there is no non-generic IObservable. This is reasonable enough: if IEnumerable were implemented today I don't suppose there'd be a non-generic version of that, or indeed any of the Collection classes.

But there is still a valid use case for being able to filter an IObservable<T> for more-derived types than T, as in this MVVM Messenger class. We could add an OfType<T> method to the Messenger class directly, but it is both more useful and more fun to apply it directly to the IObservable<T> type as an extension method.

Here we can make use of the Subject<T> primitive again; we subscribe to the IObservable<T> to be filtered, and when it fires an OnNext passing an argument of the requested type, we pass that on to the Subject. I've implemented OfType to include sub-types, and OfTypeExact to match only the specified type.

public static class IObservableExtensions{
    /// <summary> /// Filter an IObservable for the specified type or derivatives. /// </summary> public static IObservable<TResult> OfType<TResult>(this IObservable<object> src)
    {
        return from item in src
               where item is TResult
               select (TResult)item;
    }
}

This code highlights the "LINQ to Events" aspect of the Rx framework; we can construct natural queries against IObservable<T> sources just as we can against IEnumerable<T>.

Consuming messages

Now, any component which needs to react to messages can subscribe very easily, using methods which are already familiar from the IEnumerable paradigm. To use a common example, here is a WPF Window which looks for DisplayMessage messages and displays a Message Box:

public partial class MainWindow : Window{
    public MainWindow()
    {
        InitializeComponent();

        MvvmRx.Messaging.Messenger.Default
            .OfType<DisplayMessage>()
            .Subscribe(ShowMessageBox);
    }

    private void ShowMessageBox(DisplayMessage message)
    {
        MessageBox.Show(message.Text, message.Caption);
    }
}

You can download the solution file containing the code for this post, as well as a sample application, at http://github.com/markrendle/MvvmRx.