Many different products claim to be effective for Enterprise Application Integration.  There’s about as many products as there are ways to integrate applications.

The first and most common approach to integration is data integration.  I’ve seen integration from the standpoint of common data tables from multiple sources, mined data in common reports, and even “star data dispersion” where one “domain data” application acts as a source of data for a host of others.  Domain data alignment is essential to integration, but it is only the first step.

After you have created a structure for sharing common data values across applications, and keeping them up to date, you need a way to share EVENTS.  This is more important than sharing code or sharing services.  You need to have a common understanding of what events are important to the business, and a common definition surrounding the conditions that define each event. 

For example: let’s say you have a social service case management system running in a state agency responsible for child welfare.  A call comes in to a hotline, and a concerned citizen is calling to report that the child in the next apartment has been crying for hours.  They suspect possible abuse.  Your system needs to assign a task to someone to investigate.  Do you create a case even though you don’t know the name of the child?  If there is no abuse, should it be a case or just an unattached incident report?  If your system doesn’t know the “magic” condition that means “a case is created” then you have no way to share the “NewCase” event.

The obvious question then is how and why to share this event.  Do you have a reporting system that tracks the number of cases assigned to each worker?  Do you have a financial system that tracks case costs?  How about a system that instigates a long-running process to look up information on the suspect’s address, to see if a known felon is known to frequent the location?  Would you share the event with these systems?  There could be a lot of value there.

In a loosely coupled system, you really shouldn’t care what system subscribes to your events.  You should send your event to a broker and let it decide who to send it to.  More importantly, you need a way to insure that a system that is not online at the moment has a way to get the event when it returns to operation.  Perhaps you are using a system of cooperating components to coordinate these messages… or perhaps you have a single point clustered broker.  Either way, you are implementing a publish-subscribe messaging system.  If it is truly loosely coupled, you have a message bus.

The point I want to make is: thes two integration mechanisms have Nothing to do with web services. 

I can’t count the number of times I’ve had to correct folks who talk about Integration only in terms of web services.  Web Services are useful for a third kind of integration: the services bus.  They are NOT the cornerstone of either data or event integration; mechanisms that are centered around data coordination and event brokering, respectively.  While web services can be used as a communication end-point, especially for the messages bus concept, the fundamental technology is not web services or even SOAP.  It’s loosely coupled brokering.

Web services, and the new Indigo framework, are useful for creating a services bus.  A services bus is a mechanism for registering, managing, and serving up a list of services.  If a service has a way to advertise itself, and if an application has a way to find services that match its needs, then a services bus can connect the two, and allow an application (or a user) to consume a service without knowing who wrote it, in what language, or what server its running on.

This is very useful, and in some ways, fundamental to integration.  However, it is only one aspect of integration.  The services bus compliments the message bus and the shared data repository service.  It does nothing to supplant it.  On the contrary, I would posit that a services bus, without shared domain data or a mechanism for retrieving it, is fundamentally crippled. 

So, the next time someone says “Use Web Services for Integration”, think to yourself: “that’s part of the story, but not all.”

After all, a barber shop quartet sounds much better if all four vocalists are in the room.

By Nick Malik

Former CIO and present Strategic Architect, Nick Malik is a Seattle based business and technology advisor with over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

4 thoughts on “Draw the distinction between a message bus and a services bus”

Leave a Reply

Your email address will not be published. Required fields are marked *

ten − 2 =

This site uses Akismet to reduce spam. Learn how your comment data is processed.