Reuse across ESB Systems

Introduction

Nowadays, enterprises are adopting information technology (IT) to automate their business processes and to simplify their operational activities. A typical business process composes discrete business functions provided by multiple applications. An adaptable and flexible integration of these applications is vital to execute the business process efficiently, and enterprise application integration (EAI) middleware is to provide robust solutions for application integration. An Enterprise Service Bus (ESB) has been touted as the next generation EAI middleware (Chappell, 2004). The current ESB market encompasses a wide range of ESB products and customers.

The selection of an ESB product for an enterprise is ascribed chiefly to the business domain and business scale of the enterprise. The customer base of an ESB is heterogeneous and consists of business domains such as e-commerce, healthcare, and government. It can also be classified based on the business scale such as large, medium, and small. Moreover, each customer potentially possesses their own unique business requirements. As a reason, an optimum EAI solution for a particular customer would be an individualized ESB, which is an ESB tailored to solve his or her application integration problems in a scalable and robust manner.

The capability to produce ESB variations without incurring excessive cost and time is of paramount importance for an ESB vendor’s agility. One reason is that it helps a vendor to respond efficiently to ever changing customer requirements. For instance, an existing ESB cannot meet a particular customer’s new software quality requirements, and the ESB architecture should be changed. Another reason is that an ESB already represents a wide range of architectural approaches such as service component architecture, java business integration, etc., and new architectural styles and standards would emerge as time pass. What a vendor requires is to change the architecture of the product with ease. In other words, a vendor needs a potential to produce a new ESB product reusing existing ESB components.

Although the current ESB product space is heterogeneous in terms of architectures, they offer the same set of ESB services such as message routing, message transformation, message and data security, etc. If these ESB services were adaptable for most ESB architectures, then that would allow a vendor to formulate most ESB products from a single ESB service library. This emphasizes the fact that the reusability of an ESB service across the products is critical to develop diverse ESB products. Moreover, as each ESB variation would be for a different market segment, each ESB service’s design should be flexible enough to be configured to support a greater variety of software quality attributes.

The significant commonality among ESB products and the variability in their architectures make it plausible that a systematic reuse across multiple ESB architectures is what required for formulating individualized ESB products and ESB variations cost and time effectively. The reuse approach discussed in chapter Reuse across Multiple Architectures paves the way for achieving it; each ESB service should be developed as a Multi-Architecture Reusable Component and a solution space for an ESB sphere should be the system architecture for reuse. As per the discussion in the aforementioned chapter, the solution space provides a strong context for a well-planned reuse across different systems. Furthermore, the methodology for developing Multi-Architecture Reusable Components can ensure that ESB services are reusable in different ESB architectures with the desired quality attributes.

The objectives of this chapter are to present a platform developed for realizing the development and evolution of different ESB products reusing the same set of ESB service implementations. The platform leveraged the reuse approach presented in chapter Reuse across Multiple Architectures. As the ESB services are reusable across multiple ESB systems, we identified them as the software elements that encapsulate the concerns that crosscut multiple ESB systems. This observation led us to adopt the principles of Aspect-Oriented Programming (AOP) (Kiczales, et al., 1997), which modularizes crosscutting concerns. Aspects capture crosscutting concerns and in turn, we capture ESB services as aspects. Although, in traditional AOP, an aspect encapsulates concerns such as logging, security, etc., in our approach, an aspect can provide any kind of a self-contained functionality. Our aspect weaver can assemble the aspects (ESB services) in accordance with diverse architectural styles, and employs the component-based development. Throughout this chapter, we use “aspect” and “ESB service” synonymously.