One of my favorite features is the visualization of the RETE graph once the engine has been loaded with rules. An example is shown below.

You can download the Visualizer and install it in Visual Studio 2010 (unzip the contents to your My Document/Visual Studio 2010/Visualizers folder). Then, mouse over a reference to a rules engine while debugging and you should be able to select and display the RETE graph of the engine.

Download the visualizer assemblies here: OdoyuleRulesVisualizer.zip

The project is hosted on GitHub, at http://phatboyg.github.com/OdoyuleRules

Enjoy!

As I mentioned previously, I didn’t invent it. I’m merely leveraging the information obtained from a number of sources and applying it in a way that I think makes it easier to build certain types of applications. Applications that can benefit from a highly concurrent actor-based programming model include reactive systems — ones that respond to nondeterministic external events. Since many applications can be described as “a program that responds to external events” it only makes sense that the actor programming model can be applied to many domains.

Here are some papers that I’ve read on the actor model, some of which have influenced me in how I think about concurrent programming and others that have merely provided background information or depicted ways in which concurrent programming should not be approached.

Actors, Rajesh K. Karmani, Gul Agha

Actors: A Model of Concurrent Computation In Distributed Systems, Gul A. Agha (out of print)

Actor Languages for Specification of Parallel Computations, Gul Agha, Wooyoung Kim, Rajendra Panwar

An Actor-Based Framework for Heterogeneous Computing Systems, Gul Agha, Rajendra Panwar

Actors that Unify Threads and Events, Philipp Haller, Martin Odersky

Lightweight Language Support for Type-Based, Concurrent Event Processing, Philipp Haller

Compilation of a Highly Parallel Actor-Based Language, WooYoung Kim, Gul Agha

These are some of the more involved works from which I’ve found many useful bits of information. I’ve got them permanently stored in GoodReader so I can keep looking back to them (and my associated annotations as well). Hopefully anyone looking to build systems using the actor model (and hopefully, using Stact if you’re on the .NET platform) can get a better understanding of the model by reviewing these papers.

For those using the 1.x lineage of MassTransit, v2.0 includes several breaking changes in the API. This was necessary to reduce the complexity of getting new users up-to-speed, as well as eliminating some common areas of confusion. The API for v2.x should remain consistent from this point forward (well, until we start working on v3.x, which is a long ways off honestly).

Project Site (hosted on GitHub)
NuGet Project
Documentation
Mailing List
Ohloh Metrics

It’s worth noting that the MassTransit organization on GitHub is the ‘official’ repository. Please file any issues on that repository so that all of the MassTransit team members can help with any issues. However, you are encouraged to check the mailing list first as many first-time issues are discussed there.

This release was a long road and involved a lot of internal code cleanup, API grooming, and support for a new transport (RabbitMQ). We welcome your feedback, questions, and suggestions.

Enjoy!

First, I wanted to share a few links to the content discussed in the session, including the GitHub Project, the NuGet package, and the TeamCity build. I will update the post with the video link once the presentation video is available, along with the slide deck.

Second, I plan to post a series of blog posts explaining how actor model programming is a great model for building concurrent applications, despite the difficulties that the actor model has had in becoming more mainstream (some of those difficulties are explaining in this article by Paul Mackay).

In the meantime, I’m going to take a hard look at how different languages have implemented the actor model (many of which have influenced the current syntax used in Stact). I’m also taking a step back and identifying other ways the model can be implemented the minimize many of the difficulties and bring some modern programming style to the model. Concurrency is certainly difficult, but I’m convinced that many aspects can be made more approachable by applying some existing idioms to the problem.

If you do take a look at Stact, please offer any feedback you have via Twitter (I’m @PhatBoyG) or GitHub (using issues, whatever). If the traffic grows, we’ll setup a Google group to keep things manageable.

Until next time…

After what seems like a long slumber, along with work being done on other projects such as Topshelf and Stact, it is our great pleasure to announce the first beta release of MassTransit v2.0. What originally started out as a minor “1.3” update has turned into a full-out cleanup of the codebase, including a refinement of the configuration API. Since there were some breaking changes to the configuration, we felt a 2.0 moniker was better to ensure users of the framework understood the depth of the changes made.

And what a list of changes it is (TL;DR = We filled it with awesomeness):

1. Configuration
   MassTransit v2.0 now includes a streamlined configuration model built around an extensible fluent interface (inspired by Stact and Topshelf and sharing a common, consistent design). As a result, getting started with MassTransit is now easier than ever. In version 2.0, all configuration starts with the ServiceBusFactory and Intellisense guides you from there forward. The result is a clean, understandable API and a quicker out-of-the-box experience.

2. Container-Free Support
   With the release of MassTransit 2.0, using a dependency injection container is now optional. When we started MassTransit, we leveraged the container extensively to assemble the internal workings of the bus. As we added support for other containers, required features that were not supported by a particular container led to some creative solutions (read: hacks) that were less than optimal. By moving away from a “container-first” approach, we have increased the reliability of the software and now provide container-specific extensions to subscribe consumers from the container in one simple step. We also threw in support for Autofac!

3. Quick-Start
   By simplifying the configuration, and dropping the need for a container, it is now fast and easy to get started using our new QuickStart:
   http://docs.masstransit-project.com/en/latest/configuration/quickstart.html

4. #NuGet
   NuGet packages have been added for the base MassTransit project, with any external dependencies (log4net and Magnum) resolved using the proper NuGet packages. Any additional references are downstream in additional NuGet packages, such as support for persisting sagas using NHibernate (MassTransit.NHibernate), and the various dependency injection containers supported.

5. Multiple Subscription Service Options
   In addition to the existing RuntimeServices included with MassTransit, an all-new peer-to-peer subscription service has been added. By leveraging the reliable multi-cast support in MSMQ, services can now exchange subscription information without the need for a centralized subscription service. To ensure everything is setup correctly, a VerifyMsmqConfiguration method has been added that will check the installation of MSMQ and install any missing components. This is the first iteration of multi-cast support, and we need to get some mileage on it. In the meantime, the original run-time services continue to work as expected.

6. Documentation
   Which brings us to the next big update. DOCS! They’re not perfect, and they’re far from complete, but we have focused on the configuration story to help get you up and running. As we see a need for more documentation in a given area, we will continue to flush out the docs appropriately. The docs are located at http://docs.masstransit-project.com/ and are being hosted by the fine people at http://readthedocs.org. [Thanks Eric!]

7. Support for .NET 4.0 and .NET 3.5
   The project files and solution have all been updated to Visual Studio 2010 SP1. By default, all projects are now built in the IDE targeting .NET 4.0. The command-line build (which has been revamped to use Rake and Albacore) builds both .NET 3.5 and .NET 4.0 assemblies, including the run-time services and System View. The NuGet packages also include the proper bindings for the target project run-time version (you must use the full .NET 4.0 profile with MassTransit, the client profile is not supported).

8. Transport Support
   Internally, the transports and endpoints have been redesigned to improve the support for new transports like RabbitMQ (and improve our ActiveMQ support). For example, transports are now inbound, outbound, or both, allowing us to properly leverage fan-out exchanges on RabbitMQ for publishing and subscribing to messages. There is more to come in this area as we take greater advantage of these advanced transport features. If you’re a RabbitMQ or ActiveMQ user and don’t mind getting your hands dirty, now is a great time to jump in and help improve transport support.

9. Distributor Consumer And Saga Support
   Work on the MassTransit distributor subsystem continues to be improved. Testing on a multi-master system has been completed which will allow it to serve multiple distributors to improve load balancing efficiency. Support for all sagas (previously only state machine sagas were supported) has been added as well.

10. Swinging the Feature Axe
    Some previous troublesome and poorly supported features (Batching and Message Grouping) were removed from the 2.0 release to reduce code complexity. Also in light of the new Parallel Tasks work in the framework the Parallel namespace has been removed.

In the next few days, I’ll be posting an annotated walkthrough of the new configuration API. In the meantime, fire up Visual Studio 2010, create ConsoleApplication69, switch to the full .NET 4.0 framework, and Add a Library Package Reference to MassTransit using NuGet. Paste the code from the Quick Start into your program.cs and check it out!

What follows are a few of the common design choices that I encountered, with my take on how appropriate that same choice would be today.

Data Storage

As I looked into each product, I examined how various requirements were addressed given the tools available at the time. For example, I didn’t question the use of a flat file to store reference data in the early client/server products since flat files were perfectly acceptable at the time. However, this led me to question some design choices when looking at SAAS products — including some choices that you might not expect. For instance, why is a flat file not an acceptable design choice for a system developed today? The data is still the same reference data, yet current guidance would suggest this reference data be stored in a database, most likely a relational database.

Is this because developers have become too lazy to write the component to read the file? Surely not, since a component will have to be written to import the reference data into the database. While it can be done fairly easily using database tools, the process still has to be scripted out and repeatable in case the import needs to be repeated on a new database.

Let’s enhance the problem and add a time dimension to the reference data, making updates available every thirty days. Now, not only is an initial import needed, but the import component will also need to support updating the database with the new content. Again, this could be done using database tools — a simple truncate table and repeat the import process. But what if developers have created relationships between the reference data table and other tables in the system? What if those relationships were created using the row id instead of the appropriate business identifier? At that point, the table cannot be simply truncated and the update process must now perform a complete delta of the existing and updated data sets and merge the changes into the database. That certainly doesn’t sound lazy — if anything, it sounds downright painful.

Another question that came to mind when using a relational database to store reference data was “which database?” Now, if the first answer that popped into your head when you read that was “SQL Server,” or even worse “the database,” therein lies the real problem.

A product is not just an application, it is a system composed of one or more applications, multiple components, multiple services, and multiple databases. Consider the earlier example that used a flat file to store reference data. The flat file itself is a separate database. In a system of any complexity there are many different sets of reference data, all of which are stored in their own separate flat files. Therefore, the system has multiple databases, each using the appropriate technology based on how that database is used.

If the reference data had remained in a flat file, when the flat file was updated with the new reference data, the original file is simply replaced and the system continues. No special import or update process is required.

Nested Object Graphs

Another common design I saw, particularly in products that manage a revolving set of accounts, was the use of a deeply nested object graph that is persisted in a relational database. As accounts were accessed, the entire object graph would be loaded from the database and presented to the user. Once the user made whatever changes were necessary at the time, the account was then saved to the database. In order to save the object graph, the nodes at each level in the graph are compared with the database, and deltas are generated to update the database tables.

In early examples of this design, a pessimistic locking system was implemented to track user activity and prevent multiple users from working on the same account at the same time. This was common in the client/server products, since even at that time record locking using ISAM files (or even network file locking) was fairly problematic.

As products moved to the web, a more optimistic locking strategy was used. I found two different conflict resolution methods, the first of which used a timestamp to track modifications to an account. If an update was received and the timestamp didn’t match, the later update was rejected. The second method was “last write wins,” updating the account to whatever was in the later update — possibly and quite commonly losing previous updates from other users. This got real interesting when two updates were performed at the same time.

Neither of these solutions make sense today for SAAS applications. In an environment where multiple users may be interacting with an account at the same time, it’s more important to look at providing users with a task-based user interface that captures the intent of each action on an account. For example, loading an entire account just to change the billing address creates unnecessary data movement that can limit throughput (read: scalability concern). At the same time, preventing a user from adding a charge to an account because another user slipped in behind you to update the phone number creates an unnecessary user burden. If updating the billing address, updating the phone number, and adding a charge to an account were explicit actions (read: commands) that can be performed on an account, they could all be performed simultaneously without conflict.

Note that the Command-Query Responsibility Segregation (CQRS) or even just Command-Query Separation (CQS) architectural styles specifically addresses this type of design.

Stored Procedures

In the example above, a deeply nested object graph was loaded from the database. In a system designed today, a developer would most likely reach for an object-relational mapper (ORM) to deal with loading and saving the object graph to the database. There are many to choose from (Hibernate, NHibernate, and Entity Framework are a few) and they solve the problem of binding object graphs to relational database tables very well. In fact, most ORMs today can generate the DDL needed to create the database objects as well — eliminating the need to write table creation scripts by hand.

At this point, I can hear the blood pressure of many database administrators reading this rising through the roof. With SQL book in hand and years of experience writing stored procedures full of selects and cursors, the story of how a hand tuned stored procedure that returns a sequence of forward-only record sets in a single round trip to the database server is the only way the scalability requirements of the application can be met. I’m not saying that using a stored procedure in this situation is wrong, but making a stored procedure the first tool you pull out the toolbox is very wrong indeed.

Why is it wrong? Creating a stored procedure to read data as the first approach is wrong because it is an optimization. Optimizing components of a system before that particular component has been identified as a bottleneck will lead to increased complexity, and that complexity will breed quickly in the project. And as complexity increases across the project, long term maintainability suffers as the capabilities of the development team are challenged. Yep, you guessed it, the stored procedure first approach is a classic case of premature optimization.

How does using a stored procedure in this way breed complexity? First of all, it establishes a myth that reads are a problem. As functionality is added to the system, developers who have come to believe that any account related reads must be done with a stored procedure else they become responsible for performance inadequacy, create more read procedures. As features continue to be implemented, more data elements are added to the schema, requiring every stored procedure to be updated as the schema changes — creating more work for developers who must now touch features that were complete and tested to ensure they still operate as expected.

The opposite effect of the read myth is that retrieving the entire object graph for an account is so well optimized that it is better to load the entire object and use only the needed data elements rather than create a new read procedure. With an ORM, this is handled very well using projections and fetching strategies. Developers can use the ORM to read a partial object graph, returning on the required data elements and reducing the data movement between the database and application server.

All of this accidental complexity was created based on the superstition that only a stored procedure would be fast enough to support the scalability needs of the product. An optimization that was implemented before a bottleneck was identified.

Considering that most ORMs today are capable of writing very efficient SQL and have dialects specifically tuned for each database platform, the read performance of the ORM is less likely to be a system bottleneck. For example, with Microsoft SQL Server, NHibernate takes advantage of batch queries with ADO.NET to reduce the number of round trips between the database and application servers. The SQL generated is also parameterized, allowing the SQL engine to cache execution plans for better server performance. Given these optimizations have already been done by the ORM, tuning read performance in the database is not likely to create the biggest benefit in system scalability. For example, caching of already loaded objects will likely result in greater overall read performance.

Did I forget to mention that this early decision tightly coupled the product to using a particular database platform? SQL dialects are hardly portable between platforms, so the product now has to decide if it will work with a single platform or create a separate release branch for each database platform supported. The better ORMs support multiple server dialects, including Microsoft SQL Server, Oracle, MySQL, PostgreSQL, and many others.

I said I wouldn’t argue the performance difference between using an ORM and a stored procedure. I will point out, however, that using a stored procedure to tune performance is an optimization for a particular environment and should not be an early choice in system design. Going straight for the stored procedure without considering less complex options is another case where a lot of times, the tool we used yesterday is not always appropriate for a system being designed today.

To Be Continued…

Above I’ve covered a few of the design choices made early in the development of several major products and how that affected the evolution of the product over time as featured were added. I also applied a modern view of how many of the choices we made before all these “great tools” were available are not necessarily bad today. As I get more time, I hope to share a few more stories with you as I undercover them in what has basically become a “career retrospective” for me.

While traveling to community events, it’s amazing to run into folks that are using MassTransit in their applications — particularly ones that I’ve never heard from before. It’s a cool feeling to know that people are finding value in the effort we’ve put into it. Over the past few months, several organizations have been finalizing the testing of new applications built on top of MassTransit, taking advantage of the state-driven saga support (including the new distributor for load balancing saga instances across servers), in preparation for production launches. Several contributors have offered tremendous help with this new functionality, including development of and testing with the distributor support.

It is great to see users of the framework taking an active role in shaping the feature set to meet a more generalized set of requirements. When Dru and I started creating MassTransit, we had a fairly narrow feature set that needed to be implemented. As the use of messaging in our applications expanded, we started to identify new features that would provide additional benefits. Being able to harvest application-specific code into the framework has provided a high level of reuse which helps everyone.

GitHub

The biggest move that we made in the past few months was leaving GoogleCode behind and migrating the project to GitHub. If you have not yet discovered it yet, Git is an amazing distributed version control system that offers tremendous flexibility when working on highly distributed projects, such as open source projects. Combined with the amazing social collaboration that occurs on GitHub, we have merged significantly more features from contributors on GitHub in the past few months than we had previously received the entire time we were hosted at GoogleCode. Many have forked the main project (which is hosted on my GitHub account, and is also used to drive the official builds on the CodeBetter TeamCity server) and made changes that I have merged into the main project.

You can still download a compressed archive of the latest source from GitHub by clicking the download source link on the project source page. You can also download the latest build (or the tagged v1.0 build) from the TeamCity artifacts link. The build runs automatically when code is push to GitHub, so the latest build is always from the latest bits in the master branch.

Major Milestone

On March 1st, we marked a v1.0 release candidate of MassTransit (and the related projects Topshelf and Magnum). With open source projects there is always a syndrome of 0.x, where many projects never reach 1.0 yet are still used in production systems at multiple organizations. Considering the number of organizations using MassTransit (and even Topshelf by itself for hosting Windows services), we decided it was time to mark the release 1.0 and freeze the feature set for that line of the codebase.

Since the 1.0 release candidate, there has been very little active development on the MassTransit codebase. The reason for this is simple, we wanted to allow the framework a little time to soak into the community. There are a lot of features that we want to put into the framework, and several of these are under heavy development outside of the master codebase, but the main feature set for 1.0 was released to allow organizations to go forward with implementations that were waiting on an official release.

Documentation

We have heard you, and we are going to start improving the documentation. We’ve set up a site specific to each project (MassTransit, Topshelf, Magnum) and are going to be harvesting the content from the wiki to create a reference set of documentation for using MassTransit. Hopefully we can take some of the questions from the discussion list and get them into a QA/FAQ section as well.

As an aside, I started this post based on a purse fight that was held on Twitter this morning in regards to OSS activity in the .NET community. It is certainly important as an open source project owner to keep the lines of communication flowing in regards to the project status, new features, and roadmap. I plan to work with Dru over the next few days to get these details laid out on the web site so that we can get feedback from the community.

In the next few weeks, I hope to start detailing out some of the 2.0 features that are planned for MassTransit. There are several exciting features in the pipeline, including an entirely new set of edge components for interfacing with clients connected via Ajax/JSON, WCF, or regular web services. As I get my actors together, I hope to post some details, as well as complete my series on building a service gateway using the new edge components.

Getting Started

The first thing I did was slide the Windows 7 DVD into the drive and rebooted the machine. Once the setup window appeared, I pressed Shift+F1 to open a command prompt and created a new VHD by typing the commands shown below.

<br />
diskpart<br />
create vdisk file="d:vhdsw7base.vhd" type=expandable maximum=80000<br />
select vdisk file="d:vhdsw7base.vhd"<br />
attach vdisk<br />

Once this was finished, I switched back to the setup window and clicked Install Now. I chose the advanced install option, after which I selected my newly created partition as the installation target and formatted it so the installation could continue. While waiting for the setup process to complete (which included at least two reboots, both of which properly loaded into the VHD without any issues, so that’s cool), I started working on this blog post.

After the install completed, I wanted to make sure I didn’t get confused by the boot manager now having two “Windows 7″ options at started. So I quickly opened a command prompt (as Administrator), and typed:

<br />
bcdedit /set description "Windows 7 Baseline"<br />

This will change the name of the boot manager entry for the current machine to “Windows 7 Baseline,” distinguishing it from the normal Windows 7 install. Once I’ve completed all the setup tasks, I’ll set the regular Windows 7 option to be the default when I’m not working with the beta software installations.

Next I ran Windows Update, along with installing the Microsoft Security Essentials to have a basic level of virus/malware protection.

I almost always need a database server to do any sort of distributed application testing, so I wanted to have a SQL Server 2008 available. However, I didn’t want to have it setup on each virtual disk. So I installed it to the base installation, along with a few other tools that I use often (and are not really updated regularly). I also decided that since Visual Studio 2010 and Visual Studio 2008 run nicely side-by-side that I would go ahead and install Visual Studio 2008 on the base image since I’ll most likely be working primarily with 2008 through the next year.

When you boot from a VHD, your regular Windows system drive is available as drive D. This is really useful since you can keep a single checkout of all your projects and work on them from different systems! On my regular Windows 7 install, I created a “Shared” folder off the root (OMG not a Library?). Within that folder I have a Home folder which I use for SVN checkouts, and I also configured SQL Server to use a directory under Shared for all the data storage. This will be handy for ensuring that data in the database is updated regardless of which system is using SQL – very cool.

Making a Difference

With the above steps behind us, we now have a machine with two Windows 7 installations on it. The first, a regular disk-based install, is our primary installation that we use for whatever. The second, a VHD-based install, is our clean Windows 7 with our minimum set of software installed on it. It’s this clean version that we want to keep “pristine” to avoid having to redo all the steps above with each new release of Visual Studio 2010.

A quick note, the size of the VHD after all the software is installed is about 20 gigabytes, which is pretty substantial considering that we now don’t need to copy this space for each branch of the baseline we create — a nice savings!

To create the differential image, I restarted the machine and selected my regular disk-based Windows 7 install. Once it was loaded, I opened up a command prompt and created a new VHD based off the existing one I just finished creating.

<br />
diskpart<br />
create vdisk file="D:vhdsw7-2008.vhd" parent="D:vhdsw7base.vhd"<br />
create vdisk file="D:vhdsw7-2010.vhd" parent="D:vhdsw7base.vhd"<br />

Once the partition is created, create a boot entry for it using:

<br />
bcdedit /v <em>(this displays the GUID we'll use next for our copy)</em><br />
bcdedit /copy {3F2504E<strong>0</strong>-4F89-11D3-9A0C-0305E82C3301} /d "Windows 7 - 2008"<br />
bcdedit /v <em>(to get the GUID of our copy, which is also displayed after the copy command as well)</em><br />
bcdedit /set {3F2504E<strong>1</strong>-4F89-11D3-9A0C-0305E82C3301} device vhd="[C:]vhdsw7-2008.vhd"<br />
bcdedit /set {3F2504E<strong>1</strong>-4F89-11D3-9A0C-0305E82C3301} osdevice vhd="[C:]vhdsw7-2008.vhd"<br />
bcdedit /v <em>(to verify our work)</em><br />
bcdedit /set {3F2504E<strong>2</strong>-4F89-11D3-9A0C-0305E82C3301} device vhd="[C:]vhdsw7-2010.vhd"<br />
bcdedit /set {3F2504E<strong>2</strong>-4F89-11D3-9A0C-0305E82C3301} osdevice vhd="[C:]vhdsw7-2010.vhd"<br />
bcdedit /v <em>(again, to verify our work)</em><br />
bcdedit /displayorder {current} {3F2504E<strong>1</strong>-4F89-11D3-9A0C-0305E82C3301} {3F2504E<strong>2</strong>-4F89-11D3-9A0C-0305E82C3301}<br />

In this case, {3F2504E0-4F89-11D3-9A0C-0305E82C3301} is my original VHD-based install, {3F2504E1-4F89-11D3-9A0C-0305E82C3301} is my copy for Visual Studio 2008, and {3F2504E2-4F89-11D3-9A0C-0305E82C3301} is my copy for Visual Studio 2010.

I now have three boot options when the system starts, my disk-based Windows 7 install, and my two newly created “differential” installs — one for Visual Studio 2008 and one for Visual Studio 2010. Since both of these are based off the VHD we created above, we want to make sure we don’t accidentally boot into the w7base VHD and change it — that would be like crossing the streams in Ghostbusters (read: bad). The /displayorder command takes care of this by having a side effect of removing the Windows 7 Baseline option from the list of boot configurations.

One thing to keep in mind, and another benefit of having the physical disk drive available as drive D, is that I do all of my work on the D drive (in the Shared folder). Since this drive is persistent I can be sure that I don’t lose my files as I boot between different installations of Windows 7. It also makes it so I don’t have to checkout projects on each VHD, which would waste valuable space.

Cleaning Up

So now that we have a nice baseline and a couple of working boot options (both of which don’t impact each other as changes are made), we can install our latest BETA/CTP/whatever on our 2010 install. When an update is released (in the form of a subsequent CTP, beta, etc.), we can take a few simple steps to revert our 2010 to a clean install.

First, we need to boot into our disk-based installation of Windows 7. Once there, there are a couple of options available. We could create an entirely new configuration by repeating the steps above. This would be helpful if we were in the middle of something on a current version of 2010 and wanted to try it in the update to check for breaking changes. The more likely option, however, is to just replace the installation with a clean baseline to install fresh.

To install fresh, we can just delete the existing w7-2010.vhd and create it again using:

<br />
diskpart<br />
create vdisk file="D:vhdsv7-2010.vhd" parent="D:vhdsw7base.vhd"<br />

The boot configuration is still pointing to that file, so it will find it after a restart and you can install the latest update without fear of some bad configuration/files from a previous beta/CTP getting in the way.

Conclusion

The new boot to VHD features of Windows 7 (which also work just fine for Windows 2008 Server R2 by the way) are a really slick addition to the Windows platform. Being able to take advantage of the VHD features, differential disks in particular, really makes it a great host for the various incarnations of Visual Studio. I hope this guide has helped ease some of the CTP/BETA pain that comes with running on the bleeding edge.

In this post, I would like to share with you a few things that I have found that can make the difference between a good event and a great event, at least as far as your presentation is concerned.

Before You Leave (a.k.a. Pack Lightly, But Carry An Armored Tank Division)

If you pack a multiple outlet power strip, you will make friends. Power outlets are like gold at any technical event and people will covet them to charge up their power hungry devices. If you encounter a full tap and plan to stay for more than a few minutes, pull it out and share the juice with your five new friends. I have a very compact one that turns 2 outlets into 6, as well as a slightly larger unit that provides 3-to-1 expansion along with 2 USB ports for charging iPhone, iPod, or other USB-powered devices.

If you will be driving during any part of the trip, pack a car charger for your devices. Small and compact usually wins, so I prefer something that gives me at least two USB connections from the 12V plug. That is usually enough to charge my phone and headset, and can help charge a friends phone at the same time (since they likely forgot their charger unless you forwarded them a link to this article).

Don’t forget to bring plenty of cables. I always pack at least one 14-foot network cable, two USB-to-mini-USB cables, one USB-to-micro-USB cable, one firewire 800 cable, and a 800/400 adapter. The power supply for your laptop is pretty important too, so bring that long as well.

Bring an additional mobile phone battery or a battery powered top-up charger to get you through the trip. Nothing drains an iPhone like watching a movie during the flight, firing up the GPS to find your way to the hotel, checking your email and flight status, etc. I bought an inexpensive unit from Monoprice (less than $20) that connects to the bottom and tops off an iPhone that is under 20%. It has another dock connector on the bottom and charges from the same cable as the iPhone.

Scope out your network availability and plan accordingly. If you are traveling alone and cannot tether your phone to your laptop, make sure wireless networking is available. If it is not available, be sure to have all the software you need installed and make sure your demo doesn’t require an internet connection. If you are traveling with others and the hotel charges for internet, considering bringing along a wireless router (the Airport Express from Apple is small and easy to setup) to share the connection with your friends!

A quick note about travel gear – carry on only. Do not check a bag, it will only slow you down. If last minute flight changes are needed when travel issues occur, being quick and unencumbered by checked baggage will help you out. Also, the 22” roller bags will not fit in smaller aircraft, so get yourself a smaller 17” one that fits under the seat (and in the overhead on the smaller regional jets). You can easily make a two day trip with a smaller bag, particularly if you avoid different styles of clothes.

En Route (cue Vacation theme music)

First things first — if you don’t have an iPhone (or some other type of reliable smartphone), get one. I have found that having an always available internet connection, full web browser, instant email access, real-time flight tracking, and live Google maps with GPS to be the most important tools when traveling.

Now that you have your iPhone, some great apps that will really help your trip are listed below.

• AutoPilot from USA TODAY is a great, free application for managing your travel. It’s not the fastest or best, but it is free and includes TripIt integration for loading your flight information.
• Flight Update Pro is a air travel focused app that is highly accurate in keeping you up-to-date on flight status and arrival/departure times. While expensive ($9.99), it also includes TripIt integration (saving you data entry) and an easy to read status.
• The FlightCaster web is fairly accurate at predicting delays, and they also have an iPhone application. Again, integration with TripIt eliminates the duplicate entry of information.

By the way, if you aren’t using TripIt to consolidate all of your booking confirmations into a single site yet — do it. TripIt can parse the details from most booking confirmation emails and automatically updates your travel calendar (which you can subscribe to using iCal). I setup a filter in Gmail to forward my confirmation emails to plans@tripit.com, which parses the message and updates your travel calendar.

And hopefully this goes without saying, but when traveling — particularly by air — dress respectable, be courteous, and don’t lose your temper. Things happen during travel — delayed flights, road construction, missed exits, engine fires — most of these are out of your control. The last thing you want to do is be an ass to a person already under pressure. Being polite can mean the difference between getting the last seat on the last flight and sleeping on the airport floor. Oh, and when at all possible, use your phone since there are more agents at the call center who can help get you on the right flight then there are at the airport helping the people in line.

After Arriving (the night before)

Do not let any friends, co-workers, acquaintances, or otherwise get you drunk because presenting with a hangover is just not cool. And that’s all I’ve got to say about that.

Presenting (drum roll, please)

If you are presenting to a Microsoft-centric audience and you are using a Mac, make sure you have everything you need to peacefully coexist in a Windows world. You will get the inevitable comments about running a Mac, so the last thing you want is to fail due to hardware or software issue. To help you out, here are a few tips:

Almost every projector you come across will use an analog VGA (d-sub) connector, so be sure to keep a Mini DisplayPort to VGA (or DVI to VGA for older Macs) in your backpack. It doesn’t hurt to have a Mini DisplayPort to DVI as well in case you encounter a more modern project (although I’ve seen more HDMI than DVI projectors this past year — all of which also supported VGA). I also pack actual video cables as well in case you end up doing an ad-hoc session in your hotel room.

Many groups like to record or broadcast their sessions so that members unable to participate in person can view the presentation. To make things easy, be sure to have LiveMeeting already setup and tested on your machine. If you are on a Mac, this means converting your presentation from Keynote to either PowerPoint (using the free PowerPoint viewer if necessary) or Quicktime and presenting the slides from Windows. If you are not doing any Windows-based demos (like if you were giving an iPhone development talk), well, the remote folks are out of luck!

If your talk is less about code and more about practices or principles, use the presenter display from Keynote or Powerpoint on your laptop. This helps you keep track of time, review your slide notes, and preview the next slide (which helps you avoid talking ahead of your deck). On the other hand, with code focused sessions stick to a mirrored display in the native resolution of the projector.

When presenting code it is best to use a white background with black text. While the dark themes are great for large screen monitors, they look terrible on projectors with monospaced fonts. Many editors allow you to save and load settings, so build yourself a presentation mode settings file. With a set of high contrast colors (the default Visual Studio colors are a bit too hard to read at 25 feet) and a font size of 12-14 you’ll be all set to show your code to a large room. Font choice is another thing. While Consolas is my favorite, at larger font sizes it looks terrible – particularly in bold. Consider an alternate font for your presentation settings that looks good at a large font size.

When presenting with slides, a remote is a great way to get out from behind the podium. I like to present while standing in front of the screen, so I always pack my Apple remote. I tend to avoid the higher tech solutions such as the Keynote Remote app for the iPhone as they tend to just get in the way. If you need to use the remote to control PowerPoint, there are some utilities that will make that work as well.

Choose Your Own Adventure (n, n, open door, n, e, melt wizard)

Most of the time, your presentation is going to be perfect for the audience. Assuming that your session description was accurate and a level of learning was indicated you should be set. However, your audience might not be prepared for the material being covered. In these situations it is best to have an alternative path that your presentation can take, one that is more appropriate for a general audience. In some cases this might not be possible, but it can really make the difference between an engaged audience and a bunch of people cleaning out their inbox (because there is likely was too much caffeine in their blood to actually sleep).

Wrap It Up (I’ll take it)

I hope the tips I’ve shared with you here will be useful if you decide to step up to the podium. There are many other posts that talk about slide design, demo subject matter, travel tips, and more but the items above are some of the ones I’ve had to learn on my own (and thankfully not always the hard way — well except for one).

Did somebody say code?

The past two posts began to explain how to build a service gateway using MassTransit. In this post, I’m going to share some of the initial code that makes up the gateway service. The gateway itself consists of two components. The first implements the communication to the external service with a set of messages that are only used internally by the service. The second is the saga that provides the interface to the service gateway.

Service Contract

The interface exposed to the application consists of two messages, the first for the command and the second for the response. The message contracts are defined using interfaces, allowing the class for the message to be an internal implementation detail.

The message contract representing a request for order details includes the CustomerId and the OrderId.

public interface RetrieveOrderDetails
{
	string OrderId { get; }
	string CustomerId { get; }
}

When the order details are received, the following message is published.

public interface OrderDetailsReceived
{
	string OrderId { get; }
	string CustomerId { get; }
	DateTime Created { get; }
	OrderStatus Status { get; }
}

public enum OrderStatus
{
	Unknown = 0,
	Submitted = 1,
	Accepted = 2,
	InProcess = 3,
	Complete = 4,
}

The CustomerId and OrderId are the same as the values passed in the request. Created is when the order was created, and Status is an enum representing the status of the order. Notice that no internal values are included — no primary key from the order table and no primary key from the customer table. The request and response are correlated on identifiers that make sense in the application domain. While SQL purists will point out that numeric primary keys are quicker for retrieving rows in a database, they make for a very fragile interface with other components in the system. Reliance on a primary key outside of the context of the system storing the order details is a path to friction or outright failure.

Time To Make the Saga

At this point in the design of our service, the need for a saga to manage the request state is not entirely obvious. While the TDD purists might want to call YAGNI at this point, let me assure you that “it will all be… revealed!” So for now, let us take a look at the first pass of our saga definition.

public class OrderDetailsRequestSaga :
	SagaStateMachine<OrderDetailsRequestSaga>,
	ISaga
{
	static OrderDetailsRequestSaga()
	{
		Define(Saga);
	}

Our saga state machine uses a static initializer to define the states, events, and transitions of a saga. The previous code merely defines our class as a saga and calls our saga initialization method (shown below).

	private static void Saga()
	{
		Correlate(RequestReceived)
			.By((saga, message) => saga.CustomerId == message.CustomerId &&
			                       saga.OrderId == message.OrderId &&
			                       saga.CurrentState == WaitingForResponse);

		Correlate(ResponseReceived)
			.By((saga, message) => saga.CustomerId == message.CustomerId &&
			                       saga.OrderId == message.OrderId &&
			                       saga.CurrentState == WaitingForResponse);

Since our request criteria include our customer id and our order id, we use those to correlate the message to the saga. We also include the state of the saga to ensure that we do not match to a request that has already completed. We will look at some other ways we can enhance the performance of the service later on by using some additional states.

	public static State Initial { get; set; }
	public static State WaitingForResponse { get; set; }
	public static State Completed { get; set; }

The three states we have defined, including an initial state when a new saga instance is created, a waiting for response state one our request has been sent to the service, and a completed state once the response has been received and published.

	public static Event<RetrieveOrderDetails> RequestReceived { get; set; }
	public static Event<OrderDetailsResponse> ResponseReceived { get; set; }
	public static Event<OrderDetailsRequestFailed> RequestFailed { get; set; }

The three events that we have defined, including the message contract that maps to the event. The subscription logic for the saga will automatically map message handlers for these events that will invoke the actions depending upon the current state of the saga.

		Initially(
			When(RequestReceived)
				.Then((saga, request) =>
					{
						saga.OrderId = request.OrderId;
						saga.CustomerId = request.CustomerId;
					})
				.Publish((saga, request) => new SendOrderDetailsRequest
					{
						RequestId = saga.CorrelationId,
						CustomerId = saga.CustomerId,
						OrderId = saga.OrderId,
					})
				.TransitionTo(WaitingForResponse));

The first event handler, RequestReceived, is invoked when the saga is created in response to the RetrieveOrderDetails message. The handler copies the properties of the request, and then publishes the request message to the proxy that will call the external web service. After the message is published, the state of the saga transitions to the waiting for response state. When using transactional queues, the receipt of the message, creation of the saga in the database, sending of the command message to the proxy, and saving the saga are all part of a single distributed transaction. This ensures that everything completes as a single operation to ensure no requests are lost.

		During(WaitingForResponse,
			When(ResponseReceived)
				.Then((saga, response) =>
					{
						saga.OrderCreated = response.Created;
						saga.OrderStatus = response.Status;
					})
				.Publish((saga, request) => new OrderDetails
					{
						CustomerId = saga.CustomerId,
						OrderId = saga.OrderId,
						Created = saga.OrderCreated.Value,
						Status = saga.OrderStatus,
					})
				.TransitionTo(Completed));
	}

The second event handler, ResponseReceived, is invoked when the OrderDetailsResponse message is received. The results of the request are stored in the saga and a message is published containing the details of the order back to the original requestor. Another approach would be to capture the requestor address (via the ResponseAddress header from the message) and then resolve that address using the endpoint factory to send the response directly to the requestor. I don’t really encourage this approach without having a truly unique identifier for each request.

	public OrderDetailsRequestSaga(Guid correlationId)
	{
		CorrelationId = correlationId;
	}

	protected OrderDetailsRequestSaga()
	{
	}

	public virtual string CustomerId { get; set; }
	public virtual string OrderId { get; set; }
	public virtual OrderStatus OrderStatus { get; set; }
	public virtual DateTime? OrderCreated { get; set; }

	public virtual Guid CorrelationId { get; set; }
	public virtual IServiceBus Bus { get; set; }
}

The rest of the saga class is shown above for completeness. The properties are part of the saga and get saved when the saga is persisted (using the NHibernate saga persister, or in the case of the sample the in-memory implementation). The constructor with the Guid is used to initialize the saga when a new one is created, the protected one is there for NHibernate to be able to persist the saga.

The Service Proxy

The saga uses the external service proxy to perform the actual work, which is shown in the proxy class below.

public class OrderDetailsWebServiceProxy :
	Consumes<SendOrderDetailsRequest>.All
{
	public void Consume(SendOrderDetailsRequest request)
	{
		// make the call to the service to get the order details here

		var details = new OrderDetailsResponse
			{
				OrderId = request.OrderId,
				CustomerId = request.CustomerId,
				Created = (-1).Days().FromUtcNow(),
				Status = OrderStatus.InProcess,
			};

		CurrentMessage.Respond(details, x => x.ExpiresAt(5.Minutes().FromNow()));
	}
}

The message handler uses the criteria from the SendOrderDetailsRequest message (which was published by the saga) to call the external service and retrieve the order details. The details are then returned to the saga in the form of an OrderDetailsResponse message which is internal to the service (and therefore not part of the interface assembly that is provided to applications that want to use the order details service).

Test That Thang

Now that our saga has been developed, we need to be able to test it. A unit test will be created that creates a testing instance of the service bus (see the sample for the implementation details) and verifies that the saga responds properly to the request. To request order details, a very simple client would subscribe to the response message and then publish the request.

const string orderId = "ABC123";
const string customerId = "12345";

LocalBus.Subscribe< OrderDetailsReceived >(message =>
	{
		response.Set(message);
	},
	x => x.OrderId == orderId && x.CustomerId == customerId);

RetrieveOrderDetails request = new RetrieveOrderDetailsRequest(customerId, orderId);
LocalBus.Publish(request, x => x.SendResponseTo(LocalBus.Endpoint));

The subscribe method used above specifies that when a message of type OrderDetailsReceived is received, if the contents of the message match the predicate specified (which in this case, is checking the OrderId and CustomerId contained in the message) then the statement specified should be called. Our example is from the integration test (built using NUnit) that verifies the service performs from end-to-end.

The syntax above is functional, and it will work, but it does not represent the most scalable approach. In the next post, I’ll start to explain how to build a much more scalable method of handling thousands of concurrent requests on a single machine using IIS.

In the meantime, the sample code is available in the MassTransit trunk as a standalone solution. You can find it in the trunksrcSamplesServiceGatewaySample folder. There are unit tests that verify the calling syntax shown above and a service that hosts the services (both the saga, and the proxy service).