Andreas Ohlund’s talk on New and Shiny things in NServiceBus 3.0 is available here.

By the way, we’ve now got a beta out of NServiceBus 3.0 – get it here.

Yves Goeleven will be giving a talk on simplifying distributed application development with NServiceBus and the Windows Azure Platform on Jan 31 – details here.

Carl and Richard over at Dot Net Rocks interviewed me at the Oredev conference in Sweden about Domain Driven Design and one of my pet peeves – the use of Customer in example applications. Get it here.

I’m also happy to announce that registration for my 5-day Advanced Distributed Systems Design course has now opened for Bad Ems Germany and New York, in addition to the already open registrations for Austin TX and London. Information and registration on my training page.

I’ve also made some progress with the recording of the course – you can now access days 1, 2, and part of day 3 – covering distributed systems theory, coupling, messaging patterns, bus and broker architectural style, SOA building blocks, and the hotel management SOA exercise. Information and purchase available here.

For more information, take a look at this video.

You can get this tool on our download page and also via the Visual Studio Gallery here.

You see, the majority of our focus since releasing version 2.5 at the end of last year was to building our amazing new version 3.0 with all of its slick new coolness. But then we started getting requests from companies here and there using 2.5 to improve this small piece, that small piece, etc.

For a while, we thought we’d get version 3.0 out the door fast enough to address it all in one fell swoop. It turns out we couldn’t – version 3.0 had too many big changes in it that would take too long to stabilize. And thus, version 2.6 was born.

Get it here.

Customer Testimonial

I’m also thrilled to announce that we got permission to go public about ****** one of the world’s largest investment banks using NServiceBus (publication pending final corporate approval). They were kind enough to provide us with this testimonial:

NServiceBus is an exceptional framework for rapidly building enterprise applications. Not only was it easy to use out of the box, but the documentation was great and the large user community was very responsive. We were up and running with a prototype in a week.

We turned to NServiceBus for its performance and scalability for our new Structured Notes publishing systems. The reliability it provided us in integrating with other systems like Exchanges, IPA and code providers, as well as our internal systems allowed our developers to deliver on our core business objectives very quickly.

Like most large enterprises, we need full control of all of the internal behaviors of our infrastructure. We found the multiple layers of extensibility in NServiceBus gave us the control and flexibility we needed without sacrificing stability.

A truly exceptional framework.

– Manoj Oswal, VP – Structured Notes, Tier 1 Investment Bank

And in other news…

We’re hiring!

Business is booming and we’re looking to grow, currently focusing on the business side of the company. This includes project managers, practice managers, and program managers as well as sales and marketing people.

I’m also looking for a Chief Operating Officer who will be responsible for this group.

If you’re interested – please let us know: recruiting@nservicebus.com

Our HR story isn’t yet very well developed so please bear with us as we ramp up.

What’s RavenDB?

For those of you who haven’t heard about RavenDB yet – it’s a transactional document database for .NET, and it’s been/being developed by my good friend and partner in crime Ayende Rahien (a.k.a Oren Eini). Although Ayende is known for his “not invented here” tendencies, when it comes to transactional document databases, well, you’d have been hard pressed to find one – especially with a decent .NET API.

NServiceBus Storage

In NServiceBus we have a variety of storage needs – from things like durable subscriptions so that you get fault-tolerant pub/sub, through persistence of long-running workflow (a.k.a saga) state, and durable timeouts so that your time-bound long-running processes never get stuck. None of these actually require relations – we were just using relational databases for storage because it was the easy answer everyone was going with.

Relational vs. Document

And these relational databases came with some downsides – developers had to “beg” their DBA to create the needed tables in the production databases, when that central database was down it prevented otherwise autonomous publishers and subscribers from going about their business, and it was very difficult to version the long-running workflows especially when newer versions required different state.

By moving to an embedded and transactional document DB, no longer do you need to bargain with the DBA, by keeping the storage together with the processing nodes you are back in parallel processing bliss, and the schema-less nature of the storage makes versioning those long-running workflows much easier.

Licensing

And I’m also happy to announce that an agreement has been reached with Hibernating Rhinos (Ayende’s company) so you won’t need to license RavenDB separately to get all of these benefits. RavenDB will be bundled with NServiceBus so licensing NServiceBus covers them both (for the storage needs mentioned above).

If you’re also thinking about using RavenDB as the storage for the rest of your system, you’ll be able to get a nice discount on the license when purchasing it together with NServiceBus. This will be going into effect with the release of NServiceBus 3.0 this October.

Companies Using NServiceBus

Interestingly enough, there’s been a big uptick in companies using NServiceBus with the introduction of licensing. Most of these companies are not the kind of big, stand-up-and-take-notice names that everybody likes to have on their roster.

What makes NServiceBus particularly attractive is that you can get a lot done without requiring some kind of dedicated BizTalk/WebSphere/Tibco expert. This has brought down the barrier for thousands of developers who just want to get on with the business of getting their app to market.

And when it comes to the big names, well, once they see how much faster they can get stuff done with NServiceBus as well as how robust and scalable it is in production, they don’t want any of their competitors to know about it!

Anyway, I’m glad to say that two companies have stepped forwards: Rackspace and Reuters. Hopefully we’ll get confirmation from one of the big banks soon that we can go public with them too.

Exciting times ahead.

NServiceBus on DNR-TV

For some more advanced stuff, I suggest looking at the Hidden NServiceBus Gems talk that I gave at Skills Matter the week after. Here we get into all sorts of things that you won’t tend to find by yourself through regular usage of NServiceBus.

Hidden NServiceBus Gems

Enjoy.

The ugly truth

You don’t need an ESB for integration.

There. I’ve said it.

Most of the ESB products on the market, in focusing on integration, are addressing the wrong problem.

What integration is about

There are three primary components to integration – data format translation, protocol bridging, and logic. Let’s take the Agile “simplest solution that could possibly work” motto and apply it to these elements:

1. Data format translation
   
   • Use something like MapForce (from Altova, the guys behind XMLSpy).
   • At under $1200 for a dev license and handling mapping to/from XML, EDI, flat files, and relational databases, you can host the resulting mapping in any endpoint, as XSLT or even Java/C# – no need to have “the bus” do this for you.
2. Protocol bridging
   
   • Use something like /n software
   • At about $1500 for a dev license, you get solutions for FTP, HTTP, SMTP, POP, IMAP, LDAP, DNS, RSS, SMS, Jabber, SOAP, WebDav, etc and, again – you can host the DLLs in any endpoint you want. Don’t need expensive buses for this
3. Logic
   
   This is all you – no technology can do this for you. If anything, the most important thing is to get all the ugly mapping and protocol bridging stuff out of the way and let you focus on your logic. This is Single Responsibility Principle (un)common sense.

Digging deeper into the logic

The interesting thing about most of the protocol stuff mentioned above is that they’re inherently unreliable and also their performance at runtime is unknowable due to the total load on the target server.

We wouldn’t want any of the above situations to cause our integration to “get stuck”. As such, it is best we think of our integration logic as a long-running process that manages other endpoints which do the actual protocol bridging and data transformations.

This is one of the areas where NServiceBus, with its sagas can actually help a lot. Just like the other pieces of integration mentioned above, these sagas can run on any endpoint.

You could alternatively look at other technologies like BizTalk and Business Process Execution Language (BPEL) engines, though many of those are designed to be physically centralized (just like many of the ESBs out there).

By the way, if you do want to use NServiceBus together with BizTalk, Michael Stephenson has published some great white papers on getting the two to work together. His latest is about integrating NServiceBus into BizTalk’s RFID processes – check it out.

Putting it all together

When we take all of these pieces and look at them in a cohesive architecture, here’s what it can look like:

As you can see, integration is physically distributed across multiple endpoints.

Not only that, but the integration logic is kept separate from the protocol bridging and data transformation, enabling independent versioning of each. Just as important, it makes it much easier to unit test that the integration logic is correct as we don’t have to simulate the target technologies.

Costs

As you can see, you can get integration capabilities just as powerful as if you went with something like BizTalk, but without creating a single point of failure in your architecture. In terms of costs, it’s also quite a bit cheaper.

For a high availability BizTalk deployment, you’ll be paying over $40,000 per CPU for the Enterprise Edition, not including the extra $7000 per CPU for SQL Server Standard Edition (clustered). For a clustered 4-CPU mid-size deployment, you’d be in the area of $200,000.

For the distributed integration solution above, you’d be paying around $2700 in dev licenses (for /n software and Altova MapForce), and $500 per core for NServiceBus Standard Edition. The reason there’s per-core licensing for NServiceBus is that in a virtualized environment, you’ll be provisioning virtual cores to your virtual machines. No reason to pay for a quad-core CPU when all you’re using is a single core. You can also use any number of cores running NServiceBus Express Edition at no cost, so a mid-size deployment with say 8 cores running Standard Edition, and another 24 cores running Express Edition would cost (with the volume discount) an additional $3800 – a total cost of $6,500.

BizTalk: $200,000       NServiceBus: $6,500

‘Nuff said.

In closing

We’ve been bitten by centralized architectures before.

By having our integration distributed, we can version, upgrade, and scale each piece independently.

You’ve seen how we can use simple, lightweight, and inexpensive technologies to create distributed integration solutions just as powerful and robust as the centralized ESB vendor-offerings out there, but at a tiny fraction of the cost.

Next time the topic of integration is brought up, you’ll know not to be suckered in by re-branded EAI brokers.

Learn more about NServiceBus.

Brokers

Message brokers, more broadly known and used on the Java platform, don’t come with this constraint. For example, when using ActiveMQ, you can have any number of endpoints come to the broker and publish a message under a given topic.

So where’s the problem?

It’s all about accountability.

Let’s say you’ve subscribed to a given topic, and have received two events – one telling you that the price of bananas next week will be $1/kg and another telling you that it’ll be $2/kg.

Which one is right?

Especially given that those events may have been published by any other endpoint via the broker.

Is it first one wins? Last one wins? How about first one sent vs. first one received? Ditto for last. As a subscriber, can you really be held accountable for having the logic to choose the right one? Shouldn’t this responsibility have fallen to the publishing side?

This is one of the big drawbacks of the broker, hub and spoke architecture. No responsibility. No single source of truth – unless everybody’s going to some central database, in which case – what’s the point of all this messaging anyway?

Buses

The Bus Architectural Style is all about accountability. If you are going to publish an event, you are accountable for the correctness of the data in that event – there is no central database that a subscriber can go to “just in case”. And the only way that you can be held accountable, is if you have full responsibility – ergo, you’re the only one who can publish that type of event.

If you say bananas are going to cost $1/kg next week, that’s that. Subscribers will not hear from anybody else on that topic.

Now, this is not to say that you can’t have more than one physical publishing endpoint.

You see, buses differentiate between the logical and the physical. Brokers tend to assume that the physical hub-and-spoke topology is also the logical.

In a bus, while there can only be one logical endpoint publishing a given type of event, that endpoint can be physically scaled out across multiple machines. It is the responsibility of the bus to provide infrastructure facilities to allow for that to happen in such a way that to subscribers, it still appears as if there is really only one publishing endpoint.

The same is true about the subscriber – one logical subscribing endpoint may be scaled out across multiple machines.

Product Mix-ups

Unfortunately, there are many broker-style technologies out there that are being marketed under the banner of the Enterprise Service Bus. While some products have the ability to be deployed in both a centralized and distributed fashion (sometimes called “federated” or “embedded” mode), many do not enforce the “single publishing endpoint per event-type” rule.

Without this constraint, it is just too easy to make mistakes.

NServiceBus

By enforcing this constraint, we see the same kind of question appear on the discussion group time and time again:

“I have an Audit event that I’d like all of my machines to publish, and have one machine subscribe to them all, but NServiceBus won’t let me. How do I make NServiceBus support this scenario?”

And the answer is the same every time:

“You should have all the machines Send the Audit message (configured to go to the single machine handling that message), and not Publish. It is not an event until its been handled by the endpoint responsible for it.”

The semantics of the message matter a lot.

When looking at Service-Oriented Architecture, these messages are the contract and, as any lawyer will tell you, contracts need to be explicit and the intentions really need to be spelled out – otherwise the contract is practically worthless.

In closing

Friction is sometimes a good thing – it prevents us from making mistakes. It keeps cars on the road. And because that’s not enough friction, we introduce curbs as well.

If you’re looking for a service bus technology for your next project, check that it’ll give you the friction that you need to keep everybody safe. Really check what it is that the vendors are offering you – more often than not, it’s some ESB lipstick on a broker pig.

To learn more about how NServiceBus supports this kind of publish/subscribe, click here.

Content-Based Routing and ESBs

Since content-based routing often appears on feature lists for various ESBs, many people consider them to be a necessary part of systems built on SOA principles. The pattern also appears in the book Enterprise Integration Patterns, which apparently is also a convincing reason to use it, even though the book specifically states:

“When implementing a Content-Based Router, special caution should be taken to make the routing function easy to maintain as the router can become a point of frequent maintenance.”

That’s right – maintenance nightmare.

For Example

Let’s take a real-world example – a trading system where users can put orders for stock and for forex (money from other countries).

We’d start by creating a message that can be sent by a client:

public class PlaceOrder : IMessage
{
    public OrderTypeEnum OrderType { get; set; }
    public string Code { get; set; }
    public double Amount { get; set; }
}

public enum OrderTypeEnum
{
    Stock,
    Forex
}

Clients would send messages by using code like the following:

Bus.Send<PlaceOrder>(m => {
    m.OrderType = OrderTypeEnum.Stock;
    m.Code = "MSFT";
    m.Amount = 300;
    m.SetHeader("AccountId", myAccountId);
});

The header is the way that clients identify themselves in the system.

Let’s say that the logic for handling the different types of orders is different, but also that we’d like the logic to be deployed to different endpoints. One reason we might want to do this is so that we can independently scale each of these endpoints. This is where it would appear we’d need some content-based routing – having some code that looks at the OrderType property and decides where to route based on its value.

Before we get into solutions, let’s make this more involved.

Not only do we want to route based on OrderType, but we want to use the account ID in the header to check in our database (or via a web service) if the account belongs to one of our VIP customers, and if so, it should be given higher priority.

Content-Based Routing and Brokers

We can see that if we were to go with a content-based routing solution, this would drive our architecture to a hub-and-spoke model where the hub becomes quite large and complex, as well as likely becoming a bottleneck in terms of performance.

This logically centralized place through which all communication flows defines the Broker architectural style – not that of a Bus. In the Bus architectural style, there is no logical (or physical) hub. You can think of it as a kind of peer-to-peer setup. Just like you wouldn’t want ethernet getting involved in applicative routing decisions, neither should your bus get involved.

Business-Topology Mapping Solutions

Instead, when following the Bus architectural style – we look at mapping stable business characteristics to bus-level topology. At one level, that would mean defining two different message types for our different types of trades:

public abstract class PlaceOrder
{
    public string Code { get; set; }
    public double Amount { get; set; }
}

public class PlaceStockOrder : PlaceOrder { }

public class PlaceForexOrder : PlaceOrder { }

Once we have two different message types, then we can configure the client to have those statically sent to different endpoints like this:

<UnicastBusConfig>
  <MessageEndpointMappings>
    <add Messages="Messages.PlaceStockOrder, Messages" Endpoint="Stock" />
    <add Messages="Messages.PlaceForexOrder, Messages" Endpoint="Forex" />
  </MessageEndpointMappings>
</UnicastBusConfig>

And when it comes to handling our VIP customers, the recommendation would be to have those customers be served by a different set of web servers – we wouldn’t want a sudden flux in regular customers stealing all the HTTP connections from our VIP customers. Then we’d statically configure our VIP front-end to talk to our VIP back-end like this:

<UnicastBusConfig>
  <MessageEndpointMappings>
    <add Messages="Messages.PlaceStockOrder, Messages" Endpoint="VIP_Stock" />
    <add Messages="Messages.PlaceForexOrder, Messages" Endpoint="VIP_Forex" />
  </MessageEndpointMappings>
</UnicastBusConfig>

And the logic to identify VIP customers would be done in the login screen which, from there, would direct the user to the appropriate web server farm.

Static vs. Dynamic

It may appear that the above statically configured solution is less flexible then the afore-mentioned hub-and-spoke content-based routing solution. And that’s probably correct. But the question is, are the business requirements (better called “objectives” in this case) likely to change? If we make the technological solution 10x more flexible than the business needs, but at the cost of maintainability (read time to market), we probably haven’t used the right tool for the job.

Many times we can find stable business objectives and align the topology of our solution with them. Not all that is dynamic and flexible is necessarily better than that which is static.

I’d go so far to say that if a solution makes heavy use of content-based routing, it is likely a more fragile solution as implementations of stable business objectives and volatile requirements are mixed up together.

In Closing

NServiceBus intentionally does not support content-based routing so as not to make it easy for developers to make architectural blunders that could require full-system rewrites a couple of years down the road.

If you want to learn more about these kinds of architectural principles, I suggest coming to my course. I’m afraid that New York City is already sold out, but I’ll be coming back to the US again around October. Stockholm, London, Sydney, and Oslo are now all open for registration.

Hope to see you there.

This will actually be part 2 of his previous presentation – you can find the recording of part 1 here.

This time Andreas will be showing publish/subscribe communication as well as the use of sagas – get the full details here.

Messaging Basics

First of all, when building a system using messaging, you don’t have methods that are invoked on some remote object (a.k.a “service”) to which you pass parameters. Instead, you use some generic piece of infrastructure (in the world of Java, this is most commonly a Message Broker) to send a message where a message can be thought of as a serializable class. Here’s an example of a message:

public class UserCreated : IMessage
{
    public Guid UserId { get; set; }
    public string Name { get; set; }
}

This message would be published using NServiceBus like this:

bus.Publish<UserCreated>( m =>
{
    m.UserId = Guid.NewGuid();
    m.Name = "John Smith";
});

This can be contrasted with RPC models like WCF where you need to define a “service” that has methods on it, where those methods accepts parameters. Sometimes developers try to make this more generic by having a single “service” with one method on it named something like “Process” where the parameter it accepts is of the type “object”, or they introduce generics like this: Process<T>(T message);

This is where Polymorphic Message Dispatch comes in:

Polymorphic Message Dispatch

While you can pull of the WCF generics thing, one thing that is more difficult (without writing your own dispatch model) is to have a pipeline of classes which can be invoked based on their relationship to the type passed in. Using NServiceBus, both of the following message handlers will be invoked when UserCreated arrives:

public class Persistence : IHandleMessages<UserCreated>
{
    public void Handle(UserCreated message) { }
}

public class Audit : IHandleMessages<IMessage>
{
    public void Handle(IMessage message) { }
}

Now some might say that WCF, BizTalk, and the .NET Service Bus allow you to do auditing in their own internal pipeline, and that’s true. The place where this becomes more powerful is when you need to build V2 of your system, and the publisher now publishes a slightly different event – that a user was created as a part of a campaign, requiring the subscriber to register statistics about the campaign. Of course, this event also means that a user was created. Here’s how you’d do that with NServiceBus:

public class UserCreatedFromCampaign : UserCreated
{
    public Guid CampaignId { get; set; }
}

//publisher code
bus.Publish<UserCreatedFromCampaign>( m =>
{
    m.UserId = Guid.NewGuid();
    m.Name = "John Smith";
    m.CampaignId = theCampaignId;
}

//subscriber code
public class Statistics : IHandleMessages<UserCreatedFromCampaign>
{
    public void Handle(UserCreatedFromCampaign message) { }
}

The important part is what you don’t see – since UserCreatedFromCampaign inherits from UserCrated, the Persistence handler we had from V1 will also be invoked, and so will the Audit handler of course. You don’t have to make your new code call the old code like you would in a method based dispatch model. This makes sure that the coupling in your service layer code remains constant over time as you grow the functionality of your system.

This was one of the main benefits mentioned by Rackspace in their use of NServiceBus (here):

“The main benefit NServiceBus has brought us so far is developer scalability due to lower coupling and higher consistency in our code.”

But, when looking at the above scenario, we can obviously expect that all sorts of things can happen in relation to campaigns – it is a separate concern, and thus should be handled by a separate subscriber. And this bring us to…

Polymorphic Message Routing

The challenge that we have here is that we no longer have a hierarchy where something clearly belongs on top of something else. We have users created and activities happening related to campaigns – that may happen in any combination. By having separate subscribers, we could then introduce new handlers/subscribers to our environment without touching or taking down any of the other subscribers. Here’s what the subscribers would look like:

public class Persistence : IHandleMessages<UserCreated>
{
    public void Handle(UserCreated message) { }
}

public class Statistics : IHandleMessages<CampaignActivityOccurred>
{
    public void Handle(CampaignActivityOccurred message) { }
}

But if each of the above messages were a class, how could we define a message which inherited from both?

Before answering that, we need to understand why the publisher wouldn’t just publish both of the above messages. You see, the publisher can’t make any assumptions about its subscribers – it could be that one of them has logic that correlates across both of these messages that could end up counting the occurrence as happening twice rather than once, possibly charging the account associated with the campaign twice. Publishing two messages results in two transactions when there really should have been one.

So, here’s how to define messages so that we can have multiple inheritance:

public interface UserCreated : IMessage
{
    Guid UserId { get; set; }
    string Name { get; set; }
}

public interface CampaignActivityOccurred : IMessage
{
    Guid CampaignId { get; set; }
    Guid ActivityId { get; set; }
}

public interface UserCreatedFromCampaign
                 : UserCreated,
                   CampaignActivityOccurred
{
}

And when the publisher publishes UserCreatedFromCampaign, the event would be routed to both the UserCreated subscriber and the CampaignActivityOccurred subscriber. The power of this approach is felt as we handle new requirements around purchases made related to a campaign. Now we can have another event which inherits from CampaignActivityOccurred and not have to worry since the existing subscriber will be routed those messages automatically.

Since WCF doesn’t have publish/subscribe capabilities, we might as well move along.

Not to throw a burning match on an ocean of oil, but REST doesn’t really support this either.

Not Content-Based Routing

This may sound like the content-based router pattern from EIP (CBR), but it’s not. The important difference is that there isn’t some part of the routing that depends on the structure of the messages. The major drawback of CBR is that it creates a central place in your system that needs to be changed any time *syntactic* changes happen to message structure *in addition to* to changes in the subscribers.

Now, this is where the BizTalk guys would say that “that’s why we can do message transformations”, and then the subscribers wouldn’t need to be changed. However, can we really know when getting a requirement that the change is syntactic and not semantic? I mean, it’s quite common that changes to message structures happen together with changes to processing logic.

You may be beginning to get the feeling that more and more logic is being sucked out of the subscribers into some monolithic black hole that is likely going to be unmaintainable and quite slow.

This is one of the main differences between using a bus and a broker – a bus supports the correct distribution of logic keeping the system loosely coupled; brokers are useful integration engines when you absolutely can’t change the applications being integrated. Enterprise Application Integration (EAI) brokers don’t usually make good Enterprise Service Bus (ESB) technology.

In Closing

NServiceBus has all sorts of features you didn’t know you needed until you saw what life could be like when you had them. Most of these features don’t have snazzy drag-and-drop demos that make people ooh-and-aah and TechEds and PDCs, but they’re really necessary to avoid finding yourself in yet another big-ball-of-mud code base telling your manager/customer (again) that it would be faster to rebuild the system from scratch than to implement that new requirement in the old one.

Take NServiceBus for a spin and see for yourself.

Yes, there’s a new logo, and the website’s been redesigned.
It’s been a long time coming – the previous version (2.0) was released in March.

I’m really quite excited about this version as it rolls up all the bug fixes and enhancements that customers have asked for as they ran version 2.0 under the most severe types of production environments. The next thing that is a big deal that many have been asking for is a licensed version of NServiceBus – that is, the ability to purchase a commercial license and receive support.

We all know how managers like having a throat to choke.

And now they’ll have one – NServiceBus Ltd is the company that will be providing licensing, services, and support for all customers’ NServiceBus needs. After more than 33,000 downloads and over 1000 developers in the community, the demand has really grown. Who would’ve thought all this would happen when I started NServiceBus 4 years ago (before it even had a name).

Why NServiceBus is better than WCF for your distributed systems

This question comes up repeatedly for people hearing about NServiceBus for the first time.

The answer is simple – reliability.

A system built with NServiceBus is so much more reliable to all kinds of production conditions than WCF that it’s hardly a fair comparison at all. While WCF can be configured to provide something kind of close to the same level of reliability, you need to do a fair amount of spelunking through the various options of netMsmqBinding to get it right.

The second reason to use NServiceBus instead of WCF is publish/subscribe.

The ability to make use of events and the observer pattern not just to achieve loose coupling within a single process, but across many processes, machines, and sites. Can you imagine going back to programming without events? Shudder. But that’s exactly what it’s like to use WCF in your distributed system. NServiceBus brings you the best of object-oriented programming but in a distributed and reliable infrastructure.

Don’t wait any longer

Take NServiceBus for a spin.

But things may look a bit different after you do…

http://www.NServiceBus.com

And have a happy New Year.

For those of you looking at on-premise solutions but don’t want MSMQ and prefer a more “enterprise-ready” infrastructure, there is now an adapter for WebSphere MQ. This is already being used in production with NServiceBus version 1.9 and WebSphere MQ 6.x. Read more.

For those of you looking at the cloud, Yves been doing some amazing work on getting NServiceBus to work on Azure. You can read about it here. As Ayende wrote about in his post about queuing systems, there is a big difference in how things like transactions work with local queues (like MSMQ) versus remote queues (like Azure queues).

I’m also happy to see that the community-driven NServiceBus-Contrib effort is beginning to pick up steam. We’ve now got more than 1000 people in the discussion group and a critical mass of community leaders able to answer almost all questions without my involvement – a truly scalable and sustainable ecosystem.

Currently the company using NServiceBus at the largest scale (that I know of) is Conduit.com with over 200 million users, the important thing being that they were able to do so without requiring thousands of servers (like the way MySpace did as described here). I obviously can’t divulge how many servers Conduit.com is using, but suffice it to say that it’s an order of magnitude lower – that’s what true scalability is about, doing more with less.

Lots more interesting stuff is in the pipeline so keep watching.

Learn more about NServiceBus

Hands-on

The NServiceBus course is actually different from what I previously delivered – the course has been extended from 2 days to 3 days and now has a much larger hands-on component for attendees.

The idea is that team leads and architects will likely be going to the 5-day distributed systems course, and then that the members of their teams go to this one. This 3-day course will have enough theory that attendees will know what the terms AC, BC, and Service mean, but the main focus will be on the concrete implementation of these concepts using NServiceBus – the actual building of reliable and scalable systems.

The next delivery planned for this course will be in London on Nov 8-10 – register here.

Upcoming Advanced Distributed Systems Design

Oct 11-15: Johannesburg, South Africa

Oct 24-28: Israel

Nov 1-5: London, UK

Nov 22-26: Sydney, Australia

Dec 13-17: Seattle WA, USA

Information on the Advanced Distributed Systems Design course can be found here.

Upcoming conferences

Oct 19-20: Prio Conference – Nurnberg, Germany

I’m also giving a post-conference workshop on NServiceBus – details here.

YOW Australia – Melbourne, Dec 2-3

* I have one free day of consulting left between my course and the conference – if you’re interested, and the beginning of December in Sydney or Melbourne works for you, contact me at consult@udidahan.com

The problem is that, as software developers, we’re all too quick to accept them at face value. We don’t question the requirements – in all fairness, it was never our job to do so. We were the ones that implemented them, preferably quickly.

For example

Let’s say we get the requirement the following requirements:

1. If the order was already shipped, don’t let the user cancel the order.
2. If the order was already cancelled, don’t let the user ship the order.

The race condition here is when we have two users who are looking at the same order, which is neither cancelled nor shipped yet, and each submits a command – one to ship the order, the other to cancel it.

In these cases, the code is simple – just an if statement before performing the relevant command.

So what’s the problem

A microsecond difference in timing shouldn’t make a difference to core business behaviors. Which means that we’ve actually got here is a bug in the requirements. Users are actually dictating solutions here rather than requirements.

Let’s ask our stakeholders, “why shouldn’t we let users cancel a shipped order? I mean, the users don’t want the products.”

And the stakeholders would respond with something like, “well, we don’t want to refund the user’s money then. Or, at least, not all their money. Well, maybe if they return the products in their original packaging, *then* we could give a full refund.”

And as we drilled deeper, “when do refunds need to be given? Right away, in the same transaction?”

The stakeholders would explain, “no, refunds don’t need to be given right away.”

It turns out we were missing the concept of a refund, as well as assuming that all things needed to be processed and enforced immediately. Once we dug into the requirements, we found that there is actually plenty of time to allow both transactions to go through. We just need to add some checks during shipping’s long-running process to see if the order was cancelled, and then to cut the process short.

So is everything a long-running process then?

That’s actually a fair question – long-running processes are a lot more common than at first appears.

What we’re seeing is that cancellation is now a command that has no reason to fail – just like CQRS tells us. When this command is performed, it publishes the OrderCancelled event, which the billing service subscribes to.

Billing then starts a long-running process (a saga, in NServiceBus lingo), also listening to events from the shipping process, ultimately making a decision when a refund should be given, and for how much.

Deeper business analysis

As we discuss matters more with our business stakeholders, we hear that most orders are actually cancelled within an hour of being submitted. It is quite rare for orders to be cancelled days later.

In which case, we could look at modeling the acceptance of an order as a long-running process itself.

When a user places an order, we don’t immediately publish an event indicating the acceptance of an order, instead a saga is kicked off – which opens up a timeout for an hour later. If a cancellation command arrives during that period of time, the user gets a full refund (seeing as we didn’t charge anything since billing didn’t get the accepted event to begin with), and the saga just shuts itself down. If the timeout occurs an hour later, and the saga didn’t get a cancel command, then the order is actually accepted and the event is published.

Yes, sagas are everywhere, once you learn to see with business eyes, and no race conditions are left.

In closing

Any time you see requirements that indicate a race condition, dig deeper.

What you’re likely to find are some additional business concepts as well as the introduction of time and the creation of long-running business processes. The implementation at that point will pivot from being trivial if-statements to being richer sagas.

Keep an eye out.

The .NET Service Bus was designed to bridge internet communications using the cloud to enable a variety of devices to communicate using a WCF-remote-procedure-call type of API. NServicebus was designed to simplify the design of on-premise distributed systems using reliable messaging.

Still, people seem to want a kind of comparison, so here’s a quick one off-the-top-of-my-head:

This is not meant to be an exhaustive list, or even an accurate representation of the relative strengths and weaknesses of the technologies because, as I said, they’re designed for different purposes.

One could even plug the .NET Service Bus into NServiceBus instead of its MSMQ transport to get broad reach where required, and then switching back to the on-premise strengths of MSMQ. The pluggability of NServiceBus makes it easy to swap out almost all implementation components like the subscription storage, transport, authorization mechanisms, containers, etc.

For more information on the .NET Service Bus see the Azure AppFabric page. Juval Lowey also has a nice article on it up on MSDN magazine here.

For more information on NServiceBus see the NServiceBus site. Also take a look at the pages giving you comparisons to WCF and BizTalk.

Mistakes Made

In the previous version of NServiceBus (1.9) we over aggresively merged 3rd party libraries like Castle into the NServiceBus binaries. That in itself, wasn’t the big problem. The problem was that we didn’t know about internalizing the libraries we merged.

This resulted in all the 3rd party types being exposed when a developer used NServiceBus. For those who happened to use the same version of those libraries as that which was merged, it wasn’t a problem. Unfortunately, developers who used libraries like Castle tended to be very particular about which version they used – which resulted in version conflicts, also known as “versioning hell”.

Internalization Challenges

As we moved to NServiceBus 2.0, we were a lot more careful about which libraries were merged and made sure to internalize them as much as possible. Yes, you read that right, “as much as possible”. You can’t always internalize all the types of a given library.

For example, NServiceBus internally uses NHibernate to persist the state of long-running processes (called sagas) and we want this implementation detail to not conflict with anything that developers want to do on top of NServiceBus. The only thing is that for NHibernate to work, it needs certain types to be exposed to the configuration environment, specifically all the types in the NHibernate.Cfg.MappingSchema namespace.

Extensibility Challenges

Once you take on an external dependency, you want to configure it to “just work” so that developers that aren’t familiar with it don’t have to learn yet another library to use your framework. So far, we’ve been able to do that quite successfully with NServiceBus. The challenge comes when developers want to customize the behavior of those 3rd party libraries, wanting to call into their APIs.

You see, once you internalize those libraries and their types, developers can’t access them. This leads to all sorts of tricky extensibility problems especially for different kinds of developers. Some are happy enough to configure things from the outside using XML – like using hbm.xml files to describe how their sagas get persisted, while others really want to use Fluent NHibernate, which is fully internalized.

Finding a Balance

What we’ve currently got for NServiceBus to try to keep everyone happy is a progressive exposure model. From the developer who’s downloading NServiceBus for the first time and wants everything to just work without changing anything, our API unfolds in multiple dimensions to allow for the highest level of extensibility and pluggability. That being said, the Fluent NHibernate issue mentioned above isn’t solvable at just an API level.

In order to address the class of developer that wants full control, we’ve got a “core only” build that doesn’t merge any assemblies into it. This class of developer usually doesn’t have a problem with referencing some more assemblies as long as they retain full control of the behaviors they want.

It ain’t easy keeping everybody happy, or, at least, not unhappy.

In Closing

I would agree that more OSS frameworks should merge and internalize 3rd party libraries that don’t need to be exposed to developers – it shortens the learning curve and increases adoption. But walk this path cautiously, it’s hard striking a balance that will work all users of your framework and it takes quite some time to get it right.

And one last thing, please, PLEASE, take care of maintaining binary compatibility from one version to the next. I know it’s a pain – we’ve been doing it with NServiceBus for the past 3 years, but your users will thank you for it.

Some background

As a cohesive framework, NServiceBus makes it quite easy for developers to pick and choose which settings they want turned on and off. Being built as a loosely-coupled set of components that don’t know about each other has always kept the internal complexity low. But as the NServiceBus API has been evolving over the years, and the functionality offered has increased, some interesting challenges have popped up as the codebase has been refactored.

The challenge

The UnicastBus class has grown too large and it’s time to refactor something out. Coincidentally, users have been asking for a better “header” story for messages – the ability to specify static headers that will be appended to all messages being sent (useful for things like security tokens), as well as per message headers. So, we want to refactor all the header management out to its own component independent of the UnicastBus class.

So, here’s the issue. So far, users have specified “.UnicastBus()” as a part of the fluent code-configuration, and shouldn’t have to change that – they shouldn’t need to know that header management is now a separate component. But then how can the new component bootstrap itself into the startup, such that it gets all the dependency injection facilities of the rest of the framework? Remember that the component doesn’t know which container technology is being used (since the user can swap it out) or when the container has been set.

The solution

The only part of the framework that knows about when all DI configuration is set is the configuration component, thus it will have to be the one that invokes the new component (without knowing about it). Introduce an interface (say INeedInitialization) and scan all the types loaded looking for classes which implement that type, register them into the container, and invoke them. Have the new component implement that interface, and in its initialization have it hook into the events and/or pipelines of other parts of the system.

Other uses

One historically problematic area in NServiceBus has been people forgetting to call “.LoadMessageHandlers()”. This can now be wired in automatically by a class in the UnicastBus component via the same mechanism.

A new feature coming in the next version is the “data bus”, a component which will allow sending large quantities of data through the bus without going through the messaging pipelines. This will help people get around the 4MB limit of MSMQ and, even more importantly, the much smaller 8KB limit of Azure. We will be able to introduce the functionality transparently with the same mechanism.

As an extension point, developers can now enrich the NServiceBus framework with their own capabilities and make those available via the contrib project to the community at large. This is better than the IWantToRunAtStartup interface that was only available for those using the generic host (which excluded web apps) and gives a consistent extensibility story for all uses.

Summary

Extensibility has always been a challenge when writing object-oriented code and dependency injection techniques have helped, but sometimes you need a bit more to take things to the next level while maintaining a backwards-compatible API.

Like I said, not a ground-shaking topic but something quite necessary in creating loosely-coupled frameworks and applications. Once you know it’s there, it isn’t really a big deal. If you didn’t know to do it, you may have been contorting your codebase in all kinds of ways to try to achieve similar things.

If you want to take a look at the code, you can find the SVN repository here: https://nservicebus.svn.sourceforge.net/svnroot/nservicebus/trunk/

After I had finished speaking at QCon London last March, I sat down for a short interview with the guys from InfoQ chatting about topics from CQRS, to DDD, to NServiceBus. I’m happy to say that the interview is now online with a full (and mostly accurate) transcript as well as with an MP3 download link.

Get it here: Udi Dahan on CQRS, DDD and NServiceBus

Currently, the video is being graciously hosted by Jon Torresdal on his blog, so let’s hope that the bandwidth holds up.

Get it here.

While Mule has many features in terms of connectivity and integration, NServiceBus provides platform interop only. One could say that this is a product of the different backgrounds I and Ross come from.

On the other hand, the saga capabilities in NServiceBus for handling long-running processes are considered to be BPM functionality on the Java side of the industry, and as such, Mule does not have them.

In terms of other enterprise features like management and monitoring, Mule is more mature, but NServiceBus holds its own in terms of high availability and actually surpasses Mule with the grid and scale-out capabilities of its distributor.

Anyway, I think it’s about time each of these parts was explicitly described so that companies already invested in Java ESB tools will know what they’re getting with NServiceBus.

Until then, I hope this podcast describing the full spectrum of NServiceBus, from top level SOA services to in-the-weeds transaction management, will provide more information about what it is and why you might want to use it:

Deep Fried Bytes, episode 49 – Getting the right message about NServiceBus with Udi Dahan.

Comments most welcome.

NServiceBus 2.0 RTM is now generally available.

There were some small tweaks after the RC2 but I’m happy to say that, all in all, this was a very quiet stabilization period. Key customers have reported very high levels of satisfaction with the NServiceBus stability, scalability, and simplicity.

For example

Conduit.com has very happily doubled their user base with NServiceBus to 100 million.

#1 on American Banker’s 100 top financial tech companies, Fiserv has been quietly employing NServiceBus across many of their core services.

The Irish SaaS company Candidate Manager have been running the automated HR processes of geographically distributed giants like Hilton International on NServiceBus without missing a beat.

Community

Now with an active community of over 600 members, new users are quickly brought up to speed by the veterans and the much improved documentation on the site make adopting NServiceBus simpler than ever.

Training on NServiceBus has also ramped up nicely with the April course in Philadelphia now sold out. The next course will be in London in May via Skills Matter.

More courses are being planned in:

• Toronto, Canada Aug 9-13
• Calgary, Canada in September
• Johannesburg, South Africa in October
• Sydney, Australia in November
• Seattle WA, USA in December

Give it a try

You’ll have publish/subscribe messaging working in under 5 minutes with a simple F5 on the PubSub sample.

Get it here.

What’s New

The quickly approaching next release of NServiceBus will be version 2.0 and is a big step from 1.9. After 2 betas and 2 release candidates, this version has had a longer stabilization period than any of the versions so far (1.4-1.9). Many of my clients are already using it in production and are very pleased with it. I’ve heard similar reports from others in the community (now with over 500 members in the discussion group). There have been almost 10,000 downloads since the version 1.9 release and in every country I visit I meet people using NServiceBus in new and interesting applications.

With my appearance on Hanselminutes, many in the mainstream .NET industry have started taking a look at NServiceBus. That, and the fact that Microsoft’s Oslo technology has now taken a very data-driven turn (rather than its original service-oriented direction).

Interestingly enough, I’ve been hearing more and more reports about people using NServiceBus as a developer-friendly API on top of other technologies. This includes BizTalk and even Neuron. I never thought that people would take the pluggability of NServiceBus that far.

So, what is NServiceBus?

Well, it’s a service bus, y’know, like an ESB – just an open-source one.

All kidding aside, in a nutshell, it gives you an easy way to integrate transactional messaging into your applications.

One of the reasons why you might want to do that is so that you don’t lose messages containing valuable data when IIS recycles your AppDomain, every 15-20 minutes (as I wrote about in this MSDN magazine article).

There are many other nice things in there, like the ability to unit test your service layers and long-running processes but you can read more about that here…

Documentation

One of the biggest differences to NServiceBus in this release is documentation.

A lot of work has gone into the NServiceBus.com site to help developers hit the ground running with NServiceBus, including the more advanced aspects of transparent scale-out with the distributor and multi-site communications.

There is still work to be done in this area but feedback so far has been extremely positive (except for some grumblings from certain old-timers saying that if they could figure it out by themselves, well, you know the rest).

In Closing

If you’re building a distributed enterprise .NET system, take 5 minutes, download it, and see transactional publish/subscribe messaging working on your machine without any big heavy-weight middleware.

www.NServiceBus.com

Take a listen.

The thing is, when looking at this in light of the full software development lifecycle, there are signs that the waters run deeper than we might have originally thought.

Let’s take things one step at a time though…

What is it?

Wikipedia tells us:

“Convention over Configuration (aka Coding by convention) is a software design paradigm which seeks to decrease the number of decisions that developers need to make, gaining simplicity, but not necessarily losing flexibility. The phrase essentially means a developer only needs to specify unconventional aspects of the application.”

What this means is that frameworks built in this way have default implementations that can be swapped out if needed. So far so good.

For example…

In NServiceBus, there is an abstraction for how subscription data is stored and multiple implementations – one in-memory, another using a durable MSMQ queue, and a third which uses a database. The convention for that part of the system is that the MSMQ implementation will be used, unless something else is specified.

Developers wishing to specify a different implementation can specify the desired implementation in the container – either one that comes out of the box, or their own implementation of ISubscriptionStorage.

Things get more interesting when we consider the full lifecycle.

Lifecycle effects

When developers are in the early phases of writing a new service, they want to focus primarily on what the service does – its logic. They don’t want to muck around with MSMQ queues for storing subscriptions and would much rather use the in-memory storage.

As the service takes shape and the developers want to run the full service on their machine, possibly testing basic fault-tolerance behaviors – kill one service, see that the others get a timeout, bring the service back up, wanting it to maintain all the previous subscriptions.

Moving on from there, our developers want to take the same system they just tested on their machine and move it into a staging environment. There, they don’t want to use the MSMQ implementation for subscription storage, but rather the database implementation – as will be used in the production environment.

While it may not sound like a big deal – changing the code which specifies which implementation to use when moving from one environment to another, consider that on top of just subscription storage, there is logging (output to console, file, db?), saga persistence (in-memory, file-based DB, relational DB), and more.

It’s actually quite likely that something will get missed as we move the system between environments. Can there be a better way?

What if…

What if there was some way for the developer to express their intent to the system, and the system could change its conventions, without the developer having to change any code or configuration files?

You might compare this (in concept) to debug builds and release builds. Same code, same config, but the runtime behaves different between the two.

As I mulled over how we could capture that intent without any code or config changes, the solution that I kept coming to seemed too trivial at first, so I dismissed it. Yet, it was the simplest one that would work for console and WinForms applications, as well as windows services – command line arguments. The only thing is that I don’t think those are available for web applications.

But since we’re still in “what if” land, and I’m more thinking out loud here than providing workable solutions for tomorrow morning, let’s “what if” command line arguments worked for web apps too.

Command-Line Intent

Going back to our original scenario, when developers are working on the logic of the service, they run it using the generic NServiceBus host process, passing it the command line parameter /lite (or whatever). The host then automatically configures all the in-memory implementations.

As the system progresses, when the developer wants to run everything on their machine, they run the processes with /integration. The host then configures the appropriate implementations (MSMQ for subscription storage, SQLite for saga persistence, etc.

When the developers want to run the system in production, they could specify /production (or maybe that could be the default?), and the database backed implementations would be configured.

Imagine…

Imagine being able to move that fluidly from one environment to another. Not needing to pore over configuration files or startup script code which configures a zillion implementation details. Not needing to worry that as you moved the system to staging something would break.

Imagine short, frictionless iterations even for large scale systems.

Imagine – lifecycle-aware frameworks making all this imagination a reality.

In Closing

We’re not there yet – but we’re not that far either. The generic host we’re providing with NServiceBus 2.0 is now being extended to support exactly these scenarios.

It’s my hope that as more of us think about this challenge, we’ll come up with better solutions and more intelligent frameworks. Just as convention came to our rescue before, breaking us out of the pain of endless XML configuration, I hope this new family of lifecycle-aware frameworks will make the friction of moving a system through dev, test, staging, and production a thing of the past.

A worthy problem for us all to solve, don’t you think?

Any ideas on how to make it a reality?
Send them in – leave a comment below.

“A common complaint is that the first call on a client object takes some disproportionately large amount of time, usually ten seconds or more, while successive calls are instantaneous. There are many reasons why this might happen so there’s no generic resolution for this problem.” — Nicholas Allen

The thing is that there IS a generic solution to this problem.

It’s queued messaging.

The only thing is that you have to give up talking to your services as if they were regular objects – calling methods on them and expecting a response. In other words, designing a distributed systems isn’t like designing a regular OO system just with some WCF sprinkled on top.

Even when trying to do fire and forget messaging on top of WCF (void method calls with the OneWay attribute), the underlying channel can still block your thread, as Nick mentioned.

A queue isn’t an implementation detail.
It’s the primary architectural abstraction of a distributed system.