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
   

Non-Requirements

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: SOA, Service Architecture