PhatBoyG (Chris Patterson)

I'm a Microsoft C# MVP!

2009-07-02T00:14:35Z

Opening my Inbox this morning resulted in a pleasant surprise from Microsoft. I have been presented with the 2009 Microsoft® MVP Award as a recognition for sharing my expertise in Visual C# with others. It is an honor to be recognized by Microsoft for doing something that I truly enjoy - building really cool software.

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!

Dallas TechFest 2009 Tomorrow

2009-06-19T03:04:26Z

It's been a couple of busy weeks! The weekend before my presentations in Arkansas, I decided to forego sleep and go to Wakarusa! The Saturday lineup included two of my favorite electronica acts, Shpongle and Ott, and introduced to another band STS9. Staying up all night dancing to heavy techno music and getting no sleep was one heck of a prelude to the week. After the seriously fun times I stopped in on the Fort Smith and Northwest Arkansas .NET user groups and shared my thoughts on Event Driven Architecture. Both nights went well, with some great conversations afterwards about the how and why that took me towards that style of architectural system design.

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#.

Presenting on Event Driven Architecture and MassTransit

2009-05-28T02:57:29Z

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.

MassTransit Now Speaks XML By Default

2009-05-27T14:12:00Z

Last night, I made a major update to the trunk of MassTransit that changes the default message format from binary to XML.

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

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.

MassTransit Saga Enhancements for Event Processing

2009-05-23T02:32:18Z

In the past year, I've been learning about Event Driven Architecture and how using it in the enterprise can make adding functionality over time easier through a loosely-coupled event-based architecture. With Event Driven Architecture, business components can subscribe and react to events, using correlation and orchestration to combine those events to represent business processes. The loose-coupled nature makes it easier to add functionality without modifying existing services -- reducing the risk of deploying new services over time.

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
{
	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 { 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.

I'm Down With M.V.C., Yeah You Know Me!

2009-05-11T01:48:01Z

Over the past week, I've had some time to dig into the new ASP.NET MVC framework. For starters, my background in web development is mostly classic ASP talking to COM objects built in C++. I've only used ASP.NET to provide web services for smart clients. Beyond that, my experience has been all PHP joined by a short experimentation period with Ruby on Rails. When Scott Gu presented the new ASP.NET MVC framework at the first ALT.NET Austin in 2007, I was excited to see Microsoft stepping into the space where at the time Monorail was the only viable choice.

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.

Declarative Workflow with MassTransit

2009-04-08T01:53:36Z

One of the really cool features that is available in the 0.6 release of MassTransit is the ability to declaratively define a saga/workflow using a nested-closure syntax in combination with a fluent builder. While some wonder if fluent interfaces are going to become the "aluminum wiring" of the current generation of software development, I find them incredible valuable for building an expressive representation of logic.

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 NewOrder { get; set; }
public static Event 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();

Like all component-based consumers in MassTransit, the container should know how to build the saga and needs to have a ISagaRepository 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.

MassTransit 0.6 Release Candidate

2009-03-31T02:17:51Z

I'm proud to announce that we are getting close to a final 0.6 release of MassTransit. We've been working on this release since early December and have added a lot of new functionality. We're also glad to have integrated a number of patches that the community has contributed -- thanks for your help!

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.

Dr. Dru and PhatBoyG On Elegant Code Cast

2009-03-19T04:41:39Z

Just over a week ago, Dru Sellers and I recorded a podcast with Elegant Coders Jarod Ferguson and David Starr. We spent a couple of hours discussing event driven architecture (EDA), messaging, and MassTransit. Through the magic of editing, they managed to end up with a solid eighty minutes (most likely to achieve a straight up G rating).

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

Developing for the iPhone

2009-02-09T00:01:05Z

First, one my the reasons I love using OSX: 16 applications open including 4 Xcode projects, Photoshop, Numbers, Evernote, Mindjet MindManager, and more without a hint of slowdown and still 1.3 GB free (4GB total on my MBP). It's wide, because I use a 24" display next to my built-in laptop display.

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!

State Machine for Managing Sagas

2009-01-17T04:42:00Z

MassTransit supports sagas, which are long-lived transactions consisting of multiple events. The saga support makes it easy to orchestrate the events into a process, but it doesn't do much to help with state management. Since state management is fairly common, I felt it necessary to add some support for a state machine.

In MassTransit, a saga is defined by creating a class and attaching some interfaces for the messages that will be consumed. The messages are the events, and the class is the saga. An example saga is shown below.

   public class DrinkPreparationSaga :
        InitiatedBy < NewOrderMessage >,
        Orchestrates < PaymentCompleteMessage >,
        ISaga
    {
        public void Consume(NewOrderMessage message)
        {
        }
        public void Consume(PaymentCompleteMessage message)
        {
        }
    }

I've omitted the code for each consumer to keep it short, but the business logic defined would handle the fact that once the drink is prepared, it should not be served until the PaymentCompleteMessage has been received. Storing this state is an application concern.

While I was at QCon San Francisco, I attended a tutorial session on DSLs. It was here that I got the idea to somehow make a DSL for defining the behavior of a state machine that could be used with sagas in MassTransit. It's taken a couple of months, but I think I've managed to put something together that simplifies state management in sagas. With the addition of a new state machine in Magnum, along with persistence support for NHibernate, it is now easy to manage this state automatically.

To demonstrate this, below is the state machine for the above process.

	public class DrinkPreprationStateMachine :
		StateMachine < DrinkPreprationStateMachine >,
		ISaga,
		InitiatedBy < NewOrderMessage >,
		Orchestrates < PaymentCompleteMessage >,
		Orchestrates < DrinkPreparedMessage >
	{
		static DrinkPreprationStateMachine()
		{
			Define(() =>
				{
					Initially(
						When(NewOrder)
							.Then(saga =>
								{
									// start preparing the drink
								})
							.TransitionTo(PreparingDrink));
					During(PreparingDrink,
						When(DrinkPrepared)
					       	.TransitionTo(WaitingForPayment),
						When(PaymentComplete)
					       	.TransitionTo(WaitingForDrink));
					During(WaitingForPayment,
					    When(PaymentComplete)
					       	.Then(saga =>
					       		{
					       			// publish drink ready message
					       		})
					       	.Complete());
					During(WaitingForDrink,
						When(DrinkPrepared)
					       	.Then(saga =>
					       		{
					       			// publish drink ready message
					       		})
					       	.Complete());
				});
		}
		// event and state definitions not shown, but are simple properties
	}

As shown above, all the logic of states, events, and transitions is wrapped into a clean fluent interface. The During() blocks define what is to be done when events are received during a particular state. The When() blocks define the behavior when the specified events occur. All state transitions are explicit, allowing them to be captured as part of the state machine.

There are two types of events. BasicEvent supports an event without any accompanying data. The DataEvent < V > allows data to be associated with an event. In MassTransit, each DataEvent would have a matching Consume() handler. For example, Event < NewOrder > would have a public void Consume(NewOrder message) that would call RaiseEvent(NewOrderEvent, message) to pass the event to the state machine along with the message.

The state machine also supports inspection, allowing the definition to be output for verification that the intent was properly conveyed by the interface. This not only makes it possible to verify the flow between states, but also could allow the creation of a graph to display the states, events, and transitions in a visual manner. The provided state machine inspector currently only outputs to the trace window, but could easily be enhanced by somebody with some skills.

Also, not shown above, is the ability to specify an expression using the .And() method to evaluate the data associated with an event to determine if that event is handled by that state event action. This expression is kept as an expression, allowing the details to be output using the inspector as well.

Currently, the saga must still implement the Consume() method for each message and call RaiseEvent() on the state machine to pass the message and trigger the event. I plan to add some new message sinks to the message pipeline to make those methods unnecessary, mapping the messages directly into the event handlers within the state machine. This isn't done yet, but it is planned.

The StateMachine also provides an IUserType implementation for NHibernate in the Magnum.Infrastructure assembly. This makes it easy to persist the state using NHibernate, storing the current state as a string. This is just the default implementation, any other could be built if your needs are different.

I originally presented this syntax during the Virtual ALT.NET meeting last week. It was a last minute presentation, so I wasn't sure I covered all the details. Hopefully this will help provide some guidance on how it is used, along with plans for the future.

MassTransit Turns One Year Old, Celebrations Held Around the World

2008-12-26T16:20:06Z

Today marks the one year anniversary of the first commit to the MassTransit GoogleCode repository. While Dru Sellers and I initially did some proof of concept work, this day marks the decision to go forward with a standalone .NET messaging framework.

MassTransit was started as a collaborative effort to provide a lightweight messaging framework on MSMQ for .NET applications. Both Dru and I needed a framework for asynchronous messaging to address some work-related application requirements. While MSMQ is provided out of the box, it doesn't directly encourage some good distributed application practices such a loose coupling. Our goal was to abstract the messaging aspects so the services could be built to deal with plain old objects (POCOs) instead of lower level transport messages.

Originally, we both looked at NServiceBus as a way to make this happen. I've followed Udi's blog for a while and have really gained a lot of knowledge from his posts and presentations. However, our lack of experience in Spring.NET, along with a general lack of understanding of all the complexity of such a framework led us down the path of building our own framework.

So that's how MassTransit got started. A year later we're still improving the code and providing useful functionality for developers to build loosely-coupled asynchronous applications. We've even harvested some common functionality (such as the service host, which is now a standalone project Topshelf), and plan to harvest out some additional features in the near future. The great thing about building open source software is the cooperative nature -- even on similar projects. We all learn from each other and build that knowledge into tools that other developers can use and learn from as well.

Simplified MassTransit Configuration

2008-12-21T05:26:02Z

One of the things I've missed since we integrated container support is the ability to quickly and easily create an instance of the ServiceBus. After Ayende agreed, I decided it was time to do something about it.

Behold the minimum amount of code necessary to create a service bus:

That's it. In fact, you can easily mock out the container with some nifty Rhino.Mocks usage:

I'm starting to convert the tests to use the mocked container approach to reduce the runtime of the tests. But so far the HeavyLoad, Starbucks and WinFormSample samples have been verified to work with the new model. The Windsor facility is also using the new model (Dru is going to update the other two tomorrow).

I'm pretty happy with the new configuration syntax, it certainly makes it easier to setup a bus with zero XML abuse. Look for more of this style of configuration/extension in MT in the near future.

QCon San Francisco, Opening Day

2008-11-22T05:50:49Z

The main conference for QCon started Wednesday, opening with a keynote by Martin Fowler and Rebecca Parsons from Thoughtworks. The topic was Architects and Agilists - Allies not Adversaries. As you can surmise from the title, this talk focused on building a collaborative relationship between ivory tower architects and the teams responsible for delivering software. With a scene from the Matrix where Neo meets The Architect as the backdrop, a number of solutions were presented after highlighting the key disconnects between the two roles. I've always been a firm believer that architects who do not code (NCA's) are not nearly as effective as those who understand the issues of those actually writing code.

MERB

Since the presentation by Dan North was overflowing with humanity, we opted to attend the session on MERB. MERB is a high-performance, scalable MVC framework for Ruby. It is in the same space as Rails, but with a lot of optimizations to increase performance. It also supports slices, allowing features to be added as simple gems. This is one to keep an eye on as it grows.

Google App Engine and the Google Data APIs

My next stop was to learn about Google's AppEngine and how it handles scalability and performance. It's currently free, and developers can build and deploy applications into the cloud using Python and Bigtable. It's an interesting engine with a completely transparent scaling infrastructure. You worry about your application, the system takes care of the rest. Large applications have been built and Google has allowed them to scale beyond the standard quota for free accounts. While final pricing has yet to be discussed, it's likely to be very competitive. There is also a planned introduction of new language support early next year, but the exact language runtime being added was kept secret.

Responsive Design

The next stop was a talk by the legendary Kent Beck and his thoughts on what he calls responsive design. This talk was way up the clouds, and I'm talking the real ones. I think it's great that we have people that think that far out, but I found little to take away from this session other than some looks of befuddlement.

Coupling, Messages, and Conversations

Since I started working on MassTransit, I've used the Enterprise Integration Patterns book by Gregor Hohpe as a reference manual for building distributed message-based systems. In this talk, Gregor laid down some fundamentals and set the stage for a sequel to the book that will be titled Conversation Patterns. But first, the challenges of message-based systems were presented. The levels of failure are quite involved, and include things like lost request, lost response, slow response and retry duplication. A lot of these are covered in texts online, so much of this material was review for me. A new acronym for ACID was also declared: Associative, Commutative, Idempotent, and Distributed.

With large scale distributed systems where consistency is of a more eventual rather than immediate nature, it's important to recognize that the future if flexible and redundant rather than predictable and accurate. Building distributed transactions that are durable and that support compensation is crucial to having a success, scalable application.

During the final session slot, a few of us sat down and had an in-depth discussion about what we had learned that day. Realizing that this was only the first and lightest day, we recognized quickly that we were in for a couple of dense days of exposure. We went over some things in MassTransit, and thought about how we could offer a more developer-friendly method of managing the state of distributed transactions (sagas in MT). We also delved into the hierarchical structure of conversations on top of sagas, a topic we hoped to dig into more as we saw multiple concurrent sagas running in parallel as part of an overall conversation.

Attendee Party

That evening, there was an attendee party at a nearby pool hall. After some snacks and a quick game of pool, Dru and I sat down with Gregor to discuss some messaging concepts. After a quick exchange in Japanese, we earned a seat at the table and started to talk about various conversation patterns that we had identified in our own work. I was surprised that we were thinking along the same lines and that several of the message patterns we had used were going to be covered in the book. We also talked a little bit about Google Protocol Buffers (a platform and language independent format for serializing data in an efficient, binary stream). We started digging into GPB a few weeks ago as a way to build more system interoperability between Java and .NET when using MassTransit. Based on our process so far, this is likely to end up in a future release of MT.

With that, the evening was pretty much done with my head pounding. I retired for the night recognizing that the time zone change was probably going to result in me waking up at 4:00 AM again (which, of course, I did).

QCon in San Francisco Getting Started

2008-11-21T16:52:38Z

This week I'm attending QCon, the international software developers conference, and since the day I arrived it has been great. The depth of knowledge is truly amazing and I'm enjoying some excellent conversations. The attendee mix is (based on my estimation) 50% Java developers, 30% .NET developers, and 20% other languages like Ruby or Python. The diverse nature of the conference is interesting in that many of the sessions are platform-neutral, focusing more on patterns and practices and a less on tools.

Domain Specific Language (DSL) Tutorial

The first day for me was an all-day tutorial on domain-specific languages hosted by Martin Fowler, Neal Ford, and Rebecca Parsons from Thoughtworks. The content was deep, and covered everything from XML (the least expressive DSL, despite being one of the most widely used) to custom languages built using Lex/Yacc grammar syntax. Martin's site has a good amount of the content for his upcoming book on domain specific languages and a lot of that content was covered in the session.

My favorite takeaway was the styles shown for internal DSLs (also called fluent interfaces). An internal DSL is built using the language itself rather than creating a new grammar. There are plenty of great examples of fluent interfaces, including the FluentNHibernate project and StructureMap's registry DSL. The immediate value of an internal DSL is the understanding gained from reading code written using this style of interface.

Tuesday night is when a lot of the people started showing up since the tutorials were more of a pre-conference. I got to meet up with some friends and have some good chats before calling it an early night before the next three days.

I'll post more about the rest of the conference soon!