Microsoft Most Valuable Professionals (MVPs) are exceptional technical community leaders from around the world who are awarded for voluntarily sharing their high quality, real world expertise in offline and online technical communities. Microsoft MVPs are a highly select group of experts that represents the technical community’s best and brightest, and they share a deep commitment to community and a willingness to help others.

A community-based award like this would not be possible without the support of my peers, and I look forward to meeting up with some of those very peers at the next MVP Summit! In the meantime, congratulations to all the new and renewed MVPs!

Tomorrow morning at 9:00 AM (hey, if you aren’t first, you’re last — this is Texas after all) I’ll be presenting at Dallas TechFest on the same subject in the .NET track. If you want to learn more about Event Driven Architecture and how we are making it easier to implement with MassTransit, come by and check it out. I promise to deliver a demo that includes all sorts of cool things like NHibernate, FluentNHibernate, StructureMap, Castle, Topshelf, Magnum, and of course, MassTransit.

Also, if you’re in the Tulsa area and weren’t able to make it to Dallas TechFest, I’ll be presenting at the Tulsa .NET User Group on the 29th of June as well. If you do come by, be sure to stop afterwards and say hello. I’ll be at the event throughout the day and am more than happy to talk to anyone interested in learning more about MassTransit. I’m sure I’ll be around the functional programming open space playing with crazy monadic parsers written in C#.

Event Driven Architecture

Business applications no longer exist as isolated systems. In order to provide integrated solutions that add business value, applications must be connected. Modern approaches for enterprise application integration (EAI) such as Service Oriented Architecture (SOA) separate applications into services that can be accessed via a standard interface such as a web service. This collection of services provides a platform on which new applications can be created that leverage the existing functionality.

However, as application complexity increases, the coupling of services becomes an impediment in adapting applications to meet the ever-changing goals of the business. Event Driven Architecture (EDA) is a method of designing and implementing systems where events are exchanged between highly decoupled components and services. EDA does not replace SOA, instead it compliments the request/response nature of SOA with a highly scalable event model for building and coordinating asynchronous transactions.

In this presentation, I will explain event driven architecture, describe the different types of events, demonstrate how events can be related and orchestrated, and provide a basic understanding of how this method can drive the architecture of enterprise systems. In addition to understanding the concepts of event driven architecture, we will explore a working sample built using an open-source .NET messaging framework called MassTransit.

You can catch this presentation at the following events:

• On Monday, June 8th, I’ll be presenting at the Fort Smith .NET User Group.
• On Tuesday, June 9th, I’ll be presenting at the Northwest Arkansas .NET User Group.
• On Friday, June 19th, I’ll be presenting at Dallas TechFest 2009.

If you are one or more of these events, be sure to come up and introduce yourself after the session. Also, if you have any feedback on the presentation, feel free to post your comments here or via e-mail.

Since the first drop of MassTransit, the default format for messages was binary. This had several advantages, one being the ability to take any object and just use it as a message. The BinaryFormatter in .NET is pretty hard core about making sure that the object will come out the other end without any changes. The disadvantage of using binary as a message format is it makes it very difficult to interoperate with other systems. For this reason, we are embracing XML as the new default message format.

The road to XML was not easy. Many months ago when we opened up the endpoints to a configurable serialization format, we ran into some issues with our first attempt at XML. We used the .NET XmlSerializer at first, and found it to be too limited to meet our needs. There was no support for serializing dictionaries (which I would call a smell in your message contract anyway), and you had to register the type of every object being serialized in advance in order for it work properly. With all these problems, we continued to keep binary as the default with XML being experimental.

I started writing a new XML serializer from the ground up nearly a year ago. I went through a lot of approaches and just didn’t find something that I liked using .NET 2.0 as the framework. I looked at a more Google Protocol Buffers technique for a while, but found it a little cumbersome to deal with compared to just using XML. Then, a month or two ago, I started to seriously look at how we could do a solid XML serialization attempt again using the .NET 3.5 framework features. From that research, the current default XML serializer was founded.

Like many ORMs such as NHibernate, the use of the XML message serializer requires that the objects being serialized have a no-argument constructor. It can be protected to hide it from developers, but it must exist. Also, only properties are serialized as they represent the public contract that the message object is sharing. And the properties must be read/write so that the serializer can get and set the value of the property. Here is an example of one of our messages:

public class NewUserRegistered :
CorrelatedBy< Guid >
{
public Guid CorrelationId { get; set; }
public string Username { get; set; }
public string Email { get; set; }
public DateTime RegisteredAt { get; set; }
}

Since messages are DTOs (data transfer objects), I try to keep them clean and simple. They are pure data containers and are not meant to have any behavior associated with them. While I treat my messages as immutable, I don’t find I need to express that in the message class itself since it just tends to make the object more confusing. And quite honestly, there are better ways to express immutable message contracts, such as using interfaces.

The resulting XML for the above message looks like:

< ?xml version="1.0" encoding="utf-8"?>
<x :XmlMessageEnvelope
xmlns:x="MassTransit.Serialization.XmlMessageEnvelope, MassTransit"
xmlns:m="MassTransit.Tests.Serialization.NewUserRegistered, MassTransit.Tests"
xmlns:s="System.String, mscorlib"
xmlns:d="System.DateTime, mscorlib"
xmlns:g="System.Guid, mscorlib"
xmlns:i="System.Int32, mscorlib">
<m :Message>
<s :Username>billg</s>
<s :Email>billg@microsoft.com</s>
<d :RegisteredAt>2009-05-27T13:50:21.106875Z</d>
<g :CorrelationId>acb709df-7e32-45e2-a48c-9c160091aa5d</g>
</m>
<s :SourceAddress >loopback://localhost/source</s>
<s :DestinationAddress >loopback://localhost/destination</s>
<s :MessageType >MassTransit.Tests.Serialization.NewUserRegistered, MassTransit.Tests</s>
</x>

Namespaces are created for each type of object that is serialized. This makes it fast and easy for the deserialization process to figure out what type to use when reading the value from the XML. It’s easy to look and see the actual data that belongs to the message, as well as the headers used by MassTransit.

I wanted to post this as quickly as possible after committing the changes to the trunk so I will wrap up. I’m pretty excited about having a nice, readable message format. Since finding MSMQ Studio, I’ve really wanted to improve the diagnosis story for looking at messages inside the queues. I think this is a solid move towards that goal and a great first steps towards interoperability with other systems.

When I first added saga support to MassTransit, the focus was purely on allowing for long-lived transactions and the orchestration of a series of events that related to a specific process. Earlier this year, the first release of a new declarative programming style for sagas using a fluent interface was put into the trunk, making it possible to design sagas using a more natural structure and language. This feature alone is one of the more compelling things about sagas in MassTransit.

Over the past month or so, I’ve been working on extending the capabilities of sagas in MassTransit beyond the orchestration of directly correlated events (represented as messages). With the latest updates to the trunk, messages that are not directly correlated to the saga can now be observed by the saga using either the interface-based or declarative state machine based saga syntax. This makes for some very compelling functionality as sagas can now observe other events and react to them!

Let’s take a quick look at the syntax using the state machine syntax using a simple message indicating a user has signed out.

public class UserSignedOut
{
	public string Username { get; set; }
}

This message only contains the username of the user that signed out of the system. If we had a saga that tracked the state of an operation on a web site based on the current user, we could observe this message and release any resources that were being tracked by the saga. For example:

public class ShoppingCartSaga :
	SagaStateMachine< ShoppingCartSaga >
{
	static ShoppingCartSaga()
	{
		Define(()=>
		{
			Correlate(UserSignedOut).By((saga,message) => saga.Username == message.Username);

			During(Active,
				When(UserSignedOut)
					.Then(saga => saga.ReturnCartItemsToInventory())
					.Complete());
		};
	}

	public static Event< UserSignedOut > UserSignedOut { get; set; }
}

The Correlate() method is used to define the correlation expression used to match a message to one or more sagas in the saga repository. With this addition, the ISagaRepository has been changed to make it more integrated into the message pipeline, along with the new pipeline message sinks to support this enhanced functionality. The pipeline viewer has also been updated to show the contents of the message pipeline, including all the messages handled by the saga. The Correlate() method can also be used to change how a CorrelatedBy message is also correlated to the saga, making it possible to override the logic on how messages are used to create/use existing saga instances.

The first use case for this new functionality was to improve the subscription service. By making Subscription and SubscriptionClient sagas observe messages from each other, the sagas are able to now complete when they see a node coming back online after a crash or going offline, etc. Since the saga repositories themselves are used to keep track of all the clients and subscriptions in the system, putting that responsibility within the declaration of the saga state machine itself makes for a really clean implementation.

These bits are currently in the trunk and will be part of the next release drop of MassTransit. I encourage you to check them out and provide some feedback on any issues. Some of this may be extended soon to also allow for the custom definition of the policy associated with how messages should be applied to sagas, such as always creating a new instance or using an existing instance of a saga. Some conventions are currently in place based on the Initial state that select a default saga policy (check out ISagaPolicy and the classes that implement it for more details there).

So check it out and keep the great feedback and comments coming on the message group. The new syntax additions should be added to the wiki soon.

First things first — the benefit of waiting until now to jump into ASP.NET MVC is being able to learn from the writing that has been produced. Jimmy Bogard has written a number of articles about how they are using the MVC framework, including strong opinions about how to adhere to the SOLID principles and ensure the long-term maintainability of the final application. Jeremy Miller and Chad Myers have certainly voiced their opinions about the framework, resulting in their own FubuMVC framework.

From my initial dive into the framework, it seems as if an emphasis was put on the View and Controller while leaving the Model a bit behind. Views and controllers are certainly easier to demonstrate, but a good model is going to be very domain specific and hard to generalize in a demo. The framework does make it easy to keep the domain and application services separate from both the controllers and the views, so I think the underpinnings for success are certainly present.

At this point, I’ve only been working with ASP.NET MVC for about a week and I am enthusiastic about what is being provided by Microsoft. Considering Microsoft’s efforts to work with the development community during the development of the framework combined with developer interest, I think it is a sensible solution and certainly a better alternative to ASP.NET WebForms in a .NET development shop. Plus, I feel that web developers should know both HTML and JavaScript, they are the languages of the web after all.

A saga is a way of defining a long-lived transaction, typically involving multiple transactional actors. A workflow is a way of orchestrating a number of actors into a process. Both sagas and workflows can be modeled using the new declarative syntax. First, let’s look at what this new language looks like in code:

static DrinkPreparationSaga()
{
	Define(() =>
		{
			Initially(
				When(NewOrder)
					.Then((saga, message) => saga.ProcessNewOrder(message))
					.TransitionTo(WaitingForPayment)
				);

			During(WaitingForPayment,
			       When(PaymentComplete)
			       	.Then((saga, message) =>
			       		{
			       			Console.WriteLine("Payment Complete for '{0}' got it!", saga.Name);
			       			saga.ServeDrink();
			       		})
			       	.Complete()
				);
		});
}

(I’ve removed the class structure around the constructor to keep the code short)

If we read from the top down, it is easy to understand the behavior for this saga. Initially (which signifies the creation of a new saga based on an event in this block), when a NewOrder is received, then we’re going to call the ProcessNewOrder method on the saga passing it the message that was received. Once that method completes, the saga will transition to the WaitingForPayment state. During the WaitingForPayment state, if a PaymentComplete is received, the saga will output a message, call the ServeDrink method on the saga, and complete.

The states and events of the saga are defined by adding some static properties to the class:

public static State Initial { get; set; }
public static State Completed { get; set; }
public static State PreparingDrink { get; set; }
public static State WaitingForPayment { get; set; }

public static Event< NewOrderMessage > NewOrder { get; set; }
public static Event< PaymentCompleteMessage > PaymentComplete { get; set; }

The static constructor for the state machine initializes these properties during the definition of the behavior as part of the Define() call. It is nice to be able to see all the states and events for the saga in one place, as well as the messages that are related to the events.

Another great feature allows us to ask the saga state machine engine to tell us what it is going to do based on how we defined the behavior of the saga. The StateMachineInspector class is a tool that will output a trace of the defined behavior of the state machine. For the above saga, the output looks like:

	During Initial
		When NewOrder Occurs Containing NewOrderMessage
			(custom action)
			Transition To WaitingForPayment
	During PreparingDrink
	During WaitingForPayment
		When PaymentComplete Occurs Containing PaymentCompleteMessage
			(custom action)
			Transition To Completed
	During Completed

This information is generated by using expressions and reflecting over the class and types contained. The above example is taken from the Starbucks example in the MassTransit trunk. For a service to subscribe and handle sagas like this, the service only needs to call:

var unsubscribe = bus.Subscribe< DrinkPreparationSaga >();

Like all component-based consumers in MassTransit, the container should know how to build the saga and needs to have a ISagaRepository< T > implementation for the saga as well.

I hope as more people start to use this syntax that it evolves in a really rich was of doing code-first workflow and saga definitions. One thing we definitely want to do is take the text-based visualization of the saga and output it in a format that can be used by GraphViz or MSGLEE to get a nice diagram of the behavior of the saga. Hopefully that will be coming sooner rather than later!

So that’s one of the really cool features of MassTransit that have been added.

If you are currently developing with MassTransit, please check out the new bits and give us feedback. The trunk contains all of the latest code. A snapshot of the trunk, along with a 0.6 RC1 build have been added to the GoogleCode site. If you have any problems, comments, suggestions, or patches please post them to the Google Group for MassTransit. We’re interested in all experiences, good, bad, or otherwise.

A quick run down of the changes includes:

• Message Pipeline
  The message pipeline is a replacement for the message dispatcher, as well as the cache-based publishing and subscribing bits. This new pipeline is built using a pipes-and-filter approach and is dynamically adjusted as subscriptions are added and removed — both locally and by remote services.
• Saga State Machine
  With the all new method of defining sagas using a state/event fluent interface, it is now even easier to describe the business logic of a process and the events from which it is built. With the new state machine, it is not necessary to have message consumers and interfaces on your saga, you can just define the events in the class and they are wired automatically by the subscription framework. The early version of the syntax was discussed in this post.
• Better Request/Response Support
  The old bus.Request() syntax has been replaced with a new fluent style for making requests and waiting for responses. Both synchronous and asynchronous calling conventions are supported. Look for the new bus.MakeRequest extension method for more information on this slick new syntax.
• Code-based Configuration Syntax
  A new, code-based method of configuring and running a service bus has been added. This syntax significantly simplifies getting started with MassTransit and has been used throughout the unit tests. The facilities for Castle have also been updated to transparently use this new syntax with the same XML-style configuration in Windsor. More details on this syntax can be found here.
• Message Headers
  Messages are now wrapped in an envelope and headers are associated with the message. The pipeline will add certain headers, and additional headers can be added by the message publisher using an extension method to the IServiceBus.Publish and IEndpoint.Send methods. Header properties such as ResponseAddress, FaultAddress, DestinationAddress, and SourceAddress make some more advanced routing options available. All three message serializers support the message headers. Which brings me to…
• Binary, XML, and JSON Message Serializers
  All three serializers can now be configured for use as the wire message format.
• Topshelf Integration
  The old MassTransit.Host has been replaced with the easier to use Topshelf service hosting framework.
• Unsubscribe via Delegate
  The Unsubscribe methods on IServiceBus have been removed. When Subscribe is called, an UnsubscribeAction is returned instead. This delegate should be called when the subscription is no longer needed. This makes it easier to modify the state of the service bus in response to subscribe/unsubscribe actions by maintaining all of the information needed to unsubscribe in a lambda expression. The UnsubscribeAction is a delegate, and multiple unsubscribe handlers can be added together via the += operator. You can also use the extension method to get an IDisposable version of the subscription.
• Redesigned Subscription Service
  The subscription service and client have been rewritten to take advantage of the new saga syntax. This reduces the number of specialized components needed for each service, as well as leveraging the features of MassTransit internally. Check out the SubscriptionManagerGUI in the WinFormSample for a demonstration of the service, as well as the pre-built services for use in your production environment.
• Starbucks Sample Updated
  The Starbucks example has been updated to use the new saga state machines as well as some housekeeping updates to use the new features. Be sure to check it out as a starting point for understanding sagas and how to interact with them. Details on how to get the Starbucks sample running are on the wiki.

We’re hoping to get an official 0.6 release in the next couple of weeks, so please provide any feedback you have to help us wrap it up. You can get the bits, including a source and binary distribution here.

Check it out on their web site (where you can listen, or subscribe via iTunes/PodCastRSS).

I’ve been doing a lot of work in Xcode lately, building an application for the iPhone. I officially joined the developer program this past weekend, making it possible to load applications into my phone for testing. I’ve got a few ideas for some applications that I haven’t seen done yet, so hopefully I can get something out there to fill the void.

I have to say, the more I work in Objective-C, the more I like it. Sure, I’m missing a few things like all my comfortable frameworks and such, but there are plenty of other ways to deal with things I’ve coming across. And since the NDA, sites like Stack Overflow have become a great resource for getting answers to issues I come across.

I’m still working on my other projects like MassTransit, this is just something to broaden my knowledge and have fun at the same time. Between developing on the iPhone, doing Java projects at work, and building open-source .NET frameworks at home — I’ve got plenty to keep me busy!