Guest Commentary
Enterprise Service Bus (ESB): Lasting concept or latest buzzword?
by Nicolas Farges, Head of R&D, TechMetrix
A new term has appeared in the field of application integration: the "Enterprise Service Bus" (ESB). This term was used by the Gartner Group to define a new type of application integration middleware: "An Enterprise Service Bus (ESB) is a new architecture that exploits Web services, messaging middleware, intelligent routing, and transformation. ESBs act as a lightweight, ubiquitous integration backbone through which software services and application components flow." (Source: Roy Schulte, Gartner)
This definition is very similar to that of "Enterprise Application Integration" (EAI) tools, apart from three significant terms, which we shall come back to later: Web services, ubiquitous and lightweight.
Enterprises are only just starting to measure the impact of application integration on their information systems and organization. The more advanced companies have recently started deploying EAI solutions or have launched pilot projects. Given the speed with which trends seem to succeed each other, it is not unreasonable for us to wonder whether the ESB concept is actually a legitimate one.
The emergence of the ESB Concept is closely linked with the lasting trends that have been slowly transforming the EAI market for the last few years: standardization of infrastructures with J2EE, Microsoft .NET and Web services, and the redistribution of roles of integration software component vendors.
In this article, we shall look at the motivations behind ESBs, and their likely impact on the middleware and software market.
What's wrong with traditional EAI solutions?
An EAI solution is designed to integrate applications according to the principle of loose coupling, whereby applications can, to an extent, evolve and operate independent
To continue reading for free, register below or login
To read more you must become a member of SearchSOA.com
ly from one another. The stack of middleware usually provided by EAI solutions includes:
Vendors of EAI solutions have, through their R&D investments and, more often, through external acquisitions, managed to feature the full abovementioned middleware stack in their solution. Functional richness is therefore not a concern for enterprises investing in this type of solution.
However, EAI solutions are criticized for certain shortcomings:
[IMAGE]
Fig 1: Moving EAI solutions from the hub & spoke topology to the bus topology
[IMAGE]
Fig 2: Break in QoS between EAI solutions from different vendors
In addition to the problems related purely to EAI solutions and the other standards in force, difficulties may arise in relation to the design and implementation of this type of architecture. For example:
For these reasons, "35% of EAI projects are not completed in accordance with deadlines and budgets", estimates Forrester Research, and the term "EAI" is has found itself the blacklist of buzzwords that IT managers no longer want to hear. Many EAI solution vendors have also banned this term, to replace it with others such as "application integration", "integration architecture", etc.
Whatever the term or the technology used, the problem of application integration remains a difficult, long-haul affair. Strictly EAI-related difficulties can nonetheless be resolved by vendors and standardization bodies. The market does seem to be moving in this direction, giving rise to a new time of software: ESBs.
ESBs, or the quest for the universal integration middleware
Before we look at the market solutions that claim to offer ESBs, let us sketch out the ESB in its fullest form (able to meet both the internal and external integration problems of enterprises).
The diagram below shows an ESB. It does not invent any new architecture concepts, but instead uses standard Web services interfaces between its components, thus differentiating it from a proprietary EAI solution:
[IMAGE]
Fig 3 : The complete ESB middleware
This holy grail of the "universal middleware" has been sought many times - just think back to DCE or CORBA, which encountered many problems. The concept of ESB is another attempt to achieve this ideal, and there are three reasons why ESB has a good chance of meeting its goal, at least to an extent:
So, the ESB architecture is inventing nothing new, offering something as standard that has been offered for years by proprietary middleware. The success of the ESB will therefore depend on the market's ability to deliver reliable Web service standards, and truly interoperable implementations.
The stack of Web service standards is still a house of cards...
It is usual to associate Web services with the SOAP/WSDL/UDDI standards trio, together with HTTP. This trio only resolves basic application integration problems, i.e. the notions of service contract, stateless RPC and directory. Below is a list of the architecture services required by ESBs, as well as the solid standards proposed by the main standardization bodies and vendors:
[TABLE]This overview is incomplete, it being difficult to give a complete list of standards as they are issued by a number of different standardization bodies (the most active being the W3C and OASIS) or vendor consortiums (IBM, Microsoft, BEA, Sun, etc). Many standards meet head-on in competition, and a number of them are likely never to be implemented. All these standards are playing for huge stakes, as they are the key to the adoption of Web services, and therefore to the rise in sales of compatible middleware.
The standardization bodies therefore see very ambiguous relationships playing out between software vendors. A consensus is required in order to establish standards that will send software sales skyrocketing, and every vendor is trying to use their powers of persuasion in order to get a head start when it comes to implementation. The battle will be even tougher given that standardization will no doubt be followed by the appearance of open-source solutions, to the great advantage of customers and service companies.
Still missing from the Web services implementations on the market are the vital standards covering the guarantee of asynchronous message delivery and security. The HTTPs standard does not provide high enough security for Web services and the RPC connotation of SOAP/HTTP contradicts the notion of loose coupling on which Web services are based. The Reliable Messaging and Web service Security standards (in particular, based on XML Digital Signature and XML Encryption from the W3C) from the OASIS are excellent candidates to address these issues, and are likely to enable Web services to take off. While it is true that the other standards are important, they do remain secondary in terms of requirements.
The propagation of standards will inevitably be followed by a streamlining of middleware vendors, and a redistribution of suppliers' roles...
The impact of ESBs on the integration middleware market and on software vendors
The current vision of an integration solution whose components come from the same middleware vendor has now been overturned. Standards, which are more or less mature, are converging towards a "compound" view of the ESB, which will be an assembly of software components from specialized vendors:
We are already seeing vendors of EAI solutions leaving the connector market and moving towards application servers. The asynchronous messaging system is also becoming a commodity component. Examples of such positions are multiple: WebMethods is opening its system to J2EE JBoss and is clearly putting its money on Web services, SeeBeyond is offering a new version of its architecture, called ICAN, completely based on JCA and compatible with J2EE application servers and the latest Web service standards, Vitria is integrating the Tomcat server, Sonic Software has based its integration solution on Web services, XSL, JMS and JCA. Some newcomers such as SonicXQ or Kenamea are already embryonic forms of ESB. We should point out that, on the whole, application and asynchronous messaging system vendors are very well placed to address the ESB market. BEA's solution is a good example of a unified middleware stack handling different integration problems. The limits between application servers, message-oriented middleware and EAI solutions will therefore fade.
As well as the creation of connectors, the software market is also undergoing a gradual, profound transformation. The strategic turnaround by Siebel illustrates this trend particularly well. Instead of deploying its business components in a confined technical environment, Siebel will extract the business processes from its software package in order to deploy them in standard form in EAI and Web services environments, so as to resolve the integration problems traditionally encountered in CRM projects. To do this, Siebel is using partner integration solutions, particularly those of WebMethods and SeeBeyond. SAP is also following a similar approach with its xApps, although it is less clear on the technical architecture that will be used. JD Edward and Peoplesoft have not escaped the tidal wave, and are respectively offering EPI (Extended Process Integration) and AppConnect. The gradual disappearance of barriers between applications will bring some vendors to reconsider their functional scope. A new hand looks likely to be dealt...
The vision of an ESB that we describe in this article will take some time to become reality, as experience has shown that this type of architecture takes a long time to standardize. The future of EAI solutions, in their current guise, is far from certain. ESB is therefore a lasting movement which falls into the architecture standardization logic that began with J2EE and .NET, and is continuing with Web services.
Nonetheless, neither ESBs nor EAI can reduce the crucial analysis phases that must come prior to any integration project, in order to study the urbanization of the information system. Initially, and if feasible, it would therefore be reasonable to embark on these analysis phases, without investing too much in over-extensive integration solutions, and to start building the foundations that will one day hold an ESB.
Copyright 2003. Originally published by TechMetrix Research, reprinted with permission. TechMetrix is a technology-oriented analyst firm focused on e-business application development needs. TechMetrix is also backed by its parent company, a European global system integrator - SQLI - with more than 800 developers in the field.
For more information:
