Monday, January 07, 2008

Business Service Bus (BSB) - a specification

Last year I put up a post about how I viewed the ESB market. This is basically the model I recommend to large organisations when looking at the various ESB and EAI products, namely don't think that a kitchen sink approach will work and quite often you want a less powerful product that will help you enforce policy.

With help from the folks at Progress Software we wrote a definition of what the BSB would be. This was pretty much ready early last year but I've been a bit busy with work so it had to stay on the back burner so its just been used by some companies internally. Now however its time to put this BSB specification out there.

Comments welcomed. The point of the BSB specification is to be the complete opposite of most product roadmaps these days, it isn't about having more widgets or buzzwords its all about having a very simple set of capabilities that can be used in very powerful ways. I've thought about it as a sort of MQSeries for SOA, not the MQSI/MQWorkflow/CrossWorlds extensions but the core superb product that is MQSeries (or WebSphere MQ to give it the new branded name). The bit that made MQSeries powerful wasn't that it did loads of fancy things but that it did (and does) spectacularly well a small set of important features.

The point of the BSB specific is to declare a minimum set of functionality that is required to manage interaction between disparate business domains. This minimum set of functionality is also (pretty much) the maximum allowed set of functionality. The Non-requirements are in many ways more important that the requirements as they exclude things that make compliance and management more difficult. These are the core requirements and non-requirements from the BSB Specification (which explains them in more detail).

Requirements for a BSB
The following elements must all be true for a BSB to be considered complete:

  1. Homogeneous in both technology standards and document formats, typically this means WS-* and XML.
  2. Specifically the BSB must support WS-Reliable Messaging, WS-Security, WS-Policy and WS-Addressing as a minimum.
  3. Interact across different business concerns using asynchronous and synchronous Web Service calls, (although all uses of async and sync must remain symmetric—i.e. no async to sync conversion within the BSB).
  4. Be targeted at communication and interaction and not application development
  5. A BSB product must allow the automated and scripted migration of it’s configuration between development, testing and production to reduce any technical overhead in it’s deployment
  6. A full BSB environment must provide a mechanism for the testing and validation of services and service interactions through the Bus
  7. A BSB must be deployed in a federated model and contain no single point of failure


The following are the things that the BSB must not allow

  1. Although the BSB is to support both synchronous and asynchronous requests we explicitly exclude async to sync conversion or sync to async. Requests should be made in the right format.
  2. Transport to Transport conversion (e.g. SMTP to HTTP or JMS to HTTP) inside the BSB.
  3. Any process implementation beyond the simple pipe-lining described below
  4. Routing that would involve the use of external application-level meta-data or introspection into message content will expressly be outside the role of the BSB. Such logic should generally exist with in the DSB layer but may be permissible within an exit in certain circumstances. Use within an exit however, should be confined to only inter-domain routing policies and should not reflect application/business level considerations unique or local to one or more connected domains.
  5. System driven routing (i.e. those routings that may require system availability status as meta-data to drive the routing behaviour) should as well be confined to those routings that are expressly relevant to the inter-domain policies being enforced, such as SLA. BSB level routing behaviour should never exert a policy assertion that would be specific to business logic associated with a domain.
  6. Likewise, transformations should be thought of the same way—as transformations necessary for inter-domain operation and interoperability.

The reason for writing this was that I was a bit fed up with the ever growing complexity of ESBs and the focus more on new functionality rather than a small, tight core that would work effectively and allow organisations to govern their SOA environment successfully. Less really is more when it comes to governance. I don't want all the bells and whistles, I want to mandate a set of standards and approaches that can be simply enforced and thus use simplicity to drive re-use and adoption.

Technorati Tags: ,


Anonymous said...

Steve, What do you think are the additional things this offers over and above what our expectations of JBI were - or is this what it should have been ;-)

Tieu H Luu said...

I find it interesting that you named it Business Service Bus, given the second part of the following statement "The BSB is not intended to be an application development platform or to enable any form of business logic to be executed."...somewhat oxymoronic

Unknown said...


JBI could be used as the implementation approach for the bus, but I feel that JBI tends to work at an application level rather than across business areas. JBI is also focused on the internals of execution whereas this is about what users get. So JBI could be used to implement a BSB.


Its not an oxymoron that the bus has no logic as a bus should be about enabling access and transporting things from A to B. The bus provides access to Business Services and it is those services which contain the business logic. If the Bus hosted the services directly then it wouldn't be a bus it would be another application server.

Tieu H Luu said...

Yes, but the fact that you've changed it from the commonly used name of Enterprise Service Bus to Business Service Bus leads one to think that your interpretation of an ESB would contain more business-specific functionality, which after reading your document it is quite clear that that is definitely not the case.

Another thing that is unclear are your "Non-Requirements", especially when you say "The following are things that the BSB must not allow". Are you saying that these are just bad practices in general and should be avoided or are you saying that this functionality should not be a part of the BSB? If the former, then I would argue against your first non-requirement on sync/async or async/sync conversion. I have come across many scenarios where I have a client that needs to invoke a service which only offers a synchronous interface yet the client does not need a synchronous response. In this case, it is useful to have a bus where the client can asynchronously drop off the request and check for the response sometime later from a response queue.

Thomas Rischbeck said...

Hi Steve,
I've just seen this because there was a reference to your BSB specification on an InfoQ article:

I'm wondering between the relative merits of the BSB pattern (I call it "hierarchical ESB topology") vs. using a protocol-based, no-infrastructure intermediation appraoch at the enterprise level. I've created a more detailed question on my blog:

To me the jury is still out. I'd be glad to receive your thoughts on this.