The Case for a Short Bus

We’re building an event-driven architecture (EDA) for our client, so it makes sense that a part of our domain model is going to deal with events. The mountain of concerns associated with moving events around in an EDA is most often handled by an enterprise service bus (ESB). How many concerns, you ask? Just take a look at Wikipedia’s list of “core capabilities” – the ones that “most observers accept” as part of an ESB’s responsibility. There’s a lot going on there! This is why I have a lot of respect for traditional ESBs and the developers who make them.

Unfortunately, in addition to respect, I also have a lot of trepidation when it comes to choosing, installing, configuring, and using an ESB. A lot of the installation and configuration deals with capabilities that I don’t use and the API for those capabilities distracts me from the main use case: creating and consuming events. I wish that traditional ESBs were more like the Spring stack – a set of capabilities that don’t depend on each other, but integrate seamlessly when I want them to.

Another pain point is the mismatch between what existing ESBs offer and what our EDA needs. For example, a benefit of ESBs is the ability to accept events on different types of endpoints (SOAP, REST, FTP, Flat Files, etc). That’s a great selling point if you’re integrating a disparate set of legacy components, but our situation is different. We are writing or integrating every creator and consumer of events, and even if that changes in the future we are in a position to say, “if you want to play with our system, you will do X, Y, and Z.” For us, many capabilities in traditional ESBs add no value.

In addition, there is friction between our team’s goal and an ESB vendor’s goal. ESB vendors make their products generic enough to appeal to many customers; we are fitting generic frameworks to the specific needs of one customer. The level of abstraction in a commercial ESB is likely to be greater than that of a home-brewed counterpart. Keeping with the previous example, “endpoints” are a level of abstraction that is necessary to support the different ways of transporting events. However, if your requirements allow you to take the “opinion” that all components in the architecture will only use AMQP to transport events, your ESB will be less involved – it will be “lighter”. The more “opinions” you can make about your ESB, the “lighter” it will be compared to existing ESB offerings.

Currently, our needs require more than simple publish/subscribe, but less than a full-blown ESB. When we laid out the responsibilities we wanted to assign to our eventing subsystem, we discovered that most responsibilities (like platform-agnostic event serialization and event persistence) already have great frameworks that perform that responsibility (and do little else). That means we won’t have to write everything from scratch; we just have to wire up a few frameworks. Our team considers this to be the best technical solution AND the solution requiring the least amount of effort.

Because it's a smaller bus for our special needs we’ve decided to call this style of ESB a Short Bus. Kudos to Richard for coming up with the name.

In the next few posts, I’m going to lay out the use cases that our Short Bus will have to support and discuss the frameworks we’ve decided to cobble together into a Short Bus.