An enterprise service-oriented architecture is typically done with a messaging infrastructure called an Enterprise Service Bus (ESB). An ESB is a bus which delivers messages from service requesters to service providers. Since it sits between the service requesters and providers, it is not appropriate to use any of the existing capacity planning methodologies for servers, such as modeling, to estimate the capacity of an ESB. There are programs that run on an ESB called mediation modules. Their functionalities vary and depend on how people use the ESB. This creates difficulties for capacity planning and performance evaluation. This article proposes a capacity planning methodology and performance evaluation techniques for ESBs, to be used in the early stages of the system development life cycle. The authors actually run the ESB on a real machine while providing a pseudo-environment around it. In order to simplify setting up the environment we provide ultra-light service requestors and service providers for the ESB under test. They show that the proposed mock environment can be set up with practical hardware resources available at the time of hardware resource assessment. Our experimental results showed that the testing results with our mock environment correspond well with the results in the real environment.
TopIntroduction
An enterprise service bus (ESB) is part of an infrastructure, a messaging bus based on Web Service standards (Leymann, 2005; Luo, Goldshlager, & Zhang, 2005; Weerawarana, Curbera, Leymann, Storey, & Ferguson, 2005). It is a platform for Web Service intermediaries [5], and fills a core infrastructural role in a service-oriented architecture (SOA), which is a collection of services communicating with each other Alonso & Casati, 2005; Patrick, 2005). The first middleware providing ESB functionality was introduced in 2004. One of the unique features of an ESB is the use of component programs called mediation modules. These are programs that run on an ESB. There are various kinds, depending on how the ESB is used. Even though the technical concept of an ESB is not completely new, the increased adoption of SOA in industry raises new engineering challenges for research. Performance estimation of an ESB is one such challenge.
Predicting the performance of an ESB is different from predictions for traditional application servers, for which many studies have been done (Avritzer & Weyuker, 2004; Avritzer, Kondek, Liu, & Weyuker, 2002; Litoiu, 2004; Mos & Murphy, 2002). This is because an ESB plays not just a server role but also plays a client role for multiple service providers. That also means that the methods used for a J2EE server’s performance evaluation (Cecchet, Marguerite, & Zwaenepoel, 2002) aren’t suitable for an ESB. The mediation functionalities also cause some differences in how ESB performance is evaluated compared to evaluating simple intermediaries like TCP/IP network routers. Nevertheless, performance estimation of the ESB in the capacity planning phase, which happens at a very early stage in the project lifecycle, is critical to a successful project. If the capacity of an ESB used for a system is overestimated, we might need significant changes in the architecture, a large effort for system performance tuning during development or deployment, and/or extra funding for additional hardware. If the capacity is underestimated, we might overestimate costs or seek unneeded compromises from the system stakeholders.
The goal of the work presented in this article is to provide a practical solution for IT architects assessing the capacity of an ESB. Though many researchers have addressed this issue through model-based approaches (Balsamo, Marco, Inverardi,& Simeoni, 2004Litoiu, Krishnamurthy, & Rolia, 2002), they often require elemental performance measurements and sophisticated modeling of the entire system, which is usually not feasible for complex systems. In an ESB, modeling involves intermediate components called mediation modules that provide functions such as routing and protocol conversion, and configurations can vary for each system. This complexity makes it difficult to estimate the performance of an ESB with a model-based approach.
In this article, we propose a capacity testing methodology for ESBs during the phase of capacity planning, which is conducted very early in a project’s lifetime. Our approach is to allow performance testing of an ESB by using a lightweight experimental environment. This enables testing of the ESB with an actual hardware equivalent to that used in the production environment, while greatly reducing the hardware resources required to set up the testing environment. With the proposed technique, designers can evaluate the ESB capacity with a small hardware environment consisting of Web Service requesters and providers without having the server-class systems for the testing environment in the early stage of the system development project. In contrast to most capacity planning techniques, the results of this capacity testing can reveal the actual maximum capacity of the ESB server on the specific platform.
For our technique, we designed and implemented a novel framework for a lightweight Web Service provider and a lightweight Web Service client. In the framework, the lightweight service provider is implemented based on our mock environment technologies, while the lightweight Web Service client is implemented based on a common HTTP load generator. The framework can avoid the large processing overhead of Web Service handling and reduce the hardware resources required for constructing an experimental environment, which means that it allows us to measure the potential capacity of an ESB accurately with inexpensive hardware.