MassTransit Update

It’s been a while since I’ve posted about MassTransit, the .NET distributed application framework and service bus that Dru Sellers, myself, and several other contributors have been working on for the past 2.5 years. This is mostly due to a pretty heavy schedule in the first quarter (CodeMash, the MVP Summit, Pablo’s Fiesta, the North Dallas .NET User Group, and having an in-ground swimming pool built), along with a lot of exploratory coding on some new features for the framework.

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.

About Chris Patterson

Chris is a senior architect for RelayHealth, the connectivity business of the nation's leading healthcare services company. There he is responsible for the architecture and development of applications and services that accelerate care delivery by connecting patients, providers, pharmacies, and financial institutions. Previously, he led the development of a new content delivery platform for TV Guide, enabling the launch of a new entertainment network seen on thousands of cable television systems. In his spare time, Chris is an active open-source developer and a primary contributor to MassTransit, a distributed application framework for .NET. In 2009, he was awarded the Most Valuable Professional award by Microsoft for his technical community contributions.

Will there be support for custom transport soon. It’s amazing how all the OSS .net service buses (MT, NServiceBus, RhinoBus) are written around MSMQ. I for one would like to store my messages in a PORT (plain old relational table).

MassTransit endpoints have always been pluggable via the IEndpoint/ITransport interfaces. If you wanted to build an endpoint that stored messages in a database, that’s certainly possible. Out of the box, we support MSMQ, ActiveMQ, TIBCO, and (experimental) RabbitMQ.

Sam De La Garza

That’s fantastic! I’m glad to see the effort for supporting new development with heftier documentation is gaining momentum. I’ve always been impressed with the documentation surrounding the RoR community which sadly is lacking in the .net OSS community atm.

Keep up the great work.

Sam De La Garza

oh, wow, just saw the new webiste, very nice!

Sea Gough

Nice site! One thing though, there’s a typo in the navigation. I think you meant “development”.