Business users who tend to follow the enterprise service bus model to implement SOA for tool integrations are yet to optimize their effort and investment. It is imperative that businesses are completely aware of why, when, and how to select the right ESB solution to build an integrated ALM ecosystem, and they should know what to ask an integration vendor in order to get the most out of the deal. This article takes them through the critical steps of choosing an appropriate ESB solution.
Using middleware to support distributed applications started gaining popularity back in the 1980s as a way to link newer applications to older legacy systems. Many vendors and open source groups have worked to support middleware functionalities, including application integrations.
Some organizations have used the term enterprise service bus (ESB) technology to describe this approach and its specifications. Unfortunately, there is no global standard or typical protocol for implementing an enterprise service bus. Different vendors use the term in different contexts corresponding to the ESB functions their products support. Moreover, software vendors often leave the general IT population with misconceptions followed by some obvious questions: why, where, when, and how to use ESB to develop software in an integrated application lifecycle management scenario.
The myths associated with implementing an ESB infrastructure to build an enterprise service-oriented architecture, or SOA, are also many. One cannot just repackage existing middleware and messaging solutions and sell that as an ESB product. ESB is not simply an abstract pattern that can be overlaid on middleware and application server infrastructure; it is a coherent piece of infrastructure or backbone that builds service-oriented architecture.
So, are we using ESB capabilities in a correct way from the perspective of application lifecycle management (ALM)? If not, then why, and what do we need to do to address this problem?
Just writing a few web services does not mean the adoption of SOA. Also, ESB should not be treated as simply as a box in the center with a few applications hanging off it. There are a lot of things to understand about the integration points and protocols being used, data formats, available IT infrastructure, repository system, and security.
Building a successful integrated tool ecosystem has much to do with how well we adhere to the ESB principles and how efficiently we use real-time metrics between tools in improving software delivery. It is important that stakeholders are able to identify, execute, and monitor processes spanning across different tools and can generate a consolidated report on the real-time activities. The bottom line is that an ESB solution must provide a better way of managing software projects and help stakeholders take preventive actions throughout the development lifecycle.
Since the enterprise service bus became the foundation for SOA deployments in 2005, the technology had passed through various transitional phases and experienced several integration-related challenges. In fact, there is a lot of cry among vendors for and against an ESB-based integration model, which confuses customers as to what to opt for and why.
In this article we will find answers to the following questions:
- What drives the ESB today more than ever before?
- What does the ESB signify to enterprises from a tool integration perspective?
Facts That Drive the ESB Today More Than Ever Before
Application integration makes more sense for midsize and large companies today than ever before. According to Ovum’s integration middleware global market forecast model, the spend on integration middleware is estimated to “grow at a compound annual growth rate (CAGR) of 9.1% between 2012 and 2018, reaching $17.9bn by the end of 2018.”
The commercial use of the ESB is no more limited to years old message-oriented middleware than when it started. This bus concept has become the face of the latest integration technology and the foundation of SOA deployments.
Gartner’s Predicts 2013: Application Integration report shows more interesting data:
- By 2016, midsize to large companies will spend 33 percent more on application integrations than in 2013.
- By 2016, the integration of data on mobile devices will represent 20 percent of integration spending.
- By 2017, more than two-thirds of all new integration flows will extend outside the enterprise firewall.
- By 2018, more than 50 percent of the cost of implementing 90 percent of new large systems will be spent on integration.
These optimistic figures drive ALM vendors to expand their integration offerings. Moreover, the adoption of cloud-based infrastructure and increased software as a service offerings have persuaded companies to invest more on integrating applications rather than developing them in house. It is time for CIOs, IT managers, and architects to focus on integration competency center implementation.
The Significance of Using the ESB Model in Tool Integration
The enterprise service bus enables enterprises to realize the value of SOA and reduces the complexity in integrating applications. It not only increases connectivity and adds flexibility to gain better control of the applications, but also provides a user with codeless configuration facility.
Applications need to talk to each other independently without having knowledge of other systems. Achieving scalability and agility in message transformation is also a must for an organization. This requires adoption of a bus-like architecture that can decouple applications and provide a simple, pluggable system. ESB presents a single, simple and consistent interface that helps in continuous integration.
ESB architecture complements all the core principles of integration, such as orchestration, transformation, transportation, mediation, and event handling. It facilitates complex event processing, provides support for synchronous and asynchronous transport protocols, validates messages, governs business rules, and provides interoperability between applications irrespective of operating systems and programming languages used in each of the tools. The main function of an ESB as software is to eliminate the point of contact to and from each application and take part in a seamless message exchange between applications, thus enabling communication across the tool set, stakeholders, and locations.
ESB architecture uses a messaging server such as JMS or AMQP to decouple applications. The data that passes through the bus is mainly in XML format. There is an adapter or connector that sits between the application and the ESB and manages data transformation between the two. The adapter uses an API to bridge the connection between the application and the bus. Other than collecting, storing, maintaining, and queuing information between applications, the adapter also performs a range of other activities such as security maintenance, data monitoring, and error handling.
These are just some of the issues that impact the successful integration of middleware services. The enterprise service bus is a powerful methodology that vendors should embrace. In future articles we will review some of the challenges that impact the successful integration of middleware services, including the enterprise service bus.
