Requirements for an Enterprise Application Integration Tool. Kimmo Röppänen

Transcription

1 Requirements for an Enterprise Application Integration Tool Kimmo Röppänen University of Tampere School of Information Sciences Computer Science M.Sc. thesis Supervisor: Timo Poranen May 2013

2 University of Tampere School of Information Sciences Computer Science Kimmo Röppänen: Requirements for an Enterprise Application Integration Tool M.Sc. thesis, 50 pages May 2013 As companies try to keep up with the competition they often rely on information technology (IT) to make the business work more efficiently and cheaper. As the amount of IT and software increases the companies need to utilize different applications to communicate with each other. Otherwise same data would need to be inserted into each application separately, thus making the business work less efficiently. To help with the communication problem many different kinds of applications have been created. These tools are called Enterprise Application Integration tools. The problem is that the number of tools is very large and finding the most suitable tool can be an overwhelming task. This study presents a set of qualities in software that are important in Enterprise Application Integration tools. As a research method this study adopts a case study of a company trying to find a tool to help integration process with an ERP product. Some recommendations for a suitable tool are given as a conclusion of the case study. The study ends in general conclusions by expanding the conclusions made in the case study to support a more general decision making process. Main conclusion is that there are 9 qualities of an EAI product that should be paid attention to. These qualities are: Stability, Changeability, Security, Performance/Scalability, Connectivity, Management/Monitoring, Message Transformation, Routing and Pricing. Key words and terms: Enterprise Application Integration, EAI, Asynchronous, Messaging, ESB, Enterprise Service Bus, Integration.

3 Contents 1. Introduction Improving efficiency Research questions Enterprise Application Integration File Transfer Shared Database Remote Procedure Invocation Messaging Web Services Point-to-Point Broker Enterprise Service Bus Enterprise Application Integration tools Software Quality Commercial EAI Tools IBM WebSphere Message Broker Mule ESB Enterprise Free Open Source EAI Tools WSO2 ESB Apache ServiceMix Mule ESB Community Enterprise Resource Planning Case Study: Glass & Frame Merit Consulting Finland Jeeves The Customer G&F integration needs Requirements Stability Security Connectivity Performance/Scalability Management/Monitoring Message Transformation Routing Pricing Tool Comparison... 38

4 IBM WebShpere MQ Mule ESB (Enterprise and Community) WSO ServiceMix Recommendation for suitable tool Conclusions References... 45

5 1 1. Introduction In enterprise information technology (IT) companies commonly have multiple applications that need to share data between each other. Whether it is warehouse management system telling order processing if the ordered items are in stock or accounting needing to know from invoicing which bills are sent and which are not. Many times this sharing of information is done in a very inefficient way, for example people sending Excel sheets to each other. So how could we make the process of data sharing more efficient? 1.1. Improving efficiency When companies add new applications into their IT architecture they need to make them communicate with the other existing applications so as the data, and sometimes functionality, can be shared between them. There are multiple ways of doing this and often what is good way for one application might not be possible for another. Since applications have probably been acquired during the complete lifespan of the company, the tools provided for the communication might be very mixed in style and technology. This is where the study of Enterprise Application Integration (EAI) and tools that have been specifically developed with EAI in mind come into the picture. The purpose of Enterprise Application Integration is to make the process of integration simpler and easier by providing the tools for connecting to applications, transforming and routing messages and monitoring the message traffic Research questions Choosing the right EAI tool for a company can be difficult. If it s a small company with needs for very minimum of integrations to other systems then should it just rely on very simple point to point integration or should they prepare to a growing need for integration and acquire some kind of EAI tool? If so, then what is the right tool for their needs? What requirements the tool needs to fulfil? What kind of future integrations they should be prepared for? How much money can the company afford to spend on a single EAI tool? What about Open Source tools? Would those offer everything that is required and how reliable they are? How much more work is needed to configure and maintain the tool? This paper does not answer all of these questions but concentrates on finding the general requirements areas that should be considered when an EAI tool selection process is initiated. Also this paper recommends some suitable EAI tools in the specific case of Merit Consulting Finland.

6 2 In this thesis we look into some of the common Enterprise Application Integration tools and compare them to each other. The comparison is done by creating a case study using a company called Merit Consulting and trying to find the most suitable tool for their use. The findings are then expanded to provide suggestions on what are the things that should be held important when trying to find the correct tool for any company. The method of research was chosen as the author himself is working in Merit Consulting and much of the data needed was already available. Also this method was seen as the most likely to give the best results from which Merit could make their decision. The research could have also been conducted by reviewing the literature about the integration domain but this might not have provided enough information for the specific case of Merit Consulting. On the other hand a more extensive review on literature about integration might have provided a more complete generalization of the requirements for EAI tool selection. Merit Consulting Finland [Merit FI, 2013] is in search for a new EAI tool to ease their job of integration with a new Enterprise Resource Planning (ERP) system they have acquired into their portfolio. This new ERP system does not have very extensive integration tools and so Merit is trying to find an external tool to simplify the integration process. Also the tool might help their customers in other integration tasks in the future. Enterprise Application Integration is discussed more in Chapter 2. Some general software quality issues and the different commercial and open source tools are presented with some depth in Chapter 3. Also a brief introduction to enterprise resource planning systems is provided in this chapter. In Chapter 4 we look into the case study of Merit Consulting and decide what would be a good tool for them. Chapter 5 goes through more general conclusions about how companies should decide what the best solution is for them. Also some limitations of validity to the results are explained in this chapter.

7 3 2. Enterprise Application Integration The term Enterprise Application Integration (EAI) first appeared in the USA around with the publications of articles or research notes by large analyst firms [Manouvrier & Menard, 2010]. According to Manouvrier and Menard [2010] the definition of Enterprise Application Integration is a collection of methods, tools, and services that work together to bring heterogeneous applications into communication, as part of the traditional, distributed or extended enterprise. It is important to notice that not only is data shared by applications but they can also share some of their functionalities with other applications. In the past at a time before EAI was introduced companies had many different applications doing various functions that were required by their business plan. The problem was how to make these applications share their data since the same information could be needed by many applications. At first all the data was shared by people copying the data from application to application. After a while this was seen as too slow and an error prone mechanism for data sharing so companies started connecting different applications to each other. This is called Point-to-Point (PtP) - pattern (Subsection 2.1.6). In Figure 1 is illustrated how the point-to-point architecture looked like. Figure 1: Point-to-Point architecture [Brooks-Bilson, 2007]. As the number of applications increased, the points of integration between different applications also increased. Due to the n-rule (Subsection 2.1.6) each new application added to the infrastructure also introduced multiple new integration points. The more points there were the more difficult it was to manage the enterprise s IT architecture.

8 4 After a while the IT infrastructure with its numerous PtP-integrations became too complex to maintain and another way of integration was needed. This is where EAI applications come into play. EAI applications are tools that enable integration of multiple applications without tightly coupling them together. In Figure 2 is illustrated the place for an EAI tool in the enterprise IT infrastructure. EAI incorporates functionality from disparate applications and leads to cheaper, more functional and manageable IT infrastructures [Themistocleous et al., 2004]. Figure 2: Enterprise Application Integration [Cymatric, 2011]. Integration patterns are tried and tested ways of solving problems that many application developers have faced during software projects involving integrating two applications together. They are not cut and paste-type ready-made solutions to a specific problem but more of a guideline on how some problematic situations can be solved. It's up to the developer to actually choose the correct patterns and implement a specific solution for his/her specific situation. When creating an EAI tool it is good to have a wide general knowledge of different patterns and how they can be used so that it can be taken into account when designing the tool. Of course trying to implement every possible pattern solution to the EAI tool is close to impossible and also impractical. Some integration patterns will always be left out of the EAI tool since they might be impossible to implement with other chosen patterns or might just never be needed. But it is also good to acknowledge what the application is not capable of as it is to acknowledge what it is capable of. Umapathy and Burao [2005] have stated that Enterprise Integration Patterns provide designers integration tactics and strategies in the form of design patterns.

9 File Transfer In file transfer the communication between applications is handled by transforming data in one application into a previously agreed file format, saved and sent to a location from where the other application can pick it up and process the data. Great advantage of file transfer is that it, in most cases, is platform and language independent way of communication so applications don't need to have any extra tools or packages to enable the integration [Hohpe & Woolf, 2005]. Also integration with files is asynchronous so the receiving application doesn't need to know who sent the file, just how the file should be processed. Decoupling applications makes the job of integration much easier since any changes in one application does not affect the other applications as long as the file format stays the same. Another good thing with file transfer is that, as there's actually no direct interface that the applications provide but everything goes through files then it's much harder for malicious software to cause major damage to the applications. As any style of integration, file transfer is not without problems. First, the resource cost of creating/processing a file and transferring it through the network is relatively high. If the applications need to communicate in an extremely high frequency then file transfer might become a bottleneck in the integration. Another issue with this style of communication is that the updates in an application tend to happen infrequently but the file transfer is scheduled to happen only at certain times. So when and how often the files should get sent so that data stays synchronized in both applications? As said earlier the more frequently you transfer the data the more expensive it gets on the computer and network resources [Hohpe & Woolf, 2005]. Luckily this is not as big of an issue with modern powerful computers and fast networks as it was some years ago Shared Database A problem with file sharing is that there will always be moments when the data is not synchronized between applications. For modern businesses this might become a critical problem. What if customer changes his/her address in one application and then makes an order to a salesperson that sets the delivery address from another application? If the information of the change has not yet been updated in this application then the order will end up in wrong address. By sharing a database all integrated applications can be certain that the data is always consistent [Hohpe & Woolf, 2005]. However, it's close to impossible to find two applications that can fully use the same database so what sharing database usually means is that there is an external data storage that both applications are connected to for the purpose of sharing their data.

10 6 As said earlier, one advantage of shared database is that it provides consistent data to all applications by enabling the possibility of real-time updates to the database. Also with this integration style it can be certain that the data is used in the same format everywhere. Many integration problems come from the fact that different systems look at the data in different ways [Hohpe & Woolf, 2005]. Since SQL [SQL, 2013] and relational databases are widely used in software it is quite certain that any application can connect to the database without the need to include a new technology to the mix. Issues with shared database come up when designing a suitable schema that all applications can conform to. This can easily lead to a too complex and difficult schema to work with and can cause some critical applications to separate from the shared database [Hohpe & Woolf, 2005]. Many commercial software packages might also not work at all or might work with limited functionality with any other database schemas than their own making the sharing impossible. Even if unified schema could be found for all applications and they could all use it perfectly, there is the issue of how to manage multiple applications reading and modifying the database frequently? With many applications connecting to database trying to read, insert, and update the data, it can quickly cause deadlocks preventing others from accessing the data. Also if applications are distributed across a wide area network, accessing the database can get too slow. The database could of course be copied to multiple servers so applications could access the database that is closest to them but then there would be need to figure out how to handle updates between these databases Remote Procedure Invocation File transfer and shared database are suitable styles of application integration when only the data of the applications need to be shared. But what if one application would like to finish its processing, but to do this it would need to wait for someone to do some data handling in another application? The application could connect to the other application s database and try to change the data the way it would have been done by the other application. Unfortunately very often when application processes its data, it has a ripple effect around the database affecting multiple different columns. If another application tampers with the database there is no guarantee that the all the affected database columns will be changed accordingly. File transfer would require the receiving application to handle the data. Since file transfer is asynchronous, the processing would be delayed. Also how would the waiting application know when it can proceed? With Remote Procedure Invocation (RMI) (or Remote Procedure Call (RPC)) applications can call each other s exposed functionality and take advantage of direct communication with the application. With RMI the applications are only responsible of the data in their

11 7 own database and communication is synchronized making the responses almost immediate. Figure 3 explains how RMI works. Figure 3: Remote Procedure Invocation. However, RMI makes applications become tightly coupled to each other and a major failure in one application would affect the other application as well making them both fail. Because RMI is very close to the normal procedure calls, it is very simple to understand by most developers but it also means that developers might have difficult time understand the differences in performance and reliability between local procedure calls and Remote Procedure Calls. Failure to understand this difference will easily lead to slow and unreliable system. [Hohpe & Woolf, 2005] Although RMI is mainly thought of as synchronic communication, asynchronous RMI communication is also possible. The calling application could call the remote function from another thread and continue to other work in its main thread. Although this would still require the applications to be tightly coupled since the second thread would still need to stay connected to the remote application and wait for its processing to finish. [Rinneheimo, 2008] 2.4. Messaging File transfer and shared database are good options when you only need to share the data between applications. But file transfer is somewhat heavy on resources and keeping data synchronized is difficult. On the other hand with shared database it is difficult to find a suitable schema for all applications to be able to use it. Also many applications do not work with any other than their own database (DB) schemas. When you need to share functionality Remote Procedure Invocation is a viable solution. With RMI you have the applications tightly coupled to each other making application execution and application development more unreliable. What if you needed to have fast communication between applications sharing data but couldn t couple them together or to any common database schema? Messaging is an asynchronous way for applications to share data between each other without the need for sender to even be aware of the receiving application. It only needs to send a message to a message channel and the channel will make sure the receiving

12 8 application will receive it. Even if the receiver is not online when the message is sent the message channel can queue the messages and wait for the receiver to get online. The messaging allows much more decoupling of applications than file transfer would since the messages can be transformed before giving the message to the receiver. Also it is much faster since messaging does not require the data to be saved to a folder. Since messaging is fast it can also be used to share applications functionality. The invoking application sends a request message to the message channel and the receiver replies with processed data as soon as it has finished with processing the request. Unlike with Remote Procedure Calls, the invoking application can still keep on doing other things while it waits for the reply to arrive. [Hohpe & Woolf, 2005] Figure 4 explains how messaging works. Figure 4: Messaging. Messaging is not without problems. Because of its asynchronous nature, developing such a system is much more complex than simple file transfer or Remote Procedure Invocation. Unlike shared database it does suffer from inconsistent data between systems since handling messages still takes some time Web Services Web Services (WS) is one of the latest technologies introduced to the Enterprise Application Integration tools. Its XML [XML, 2012] based communication over common internet protocols such as HTTP [HTTP, 1999], SMTP [SMTP, 2008], FTP [FTP, 2013] and MIME [MIME, 2013] makes connecting applications working on different platforms, programming languages or behind firewalls much easier [Matjaz et al., 2010]. When an application wishes to make a web service call it first needs to connect to the WS server over internet, then send a request, which is an XML based message (SOAP [SOAP, 2007]) or embedded into the URL [URL, 2005] when using HTTP (REST [REST, 2013]), to the interface which then gets interpreted and the WS

13 9 Server calls the application from which the data or functionality is needed. The application processes the data and returns an answer to the WS server. WS Server will create an XML message of the result and sends it to the requesting application. Web services follow the Point-to-Point pattern where applications must be connected through WS interfaces but it enables the applications to be loosely coupled from each other. Also both synchronic and asynchronous communication is possible with web services. In Figure 5 is illustrated how web service calls work. Figure 5: Web Service. The drawbacks of web services are that the performance of WS calls is much slower than remote procedure calls. Also plain WS does not offer Quality of Service (QoS) [QoS, 1997] features such as security, transactions and other longtime component model features. For these the WS has other additional specifications [Matjaz et al., 2010] Point-to-Point Point-to-Point (PtP) integration is the simplest way of communication between two separate applications. With PtP integration each application is directly connected to all the other applications it needs to communicate with. This also means that there exists a tight coupling between these two applications. This means that both the applications need to be online at the same time for them to work properly. In PtP the integration is quite simple since all the communication happens directly from one application to another. Also the communication is fast as there is no middleware that handles and processes the data before its being received by the other application. The problem with Point-to-Point integration is that although it is good when only a few applications need to be integrated with each other. It will soon start to become too complex when new applications are added to the integration. The more there are applications the more direct connections are needed for the integration. This will soon turn into an integration

14 10 spaghetti [Hohpe & Woolf, 2005]. To fully integrate applications together, the amount of integration points for PtP integration architecture with three applications is three for five applications it's already 10 and with 10 applications it would be 45! This is due to the n-rule which means that for n applications an amount of n(n-1)/2 integration points is required for full integration [Manouvrier & Menard, 2010]. The situation is illustrated with 3 applications and 2 servers and 10 integration points in Figure 6. Figure 6: Point-to-Point pattern Broker Integrating applications using broker style (also called hub and spoke architecture) integration means using a middleware application between all the applications that need to be integrated. The middleware handles the routing and transforming of data for the receiving application. This type of middleware applications are commonly called as integration brokers [Manouvrier & Menard, 2010]. Unlike Point-to-Point architecture where each application has many integration points for each application it needed to integrate. With the broker architecture each application only has one integration point which is connected to the broker. The broker then handles all the message routing and processing before sending the message forward to all the receivers that are interested in the message. This simplifies the integration process greatly when the amount of integrations needed for different applications grow. With broker pattern a single integration point per application is needed. In Figure 7 is illustrated a simple broker architecture

15 11 Figure 7: Broker pattern. There are multiple advantages to broker architecture that makes it an excellent option for EAI. Most implementations of the broker architecture follow the asynchronous communication pattern where connected applications don't need to wait for a response from the receiver but instead can return to doing other work while the broker delivers the messages to correct recipients. The broker architecture also enables loose coupling, of which asynchronous communication is part of, where recipients don't need to be aware of each other or even know whether the other application is currently online. The broker will receive messages from the sending application and route them to the receiving application(s). If one or all of the receivers are unavailable at that time, then it can save the message internally until such time that all the receiving applications have successfully received the message. All this happens without the sending application knowing. Broker architecture also enables a much easier management of integrations since all the configuration is done in a one central location making it easier to modify existing integrations and create new ones. With the broker architecture the problem is that it creates a single point of failure inside the IT infrastructure. If the platform that supports the hub becomes unavailable or overloaded it can potentially generate a single point of failure (SPOF) [Manouvrier & Menard, 2010]. However this problem can be avoided for example by multiple parallel instances of the broker that work together. If one instance would fail for some reason, the network would still be working since other instances would take the place of the failed broker and start handling incoming messages. [Hohpe & Woolf, 2005]

16 Enterprise Service Bus Enterprise service bus (ESB) is the one of the newest architectural patterns introduced to EAI. The main problem in integration it tries to solve is the broker-pattern s single point of failure vulnerability by dividing the burden into multiple separate components. Salil and Swaminathan [2010] define the ESB architecture like this: An ESB is essentially an architecture pattern that provides capabilities including connectivity, communications, message queuing, message routing, message transformation, reliable messaging, protocol transformation and binding, event handling, fault handling, message level security, and so on. It enables loose coupling between service consumers and service providers, and thus enhances the ability to rapidly change and introduce new Business Services into the environment In Figure 8 is an illustration of the architecture of enterprise service bus enabled environment. Figure 8: Enterprise Service Bus [Salil & Swaminathan, 2010]. As illustrated in figure 8 the ESB works in the middle of communicating applications mediating messages from sender to the receiver. It receives messages through its endpoints and wrapping them as service message object. Then it routes the messages through different message processor services, data transformers and protocol transformation using message queues and event handling until it can send the message to the receiver through another message endpoint. The ESB can also log the progress of the message during the different steps of the messages. All this is done in a secure way and providing quality of service so that no message is lost. Although the ESB still relies on a central message bus for delivering messages it divides its functionality to multiple components making the burden of single component

17 13 much smaller. With smaller burden the components are capable of working faster and more reliably. Although being very different compared to each other, There are some core services that most ESBs provide. These are, as defined by Mulesoft [2013e]: Location Transparency: A way of centrally configuring endpoints for messages, so that a consumer application does not require information about a message producer in order to receive messages Transformation: The ability of the ESB to convert messages into a format that is usable by the consumer application. Protocol Conversion: Similar to the transformation requirement, the ESB must be able to accept messages sent in all major protocols, and convert them to the format required by the end consumer. Routing: The ability to determine the appropriate end consumer or consumers based on both pre-configured rules and dynamically created requests. Enhancement: The ability to retrieve missing data in incoming messages, based on the existing message data, and appends it to the message before delivery to its final destination. Monitoring / Administration: The goal of ESB is to make integration a simple task. As such, an ESB must provide an easy method of monitoring the performance of the system, the flow of messages through the ESB architecture, and a simple means of managing the system in order to deliver its proposed value to an infrastructure. Security: ESB security involves two main components - making sure the ESB itself handles messages in a fully secure manner, and negotiating between the security assurance systems used by each of the systems that will be integrated. As any other architectural pattern, the ESB architecture also has its drawbacks. Since the ESB applications architecture is much more complex than for example Point-to- Point -pattern it will require much more initial planning before it can be built and installed. Developers are also required to learn many new concepts that ESB s use.

18 14 3. Enterprise Application Integration tools Enterprise Application Integration tools make integration of multiple applications much easier by decoupling the receiver and sender from each other and handling the delivery of messages to the receivers in the right format. It also simplifies the administration of company s IT architecture since all communication can be handled through a single application instead of each application needing to connect to every other application directly. In this chapter some of the existing EAI tools are examined. First, some basic information about software quality is provided and then the tools are presented. The tools are organized according to whether they are commercial products or open source implementations. Applications chosen implement the Enterprise Service Bus architecture. ESB tools are one of the newest things in Enterprise Application Integration and so many tools are implemented following that pattern. Although, probably no single integration technology can solve all the problems integration produces [Themistocleous et al., 2004], ESB s seem to be the best viable option for being the EAI tool in the case study. Other implementations seem to be missing some crucial parts or are more concentrated to smaller areas of integration. At the end of the chapter some information of enterprise resource planning (ERP) software is provided. Although not an integration tool as such, the ERP software tries to make integration of separate systems obsolete by trying to include all business functionalities inside one application. The presented here are only a small part of all the possible integration tools available. As it would have been impossible to go through all the different integration tools on the market inside the scope of this thesis, the amount of tools to be presented was decided to limit to 4 (IBM WebSphere Message Broker, Mule enterprise and community (counted as one), WSO2 and Apache ServiceMix.). There were many other tools that could have been equally viable options for presenting in this paper. Here are some tools that were considered for this paper but were left out: - Axway B2Bi [Axway, 2013]: Some problems with installation of the tool. Unable to test. - Apache Synapse [Synapse, 2012]: WSO2 is based on this and is more evolved. - OpenESB [OpenESB, 2013]: Future uncertain. - Red Hat JBoss Fuse [Fuse, 2013]: Not enough provided compared to ServiceMix to which it is based on. - JBoss ESB [JBoss, 2013]: Not as evolved as others.

19 15 Each of the chosen tools was installed on a Lenovo W500 laptop for the purpose of research and testing. Also more information about the tool was gathered by researching the internet Software Quality The quality of software is a crucial factor when deciding on acquiring an application. As the criticality of software increases so does the importance of the software s quality. Unreliable software being used in a highly critical position, like monitoring safety of a nuclear plant, will most certainly increase the possibility for disaster. Problem is how can it be known whether an application is of good quality before acquiring it? To verify the quality of software it needs to be defined what are the precise requirements for the software. [Hughes & Cotterell, 2009] The international standard ISO/IEC 9126 for the evaluation of software quality defines a standard approach for evaluating the software quality in a way that removes some well-known human biases from the process. The standard consists of four different parts: quality model, external metrics, internal metrics and quality in use metrics [ISO/IEC 9126, 1991]. The quality model specifies a set of characteristics of quality software. These characteristics are Functionality, Reliability, Usability, Efficiency, Maintainability and Portability. Functionality specifies the functions that fulfill a set of implied or stated needs, Reliability defines the level of performance for certain period that the software is required to be capable of, Usability specify the needed effort and experience by users from using the software, Efficiency defines how effectively can software use the resources that are allocated to it in terms of performance, Maintainability specifies the required effort to maintain and modify the software and Portability defines how easy the software is to transfer from one environment to another. Each of these characteristics is further divided into multiple sub-characteristics. The subcharacteristics are listed below [ISO/IEC 9126, 1991]: Functionality o Suitability o Accuracy o Interoperability o Security o Functionality Compliance Reliability

20 16 o Maturity o Fault Tolerance o Recoverability o Reliability Compliance Usability o Understandability o Learnability o Operability o Attractiveness o Usability Compliance Efficiency o Time Behaviour o Resource Utilisation o Efficiency Compliance Maintainability o Analyzability o Changeability o Stability o Testability o Maintainability Compliance Portability o Adaptability o Installability o Co-Existence o Replaceability o Portability Compliance The internal metrics are specified as those that are always static regardless of any software execution related variables. Internal metrics are mostly relevant when developing software and not in cases when choosing from existing products. The external metrics specify the metrics related to running the software on different setups and platforms. Quality in use metrics defines the metrics that are only applicable in real use situations and not otherwise testable. In ideal situations the internal quality should determine the external quality and quality in use should be determined by the external quality. [ISO/IEC 9126, 1991] The importance of each characteristic and sub-characteristic should be judged for each application separately. Reliability is very important in monitoring nuclear plants as efficiency is important for software working under strict time constraints. For each

21 17 quality there should be an external measurement defined which verifies that the said quality is found in software. The ISO/IEC 9126 specification gives a standard list of quality characteristics but under the characteristics and sub-characteristics are the actual requirements that the software in question should adhere to. [Hughes & Cotterell, 2009] To be able to decide whether a system meets its requirements there should be a way to measure its qualities [Hughes & Cotterell, 2009]. The requirements should be stated in a manner that it is possible to decide from objective measurements whether the software fulfills it. A requirement that cannot be objectively measured can easily become a subject of biased inspection where a person s views can affect the decision of whether the requirement is fulfilled or not. Collecting the requirements for software can be done in many ways. Requirements can be collected doing interviews, doing research on existing similar software implementations built for similar purpose as the target software, collecting information about the business domain that the software is supposed to be working in or making case studies of the ways the software is operated and how the users are be using it. These are but few ways and there are more possible ways of collecting the requirements. As using only one collection method will not be sufficient to locate all the requirements, it is useful to include more than one collection method Commercial EAI Tools In this part of the chapter we look into some of the commercial EAI tools available. The tools were chosen by doing research using the internet and choosing the Enterprise Application Integration applications that were found to be probably the most suitable IBM WebSphere Message Broker IBM WebSphere Message Broker is an enterprise service bus (ESB) providing connectivity and universal data transformation for service-oriented architecture (SOA) [SOA, 2013] and non-soa environments. [IBM, 2011] IBM WebSphere Message Broker works on top of WebSphere MQ, a Message Oriented Middleware (MOM) [Curry, 2004] implementation also from IBM, and requires it to be installed on the same machine. The WebSphere MQ is included in the licence fee and incurs no extra costs. IBM WebSphere Message Broker also requires the Message Broker toolkit to be installed which is a graphical user interface for managing the message broker and its messaging flows.

22 18 The tool is capable of dynamically mediating interaction between services and routing and transforming message data. It supports Microsoft.NET enviroments including CLR [CLR, 2013]. It can be scaled to multiple servers. It has a browser based diagnostic tool and the data-mapper tool is based on open source and built on top of Eclipse. Figure 9 illustrates the Eclipse based data mapper tool. IBM WebSphere Message Broker supports multiple protocols including WebSphere MQ, JMS 1.1 [JMS, 2002], HTTP and HTTPS, Web Services (SOAP and REST), File and TCP/IP [TCP/IP, 2013]. It also supports multiple data formats including binary formats (C and COBOL), XML, industry standards (including SWIFT [SWIFT, 2013] and EDI [EDI, 2013]) and user can create his/her own custom formats. [IBM, 2011] Figure 9: IBM WebSphere Message Broker. The IBM WebSphere Message Broker seems quite monolithic with its almost 2Gb combined size installation packages compared to just few hundred megabytes in most of the other tools that were looked into. Although IBM s own feature list advertises the WebSphere being easy to use and install this was not the experience when trying to install and use it. The graphical user interface of the toolkit seemed quite simple but trying to use it proved to be not so simple. For some reason the examples did not work although everything was supposed to be configured correctly. This is something that is not expected from a commercial tool. The initial impression of complexity can easily turn users away from the product just because they can t even get the examples working.

23 Mule ESB Enterprise Mule ESB is an integration tool developed by MuleSoft [2010]. It was first released in 2003 and was one of the first open source ESB s in the market [Cope, 2010]. Current stable version is There are two versions of Mule ESB, the Mule enterprise and the Mule community. Mule enterprise is a commercial product with more features to provide better reliability, security, performance, control and message transformations. It includes a graphical web based management console. A customer that buys the enterprise license also gets better access to different support channels from MuleSoft. The community version of Mule ESB has fewer features and lacks the graphical management console but is completely free to use. In this subsection we concentrate on the enterprise version of Mule ESB. In the Free Open Source part of this chapter we will briefly look into the Mule Community. Nevertheless large part of what is told about Mule ESB enterprise will be true about the community version also. Mule ESB has an open source core, uses open standards and is based on Java programming language. It s lightweight, flexible and scalable both vertically and horizontally. Horizontal scaling means adding more nodes (For example servers) to the system and vertical scaling is done by adding more resources to the existing node(s) (for example increasing memory or CPUs to the server). It s also promised to be capable of 100% uptime and is vendor-neutral so different vendor implementations of app engines can be used to run it. [MuleSoft, 2013b] Mule ESB has a wide range of connectors and transports (CXF [CFX, 2013], , FTP, Hibernate, HTTP/S, JMS, LDAP [LDAP, 2006], RMI, SOAP, TCP, etc.). It has a strong support for Web Services for multiple frameworks and protocols (Axis [Axis, 2010], Atom [Atom, 2005], CXF,.NET Web Services, REST, etc.). Message transformations can be done in multiple different mechanisms (XSLT [XSLT, 1999], XQuery [XQuery, 2010], Smooks [Smooks, 2012], Oakland (not open source) [Oakland, 2013]). [Cope, 2010] The Mule ESB has, roughly said, two parts, the connectors\transports that handle the delivering of messages from the sender to the receiver and the integration services that handle the routing, transaction management, security, transformation, transportation management and message brokering. Figure 10 illustrates the components of Mule ESB.

24 20 Figure 10: Mule ESB [MuleSoft, 2013c]. In addition to the Mule ESB, Mulesoft offers an Eclipse [Eclipse, 2013] based graphical design environment called MuleStudio for creating different integration applications which can then be easily deployed to the Mule ESB. One of the most important features of the MuleStudio is the DataMapper. With it the developer has much more detailed access to the data inside the messages and can process it in any way he/she likes. The DataMapper feature is only available in enterprise version of Mule ESB. Figure 11 shows the graphical user interface of MuleStudio. Figure 11: Mule Studio [Burton, 2012].

25 21 Although the MuleStudio seems quite simple and easy to use, the initial experience of the tool made a very different impression. Many of the components seemed to have lots of different configurable boxes without much information on what should be put into them. Although wide configuration options were seen as a good thing it was thought that the implementation left much to hope for. Luckily the documentation and tutorials for MuleStudio are quite good so with some patience it was relatively simple to get comfortable with the tool. Still it must be said that there is some learning curve to getting familiar with all the components and using them efficiently. The DataMapper tool seemed to be quite an efficient tool for message transformations and the scripting language used for it seemed easy to learn. Another component only available to the enterprise version is the web based management console. The management console provides a complete view to all instances of Mule ESB installed across the enterprise. From the management console a developer can view servers, clusters, applications, flows, alerts and errors; manage applications, deployments and server resources and perform administrative tasks [MuleSoft, 2013d]. Basically everything required to run and configure the Mule ESB should be manageable from the management console. Figure 12 illustrates the graphical user interface of the management console. Figure 12: Mule Enterprise GUI [MuleSoft, 2013d]. As with the MuleStudio, the Management console also gave an initial impression of having lots of different ways to manage Mule ESB but also was a bit confusing to use and there certainly is a learning curve to using the Management console. A nice feature is the Flow Analyser that allows users to analyse different flows separately providing better visibility to the problematic flow and what is happening inside it.

26 Free Open Source EAI Tools In this part of the chapter we look into some of the free open source EAI tools available. These tools were chosen using the same methods as were used in the commercial tools WSO2 ESB WSO2 is a company started in 2005 and released their first Enterprise Service Bus in 2007 and current version of the ESB is It s built on Apache Synapse ESB. It uses ActiveMQ for message queuing and Axis2 for web services. It is concentrated on using web services as message processing components. WSO2 ESB [WSO2, 2013] is licensed under the Apache 2.0 License. There is no commercial version and it is 100% open source. [Cope, 2010] WSO2 supports multiple common transport protocols (HTTP, HTTPS, FTP, JMS, etc.). For message transformation it uses java framework called Smooks [Smooks, 2012]. The web management console includes an interface for creating transformations but it does not remove the need for coding [Cope, 2010]. WSO2 has a surprisingly good looking and extensive web based management console which is not so common on open source tools. Inside the management console is basically included everything from message routing and transformation to server management and configuration. Figure 13 shows the homepage of the web console. Figure 13: WSO2 web console. Configuring the WSO2 Enterprise Service Bus is somewhat difficult and requires some studying and work just to get the samples working. Luckily the community around WSO2 ESB seems quite active and there is extensive documentation on how to get started.

27 Apache ServiceMix Apache ServiceMix is a free open source implementation of an Enterprise Service Bus licensed under Apache license v2. ServiceMix project started in 2005 and is now in version It can be run as a standalone or in an application server. ServiceMix supports multiple application server vendors from which the user can freely choose one. Initially ServiceMix was based on JBI [JSR208, 2005] but has since migrated to OSGi [OSGi, 2013] though it still supports JBI. There is a commercial Enterprise Service Bus implementation called Fuse ESB from RedHat that is heavily based on ServiceMix and can be thought of as the commercial version of ServiceMix. [Cope, 2010] ServiceMix introduces a modular approach to Service Oriented Architecture (SOA). It uses Apache ActiveMQ [ActiveMQ, 2013] for messaging, Apache Camel [Camel, 2013] for Enterprise Integration Patterns and routing messages and Apache CXF for web service connections. It has an OSGi-based runtime by Apache Karaf [Karaf, 2013] and a complete WS-BPEL [WS-BPEL, 2007] engine with Apache ODE [ODE, 2013]. All the components are loosely coupled using Apache ServiceMix NMR. [ServiceMix, 2013] Figure 14 shows the overview of the architecture of ServiceMix. Figure 14: ServiceMix overview [ServiceMix, 2013]. ServiceMix s Apache Karaf based management interface is on command console but a web based management console is also available for install as a feature. The web console is quite basic and the command console is actually also embedded into the web

28 24 console to provide all the same functionality inside the web console as is in the command console. There is no actual data mapping tool for creating message transformations with ServiceMix but it supports multiple ways of creating your own transformations including XSLT, JSR223 standard based scripting engines [JSR223, 2006], Web Services and JAXB [JSR222, 2009]. In the latest version the JBI modules are still supported but not recommended and CXF is recommended instead. ServiceMix also supports a wide range of connectors including File, FTP, HTTP, JMS, and SOAP [Cope, 2010] Mule ESB Community Mule ESB Community Edition is a stripped down version of the commercial version missing some important features such as enterprise hardening with back ported bug fixes and the DataMapper-tool. Also the management console has been left out and monitoring of the community version requires using java s JMX-framework [JMX, 2006]. The JMX management tool does not support all the features provided in the web-based management tool. These features include operational dashboard, deployment manager, integrated application repository, ESB remote control, task scheduler and the REST API for management. The community version also lacks some special proprietary connectors like SAP and IBM WebSphere connectors. As the community version does not have the Mule Enterprise Security package which is included in the commercial version it is not as secure. Performance and reliability of the community version has also been greatly reduced by omitting the high availability and caching features. Also there is less options for performance management than what is included in the commercial version. The commercial version includes features like SLA [Bouman et al., 1999] alerts, monitoring framework integration, runtime performance manager and key performance indicator tracking. Also many analysis tools have been omitted that would help problem resolution and the support is only limited to the community forums. Lack of so many features basically makes the community mule somewhat a crippled one. Unfortunately, as listed above, all the most important features are inside the commercial version and it seems that MuleSoft is pushing the commercial version to customers quite heavily so the open source version is left missing on some important features. Deciding to use this tool would require commitment on taking the commercial route. [Cope, 2010]

29 Enterprise Resource Planning ERP (Enterprise Resource Planning) system has a major role in a company, its purpose is to integrate the company s different facets of operation into a one big information system and provide up-to-date information in real time to all interested parties [Patrick, 2002]. According to Malhotraa & Temponi [2010] ERP is an enabler for technological integration that has evolved from basic Material Requirement Systems (MRP, MRPII) to sophisticated and multimillion-dollar systems that aim to link databases and applications in a friendly manner. One of the ideas behind ERP systems is that it could answer to all business needs a company might require. This way all the business logic would be inside one system making the integration of multiple applications obsolete. Most of the time this, of course, is not the case in real life. Normally the ERP systems take quite a large and central part of the company s IT architecture and most of the business information is stored inside its data storages. ERP s are quite expensive to acquire and require much training for the staff of the company. The company might be even required to change some of its procedures and processes along the way to better utilize the ERP system and its procedures. Many times, due to the extent of the system, the job of implementation and maintenance are outsourced to an expert organization. For these reasons the ERP system is also normally the last thing to be changed inside the company. [Rinneheimo, 2008] Often when a company purchases its first ERP system there is already a working IT architecture inside the company built using multiple different applications. Sometimes the old applications might be better than what the ERP system can provide as a replacement. If the company decides that they should be able to use some of the old applications even when the ERP system is in use, those tools need to be integrated with the ERP. Most companies also don t work without any connection to the outside world but have connections to outsider organizations that they must communicate with, sending billing information to customers for example. Whether it s integrating an inhouse application or communicating with and outsider organization, integration from the ERP can happen mainly in two ways: Either the ERP itself has a built in system that provides connections to other systems or some kind of external integration system is required. The external integration can range from running stored procedures that extract data from database into files to using a professional EAI tool that handles all the integration needs between the ERP and other parties. Figure 15 shows some of the different business sections that can be included inside an ERP.

30 26 Figure 15: ERP business sections [Acsonnet, 2013].