This article is more than 1 year old
One bus or two?
Making sense of the SOA story
Comment This question came up during Progress's recent EMEA (Europe, Middle East, Africa) user conference: at one point, a vendor representative showed a slide showing Sonic as an ESB (enterprise service bus) and DataXtend as a comparable bus operating at the data level. From subsequent discussions it emerged that whether these should be regarded as one bus or two has been the subject of much internal debate.
This isn't the first time that this discussion has come up. Towards the end of last year I was commissioned by IBM to write a white paper on information as a service and in this paper I posited the use of a second bus (which I suggested should be called an Information Service Bus or ISB) for data level integration. IBM wasn't too sure about this and we eventually compromised by saying that the ISB is logically distinct from the ESB, but not physically distinct.
Progress has reached the same position. It is much easier to visually explain the concept of information services working alongside application (web) services to provide a complete SOA (service-oriented architecture) environment if you use two buses rather than one. At one level (and working downwards) you have web services, legacy applications and so forth connected through the ESB to more generalised web services while those web services connect via the ISB to data services, which themselves are used to extract information from relevant data sources (data or content).
Now, both buses use common communications channels, which is the argument in favour of having a single bus. However, the sort of adapters you use to connect to data sources are very different from those used in a typical ESB environment. Further, some implementations may be data-centric while others will be application-centric and, moreover, you can implement one without the other. In particular, an ISB effectively subsumes the role of data integration and, potentially, master data management, which you might easily want to implement separately from either SOA or an ESB.
So, I firmly believe that, at least from a logical perspective, it makes more sense to think of a complete SOA environment as consisting of twin buses as opposed to one. However, that's not quite the end of the story.
If you think about it, you have services to services integration, data to data integration and services to data integration (or vice versa) and each of these has its own characteristics, so you might actually think of three buses. However, three buses in a single diagram might be considered overkill though you could depict an ‘S’ shaped bus if you wanted to, implying three uses of a single bus. Of course, you could use a sideways ‘U’ for the same purpose with a dual bus structure but again I think these approaches are overly complex—the whole point about SOA is simplification—if you can't depict it in a simple fashion you are defeating the object of the exercise.
Of course, we all know that the problem with buses is that you wait for ages for one and then several come along at once. In this particular case I think that two buses is just right: one is too few and three is too many.
Copyright © 2006, IT-Analysis.com