Technische Universität Wien DIPLOMARBEIT Ausgeführt Am Institut Für Der .

Transcription

Technische Universität WienDIPLOM ARBEITAn Evaluation of Enterprise Application Integration Solutions andt h e R o l e of We b S e r v i c e sausgeführt am Institut fürVerteilte Systemeder Technischen Universität Wienunter der Anleitung von Ao.Univ.Prof. Dr. Schahram DustdardurchUlrich EndlichLangobardenstrasse 44, 1220 WienWien, am 21.03.2004

AbstractThe worldwide globalization and the rapidly changing consumer demands challengethe e-Business market. Flexible business processes are the basis to remain competitive.Thus, the way of thinking about information comes from business and not fromtechnology. This causes a growing dependency on information systems entailinglarger and more complex IT infrastructures. However, such IT infrastructures consistof many isolated solutions whereby new applications are often newly developedalthough the required functionalities are already provided by legacy systems. In orderto find a key, integration becomes more and more important. Unfortunately, systemsare usually integrated via proprietary point-to-point connections to implement onespecific process without any adaptability which causes a multiplicity ofinterconnections. Therefore, integration becomes a major aspect within developmentissues nowadays which evokes a new buzzword - enterprise application integration,shortly EAI.The main idea behind an EAI system is that external resources are integrated onlyonce and in between there is a standardized communication-platform to enableseamless interconnections. This allows the definition of business processes acrossvarious systems based on their common platform. Nowadays, there are two differentcompeting approaches available to implement such systems. On the one hand, thereare dedicated EAI systems that integrate external resources by implementing all theirstandards. On the other hand, there are Web services that require from integratedapplications to implement standards defined within the Web services framework toestablish a common communication platform.Current EAI systems available on the market offer a large set of features that gobeyond simple application integration. This involves graphical modeling, generationand execution of business processes across various systems as well as many features tosimplify integration tasks. That means simple integration of external resources withthe help of specific adaptors, data transformation and mapping capabilities, monitoringfacilities and web-based administration features for operational tasks. Furthermore,EAI systems are built on a reliable, scalable, and solid infrastructure to fulfill allrequirements of essential business processes.The Web services framework contains a lot of standards and specifications that canbe composed to implement many features of an integration platform. As Web servicesare designed for distributed systems, most of their mechanisms address aspects ofintegration. However, many recently published specifications are still in evaluationphase and will need a lot of time to be generally acknowledged. Only if thesespecifications develop into mature and globally supported standards, Web serviceswill provide a complete enterprise application integration solution.

Although, both technologies are competing, there is a certain convergence betweenthem. This is intensified through the changing of the paradigm from client-serverarchitectures to service-oriented ones. They are based on common communicationmechanisms and implement their functionalities by the composition of services.Therefore, services have to implement certain standards to discover, describe andexecute themselves to enable a unified and platform-independent infrastructure.Recently published Web services standards implement these functionalities, whereforecurrent EAI-systems can be called into question. However, an essential contributionfor this new architecture isn’t available within the Web services framework, namelythe integration of already existing applications that aren’t Web services enabled. Theirintegration is only possible through their adaptation which is often an unsolvablechallenge. This disadvantage is used by traditional EAI systems as this is exactly theirbenefit. They integrate external resources without the need to modify them.Furthermore, they are able to wrap up Web services functionality around thesesystems to leverage service-oriented infrastructures. Thus, a certain cooperation andcomplementation of both technologies is demanded in future.

ZusammenfassungDie weltweite Globalisierung und die hohen Anforderungen an Flexibilität undGeschwindigkeit stellen neue Herausforderungen an den e-Business-Markt.Geschäftsprozesse müssen rasch den variierenden Kundenwünschen angepasstwerden, um im Wettbewerb bestehen zu können. Daher ist die Ausrichtung heutigerInformationssysteme an Geschäftsprozesse anstatt deren Anpassung an die zurVerfügung stehenden Technologien, in den Vordergrund getreten. Da heutigeGeschäftsprozesse sehr stark von Informationssystemen abhängen, werden dieseimmer komplexer, um den Anforderungen gerecht zu werden. Dadurch ist eineLandschaft von vielen heterogenen unabhängigen Systemen entstanden. NeueAnwendungen werden, obwohl Teile der Funktionalitäten oftmals schon inverschiedenen Systemen vorhanden sind, von Grund auf neu entwickelt, wodurchFunktionalitäten und Datenbestände oftmals redundant vorliegen. Ein Fakt, der nichtgerade für Wettbewerbsfähigkeit sorgt. Um dieser Tendenz entgegenzuwirken werdendie einzelnen Systeme und Funktionalitäten integriert. Diese Integration basiert abermeistens auf dedizierten Punkt-zu-Punkt Verbindungen, die eine Wiederverwendungder Schnittstelle nicht ermöglichen, wodurch eine Vielzahl von Schnittstellen undVerbindungen entstehen, die einer aufwändigen und kostspieligen Wartung bedürfen.Integration spielt daher heutzutage eine wichtige Rolle in der Entwicklung vonAnwendungen, wodurch sich ein neues Schlagwort verbreitet hat – EnterpriseApplication Integration, kurz EAI.Das Grundkonzept besteht darin, Systeme einmal zu integrieren und dazwischen einegemeinsame standardisierte Plattform zu schaffen über die die integrierten Systemeuntereinander verbunden sind. Dies ermöglicht Geschäftsprozesse auf dieser Ebene zudefinieren, und dadurch übergreifend über die verschiedenen Systeme abzubilden. Umdies zu bewerkstelligen, gibt es zwei verschiedene Ansätze, die zueinander im engenWettbewerb stehen. Einerseits gibt es proprietäre EAI Systeme, die externe Systemeintegrieren indem sie sich deren Schnittstellen über spezielle Adaptoren anpassen undandererseits etablieren sich die Web Services Standards, die den Applikationen ihreStandards aufdrängen, um eine gemeinsame Kommunikationsbasis zu schaffen.Die heute am Markt verfügbaren EAI Systeme besitzen eine Vielzahl vonFunktionen, die weit über einfache Applikationsintegration hinausgehen. Dieseumfassen das grafische Modellieren und Umsetzen von Geschäftsprozessen überSystemgrenzen hinaus und weitestgehende Unterstützung bei der Implementierungvon Integrationslösungen mit all ihren Aspekten, um deren Implementierungsignifikant zu vereinfachen. Dazu zählen die einfache Integration externer tentransformationen,Monitoringfähigkeiten zur Überwachung ablaufender Geschäftsprozesse und webbasiertes Systemmanagement. Außerdem unterliegt nahezu jedem EAI-System einezuverlässige, skalierbare und stabile Infrastruktur, um die hohen Anforderungen anessentielle Geschäftsprozesse zu gewährleisten

Das Web Services Framework besteht aus einer Vielzahl von Standards undSpezifikationen, die gemeinsam eine große Anzahl von Funktionen einerIntegrationsplattform ermöglichen. Die meisten der vorgestellten Mechanismenadressieren Integrationsaspekte verteilter Systeme. Allerdings sind einige dieserSpezifikationen erst in einem Evaluierungsstadium und noch weit davon entfernt,allgemein anerkannt zu werden. Erst wenn sich daraus ausgereifte und globalunterstützte Standards entwickelt haben, werden Web Services vollständigeunternehmensweite Integrationslösungen bieten.Obwohl die beiden Technologien oft als im Wettbewerb stehend angesehen werden,ist die Konvergenz zwischen diesen Technologien nicht zu verleugnen. Zusätzlichwird diese durch das Aufkommen des Paradigmenwechsels von Client-ServerArchitekturen zu Service-Orientierten Architekturen verstärkt. Diese Bauen auf einemgemeinsamen Kommunikationsmechanismus auf und bilden Funktionalitäten durchKompositionen einzelner so genannter Services ab. Dies verlangt aber den Serviceseine Einhaltung gewisser Standards wie deren Findung, Beschreibung und Benutzungab, um eine einheitliche und plattformunabhängige Infrastruktur zu ermöglichen. NeueWeb Services Standards versuchen genau diese Anforderungen abzubilden, weshalbaktuelle EAI-Systeme manchmal in Frage gestellt werden. Einen wesentlichen Beitragzu dieser neuen Architektur können Web Services aber nicht anbieten, nämlich dieIntegration bereits bestehender Anwendungen, die noch keine Web ServicesSchnittstellen besitzen. Deren Einbindung kann nur durch deren Adaptierunggewährleistet werden, was allerdings oftmals aufgrund von veralteten Technologienund Systemen eine fast unlösbare Herausforderung darstellt. Diesen Nachteil nützenEAI–Systeme zu Ihrem Vorteil, indem sie die Einbindung solcher Systemeermöglichen, ohne diese modifizieren zu müssen. Weiters können den somitintegrierten Funktionalitäten Web Service Standards aufgesetzt werden, um denganzheitlichen service-orientierten Ansatz zu ermöglichen. Daher wird die Zukunftwohl verstärkt eine gewisse Kooperation und ein gemeinsames Auftreten dieserTechnologien verlangen.

ContentsAbstract. IIZusammenfassung .IVContents .VIIndex of illustrations.IX1Problem Description . 11.11.22Introduction . 1Problem Definition and Motivation . 3Review of the State of the art . 42.12.1.12.1.22.1.32.1.4Levels of Integration. 4Platform or Infrastructure Integration. 4Data integration . 4Application Integration. 5Business Process integration . 62.2Middleware . 72.2.1 Message Queuing . 72.2.2 Publish-and-subscribe. 82.32.42.4.12.4.22.4.3Enterprise Application Integration - EAI . 9EAI Architectures. 9Hub-and-spoke . 9Federated . 11Bus topology. 112.52.5.12.5.22.5.32.5.42.5.52.5.6EAI Components . 13Connectors. 13Messaging Middleware . 14Data mapping and transformation . 14Process management . 14Workflow tasks. 15Administration and monitoring . Web services. 17Service-oriented architectures . 17A technical overview. 18WSDL. 20SOAP. 21UDDI. 21Business Process Execution Language for Web services . 21Web services Composite Application Framework . 24Web services Security . 25Web services Notification . 262.7Web services and Integration . 27

34Evaluation of EAI products. 3.1.103.1.11BEA WebLogic Platform . 30Installation and configuration. 31WebLogic Integration overview. 31WebLogic Workshop. 32WebLogic Control Architecture . 33Business Process Management. 34Data Transformation. 36Message Broker. 37Application Integration. 37Human collaboration . 37Management and Administration . 38Conclusion. 393.23.2.13.2.23.2.33.2.43.2.53.2.6Microsoft BizTalk 2002. 40Conceptual overview . 40Installation and configuration. 41BizTalk Orchestration Services . 41BizTalk Messaging Services . 43Management and Administration . 47Conclusion. 3.3.103.3.11webMethods integration platform . 50webMethods integration platform overview. 50Platform architecture . 51Installation and configuration. 52webMethods Developer. 52Workflow Modeler . 53Data Transformation. 54Message Broker. 55Adapters . 55Human workflow. 56Management and Administration . 56Conclusion. 583.4Product taxonomy . 58Case study . 614.14.1.14.1.24.1.34.1.4The problem. 61The environment. 61The claim of the management . 61Analysis of a flawed process . 61The challenge . 624.24.2.14.2.24.2.3Solution strategies. 63Implementation of the EAI based solution . 63A solution approach based on Web services . 63Web services within EAI projects . 644.3The solution based on the webMethods Integration platform. 654.3.1 Description . 65

4.3.2 Context . 654.3.3 Scope . 654.3.4 Risks . 654.44.4.14.4.24.4.34.4.44.4.5System Description . 66Functional Requirements. 66Design constraints . 66Hardware environment . 66Software environment . 67Network environment. 674.54.5.14.5.24.5.34.5.44.5.54.5.64.5.7Logical Design. 67Scenario: Shop exchange request . 68Scenario: Create new debtor. 70Scenario: Notify administrator group . 71Scenario: Acknowledgment of requests . 71Scenario: Modify Partner data. 72Scenario: Create export document. 73Scenario: Send success mail . 734.64.74.7.14.7.24.7.34.7.44.7.54.7.64.7.7The business process diagram . 74Detailed Design . 75Scenario: Shop exchange request . 75Scenario: Create new debtor. 76Scenario: Notify administrator group . 78Scenario: Acknowledgement of requests. 78Scenario: Modify Partner data. 80Scenario: Create export document. 82Scenario: Send success mail . 844.8Summary . 845Conclusion and future work. 856References . 86

Index of illustrationsFigure 2.1 Data integration level . 4Figure 2.2 Application Integration with API’s . 5Figure 2.3 A simple business process model . 6Figure 2.4 Message Queuing . 7Figure 2.5 A publish/subscribe system . 8Figure 2.6 The “hub-and-spoke”-architecture . 10Figure 2.7 The “federated”-architecture . 11Figure 2.8 The bus-architecture . 12Figure 2.9 Cooperation of EAI components . 13Figure 2.10 Process management . 15Figure 2.11 Basic service-oriented service interaction . 17Figure 2.12 Web services layers . 18Figure 2.13 Basic Web services interaction. 19Figure 2.14 BPEL process interactions with partners. 22Figure 2.15 WS-Context overview . 24Figure 2.16 A possible service-oriented architecture based on Web services and EAI . 28Figure 3.1 BEA WebLogic Platform architecture [53]. 30Figure 3.2 BEA WebLogic Workshop. 32Figure 3.3 A clipping of a business process model in Workshop . 34Figure 3.4 BEA WebLogic XQuery Data Mapper. 36Figure 3.5 Monitoring. 38Figure 3.6 Administration. 39Figure 3.7 Microsoft BizTalk Server architecture . 40Figure 3.8 Workflow (left) and Implementation (right) view. 42Figure 3.9 Integration of SAP into BizTalk. 44Figure 3.10 BizTalk Editor . 45Figure 3.11 BizTalk Mapper. 45Figure 3.12 Message flow between receive functions, channels and messaging ports . 46Figure 3.13 The XLANG Event Monitor. 47Figure 3.14 BizTalk Document Tracking Query Builder . 48Figure 3.15 A business process in BizTalk Orchestration Designer. 49Figure 3.16 webMethods architecture - an example . 51Figure 3.17 Workflow Modeler . 53Figure 3.18 Graphical data mapping. 54Figure 3.19 webMethods Administrator . 56Figure 3.20 webMethods Moni

Zusammenfassung Die weltweite Globalisierung und die hohen Anforderungen an Flexibilität und Geschwindigkeit stellen neue Herausforderungen an den e-Business-Markt.