Enterprise Service Bus: Five Keys for Taking a Ride

Transcription

1 About this research note: Technology Insight notes describe emerging technologies, tools, or processes as well as analyze the tactical and strategic impact they will have on the enterprise. Enterprise Service Bus: Five Keys for Taking a Ride Publish Date: February 1, 2007 Business integration through Service-Oriented Architecture (SOA) is a major driver for integration technologies. Buyers in large enterprises that are in the market for a robust and scalable integration solution should start looking at Enterprise Service Bus (ESB) technologies.

2 Executive Summary Business agility is the Holy Grail that all enterprises pursue. As a result, technologies that make the integration process smoother and faster are foremost in the minds of all IT executives. The Enterprise Service Bus (ESB) is one such integration technology that is increasingly gaining more attention from buyers. This note provides information on:» The technological makeup of an ESB, and the five basic components that must be present in an ESB solution.» How the ESB has risen to become the business integration solution of choice.» The benefits that ESB provides to the enterprise as an integration solution.» Which types of enterprises should use an ESB.» The potential pitfalls associated with the ESB. ESB holds significant promise for solving business integration problems, and potential buyers must have an unbiased picture of this technology before forming a strategy or making a selection. Technology Insight 2

3 Technology Point Finding a technological solution for implementing business agility invariably highlights the problems that poor data, information, and process integration causes. Over the last 15 years, enterprises addressed these business integration problems by using architectures and paradigms like:» The Common Object Request Broker Architecture (CORBA). An architecture that describes an object model for enabling objects to share their characteristics across multiple enterprise applications to create an integrated application.» (Distributed) Component Object Model (DCOM/COM). A model based on the object-oriented paradigm. The object model was designed and promoted by Microsoft Corporation and defined interfaces so that objects could request services from any server in the network.» Enterprise Java Beans (EJBs). This is a component architecture that a number of large software vendors promoted the foremost were Sun Microsystems and IBM. This architecture allowed developers to build object-oriented, distributed applications that maintained transactional integrity. Enterprises frequently built their own integration solutions using EJBs.» Enterprise Application Integration (EAI). The goal of implementing the EAI paradigm was to enable data sharing and coordinating process execution amongst all the applications in the enterprise. Implementations of these architectures and paradigms had some success although they suffered from a number of shortcomings:» They used proprietary protocols and did not employ widely accepted standards.» They were monolithic and difficult to scale.» They were hard to configure and learn and required very specialized skills to develop and manage solutions.» They suffered performance problems and the promise of scalability was difficult to realize. A Different Road The migration from solutions like CORBA, DCOM, and EAI started as the Internet and its accompanying lightweight protocols became more pervasive. Although Internet-based standards are the initial driver, the growing adoption of Web services and Service-Oriented Architecture (SOA) by enterprises is the major catalyst for the appearance of standards-based integration technologies like ESB. Technology Insight 3

4 Already, over 70% of companies with over $100 million in revenue are using Web services to meet their integration needs. Info-Tech Research Group anticipates that 40% of companies with over one billion in revenue are going to implement SOA to some degree in the next 18 months. As this trend continues, Info-Tech expects that some future incarnation of the ESB will become the integration method of choice. ESB Is Far from Commoditized The uptake of ESB in the IT marketplace is heavily concentrated in enterprise with over $100 million in revenue. There is little indication that vendors are moving down market since most ESB solutions are:» Too complex for smaller enterprises. SMEs typically have few large enterprise applications and face simpler integration issues that can be addressed with point-to-point integration.» Priced beyond the budget of most smaller and mid-sized enterprises. Even the lower-priced ESB solutions cost over $100,000 on average. These two factors place the ESB firmly outside the consideration of smaller enterprises. Decision makers should evaluate their circumstances before pursuing ESB as an integration option. Table 1 presents two basic profiles: one of a company that should delay ESB adoption, and the other of a company that can adopt ESB. Table 1. Profiles for Delaying or Considering an ESB Adoption Delay ESB» No complex enterprise applications. Probably uses Exchange Server Standard Edition and other entry-level applications.» Fewer than 15 servers.» No prior experience with enterprise messaging technologies.» Fewer than 20 IT staff on hand.» Existing staff has little application integration experience. Consider ESB» Over 20 enterprise-grade applications that need integrating.» At least 100 servers.» Prior experience with messaging technologies.» Staff with prior experience in enterprise application integration. Technology Insight 4

5 What It Is & How It Works An ESB is a standards-based digital conduit that facilitates the seamless sharing of data, and the deployment and implementation of business processes, across all the applications in the enterprise. In essence, an ESB is messaging middleware that is built-upon, and uses widely accepted Internetinspired standards to facilitate application, data, and process integration. Figure 1 below depicts an ideal ESB. Unlike CORBA, COM and EAI, an ESB uses mainly Web-based standards like WS-Security, WS- Addressing, and WS-ReliableMessaging to provide security and robust messaging capabilities. A true ESB should also be platform and programming language agnostic and use SOAP-based or other common adapters like JCA and JMS to interface with other applications. Figure 1. Technological Makeup of an ESB Source: Info-Tech Research Group Web Service (SOAP) Web Service (SOAP).NET Application Enterprise Service Bus UDDI Asynchronous Messaging Publish/ Subscribe BPEL Routing Data Transformation Performance Management Fault Management J2EE Application JCA Application J2EE Application Technology Insight 5

6 ESB provides a number of key benefits over earlier paradigms like EAI because it is built on Web standards, and uses XML for messaging. Other differences between ESB and EAI include:» Faster implementation and easier management. ESB is configuration oriented instead of being focused on coding integration adapters and integration rules.» Greater potential for increased scalability because it employs lightweight protocols and standards.» No centralized broker architecture. This reduces bottlenecks and increases its flexibility and ability to scale. Key Considerations It is important that decision makers looking to ESB be able to see beyond the vendor marketing used to augment the benefits of ESB. Table 2 describes the five essential components that form the foundation of an ESB solution, and affect the success of the ESB as a business integration solution. Table 2. Key Components of an Effective ESB Component Architecture This is the most important aspect of the solution. A poorly architected ESB solution will fail to perform or scale effectively and will quickly become a millstone around the enterprise s neck. To get a clear picture of a vendor s architecture, develop use cases based on the enterprise s current and nearterm performance and scalability requirements. Ask vendors to either describe how their solution addresses this use case or, if possible, have the vendor give a demo based on the use case. Consideration Points Potential showstoppers in the architecture include:» The need to deploy monolithic broker stacks at endpoints in the enterprise to facilitate scaling.» Very large servers or server clusters are the only way to boost performance.» The inability to selectively deploy components of the ESB on different servers in the enterprise.» Minimal load balancing capabilities available out-of-the-box. Technology Insight 6

7 Table 2. Key Components of an Effective ESB (continued) Component Services Adapters A broad range of adapters for pervasive applications, databases, and legacy systems should be provided out-of-the-box, or at a very low cost. Additionally, adding new adapters should be trouble-free and require no special training or additional skills. Consideration Points An ESB should provide at a minimum:» Transformation services. These should be GUI-based and provide standard drag-anddrop as well as cut-and-paste functionality.» Intelligent routing services. This is essential to ensuring reliability because if a network route between two applications fails, the ESB must be able to re-route or change its path, and complete the transaction without user intervention.» Communication services. This is the bus in Enterprise Service Bus. The communication service should provide at least four types of messaging: publish/subscribe, store-andforward, synchronous and asynchronous. The ESB should at least have adapters for:» JDBC» LDAP» Oracle Business Suite».NET» SAP» CICS» Flat files like CVS Technology Insight 7

8 Table 2. Key Components of an Effective ESB (continued) Component Distributiveness The ESB should be deployable on any platform in the enterprise. Access to these different deployments should also be platformindependent. That is, services should not have to change their access methods to account for variances in the platform. Manageability Consideration Points An important component of distributiveness is fault management. An ESB must maintain:» High availability and reliability» Intelligent routing» Failover capabilities» Fault management To get the most from their ESB investment, decision makers should ensure that their ESB solution has two characteristics:» It is configuration oriented. The emphasis of the management tool is on configuration instead of coding. If the ESB is codeoriented, then the likelihood of breaking the ESB post-deployment is higher especially if the ESB is highly distributed. A configuration-oriented ESB management tool reduces the risk of incorrect configuration in the production environment.» It has strong monitoring capabilities. System behavior and performance is critical. Ensure that there is adequate reporting and runtime monitoring available to assess the health of the ESB. Technology Insight 8

9 Key Takeaways 1. Standard adherence only goes so far. Simply because ESB is standards-based, it does not mean all vendors solutions are equal. Ensuring that the vendors are implementing Web-based standards in their solutions is only the first step. ESB buyers should probe deeper into the vendor offering and ensure that product architecture and vendor implementation philosophy fit with the enterprise s integration strategy. 2. Do not overlook fault management. Since the ESB is the backbone of the enterprise, a good ESB will fully address fault tolerance, availability and reliability issues. Additionally, SLAs play an important role as a layer of protection to buyers because they can provide recourse in situations where poor performance or system outages occur. 3. Next step: look to vendors that specialize in ESB. The ESB market has at least 25 strong vendors with solid ESB solutions. Interested and qualified buyers should start examining solutions from vendors that have a distinct ESB solution. Buyers new to the market should also avoid monolithic ESB solutions built for only one OS platform. Since an ESB should be platform- and languageagnostic, a single-platform solution can introduce deployment and scalability issues that the uninitiated will have difficulty resolving. Table 3 represents a non-exhaustive list of some vendors with platform-agnostic ESB solutions. Table 3. ESB Solution Vendors Vendor BEA Systems, Inc. Cape Clear Software Product BEA AquaLogic Service Bus Cape Clear ESB Fiorano Software Fiorano ESB 2007 IBM Corporation IONA Technologies Progress Software Software AG WebSphere Enterprise Service Bus Artix ESB Progress Sonic ESB Enterprise Service Integrator Technology Insight 9

10 A preliminary investigation of these solutions will either help buyers develop a business case for adding an ESB to their IT infrastructure or justify delaying their purchase. Bottom Line Business integration through SOA is a major driver for integration technologies. Buyers in large enterprises that are in the market for a robust and scalable integration solution should start looking at ESB technologies. Technology Insight 10