Business Service Bus - A definition

I've been involved in a number of technology selection pieces over the last 18 months or so, and one of the biggest challenges is rating the products against what they need to be used for rather than against each other. One of the biggest challenges has been convincing people to rate down products that have more facilities than are required.

So I've decided to have a crack at defining the products that I'd like to see and the selection criteria around them, I covered this a while ago in Splitting up the ESB but since then I've realised that its not quite a cut and dried. So the old picture was something like this...

Where the idea is that a BSB works across multiple SOA Apps and then you can have a "BSB of BSBs". What I've found since then (well its been 12 months) is that there is actually an even simpler BSB out there and there is another layer where the choice between a pure BSB and an ISB style needs to be considered. This means that the model I tend to use now is like this


The DSB is just on the diagram to note something to talk about, it stands for "Domain Service Bus" and this is where you have the decision between using an ISB style of product, mainly if you already have a legacy estate and there really isn't much point building a "pure" SOA layer above it, the only thing that is important here is the external services to the domain and getting those right. This is where the older EAI products with their new EAI badges and the newer "richer" (aka more complex) ESB products come into their own.

The big issue I’ve found however when making selection choices is that vendors take a “shotgun” approach to all responses and tend to lob in lots and lots of products with very little actual architectural clarity and almost never do they try and sell anything other than the most feature rich product. Now in the ISB space this is fine as feature rich means more able to do what you want with the heterogeneous landscape you are trying to manage. For the BSB however the focus is exactly the opposite for two reasons

1) It’s a homogeneous environment with XML as the document format
2) It’s the layer you want to keep the most simple to enable the most flexibility

This means that you want the least features possible to stop people doing stupid things. I’d argue in fact that at the BSB level this should be one of the cheapest product that a company every buys. The BSB does not need to support multiple document formats, it does not need to support multiple transport mechanisms and in reality it needs to support only one packaging approach, namely WS-*. Now even if the RESTians scream and shout for inclusion this doesn’t add too much complexity because its still XML over HTTP even if there are certain differences. So lets keep REST in for now to be fully buzzword compliant. Now I know here that some people are going to scream “performance” and mention JMS v WS-RM and talk about email and those pieces. But my point is that the drive at the BSB should be towards mandate and simplicity. Taking 802.11x as an approach, this can support multiple protocols (b, g, a, n) but its all based around the same standards group. So lets start with the simplest approach and then evolve it, rather than starting with multiple approaches.

So what facilities does the BSB actually need? During all of these evals I’ve done I’ve come to realise that the facilities in the BSB don’t, in some ways, make an attractive proposition for a software vendor because the product will be cheap. A BSB is in fact MQSeries for the 21st Century. The thing I most loved about MQSeries was its price for what it did. Clustering, failover, simple load balancing, a joy to configure and it pretty much always worked as advertised (except in MQSeries 5.1 using JMS on AIX with IBM’s Java implementation, but we got a patch pretty quickly… MQSeries 5.2) and once live it was solid as a rock. This is what the BSB should be, just the basics.

Application (stuff related to Services) -
1) Mediation - Transformation, Audit, Logging, Security Mediation (one authoriser to another) probably via exits
2) End-point Routing
3) WS-* support including WS-RM, WS-Security over HTTP and HTTPS

Infrastructure (Stuff that is just "Magic")
4) Clustering - Federation
5) Failover
6) Basic Load balancing (Round Robin or Random) Exits
7) Monitoring points
8) Policy enforcement point

And by monitoring I mean being able to see the flows, bottle necks and responses across the bus, its operational monitoring rather than pure business monitoring but this is information that can flow up to a proper business monitoring solution. Complex load-balancing i.e. SLA based, is something I’d leave out for now but somewhere I’d expect the vendors to be going.

So this means no async to sync mapping, no "lightweight" process, no processes at all in fact nothing that really requires much of a product to support it at all. It needs to be fast, it needs to be simple and it needs to be able to federate. In fact I'd say that a product like this would tend to live all over the place and just "happen" to connect up to other products. These BSB would delegate to registries and policy engines it would just provide the standard mechanism for those elements to be enforced.

Now in my simple mind this looks like a good "base" product (ala MQSeries) for connecting pieces together, it isn't smart its just simple. All it does is enable different pieces to connect and be kept apart using simple routing and mediation. Lob in some semantic matching and it could get even easier.

So that is my view of what a BSB needs to be. Its the MQSeries of SOA technology, its for linking things up that know what they are talking about and know why they want to talk. I don't want the bells and whistles, I want it simple and I want it fast. This is the bit I want to use to do the cross domain pieces and the bit where I want to prevent people being "clever" so I can do the really smart stuff somewhere else.

Technorati Tags: SOA, ESB, Service Architecture