What are measurement fees from IIIT Bangalore

Analysis and design of a service-oriented architecture for the flexible mapping of business processes in the energy industry

Transcript

1 Master's thesis in the Application Architectures program Analysis and design of a service-oriented architecture for the flexible mapping of business processes in the energy industry Master's thesis for obtaining the Master of Science degree in the Application Architectures program at the Faculty of Business Informatics at Furtwangen University, presented by Stefan Becke Supervisor: External supervisor Prof. Dr. Bernardin Denzel Dipl.-Wi.-Ing. Klaus Zabel Submitted on:

2

3 Affidavit I hereby declare in lieu of an oath that I wrote this thesis independently and without unauthorized outside help. The sources used are cited in full. Hamburg, the Stefan Becke

4 Legal information SAP / R3 and all other SAP AG products mentioned in this work are trademarks of SAP Deutschland AG. Java and all Java trademarks are trademarks of Sun Microsystems Inc. All other company, product and service names may be trademarks of their respective owners.

5 Abstract III Abstract Master Thesis Analysis and design of a service-oriented architecture for the flexible mapping of business processes in the energy industry Stefan Becke European and national legal requirements result in a deregulation and globalization of the energy markets as well as an increasing decentralization of power generation and a further liberalization of the metering system. The long-term stable framework conditions in the energy supply have therefore been in motion for several years and are currently changing fundamentally. Accordingly, energy supply companies (EVU) are faced with ever increasing and dynamic competition and must adapt flexibly and promptly to changing framework conditions and continuously establish new, innovative business processes. The concept of a service-oriented architecture (SOA) promises to improve the information technology of a company, e.g. of an EVU, to adapt flexibly to changed business processes. This thesis analyzes the potential benefits of an SOA through the encapsulation of functionalities in mutually independent services for an EVU. The focus here is on application integration using an Enterprise Service Bus (ESB) as the integration infrastructure and the orchestration of services into a business process. In the course of the design and implementation, a prototype is realized based on the business requirements of an exemplary business process in the energy industry and its technological feasibility is shown. The results of this work show that an SOA is suitable for a power supply company, whereby known concepts such as message-oriented middleware should be used. Open standards enable manufacturer and platform-independent integration. However, it should be noted that the implementation of an SOA requires a methodical, systematic approach.

6 Table of Contents IV Table of Contents Abstract ... III Table of Contents ... IV List of Figures ... VI List of Tables ... IX List of Abbreviations ... X 1 Introduction Problem and aim of the thesis Structure and procedure Introduction to the energy industry Energy industry in Germany Challenges of an energy supply company Requirements to the IT architecture Basics of Enterprise Application Integration Motivation for Enterprise Application Integration Integration levels EAI architecture EAI solutions Service-oriented architectures Basics of services Classification of services Service identification Implementation of service-oriented architectures Asynchronous communication Transaction security Orchestration of business processes Transactions and error handling in WS-BPEL Language extensions of WS- BPEL ... 52

7 Table of contents V 4.5 Infrastructure ESB architecture Java business integration Prototype design of a SOA analysis Business process Quotation calculation for electricity Design business process Quotation calculation for electricity Services process User interfaces Application and system architecture Prototype implementation of an SOA integration and technology platform Services Process orchestration User interfaces Assessment Service-oriented application integration for a power supply company Integration and Technology Platform - Sun openesb Summary and Outlook Bibliography Sources Appendix A: Service descriptions Appendix B: Database design Appendix C: Interface descriptions Appendix D: System configuration Appendix E: WS-BPEL quotation calculation for electricity Appendix F: JBI container quotation calculation for electricity Appendix G: CD for master thesis

8 List of Figures VI List of Figures Figure 1: Competitive sub-markets in the energy industry ... 5 Figure 2: Development opportunities for utility companies. 79

9 List of Figures VII Figure 25: Sequence Diagram - JMS Message Queue Figure 26: Layout UI; Entry of offer calculation version Figure 27: UI layout; Overview / selection of offer calculation version Figure 28: Design of the application integration Figure 29: Distribution diagram Figure 30: Web service bean of the web service LsyasPremiseService.101

10 List of Figures VIII Figure 47: Assignment of Actions and Web Service Operations Figure 48: JAX-WS Client QuotationCostingProcessAction Figure 49: NetBeans openesb JBI Manager

11 List of Tables IX List of Tables Table 1: Forms and Effects of Unbundling ... 8 Table 2: Challenges for an EVU and IT requirements Table 3: Overview of the backend functionalities for the business process 71 Table 4: Overview of process steps and services Table 5: Parameters UI, acquisition of offer calculation version Table 6: UI parameters, overview / selection of offer calculation version ... 83

12 List of Abbreviations X List of Abbreviations 2PC AVB BAPI BC BPD BPELJ BPEL4People BPML BPMN BTP CORBA CRM or DCOM i.e. EAI EDM EJB EnWG ERP ESB et al. EVU if necessary GIS HPFC Ed. HT HTML Two-Phase Commit General Conditions of Supply Business Application Program Interface Binding Components Business Process Diagram BPEL for Java WS-BPEL Extension for People Business Process Modeling Language Business Process Modeling Notation Business Transaction Protocol Common Object Request Broker Architecture Customer Relationship Management with regard to or Distributed Component Object Model, i.e. Enterprise Application Integration Energy Data Management Enterprise Java Bean Energy Industry Act Enterprise Resource Planning Enterprise Service Bus et altera Energy supply companies, if applicable, Geographical Information System Hourly Price Forward Curve Publisher High tariff HyperText Markup Language

13 List of Abbreviations XI HTTP HyperText Transfer Protocol IDL Interface Definition Language i.d.r. Usually JBI Java Business Integration JSP JavaServer Pages IT Information Technology JCo Java Connector JCP Java Community Process JDBC Java Database Connectivity JMS Java Message Service JMX Java Management extensions JPA Java Persistence API JPQL Java Persistence Query Language MDB Message-Driven-Bean MOM Message-oriented Middleware MTOM Message Transmission Optimization Mechanism MVC Model-View-Controller NLT Network Control Systems NMR Normalized Message Router NT Low Tariff o the above OMG Object Management Group ORB Object Request Broker RDA Remote Data Access RFC Remote Function Call RPC Remote Procedure Call RMI Remote Method Invocation see page SE Service Engine SLA Service Level Agreements SOA Service-oriented architecture so-called so-called (s)

14 List of Abbreviations XII SQL Structured Query Language et al. including UDDI Universal Description, Discovery & Integration UI User Interface WS-AT WS-Atomic-Transaction WS-BPEL Web Service - Business Process Execution Language WS-CAF WS-Composite Application Framework WSDL Web Service Description Language WS-HT Web Service - Human Task WS-I Web Service Interoperability Organization WS-TX WS-Transaction XML Extensible Markup Language ZB for example

15 Introduction 1 1 Introduction The long-term stable framework conditions in the energy supply have been in motion for several years and are currently changing fundamentally. European and national legal requirements, such as the Energy Industry Act (EnWG), cause a deregulation and globalization of the energy markets, an increasing decentralization of electricity generation and a further liberalization of the metering system. Energy supply companies (EVU) are thus faced with ever increasing and dynamic competition. In order to be able to survive on the market in the long term, EVUs have to adapt flexibly and promptly to changing framework conditions and continuously establish new, innovative business processes and optimally design existing business processes. Information systems play a central role in the implementation of business processes. 1 The information technology (IT) of an EVU is thus faced with the challenge of supporting new, innovative business processes in ever shorter cycles and reacting flexibly to changes in the corporate structure. A current topic in the field of information technology are so-called service-oriented architectures (SOA). The technology-independent architecture concept of an SOA should enable a more flexible mapping of business processes in information technology than the traditional, monolithic applications and systems of a heterogeneous IT landscape. In addition, SOA should generate cost savings and reduce development risk. In the case of new or changed business processes, loosely coupled services should be exchanged and reassembled without great technical effort in order to make IT systems easier and more flexible. 1 Cf. [Allw05], p. 42.

16 Introduction 2 and thereby supporting the reuse of existing components (services) Problem and goal of the work From the point of view of information technology, the mapping of flexible, quickly adaptable business processes and new functionalities is often a problem of integrating existing and new applications Middleware technologies such as RDA, RPC, ORB or MOM can be used. These traditional IT architectures of companies, including the EVU, have to be reconsidered and redesigned in many ways due to ever increasing and more dynamic competition. For this reason, a concept for a service-oriented architecture in the energy industry is designed and evaluated within the scope of this work, which should serve as a basis for future developments. Varying technical requirements and a heterogeneity of the applications to be integrated are particular challenges for the conception of a corresponding service-oriented architecture. The utility potential of a service-oriented architecture through the encapsulation of functionalities in mutually independent services has to be analyzed for an EVU. For this purpose, an example of a business process in the energy industry is to be analyzed and implemented as a prototype. To map the business process, the economically required functionalities must be identified and made available with the help of services. For this purpose, a service design is to be developed in order to create the required services from the point of view of the business process and the already existing backend functionalities. The expected gain in knowledge of this work lies in the statement and evaluation of the applicability of the architectural concept of an SOA for application integration in the energy industry. Specifically, it is worked out to what extent the implementation of an SOA meets the increased requirements for mapping flexible, rapidly changing business processes in information technology. 2 cf. [RLPB07], p. 8.

17 Introduction 3 and what a prototype implementation can look like. The realization should be flexible and expandable to the effect that services can be added or exchanged without major manual adjustments or implementation effort. The security of SOA by means of SAML, XACML and the WS- * security standards, which provide possibilities to technically implement security concepts, is not dealt with in this thesis, as this would exceed the scope of this thesis. 1.2 Structure and procedure At the beginning of this thesis, the energy industry and its challenges are dealt with in general, in order to define the corresponding requirements for the IT architecture. Then the motivation for application integration (Enterprise Application Integration; EAI), different integration levels, corresponding architectures and possible implementations using classic middleware solutions are presented. After a general understanding of the energy industry and the topic of enterprise application integration has been created, the general concepts of a service-oriented architecture and its technological implementation are presented. This chapter deals in particular with the mapping of business processes in a service-oriented architecture and a necessary integration infrastructure. After the analysis of the theoretical basic charge, the concepts are transferred to a possible IT architecture concept and applied to the exemplary business process of quoting electricity in the energy industry. A distinction is made between the analysis and the subsequent implementation of the business process in terms of a service-oriented architecture. Finally, the IT architecture concept of an SOA for a flexible mapping of business processes in the energy industry is evaluated. The knowledge gained is presented in a summary and a further outlook is given.

18 Introduction to the Energy Sector 4 2 Introduction to the Energy Sector This chapter takes a closer look at the energy sector in Germany and highlights its special features. Above all, those aspects are examined in more detail that have an impact on the mapping of business processes in IT. Overall, the presentation is condensed and is intended to give the reader an overview of the energy industry and its current challenges. In addition, the presentation should provide an understanding of the necessity of an IT architecture for the flexible mapping of business processes in the energy industry. The current situation in the energy industry in Germany is discussed below. Subsequently, challenges for an energy supply company (EVU) are concretized and requirements for a corresponding IT architecture for an EVU are defined. 2.1 Energy industry in Germany The energy industry in Germany has been in a fundamental process of change since the deregulation of the electricity market. The law on electricity and gas supply that came into force on July 7, 2005, in short the Energy Industry Act EnWG, as well as the successor ordinances to the General Supply Conditions (AVB) for electricity and gas that came into force on, have far-reaching consequences for utility companies in the electricity and gas sector . In terms of content, the EnWG primarily regulates the principles of network access. The guiding principle here is a non-discriminatory, efficient and transparent network access at reasonable prices. This represents the unbundling of the competitive sub-markets (generation / purchasing, trading and sales) from the natural monopolies (transmission and distribution), which in turn represents the unbundling of a power utility along the value chain (see Figure 1) in network operation and energy sales.

19 Introduction to the energy industry 5 Figure 1: Competitive sub-markets in the energy industry The aim of deregulating the energy market is to create the same sales conditions for all RUs operating on the market and thus to enable every customer to choose freely between the competitive RUs . The energy market is characterized by the fact that it is characterized by a natural network monopoly, since a network infrastructure is necessary from generation to transmission / distribution of energy to the end customer. For example, before deregulation, competition between RUs was ruled out due to closed supply areas (network areas). The local network operator was automatically the corresponding supplier for the local end customer. The central point of market liberalization is non-discriminatory network access. This results in the fact that the transmission / distribution of the value chain is part of the network operators, i.e. the integrated power supply companies, in a natural monopoly, while the other parts of the value chain can be freely implemented on the markets. In order to prevent the network operators, who are also suppliers and / or producers, from being preferred, the competitive sub-markets (generation / purchase, trade and distribution) must be separated from the natural monopolies (transmission / distribution). This is known as unbundling. In accordance with the EnWG of July 7, 2005, every network operator must enable a power supply company to transmit energy to the end customer without discrimination in return for payment of a so-called usage fee. Network usage fees are charged by the network operators for transport and distribution

20 Introduction to the Energy Industry 6 of energy. The determination of the network usage charges is regulated in the Electricity Network Charges Ordinance (StromNEV). Network operators must submit their calculated network usage charges to the Federal Network Agency for approval. The Federal Network Agency checks and, if necessary, corrects the calculated network usage fees in order to ensure that energy is passed through at fair market prices.This means cost pressure for the network operation of an EVU to survive independently in the market, since these costs are only covered up to the price of the network usage charges. In order to be able to survive on the energy market in the long term, EVUs must adapt to the challenges of the changed framework conditions and pursue a consistent focus on customers and the market. The procurement / generation of energy not only includes the actual generation in possibly own power plants, but also the trading of electricity on electricity markets. The possibility of trading in electricity leads to a variety of new products, services and potential trading partners. With the opening of the energy markets in Germany and the establishment of electricity exchanges, such as the EEX in Leipzig, more and more providers with alternative concepts on the market, which previously only a few market participants with partly long-term contracts dominated. Suppliers try to use innovative marketing and communication concepts and significant discounts to force their way onto the market and increase their market share. Furthermore, laws lead to the feed-in of renewable energies and to combined heat and power, due to the emergence of alternative forms of energy generation, such as e.g. Wind energy, biomass or solar energy, to changes in the producer structure. These laws promote the construction of decentralized generating units, such as Wind turbines. However, these decentralized generating units also lead to an increasing incalculability of the feed-in into the power grid and create a more complex overall system. This is due to the fact that previous network infrastructures and

21 Introduction to the energy industry 7 network management strategies are geared towards a central supply and must now be converted to a decentralized supply. 3 In addition, the law that came into force on the opening of metering for electricity and gas leads to a further liberalization of metering by liberalizing meter reading in addition to metering point operation, i.e. meter installation and maintenance. Now the connection users and no longer the subscribers can arrange for a third meter operator to be commissioned. From then on, metering point operators are obliged to install so-called intelligent meters in new and refurbished residential units, which reflect the actual energy consumption and the actual usage time. The suppliers have to offer variable-load or time-of-day tariffs no later than from In addition, the customer has the right to a monthly, half-yearly or quarterly billing from the supplier. This leads to new demands on the information and communication infrastructure as well as on the corresponding business processes of an EVU. The main challenges faced by a utility company are specified below. For the precise measurement of electricity or gas consumption, electronic meters, so-called smart meters, are to be used, which forward the measured consumption values ​​to the systems of the metering point operator via a data link. This is a remotely readable meter structure with a high communication effort, which allows a relatively simple and flexible connection to the respective IT systems, such as Meter data- 3 cf. [LMW07], S cf. [EnWG], 21b,; [EnWG], 40 para. 3.

22 Introduction to the Energy Industry 8 management system or billing system of the metering point operator. Decentralized generating units, such as Wind power plants lead to a significantly increasing need for information technology interfaces as well as planning and control strategies, which the previous centrally oriented network management strategies do not provide. Thus, the decentralized systems of the various generating units must be able to be connected relatively easily and flexibly to the IT systems of the network operator. Furthermore, deregulation and globalization of the energy market cause unbundling, which causes far-reaching structural changes in a utility company (see Table 1). Form Effects Accounting unbundling Separate account management and preparation of divisional balances in internal accounting Information unbundling Confidential treatment and separate use of sensitive data between sales and network operations Organizational unbundling Company law. Unbundling Development of separate departments, own management, functional separation of employees, financial independence Separation of areas under company law, own subsidiaries Table 1: Forms and effects of unbundling 5 For example, information unbundling provides for a separation of sensitive data between sales and network operation and is intended to ensure the non-discriminatory provision of data for all market participants. This means that processes and system functions are separated into separate perspectives for sales and network operations. This is to prevent the distribution of a network operator from gaining a competitive advantage over a market participant due to internal data, e.g. can make a tailor-made offer to an end customer based on network operation data. Complete independence of transmission / distribution from the competitive sub-markets of generation / purchasing as well as trading and sales can only be achieved through a separation of ownership. This leads to the fact that the application of an EVU, which was previously for 5 cf. [EnwG], part 2.

23 Introduction to the Energy Industry 9 Sales and Network Operation has to be divided into two independent applications. This means that data that was previously held in a master data system with a customer type can now be mapped in two independent systems or clients. In this respect, the common data such as Address data are maintained twice or changes are exchanged using suitable system functions and interfaces. Furthermore, a non-discriminatory application integration of all market participants must be taken into account for all data access, optimization questions or business processes. As already described in Section 2.1, the deregulation and globalization of the energy market is leading to a large number of new products, services and potential trading partners. Due to the fact that the energy product cannot be differentiated between the competing utility companies, the competition for end customers takes place on the basis of price or services. It should be noted here that, according to the Federal Network Agency, only two percent of the electricity price is available to cover sales costs and to realize a profit margin for sales. At around 39 percent, taxes and duties make up the largest cost pool. Procurement or generation costs amount to approx. 31 percent and the network usage fees to approx. 28 percent. This increased price competition as well as the development of new and innovative services from competitors are forcing EVU to optimally design existing business processes and continuously establish new, innovative business processes in order to continuously reduce process costs and to continuously increase customer orientation and the range of services. 6 This also includes the development opportunities for EVUs to open up new markets, new products, new sales channels, new business models and new collaborations (see Figure 2). 6 See [FaKl07], p. 18.

24 Introduction to the energy industry 10 Figure 2: Development opportunities for power supply companies 7 For example, Business processes that were held holistically by an EVU before deregulation, such as the billing of services, due to cost relief and flexibility in sub-areas or completely outsourced. Smaller RUs join together to form loose, task-specific networks or are part of corresponding corporate groups. 8 These changes to existing and new business processes are to be mapped as flexibly and inexpensively as possible using the appropriate IT systems. Furthermore, new functionalities must be provided and integrated into the corresponding IT architecture. Due to the unbundling, e.g. the invoicing of the network operation to the sales department was added. Furthermore, it should be noted that many supporting business processes, such as Short-, medium- and long-term deployment planning, decentralized load profile management or non-discriminatory electricity trading have not yet been adequately researched and therefore adjustments are gradually made that have to be mapped flexibly with the help of the IT systems. 9 The challenges presented by a utility company and their IT requirements are finally summarized in Table 2. 7 Cf. [Zaji07], p. 14ff. 8 cf. [FaKl07], S cf. [LMW07], p.344.

25 Introduction to the energy industry 11 Challenges for a utility company Deregulation and globalization of the energy market (unbundling) Decentralization of generation Liberalization of metering Improvement of customer orientation and service offering Increased cost management due to increased market transparency and competitive pressure IT requirements Non-discriminatory application integration of all market participants Flexible establishment of new business processes , innovative business processes Reduction of process costs (mapping of the most automated business processes possible) Reduction of development and subsequent maintenance costs of software components, i.e. services (reusability) Quickly adaptable illustrations of business processes and functionalities within the I T landscape of an EVU. A corresponding challenge for IT is to support new, innovative business processes in ever shorter cycles and to react flexibly to changes in the corporate structure. In order to achieve the highest possible process efficiency, the business processes should be IT-supported and thus automated as far as possible. Furthermore, the development and maintenance costs of services are to be reduced through the highest possible reusability. A corresponding IT architecture concept is required to implement the requirements for the IT of an EVU, the requirements of which are defined in more detail in the following section. 2.3 Requirements for the IT architecture The established IT architecture of a utility company is often based on heterogeneous IT systems. Supporting the IT requirements defined in the previous section primarily poses a problem of application integration.

26 Introduction to the Energy Industry 12 tion. 10 Thus, the IT architecture of a utility company currently in existence has to be reconsidered and redesigned in many ways in order to enable simple and cost-effective in-house as well as cross-company integration of applications and services. Aspects such as data integration, integration of legacy systems, standardization, but also the development of new IT architectures and integration platforms are in the foreground. 11 In order to introduce a corresponding IT architecture concept, certain minimum requirements must be met, which are examined in this thesis with regard to a service-oriented application integration for an EVU. These minimum requirements are explained below. 12 Integration: Due to stronger networking and greater communication between all players in an energy market, the architecture should enable platform and manufacturer-independent integration of highly distributed applications and services in the environment of heterogeneous systems and platforms. A number of different commercial systems exist within the system landscape of a utility company, such as Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), Data Warehouse and technical systems such as Network control systems (NLT) or the geographical information system (GIS). In addition, there are a number of other applications for special tasks that must also be integrated into the IT architecture. Here, not only an internal, but also a cross-company integration is necessary, e.g. To enable competitors in electricity trading to have non-discriminatory access to information. To this end, a suitable IT infrastructure must first be created in order to make the heterogeneous and highly autonomous and dynamic systems interoperable. Services, i.e. so-called services, should be 10 cf. [LMW07], S cf. [LMW07], S cf. [KBS04], p. 6, [LMW07], p.345.

27 Introduction to the Energy Industry 13 are offered by the various players in the energy market and can be connected relatively easily to the IT infrastructure. In order to map a loose system coupling, both synchronous and asynchronous communication are required. Furthermore, transaction-secured calls across system boundaries must be ensured. Decoupling of functionality and technology: IT systems from different market participants should be integrated easily and cost-effectively into the existing IT infrastructure and different services should be able to be exchanged for one another without major migration effort. For this purpose, the architecture of a utility company must allow it to operate largely independently of a special technology. This also includes the marketability of individual services or a product solution that could be embedded in heterogeneous system landscapes at different energy providers. In order to implement these requirements, a high degree of standardization is required, e.g. of exchange formats and interfaces, as well as a clear separation of business logic and infrastructure details. Uniform standards should thus guarantee the interoperability of the different IT systems. Reusability: For different user groups within an EVU, e.g. Procurement / generation, transmission / distribution or sales, different technical basic services must be implemented. Due to the increasing cost pressure on the IT systems, technical basic services are to be used across applications in the sense of informational unbundling and to be combined into new applications. This should save development and subsequent maintenance costs. A basic service is e.g. to be used for network operation as well as for sales. Furthermore, a basic service can e.g. can be used for sales in different sales processes. This requires a suitable division of services and interfaces so that services can be used by different potential user groups.

28 Introduction to the Energy Industry 14 Flexibility: Flexibility includes the requirement for expandability, maintainability and scalability. Due to changes in existing business processes or the introduction of new business processes within an EVU, efficient, flexible implementation of business processes is required. EVU's business processes must be able to be adapted quickly and efficiently to dynamic framework conditions that result from legal changes, restructuring, changed market situations, improvement of customer orientation and service offerings or technological changes. This requires loosely coupled services and a high degree of flexibility in the mapping of business processes. In order to reduce process costs, the processes must be clearly defined and as fully as possible with the help of IT, i.e. a suitable workflow management system, flexibly mapped and monitored. Based on these requirements for the IT architecture, a service-oriented solution for the problem of the integration of application systems within a power supply company is presented and evaluated in this thesis. The model should be applicable to both cross-company and company-internal application integration.

29 Basics of Enterprise Application Integration 15 3 Basics of Enterprise Application Integration The term Enterprise Application Integration (EAI) originated in the early 1990s. Even if EAI was originally intended as a term for the integration of applications, very different definitions with corresponding focuses can be found in the literature. In this thesis EAI stands for the concept of a flexible integration of heterogeneous applications to support business processes. Applications should be encapsulated as services and thus made available to other applications. 13 In the following, the motivation for EAI, the integration levels, possible EAI architectures and technical EAI solutions are briefly presented. 3.1 Motivation for Enterprise Application Integration The functionality of a business process is often covered by several heterogeneous applications that are widely spread across the company. This means that a large number of different applications are used in a company, each of which only supports a specific sub-area and is partly based on completely different technologies (heterogeneity of the system landscape). This includes standard applications such as ERP or CRM systems, custom software developed in-house or application extensions as well as software purchased from third-party providers.The connections to be realized from this necessity of handling overall processes over several applications represent the need for application integration. Heterogeneous applications within the own company must also be connected to one another as applications of business partners who are dependent on one another via an inter-company business process . 13 Cf. [RMB01], p. 2f; [Kaib02], p. 83; [Kell02], p. 9.

30 Basics of Enterprise Application Integration 16 Insufficient integration of applications and thus a lack of the possibility of automated process execution within the company as well as with business partners can lead to a loss of efficiency and a possible concrete threat to the existence of the company. The goal of an EAI is thus the coupling of previously operated applications that have been operated in isolation from one another under the aspect of keeping complexity as low as possible. Integration levels Enterprise application integration can take place on the following three levels: 15 Presentation level Data level Functional level / process level Integration on the presentation level is the most primitive Form of the EAI. Here, individual applications are presented with a common presentation, e.g. in web portals, integrated in order to offer the user a uniform user interface. Thus, user interfaces are used to extract data and functionalities from different applications. 16 As an example, a common HTML interface to a SAP R / 3 application and a mainframe application can be cited. Furthermore, with the help of so-called screen scraping tools, the required data can be extracted from user interfaces and displayed in a common user interface. However, integration at this level scales relatively poorly and can generally be described as unstable. 17 The data integration bypasses the presentation and process level and accesses the databases of an application directly for the purpose of integration. As a result, a wider range of data is available for data integration, in contrast to the presentation level. The data-oriented integration 14 cf. [ScWi02], S cf. [CHKT06], S cf. [CHKT06], S cf. [RMB01], p

31 Basics of Enterprise Application Integration 17 is based either on data interfaces, replication between databases or data federation. 18 A major advantage of the integration at the data level is that no modification of the databases or application logic is required in existing applications. 19 In many cases, however, data stocks have to be compared or queried from different locations, which can result in integration problems with regard to data model heterogeneity, schema or modeling heterogeneity and heterogeneity at the data level. There are well-engineered EAI tools and techniques for converting, aggregating, synchronizing and making available data in a standardized manner. In principle, however, the dependency on the data model used must be taken into account. As soon as the data model changes, the basis of the integration changes and involves extensive changes. In addition, the logic for aggregating the data has to be implemented again, as this remains in the existing applications that are not used during the integration at the data level. Overall, however, integration at the data level can be viewed as a tried and tested and widespread integration concept. Function integration is a form of integration at the level of the application logic. Participating applications must make functionality available to other applications via defined interfaces. If functionality is integrated along the business processes, one can speak of process integration. The integration at the process level represents the most stable and flexible, but also the most complex and difficult integration, since in addition to the technical also semantic requirements are made with regard to the business logic. 22 Their basic concept is to offer individual sub-functions of applications as services and thus to enable the common use of functionality by several application systems. 23 The main advantage of integration at the process level is therefore the 18 Cf. [Lint00], p. 28ff; [Kaib02], S cf. [CHKT06], S cf. [CHKT06], S cf. [CHKT06], S cf. [RMB01], p. 23, 26-27, cf. [RMB01], p. 27ff; [Kaib02], pp. 65ff.

32 Basics of Enterprise Application Integration 18 Possibility to map a process step to access functionalities of already existing applications and to use them again. 24 Heterogeneous technologies and different quality and scope of interfaces can, however, lead to compatibility problems with the integration and cause high costs if the existing interfaces are modified. 3.3 EAI architecture The aim of an EAI architecture is to use data and functionalities of different applications in a uniform manner and to flexibly integrate new applications into the existing IT landscape. The possible topologies of a hub & spoke architecture or a bus architecture can be used to implement an EAI architecture. The so-called point-to-point connection should also be mentioned in this context. Often the IT landscape of a company has grown historically without an architecture concept and the applications are connected to one another via point-to-point connections. However, this type of application integration is only practical with a few applications and few connections. This means that with a steady increase in applications, their integration becomes more complicated. If all applications are to be connected to one another, the number of interfaces is n * (n-1) / 2 (see Figure 3). This IT landscape is therefore also referred to as the so-called spaghetti architecture. Figure 3: Architecture of a point-to-point connection Cf. [CHKT06], S Cf. [Dun08 +], p. 9.

33 Basics of Enterprise Application Integration 19 The aim of an EAI architecture is to systematize this heterogeneous IT landscape. The aim is to create an IT architecture in which the data and functionalities of the different applications can be used uniformly in order to map internal and cross-company business processes easily and flexibly. Most EAI tools use a hub & spoke architecture (hub & spoke architecture) for this. In this architecture, a hub is used as the central integration infrastructure, the so-called EAI broker, between the applications to be connected (spokes), which receives, transforms and forwards all information that is exchanged between the applications. For this it is necessary that each application (spoke) is connected to the hub with the help of an adapter so that the application's data can be forwarded. Here, a hub & spoke architecture characteristically represents a star topology (see Figure 4). 26 Figure 4: Hub & Spoke architecture 27 With this EAI architecture, a central hub can become a so-called performance bottleneck when there is a very high communication volume. On the other hand, the load can be distributed with several EAI brokers, but this increases the administrative effort. 28 With the help of the bus architecture (see Figure 5), the disadvantage of a so-called bottleneck in a hub & spoke architecture is to be eliminated. The bus shown is a virtual construct that results from the switching of messages. As with the hub & spoke architecture, the connection is made with the help of 26 cf. [Pere06], S cf. [Pere06], S cf. [Pere06], p. 3.

34 Basics of Enterprise Application Integration 20 adapters. The main difference to the hub & spoke architecture, however, is that the transformation and forwarding of the data is carried out by the respective adapters. Because of this, a bus architecture is also referred to as a distributed architecture. In contrast to a hub & spoke architecture, this distributed architecture scales better, but it is also difficult to administer due to the distributed architecture. 29 Figure 5: Bus architecture EAI solutions EAI solutions have so far been discussed mainly under the aspect of the middleware technology used. 31 Middleware is an application-neutral software layer between business applications, which provides services for transparent communication between distributed applications on the basis of uniform interfaces and protocols. It should therefore offer an infrastructure to quickly merge new and existing applications. 32 The corresponding middleware technology must, among other things, have sufficient services for the transport of complex data (so-called messaging), for the mediation of function calls, transaction security, encryption, encryption and authentication. 33 In the area of ​​middleware technologies, one cannot speak of a generally accepted standard, as there are a large number of different manufacturer and platform-dependent solutions on the market. 34 The differentiation between the various middleware technologies is not uniform in the literature. 29 Cf. [Pere06], S Cf. [Pere06], S Cf. [SDLD02], S Cf. [Vogl06], S Cf. [SDLD02], S Cf. [Vogl06], p. 64.

35 Basics of Enterprise Application Integration 21 The following is a brief description of the main technologies of recent years: 35 Remote Data Access (RDA) Remote Procedure Call (RPC) Object Request Broker (ORB) Message-oriented middleware (MOM) Remote Data Access (RDA ) enables a (standardized) query language, such as Structured Query Language (SQL), access to a database managed independently of the respective application system. The best-known form of remote data access is the ODBC interface defined by Microsoft, with which common database systems can be accessed. Furthermore, the Java Database Connectivity (JDBC) developed by SUN based on the concepts of ODBC should be mentioned for the use of database systems by the Java programming language. However, the disadvantage of RDA is that it is only integrated at the data level and not functionally integrated at the process level. 36 With the help of Remote Procedure Calls (RPC) functions can be called from distributed applications. RPC is considered a more general concept and is now considered obsolete. A local function or procedure encapsulates a section of program code and makes it available over a network. The program code can thus be called by a remote application like a separate function by forwarding the call to the source application via the network. The source application performs the corresponding functionality and returns the result to the calling application via the network. The disadvantage of synchronous RPC systems is that the calling application (client) 37 is blocked during the procedure call until the source application (server) 38 has responded . 37 The term client is only used here to identify the pages that call a remote procedure (functionality). 38 The term server is only used here to identify the pages that provide a remote procedure (functionality).

36 Basics of Enterprise Application Integration 22 words. A definition of the function call is permanently inserted in the program code, so updating the function call of an application often requires the modification of all dependent applications. With a larger number of applications, the maintenance effort increases, since at least (n * (n-1)) / 2 interfaces are required to connect all applications with one another. However, it is precisely this point-to-point connection that is to be avoided by the concept of an EAI. Furthermore, mechanisms such as to guarantee security, performance or distribution, must be explicitly taken into account by the programmer. 39 With the help of so-called Object Request Brokers (ORB), functions can be called via objects, whereby frequently called objects can be held in the main memory. The ORB provides services for the coordination of transactions, events, security of the transmission and for the publication of the services. On the one hand, the Object Management Group (OMG) tries to define an independent standard of object-oriented middleware (Object Middleware) under the name CORBA (Common Object Request Broker Architecture), for which implementations from different manufacturers can be found. On the other hand, component-oriented middleware concepts, such as e.g. the Distributed Component Object Model (DCOM / COM +) defined by Microsoft for Microsoft platforms and the Java Remote Method Invocation (RMI) for calling Java programs on geographically distant computers. However, with these solutions there is usually a manufacturer or platform dependency. 40 In particular, message-oriented middleware (MOM), which offers the synchronous or asynchronous transmission of messages between applications involved in the integration, has largely established itself in the environment of EAI solutions. An essential element of a MOM are messages that contain the data packet, consisting of a header, a body and, optionally, certain properties. This message is 39 cf. [ScWi02], S cf. [ScWi02], p. 13f.

37 Basics of Enterprise Application Integration 23 transported from a sender to one or more recipients via virtual message channels. Message channels are logical addresses within the messaging system in which messages are stored and made available to other applications. Message channels are divided into point-to-point channels (one sender, one receiver) or publish-subscribe channels (one sender, several receivers). In a point-to-point channel, so-called message queues are set up. By temporarily storing the sender's messages in one or more queues, the corresponding processing process can be continued after a message has been sent and, if a response is expected, this can be queried at a later time, if necessary. With a publish and subscribe channel, the sender of a message does not know how many recipients will receive the message. This is a topic-oriented news distribution. The messages are exchanged via so-called topics. A topic stands for a specific subject area or area. The recipients, i.e. the consumers, register for a specific topic about which they want to receive messages and applications connect to the messaging system via so-called endpoints. An endpoint is responsible for receiving (inbound) and sending (outbound) messages via the messaging system. 41 Messages can be sent in different ways, e.g. can be influenced by routing, a filter or transformations. For each of these types there are different process patterns, i.e. so-called integration patterns. 42 For example, Using the content-based routing pattern, a message is sent to the recipient based on certain characteristics (contents) and the message filter pattern is used to ensure that only the messages that are of interest are sent to the recipient. 43 A complete description of possible enterprise integration patterns would exceed the scope of this work at this point. Reference is therefore made to the specialist literature used here. 41 Cf. [ScWi02], S Cf. [HoWo03], S Cf. [HoWo03], p

38 Service-Oriented Architectures 24 4 Service-Oriented Architectures The focus of EAI solutions, as described in Chapter 3.4, is primarily on the technical integration of an application landscape. Under the keyword EAI, a form of integration based on existing applications is often discussed, in which the coupling takes place via the technologically heterogeneous structures and boundaries using middleware solutions. For the flexible integration of heterogeneous applications for mapping business processes within the IT landscape, this results in a high level of complexity in the necessary integration relationships. This core problem of the EAI is mainly based on a lack of standardization of the interfaces and the necessary interoperability between application systems. Service-oriented architectures (SOA) promise to cope with these problems of an EAI and thereby reduce IT costs. SOA do not focus on the technological, but on the functional level in a company and its business processes. Due to standardized process integration, SOA promise greater flexibility when mapping new business processes in ever shorter cycles and when redesigning the application landscape. 44 The basics of an SOA and its technological implementation are described below. Here, the defined requirements for a flexible mapping of business processes and a corresponding application integration are increasingly addressed. 4.1 Basics SOA is not a product, technology or technology standard. SOA is a technology-independent IT architecture concept, according to which the simple and flexible design of software systems and their reuse exist- 44 cf. [RHS05], p. 413.

39 Service-Oriented Architectures 25 of the services are to be supported. 45 Interoperability is to be implemented so that the use of hardware and software, a programming language or an operating system is irrelevant. 46 In the literature, different aspects of an SOA are weighted differently. 47.As a result, there is still no clearly standardized architecture or a clearly defined conceptual structure of an SOA. 48 The core principle of a service-oriented architecture is the construction of software systems from loosely coupled services. 49 Several, largely independent, services encapsulate the business logic of a software system. 50 Functionalities or resources with great similarity (cohesion) are grouped together in such a way that they have as little dependency as possible on other components. This also speaks of an autonomy and modularity of services. This loose coupling of the services means that they can be exchanged or reassembled within new or changed business processes without great technical effort. 51 Thus, in contrast to previously monolithic software architectures, SOA make the adaptation of software systems to changed initial situations more flexible. 52 A service is a software component with a clearly defined service that can be reused multiple times in different environments. 53 services encapsulate data and application logic and tend to be roughly granular. For each service there is one or more interfaces and a service description. An interface 54 provides a functionality of a service in the form of operations 45 cf. [RLPB07], S cf. [Melz07], S cf. [Melz07], p. 11, [KBS04], p. 57, [Erl06 ], S Comp. [RHS05], S Comp. [Melz07], S Comp. [RLPB07], S Comp. [RHS05], S Comp. [RLPB07], S Comp. [RLPB07], S The terms interface and interface are used synonymously.

40 service-oriented architectures 26 are available that can be called up by the service user. 55 The actual implementation of a service, which is carried out by the service provider, remains hidden from the service user according to a black box. 56 A service description is a formal description of the interface. This should be legible for all service users and independent of the implementation, the programming language used or the platform to be executed. 57 Service interfaces and their description embody stable and binding contracts between the service provider and the service user and may only be adapted in clearly defined change cycles or after explicit consultation. 58 Services are dynamically searched for, found and integrated by the service user as required. This is a binding at runtime, i.e. at the time the program is compiled, it is not known which service is being called. In order for dynamic binding to be possible, the service user must first be able to find a corresponding service. This includes a directory service or registry in order to implement an SOA, in which the available services are registered by the service provider. 59 Service descriptions are stored in the registry that are required to identify suitable services and to use them. 60 Three different roles can be identified within an SOA: 61 Service provider directory service / registry 62 Service user The interaction between service provider, registry and service user takes place according to a uniform mechanism, the find-bind-execute paradigm 55 cf. [KBS04], p. 59f . 56 Cf. [KBS04], S Cf. [Melz07], S Cf. [RHS05], S Cf. [Melz07], S Cf. [KBS04], S Cf. [Melz07], S The terms directory service and registry are synonymous used.

41 Service-Oriented Architectures 27 (see Figure 6). This mechanism is used to call up services regardless of the platform, whereby all technical details remain hidden. 63 Figure 6: Find-Bind-Execute Paradigm 64 The service provider publishes a service description in the registry (step 1) and the service user searches for a service in the registry (step 2). If a suitable service is found (Find), the service user receives a reference to a service, i.e. an address (step 3). The function call is thus bound to this address (bind). The service user then requests the description from the service provider using a communication protocol (step 4). Finally, the service is used (execute) by transmitting input parameters to the service and returning output parameters as a response to the call (step 5). 65 Here it is important that open, platform-independent and widespread industry standards are used for technical and functional standardization. The service must be able to fully present its interface to the service user. In addition, communication between the service user and the service provider takes place via a protocol that both must be familiar with. 66 By using standards in the find-bind-execute paradigm, interoperability in an SOA can be achieved. Cf. [Melz07], p. 12ff. 64 Cf. [Melz07], S Cf. [Melz07], p. 12ff. 66 Cf. [Melz07], S Cf. [Melz07], p. 22.

42