Enterprise Service Bus is the latest generation of integration platforms. Based on standards such as XML, SOAP, WSDL and HTTP, ESB products promise lower costs and easier deployment than their predecessors. But, can they keep their promise?
First, disruptive technologies that significantly change the cost/performance curve are typically less fully featured than the technology they are disrupting. This is by no means intended to be disparaging to ESB products, just noting that disruptive technologies pursue different goals and user benefits and forgo the complexities of their predecessors. The net of this is: ESB platforms will not fully replace proprietary middleware but rather be broadly deployed in situations where the cost/benefit ratio did not justify projects with the older more products that were more expensive to purchase, maintain and deploy.
What are the business processes that will benefit from ESBs? Secondary or tertiary business process will. While customer billing and payroll in large enterprises will likely to continue to use proprietary middleware, important processes that are less central to daily operations such as customer acquisition and employee benefits management will become candidates for increased automation though integration using ESB based technologies.
In short, the economics of the ESB will broaden the scope automation through application integration. Where a company may have had 10s or 100s of integration projects in the past it may now face 1000s. Centralized integration centers will not be able to scale, integration will have to emerge under a federation model using guidelines such as those in SOA. Application owners will have to take direct responsibility for exposing their application to the service bus and consumers of those computing resources will have to assume responsibility for self-managing their consumption.
This trend toward decentralized integration will require new tools and techniques that older centralized projects didn’t need. To identify what new techniques will be needed, let’s start by looking at all the factors that are needed to successfully develop a business process that spans two or more computers.
· Exchange – moving the data between systems
· Understanding – eliminating differences in how data is captured, represented and to be processed so that it can be understood
· Motivation – assuring both parties are incented to make the process work
· Trust – conformance to security process, policies and technologies and the assessment of risk
· Comprehension – the sum of meanings and corresponding implications
· Action – behaviors to achieve a business goal
In the past, most of these factors were accounted for in human-to-human based interaction. Centralized “integration centers” or application managers dictated how data was to be represented, security and trust were easier to manage because of the small number of projects and project budgets that commonly exceeded $100,000 brought with it sufficient attention to resolve any remaining obstacles.
With the ESB and integration projects that will span many different organizations, these factors will need to be address in a more formal way. With formality comes the ability to automate and standardize.
· Discovering where specific data is and how to access it migrates from asking a centralized team to querying a central registry.
· Security formalizes away from badges and budget review to electronic credentials and biometric recognition.
· Comprehension moves from experienced humans making judgments to composite applications that monitor and manage using data from a wide variety of sources.
This world of web services, ESBs and SOAs has also reinvigorated semantics, the study of meaning. Semantics provides formalism for understanding data and its relationship to behavior. Semantic formalisms include data and process modeling, syntax, schemas, ontologies, vocabularies, relationship models, classification, constraint and logic systems.
Which formalism to use has been the center of much debate. While all of these formalisms are important, they are not all well suited to the needs of developing integrated business applications at a large scale. For this we need to consider several operational factors. Which formalism is best suited to development and management in a large, decentralized group? Which is cost effective and easy to understand?
At Contivo, we have found that the most effective approach to understanding the intent of data exchanged between systems is to use vocabularies to assist the developer in designing how to reconcile differences. While this approach is not 100% automated, it is sufficiently robust and cost effective to handle today’s integration scenarios with the broadest scope: large B2B hubs, corporate integration centers and large EAI projects. This gives us confidence that the vocabulary based approach will be best suited to large scale deployments using ESB, web services to create composite applications, SOA and grids.
Comments? Email dmh at mhxml.com