Characterising Enterprise Application Integration Solutions as Discrete-Event Systems

Introduction

Frequently the current business processes in an enterprise has to be improved or new ones have to be created to support the enterprise’s daily activities. All over the years, enterprises have been purchasing off-the-shelf software as well as developing custom applications aiming at giving computational support to implement and run their business processes. As a result it is not difficult to find an enterprise which has a software ecosystem composed of applications that were built using different technologies, data models, operating systems, and most often were not designed to exchange data and share functionalities. It is common that, from an administrative point of view, such software ecosystems are viewed as homogeneous systems, and are expected to support the enterprises’ business processes by using current data and functionality without requiring too much investment. Enterprise Application Integration (EAI) provides methodologies and tools to design and implement integration solutions. The goal of an integration solution is to keep a number of applications’ data in synchrony or to develop new functionality on top of them, so that applications do not have to be changed and are not disturbed by the integration solution (Hohpe & Woolf, 2003).

Amongst the state-of-the-art integration technologies available for enterprises to design and implement integration solutions, there are Camel (Ibsen & Anstey, 2010), Spring Integration (Fisher, Partner, Bogoevici, & Fuld, 2010), Mule (Dossot & D’Emic, 2009), and Guaraná (Frantz & Corchuelo, 2012). These technologies provide a domain-specific language that enables the design of conceptual models for integration solutions. Such languages follow the Pipes and Filters architectural style and provide support for using integration patterns (Hohpe & Woolf, 2003). In the Pipes and Filters style, a larger process is divided into a number of smaller and independent services (Filters), which are usually desynchronised by channels (Pipes). The integration patterns document a set of well-known services that are directly related to integration tasks.

The analysis of enterprise application integration solutions to predict their behaviour and find possible performance bottleneck is an important activity that contributes to increasing the quality of the delivered solutions. It is not enough to design a conceptual model for an integration solution, but it is also essential to analyse its behaviour under different workloads and minimise performance bottlenecks. Most often, the approach adopted by software engineers requires the construction of the integration solution, the execution of the actual integration solution, and the collection of data from this execution. This is a costly, risky, and time-consuming approach. The construction of integration solutions is expensive because it demands a good command on an integration technology to map the conceptual model into executable code. The execution involves the setup of a controlled environment in which the integration solution can be deployed, the generation and injection of input data into the integration solution, and the emulation of critical running scenarios. Any faults in the constructed solution may cause the execution to fail and negatively affect the analysis. The collection of data requires the insertion of extra code into the constructed integration solution and the configuration of the runtime system of the adopted integration technology that enables monitoring and collecting. A new approach that enables the analysis of the behaviour and discovering possible performance bottlenecks still in the design phase, taking as input the conceptual models of application integration solutions, would help to reduce cost, risk, and time spent.