Plugging into the bus-fabric

Systinet's CTO Adam Blum has been writing in his weblog about a concept he calls the web services bus (or if you prefer, the services infrastructure fabric, or a range of other take-your-pick names). I'm going to call this the services bus-fabric, because I think it's important to stress that it's more than either just a bus or just a fabric.

I've been meaning to highlight this topic for some time now (Adam posted these thoughts in November and December last year). Perhaps we'll see something emerging in due course out of the Systinet stable. Or perhaps Adam has penned an unwitting clue to a new source of potential merger activity in the web services management space. I can only speculate, as every time I schedule a briefing with the company we end up having to postpone it for one reason or another.

The fundamental point of importance I think Adam is making in his weblog is that it's not enough just to start using web services. There needs to be some overarching infrastructure that ties them together, and it's going to be more efficient if the infrastructure has some core messaging functionality built into it, along with a standardized way of making certain facilitation and integration services available. Adam goes on to explain that this is (in some respects) more than and (in other respects) less than an ESB (enterprise services bus). I think what this is getting at is that throwing some tools around JMS to make an ESB may be a good commercial move for certain vendors, but it's not the same as establishing a standards-based web services bus-fabric infrastructure.

Adam writes that web services management will be one of the first activities that will benefit from having this extra layer, because instead of each separately adding their own overhead, all the tools can plug into the bus-fabric and share access to the information they need:

"None of these [independent] solutions are particularly satisfying. Either they require touching each endpoint web service deployed in the enterprise (an approach which is very tedious as organizations deploy thousands of web services) or they create serious performance bottlenecks in the web service traffic ... However if web service traffic is passing through a mediating bus, the bus can simply give the management reporting service a chance to look at each message as it passes. All of the work of getting at the web service traffic is avoided."

He goes on to suggest other possible pluggable services, such as security, business process management, transaction management, XML document validation and content routing. I suspect that what he describes is going to emerge anyway once standards definitions start to settle down, but early-adopting web services users will probably find they can already gain benefits today from moving towards a bus-fabric model as a means of sharing service-oriented infrastructure resources.

posted by Phil Wainewright 9:45 AM (GMT) | comments | link