Enterprise Service Bus using MSMQ in .NET

Over the past couple of weeks, I have been working on nailing down some design for a service bus to add real-time capability to one of our applications. This has led to spending some time looking at nServiceBus as well as a few other examples. I’ve also been reading Enterprise Integration Patterns (Hohpe/Woolf) to understand some of the established patterns in the space.

It’s interesting to see the different approaches people take to things like transactions and message recovery. From my experience with health care transactions, there is no way to have a distributed transaction across the myriad of systems involved in a health care exchange. With no clear standards and hardly any real-time communication with insurance companies, auditing and electronic reconciliation are the only plausible methods of determining the state of each transaction.

The discussion is lively at the nServiceBus Yahoo Group, so if you have an interest in that style of integration, stop in and join the conversation.

Dru Sellers and I have started working on a simplified version of a service bus called MassTransit. It’s an open-source project, Apache 2.0 License, and could use some comments and/or contributions. We’re going at it with the simplified YAGNI approach to meet some specific needs for work-related projects. We’re also focusing on an easy to configure, easy to code approach to reduce the difficulty of building systems using message-based communication.

It’s an ongoing project to find the right solution for a real business problem, so we’ll see how it goes!

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.
This entry was posted in .net. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Forgive me for my ignorance but can you give me a buisness case on when this should be used? What does this solve that WCF can’t? This is an honest question not sarcasm. :-)

  • Dru

    Hi Joe!

    The big thing, to me, that WCF doesn’t handle is the subscription concept. With WCF you have to say who you want to send it to, but with the bus you just publish the event.

    WCF is also by default in preference of shared contract instead of shared type. This means that I can’t pass an interface around, which stinks. One of the big things that I have learned for Udi about SOA is that as far as the bus is concerned its all about the message not the data (Hence the IMessage concept). The app, not the bus, cares about the data. Its like TCP/IP in that way(1).

    Plus, I see WCF as more of a transport mechanism than a service bus. You can look at NServiceBus as another project that is taking the same approach.

    Lastly, its yet one more abstraction, that in our case wasn’t needed.

    Also take a look at the NSB mailing list

    Some good reads:
    1. http://wisdomofganesh.blogspot.com/2007/12/paying-restafarians-back-in-their-own.html

  • Keith Smith

    Hi Joe,

    While searching for guidance on implementing an Enterprise Service Bus in .NET, I stumbled onto your website. Is there any topic that you guys miss? Guess not!

    Anyway, I’ve become interested in ESB because it is useful in implementing an SOA architecture. Over the past year I’ve created multiple services which are hosted as windows services communicating with clients using .NET Remoting. I also had to create service installers to install these services. This seems very inefficient. Why not just have a single service host that I can publish services to and that clients can subscribe to? Isn’t this what Java Application Servers do? Why not have a centralized service host in .NET?

    Also, if I am going to invest time creating a service host (or rather a service hosting framework that will survive platform and techology changes), why not use a framework like WCF that provides a standards based solution which enables integration across open standards so that clients written in other programming languages can consume the service I create? Further, why not decouple my .NET clients from the services using a messaging architecture that supports a publish-subscribe model which an ESB would provides?

    WCF does require direct communication between the client and the service which is a form of coupling. The ESB breaks this coupling, or rather, replaces it with a different one that couples all clients to the ESB which then dispatches the messages sent by clients to the appropriate service. The model becomes a bus architecture instead of a peer-to-peer architecture.

    Is all of this necessary? In my opinion, if your goal is simply to centeralize your services to ease maintenance and deployment then this can be done using WCF without using an ESB. Using an ESB makes your architecture more complex and forces you to confront issues that BizTalk (Microsoft’s ESB) developers have to deal with. However, if you have many departments each publishing services which work together like a federation of services, then decoupling these services from each other using an ESB could be worth doing. However, this would make it necessary to add other services such as a Service Discovery service to your architecture, further complicating matters. For example, when implementing a messaging system at Countrywide we had to develop many infrastructure services for message tracking, message correlation (matching sent and recieved messages), service registration and discovery, message logging, etc… Implementing these services and there associated UI’s was a very complex undertaking.

    I guess, my opinion on using an ESB are mixed since it introduces unncessary complexity for most projects but has some nice advantages for an environment sprawling with many service publishers and just as many, if not more, consumers.

    Alright, what am I doing? I guess I just became a blogger.

    M2 Technology
    Keith Smith

  • Anonymous

    MSMQ provides a abundant framework for applications that use messaging infrastructure. Also, MSMQ facilitates sending and accepting assorted letters in a transaction through the MessageQueueTransaction class.

    toshiba coupon codes