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

Accenture still not getting SOA

A while back I pointed out some comments by Accenture's CTO which (for me) indicated that Accenture don't get SOA well they've now established a venture with BEA and it appears that Accenture still don't get SOA.

He [Accenture CTO Donald Rippert] described the four phases of SOA implementation, which begins at using XML as an interface, then implementing legacy systems as Web services, and then using an ESB to connect Web services and use composite processes. The fourth phase involves using BPEL (Business Process Execution Language for Web Services) in which a business application is revised by making changes to the process model rather than the code.

But SOA, for the most part, is not enabling this yet, said Rippert. "Maybe someday, but not today; I don't see it today," Rippert said.

Wow its still impressively wrong. Hands up everyone who has seen BPEL used in a commercial environment? Does that feel like the fourth and final phase of SOA to you? No me neither. This really is dreadful advice on what SOA is and what SOA maturity is about. I've worked with customers where their first technical SOA project was all about using BPEL (without an ESB) to do something where that made sense.

You can take what Mr Rippert is saying and easily replace WS and XML for some other basic form and an EAI tool, then have that EAI tool be the ESB and put a process engine on the EAI suite. In other words his vision is from a functional and conceptual perspective equivalent to EAI.

If SOA, or any IT change, is just about a series of three and four letter technical words then it will deliver almost no benefits. So has to be about changing the way people think or its pointless.

Technorati Tags: SOA, Service Architecture

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

Technologists to shoot...

Thanks to Gervas Douglas and the yahoo list I've got a cracking example of the sort of thing I mean....

According to Forrester, an ESB typically includes communication
infrastructure; request routing and version resolution (mediation);
transformation and mapping; service orchestration, aggregating and
process management; transformation management; security; quality of
service; service registry and metadata management; extensibility for
message enrichment; monitoring and management; and support for the
service life cycle.

Oh god, how complex do you want one product to be?

But by far the biggest change in the ESB market, he said, is "you find
more and more larger vendors adding either a standalone ESB, like IBM
and BEA, or including those features in basic integration suites, like
Tibco and WebMethods and Oracle. Over time, I believe standalone ESBs
will gradually be consumed by the larger vendors and become more basic
infrastructure technology," Vollmer said.

Genius, this doesn't actually make any sense at all. Standalone ESBs (as produced by IBM/BEA) will gradually be consumed by the larger vendors. What the hell does that mean, he has just said that the larger vendors actually are either choosing to a) consider ESB as a lightweight platform to link things or b) are lobbing stuff onto existing products. I have three issues with this

1) Oracle's ESB is miles more like IBM/BEA than it is Tibco/Webmethods... and I'd bet more on them going for that model in future
2) The consumed line makes no sense
3) How on earth can the ESB with its millions of features he described before ever become a "basic" infrastructure technology.

This is exactly the sort of thing I was ranting about in the last post. The whole article is purely about how technologies will "solve" problems and move you towards SOA, and there isn't even a consistent line about what the technology is.

Technologies won't solve those old problems. If SOA is just about building applications in the same old way using Unicode based transport mechanisms then we've regressed. If its about using EAI type tools, then we've regressed.

Not one of these people actually suggested that SOA was about altering the way you think about systems. It read exactly like a bunch of people arguing that C++, Java, Smalltalk, Eifflel, UML, BON, Schloer-Mellor et al were the "way to do OO" rather than OO actually being about a shift in the way people think about designing systems. SOA works a level above OO in that it is about the architecture of multiple as well as single systems, but still the line is pushed that buying this technology will solve the problems created by the one they sold you last year.

Technorati Tags: SOA, Service Architecture