We recently covered Goal of SOA is managing complexity. As the enteprises move towards a service oriented architecture,The role of an integration broker in a service-oriented world becomes a fascinating area to discuss. Without integration, enterprise computing often takes the form of islands of automation, where the value of individual systems is not maximised because they are working in partial or full isolation. However if integration is carried out without following a structured EAI approach, many point-to-point connections grow up across an organisation. Dependencies are added on an ad-hoc basis, resulting in a tangled unmaintainable mess, commonly referred to as spaghetti.Current thinking is that the best approach to EAI is to use a message bus to connect numerous separate systems together. Other approaches have been explored, connecting at the database level or at the user-interface level, however the message bus approach has generally been adopted as the strategic winner. Individual applications can publish messages to the bus, and also subscribe to receive certain messages from the bus.
As in any evolving area, we are seeing the emergence of three set of players beginning to offer solutions in this space viz. Pureplay startups, EAI(Integration Broker) vendors and of late ERP heavyweights. Barry Briggs offers an interesting perspective about relationship between integration brokers and SOA with good examples.Excerpts with edits and my comments added:
Here's the conundrum (or at least thought experiment): today, integration servers largely serve the purpose of normalizing,a wide variety of heterogeneous API's, protocols, data formats, security models, transaction models, and so on. Now, let's posit a world in which all legacy protocols and formats melt away in favor of SOAP, XML, and WS-*. The transition over some period of time is inevitable is our assumption. So, if all these messy issues are going away, then does the integration broker go with them? Put a different way: if every business application in your computing ecosystem exposes rich, standards-compliant services, then does the traditional hub-and-spoke model of integration still have value? Yes! It unquestionably does, and for many reasons:
- First, think about semantic normalization. Big words, but they have lots and lots of implications. If you want to build an enterprise application, you need a common vocabulary: what's your definition of a "customer," a "SKU," an "order" and so on. Every enterprise app has its own set of proprietary, idiosyncratic definitions. In the old days of silo'd applications this was fine; but today, we want a "whole is greater than the sum of the parts" effect. Bringing this distributed information together to form a consistent and rich vocabulary, tailored for the enterprise in question (you call them "customers," I call them "households") is a key value prop for integration brokers.
- Second, how do we link business applications together in an orderly, structured, and manageable way in order to build the meta-applications (or composite applications) of the future? We need a refined notion of sequencing of services, of process, and we need a hosting environment where those processes can run, can be monitored, can be tracked.
In the bad old days it was easy to do quick and dirty integration applications by writing a little VB here, a little Java there, and getting the data from one system to another in a point to point way. But as we learned, this didn't scale; it was completely unmanageable. Today we recognize we want a server that provides the process execution environment. Some ERP vendors see SOA as a way to make external applications appear part of their fabric, thus further entrenching them. That is to say, you take external apps, and using services you make them appear to be part of the ERP system you already have. This might appear to be precisely the opposite of SOA's stated goal of abstracting underlying system functionality, but for these ERP vendors, that objective has little appeal. On the other hand are the horizontal vendors whose goal is provide a programming environment for next-generation distributed business applications. The goal here is not so much to extend an existing deployment, but rather to realize all the goals of SOA: to provide a semantically rich, powerful foundation for composite business applications. The horizontal approach gives maximum flexibility to business owners by positing a fabric of services generated top-down by business requirements, and not bottom-up by rationalizing and deeply entrenching existing systems. I agree with Barry in toto - traditional EAI players and brokers shall have a significant role to play in the SOA world.
|
