Graphics & Design

Information Logistics Service Router

Faculty or Science and Technology Department of Computer Science Information Logistics Service Router An ESB for integrating enterprise services Marius Lundblad INF-3981 Master thesis in Computer Science,
of 60
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Faculty or Science and Technology Department of Computer Science Information Logistics Service Router An ESB for integrating enterprise services Marius Lundblad INF-3981 Master thesis in Computer Science, June 2015 ii Table of Contents Abstract xi Acknowledgements xiii 1 Introduction Importance Problem Definition Contributions Limitations Outline Background and Related work Pre-Project Existing knowledge/systems Usage Related work Building Scalable Enterprise Service bus B2B Contracts using BizTalk Versioned Web Services Summary Enterprise Service Bus Systems Service-Oriented Architecture (SOA) Enterprise Service Bus (ESB) iii 3.3 ESB vs. BPE ESB building platforms Mule ESB IBM WebSphere MQ BizTalk Server Azure Microservices/BizTalk Services Summary Design Early Design Thoughts Information Logistics Service Router Design Schema design Orchestration Design Mule design Schema design Message Flow design esecretary Web Service Summary Implementation Early implementation Information Logistics Service Router Mule ESB prototype Portability Summary Evaluation Testing Environment Results Performance BizTalk vs. Mule ESB Platform usability iv 6.4 Extendability Deployment Uncompleted work Improvements for BizTalk application Performance Security Integrated esecretary module Service Lookup On-premises vs. Cloud Problem Definition Solved Conclusion Concluding remarks Future Work v vi List of Figures 1.1 Illustration of the envisioned system Figure showing the traditional BPE architecture Figure showing the traditional ESB architecture Figure showing the combination of BPE and ESB architecture Figure showing the Mule ESB architecture Figure showing the BizTalk organization of elements Figure showing the architecture and components of BizTalk ESB Toolkit Figure showing the overview of Azure Microservices Figure showing the design utilizing the SQL adapter of the Enterprise Service Bus Figure showing the initial design of the Enterprise Service Bus Figure showing the schema design Figure illustrating the decide shape Figure showing esecretary XML document Figure illustrating an example service message Figure illustrating an example service response Screenshot of a service request performed in SOAPUI Figure showing the current design of the Service bus with Orchestration Screenshots showing the schema editor in Mule ESB Figure showing the service flow of the Mule ESB implementation Figure showing results after optimizations vii 6.2 Figure showing results from Mule ESB implementation Screenshot of the Service schema structure viii List of Tables 3.1 Table showing the pricing comparison between the different ESB building platforms Table showing the response times (in Hour:Minutes:Seconds) for the Information Logistics Service Router implementation Table showing the response times (in Hour:Minutes:Seconds) of the Mule ESB implementation ix x ABSTRACT Jupiter System Partner is currently working on a product idea called Information Logistics. The product focuses on collecting information via modules from several services in an enterprise system. The product will be based upon financial systems which can be customized via modules. Specifically, the product will be based upon their existing system called esecretary which extends the economy system with a document storage where invoices, packaging documents and signatures can be stored. One of the limitations addressed by the managers at Jupiter is the lack of an integration platform where the modules and implementation can be gathered. Part of the Information Logistics product idea is a web interface where customers which have issued invoices can check the progress of their orders. This is currently not possible as the esecretary system is deployed in company domains. The managers have therefore posted a request for a platform which will publish functionality for checking order progress and other modules. This thesis addresses the request and presents Information Logistics Service Router, an Enterprise Service Bus (ESB) which integrates the esecretary web service and other services and applications into a common access point. Information Logistics Service Router is a BizTalk application which serves as a basis for the Information Logistics product idea. The system integrates applications and services into a common access point using the BizTalk platform. The evaluation of Information Logistics Service Router shows that the system implements a simple, but useful integration basis for Information Logistics compared to other integration platforms such as Mule ESB and IBM WebSphere MQ. xi xii Acknowledgements I wish to express my sincere thanks to CEO at Jupiter System Partner, Kolbjørn Engeseth, for providing me with all the necessary facilities for the research in this thesis. I extend my sincere thanks to my main supervisor, Anders Andersen, for the continuous encouragement, support, and invaluable guidance and expertise during the work on this master thesis. I am also grateful to my coworker at Jupiter System Partner, Tony Liafjell. I am extremely thankful and indebted to him for sharing expertise, and sincere and valuable guidance and encouragement to me. I take this opportunity to express gratitude to my fellow students at the faculty of Computer science and my friends for their support. I also thank my family for the invaluable encouragement, support and attention. Last I want to place on record, my sense of gratitude to one and all, who directly or indirectly, have lent their hand or supported me in this venture. xiii xiv Chapter 1 Introduction Web services are defined by the World Wide Web Consortium (W3C) 1 as software systems designed to communicate over a network in a machine-to-machine interaction. In 2003 the editor in chief for InfoWorld, Eric Knorr, predicted that 2004 would be the year of web services as a low-cost alternative to proprietary middleware [16]. In 2008, Eyhab Al-Masri and Qusay H. Mahmoud published a paper [19] which conducted a thorough analytical investigation on the plurality of web service interfaces that exist on the web today. The article concluded that a search engine was needed to collect information of the existing web service interfaces, since web service access points were no longer a scarce resource. In 2010, Abdelghani Benharref, Mohamed Adel Serhani and Salah Bouktif presented a paper [20] which proposed a managerial community of web services that is able to monitor and certify the quality of web services in other communities. The article states that the number of web services will be growing exponentially for the next 5 years. Therefore the need for categorizing and classifying web services, might be crucial for the success of an underlying Service-Oriented Architecture (SOA). The article states that web service providers are trying to maximize their revenues by creating appropriate communities. In 2014, Shakab Mokarizadeh, Peep Küngas and Mihhail Matskin presented a paper [21] which proposes a plausible solution for finding missing web services and measuring the added-value of the introduced services. The article was conducted due to the increasing presence and adoption of web services, and how it has promoted the significance of management of new service development for service developing sectors. As stated by [19, 20, 21], companies are, and have been, working toward getting more data and business logic available for other services and applications over the network. This is normally achieved by creating some form of web service which implements functionality to collect and operate on data supplied by the customer. As described by these 1 (collected ) 1 articles, the number of web service access point are increasing drastically. The increase demands a unified way to offer web services, and prevent recurring business logic and data. A web service contains an interface described in a machine-processable format, most often in the form of a Web Service Description Language (WSDL) 2. Other systems interact with web services as instructed in the WSDL-file. The interaction between the two parts usually takes form of Simple Object Access Protocol (SOAP) 3 messages. The interaction is conveyed using HTTP 4 where operations are called using XML 5 serialization or in combination with other web standards. The rapid growth and usage of web services have made it troublesome for developers to manage existing interactions between applications and services. Many companies deploy several services residing at their each individual end-point which can cause confusion when creating an interaction with an application. Also services have a tendency to create redundant service functionality residing at several service locations. In this thesis we look into the possibility of lowering the complexity of several service end-points and management of existing applications by creating an Enterprise Service Bus (ESB) 6. An ESB is an integration architecture which we will go closer into in chapter 3. By utilizing an ESB, the service end-point will always stay the same and access management to web services can be handled more intuitive. In this paper we will explore the possibility to create such a system in BizTalk Server , which is a tool for integrating services and applications. Through the paper we will propose a prototype implementation of how an ESB can be implemented in a company setting. The paper will also look at other platforms such as Mule ESB and IBM WebSphere MQ to see how these perform compared to BizTalk. The platforms mentioned here will be explained and presented in chapter 3. This thesis has been conducted in cooperation with Jupiter System Partner which has requested such a system, and has therefore been part of the evaluation of the prototype implementation. Jupiter System Partner is a company located in Tromsø, started by Kolbjørn Engeseth and Odd Halvard Bjørnstad which focuses on developing enterprise solutions for both the private and public sector. Through 12 years they have developed solutions such as esecretary, UtleieSentral and Jupiter Innsyn. The implemented system is built on Jupiter System Partner s requirements, and will be part of a project started in cooperation with Innovasjon Norge (collected ) 3 (collected ) 4 (collected ) 5 (collected ) 6 (collected ) 7 (collected ) 8 (collected 08/04/15) 2 1.1 Importance Web services are used in almost every application that is developed these days. As described in [19, 20, 21], and stated by Anne Thomas Manes [17], almost every software vendor is building support for web services into its platforms, languages, and tools. Due to recent development in how applications are being developed [18], programmers and companies choose to implement web services which provide crucial application data instead of integrating the service into a static application. This model of developing was introduced as part of the Service-Oriented Architecture (SOA) 9, which is an architecture that enforces reusability and decoupling of applications and services. These architectures forwards the use of decoupled applications, where the business logic is mostly placed in web services which have no direct connection to the application itself. Due to this new way of developing applications, companies are publishing and selling access to web services. The reasoning being to forward the progress and keep ahead of the competition in providing crucial data, as described by JBoss Inc s article [18]. The constant increase of web services demands a unified way to provide several web services for clients. This has given birth to software models such as ESB and Remote Method Invocation (RMI) 10. Several enterprises does not make use of these models since they have been trivial to implement and usually requires several web services to be beneficial for the enterprise. However software platforms such as BizTalk Server 2013, Mule ESB and IBM Websphere MQ have made it easier to create ESB systems. But the question of how web services can be efficiently integrated into such a model, and if it is beneficial for companies remains. 1.2 Problem Definition Jupiter System Partner is currently working on a product idea called Information Logistics. The product will collect information via modules from several services in an enterprise system. The product will be based upon Microsoft Dynamics NAV 11, an enterprise resource planning solution (ERP), which can be customized via modules. Jupiter has already developed some prototypes of these modules. Amongst these, a module for online/offline functionality, and a possible underlying implementation for information handling. Figure 1.1 is an illustration of the system. 9 architecture_soa_definition.html (collected ) 10 (collected ) 11 (collected ) 3 Fig. 1.1: Illustration of the envisioned system. The user platform for Information Logistics will be PC/Mac, tablets and mobile phones. Information from modules will be stored in a secure cloud storage. The information modules will be; Order management, Quality management, Storage management, chat, information search, and more. The project will focus on integration of several web services, where the end system is an integration platform where web services can be invoked from a singular access point. This master thesis will look into products, such as Mule ESB, BizTalk Server 2013, and IBM WebSphere MQ, which integrate several services to a singular access point. The products will be analyzed against each other and evaluated to determine the best approach for the system. The project will focus on enterprises which constantly expands its web service portfolio. For these enterprises the benefit of having an integration platform which can be efficiently expanded is very important, since it will allow reuse of existing functionality. It is also useful since the web services need only be managed inside the integration platform, in cases where the individual web services are being moved or upgraded to new versions. The project will integrate web services such as esecretary, especially developed for Kraemer Maritime AS 12, which is part of the Information Logistics product idea. The resulting product will integrate web services running at customers, into a singular access point using BizTalk Server However, integrating web services into a singular access 12 (collected ) 4 point can be time consuming and tedious. This thesis will therefore look at how this process can be streamlined. This has lead to the following problem definition: How can services be efficiently integrated in an Enterprise Service Bus (ESB)? The author wanted to look into this problem since creating a system which integrates web services can seem time consuming. The author wants to point out that services in this case points to web services. By looking at this problem, one would get a better overview of implementation and effort needed for creating a service bus. The problem would also show how an implemented service bus could be extended with several web services in a short timeframe. This problem definition leads to the project of creating a system which allows integration of several web services into an ESB. The ESB would be implemented using BizTalk Server 2013, due to existing experience in Jupiter System Partner. The building platform was also chosen due to demand for developers with BizTalk experience in the authors home town. The resulting system will integrate the esecretary web service implemented by Jupiter System Partner, and a ConversionRate web service 13 which provides conversion rates between two currencies. The services will be integrated into a singular access point where the message specification and functionality will be provided. The resulting system will provide a basis for the Information Logistics product developed by Jupiter System Partner. 1.3 Contributions The contributions made by this thesis are: An integration platform for web services. A system which publishes integrated web services to a singular access point. A presentation of different ESB building platforms. Evaluation of different approaches to integrating web services. 13 (collected ) 5 1.4 Limitations In the work of this project, some areas are not taken into account. In the development of the system there has been no focus on the security aspect of the system. The author recognizes this as an important part of the system, but due to time constraints have not been able to implement this into the system. The system does not implement any user interface, but rather acts purely as a backend system for providing web service functionality. The end system will act as a basis for the Information Logistics product, and can be extended to provide a web interface for consumers. 1.5 Outline The organization of the remainder of this thesis is as follows: Chapter 2 : Presents the background for starting this project, and work related to this thesis. Chapter 3 : Describes the ESB, SOA and BPE terms, and presents BizTalk Server 2013, IBM WebSphere MQ, and Mule ESB. Chapter 4 : Presents the design of Information Logistics Service Router as well as an experimental design in Mule ESB. Chapter 5 : Presents the implementation details of the Information Logistics Service Router system. Chapter 6 : Evaluates and discusses the Information Logistics Service Router system. Chapter 7 : Concludes this thesis and presents future work. 6 Chapter 2 Background and Related work This chapter will discuss the earlier work and background to this thesis. It will elaborate on knowledge which has been achieved prior to and during the execution of this thesis. The chapter will end by a discussion of work which can be related to this thesis. The work explained in this chapter acted as a basis for proceeding with the project, and decided what future work would have to be done to develop the Information Logistics product idea. 2.1 Pre-Project This project is a continuation of a pre-project which was executed prior to this thesis. The pre-project looked at how data could be integrated into a common workspace or storage. The project looked into esecretary 1 developed by Jupiter System Partner, which is a module for enterprise resource planning (ERP) solutions, such as Microsoft Dynamics NAV. The module makes spreading the secretary s information and overview over the organization easier. It is made to create a better workflow, remove obstacles and give a better overview. The project looked into esecretary and tried to find a suitable method to merge several companies storage from esecretary into a common storage space. The project looked in depth at cloud architectures which resulted in a simple prototype where data could be stored in a single storage space. The data from companies would be identified with different company identifiers. The project concluded that the problem could be solved with either of the cloud architectures, and that choosing the correct cloud architecture would depend on the developing company s Service-Level Agreement (SLA) (collected ) 2 (collected ) 7 This thesis is continuing the work from the pre-project. But rather than focusing on how the data can be integrated into a common storage space, it is looking closer into how this storage can be accessed from a common access point. The project is driven by the expected demand for applications and services utilizing integration solutions rather than point-to-point connections. 2.2 Existing knowledge/systems The author of this thesis is and have now been employed at Jupiter System Partner for one year. The author approached the managers at Jupiter, in search for a problem which could be researched as a thesis subject. This resulted first in the pre-project and later in this thesis. The assignment was to
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks