Integration Architecture Blueprint

Vorwort Daniel Liebhart, Guido Schmutz, Marcel Lattmann, Markus Heinisch, Michael Könings, Mischa Kölliker, Perry Pakull, Peter Welkenbach Integration Architecture Blueprint Leitfaden zur Konstruktion von Integrationslösungen ISBN: 978-3-446-41704-5 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-41704-5 sowie im Buchhandel. © Carl Hanser Verlag, München Vorwort Der Bau von Integrationslösungen ist keine einfache Aufgabe, obwohl die Integration von einzelnen Datenbeständen, Anwendungen und Gesamtsystemen immer mehr zum täglichen Geschäft des Software Engineerings gehört. Hinzu kommt, dass die Hersteller von ESB’s, EII Infrastrukturen, Messaging Systemen, SOA Frameworks, ETL Tools und Software für die Datenintegration von sehr unterschiedlichen Ansätzen aus- gehen und viele Unternehmen eine oder gleich mehrere verschiedene Integrations- lösungen im Einsatz haben. Der Trivadis Integration Architecture Blueprint ist das Re- sultat aus dem Fazit vieler realisierter Projekte – nicht nur erfolgreicher – und in-ten- siven Diskussionen mit Kunden, Experten und einer gründlichen Auseinandersetzung mit der Fachliteratur. Die Entwicklung des Integration Blueprints hat viele Monate gedauert, da das wich- tigste Ziel war, eine Integrationslösung so zu strukturieren, dass standardisierte und bewährte Grundkomponenten mit Hilfe von Tools und Produkten zu einem funktio- nierenden Ganzen zusammengestellt werden können. Und das ganze die Anforde- rungen eines Kunden erfüllen und mit vernünftigem Aufwand realisiert werden muss. Wir glauben, mit der Gliederung der Integrationsschicht in verschiedene und klar definierte einzelne Levels und Layers und durch die Zuordnung von Best Practice Patterns auf diese Layers den Bau von Integrationslösungen in der Praxis stark zu ver- einfachen. Das Buch ist für IT-Professionals, für Architekten, für Manager und Projektleiter die mit der Planung, der Konzeption, der Bereitstellung und dem Betrieb von Integra- tionslösungen beschäftigt sind gedacht. Die konzeptionelle Idee hinter dem Integration Architecture Blueprint wurde von den Autoren gemeinsam mit Fernand Hänggi und Albert Blarer entwickelt und von Daniel Liebhart, Guido Schmutz und Peter Welkenbach ausformuliert. Grosse Teile des Buches wurden von den Autoren mehrmals überarbeitet und in Workshops hef- tig diskutiert. Wir danken den Reviewern Albert Blarer, Partick Blaser, Christoph Pletz und Karsten Krösch. Und ganz besonders Tony Fräfel für seinen detaillierten Input. IX Vorwort Zusätzliche technische Informationen sind auf unserer Website (www.trivadis.com) unter den Bereichen Download Area und Blog (unter Know-How Community) zu finden. Wir möchten all jenen danken, die in irgendeiner Weise einen Beitrag zu diesem Buch geleistet haben. Insbesondere sind dies die Reviewer und unsere Arbeitskolle- gen und Arbeitskolleginnen, die immer wieder bereit waren, verschiedenste Aspekte intensiv und geduldig mit uns zu diskutieren und klar zu stellen. Außerdem unseren Kunden und Geschäftspartnern, mit denen wir in verschiedenen Projekten eine Viel- zahl interessanter und bereichernder Erfahrungen machen durften. Und unseren Kol- legen, Kolleginnen, Freunden, Freundinnen, Angehörigen, dem Korrektor und dem Verlag für ihre Geduld. Basel, Bern, Frankfurt, München, Stuttgart und Zürich im September 2008 Daniel Liebhart, Guido Schmutz, Marcel Lattmann, Markus Heinisch, Michael Könings, Mischa Kölliker, Perry Pakull und Peter Welkenbach X Die Autoren Die Autoren Daniel Liebhart (daniel.liebhart@trivadis.com) Daniel Liebhart verfügt über 20 Jahre Erfahrung in der IT und über 10 Jahre Erfahrung im Management von IT-Dienstleistungen und Produktentwicklung. Seine Branchen- und Fachkenntnisse umfassen die Konzeption, Architektur, Realisierung und Betrieb komplexer und international betriebener Gesamtsysteme im Telekommunikations-, Finanzdienstleistungs-, Logistik- und Industriebereich. Daniel Liebhart ist leidenschaft- licher Informatiker, Träger mehrerer Auszeichnungen und Dozent für Softwarearchi- tektur und Wirtschaftsinformatik an der Hochschule für Technik in Zürich. Guido Schmutz (guido.schmutz@trivadis.com) Guido Schmutz ist seit über 20 Jahren als Software Entwickler, IT-Berater, Chef- Architekt, Trainer und Coach tätig. Als Leiter des Bereichs Application Development des Trivadis Technologie Center verfasst er viele Fachpublikationen, entwickelt er IT-Strategien, Kurse und TechnoCircles und tritt als Sprecher auf internationalen Kon- ferenzen auf. Guido Schmutz ist für die Innovation, Konzeption und Realisierung zahlreicher DWH-, CRM-, CSM-, MIS- und EAI-Lösungen für internationale Finanz- institute, Pharmakonzerne, öffentliche Verwaltungen und Logistikunternehmen ver- antwortlich. Seine Spezialgebiete sind Enterprise Architecture, Bitemporale Daten- haltung, Java Persistenz und das Spring Framework. Marcel Lattmann (marcel.lattmann@trivadis.com) Marcel Lattmann arbeitet als System Architekt, Senior Software Engineer und Haupt- referent im Bereich Microsoft Enterprise Solutions. Er ist spezialisiert auf die Kon- zeption, Beratung und Realisierung von CRM-, POS- und Forecasting-Lösungen für Finanzdienstleister, Pharmakonzerne und Industriebetriebe. Sein besonderes Inte- resse gilt dem Corporate Knowledge Engineering, der Architektur von Libraries und Frameworks und der Anwendung von Automated Software Testing and Verification Verfahren. Als Technology Owner Microsoft Application Development des Trivadis Technologie Center entwickelt er Kursunterlagen, Realisierungsszenarien und Con- sultingstrategien für Konzerne, IT Dienstleister und Engineering Teams. Markus Heinisch (markus.heinisch@trivadis.com) Markus Heinisch ist Projektleiter, Architekt und Senior Consultant mit Schwerpunkt Automobilindustrie, Halbleiterfertigung, Immobilienverwaltung und Verlagswesen. Er verfügt über langjährige Erfahrung in der Software Produktenwicklung und war als Chef-Architekt, Presales-Consultant und Manager für das Engineering und die Reali- sierung von Basiskomponenten einer umfangreichen DMS-Suite für den Weltmarkt verantwortlich. Seine technischen Schwerpunkte sind heute die Anwendungsent- wicklung mit Oracle ADF, J2EE und modernen Web-Technologien. Markus Heinisch ist Referent und Kursautor im Bereich Java und XML und prüft neue Technologien und Produkte hinsichtlich ihrer Einsatzmöglichkeiten in Kundenprojekten. XI Die Autoren Vorwort Michael Könings (michael.koenings@trivadis.com) Michael Könings arbeitet als Software Engineer, Architekt, Berater und Projektleiter für die Pharmaindustrie und für internationale Finanzdienstleister. Er verfügt als Diplom-Betriebswirt und Wirschaftsinformatiker über viele Jahre Erfahrung in der Konzeption, Entwicklung und im Betrieb von Management Informationssystemen. Er war lange als Kursautor, Trainer und Hauptreferent in den Bereichen Modellierung und Design von relationalen Datenbanken tätig. Die Entwicklungstools Oracle Forms, Reports, Designer hat er in zahlreichen Projekten eingesetzt. Michael Könings ist Spezialist für die Entwicklung von Enterprise Solutions basierend auf der Microsoft .NET Technologie und die Konzeption von Corporate Performance Management Systemen. Mischa Kölliker (mischa.koelliker@trivadis.com) Mischa Kölliker ist als Senior Architekt für die Konzeption, Gesamtarchitektur und Qualitätsicherung in Kundenprojekten im Finanz- und Telekommunikations-Sektor verantwortlich. Er verfügt über viele Jahre Erfahrung in der Realisierung und Projekt- leitung in der Software Produktenwicklung eines Telekommunikation Network Mana- gement Systems. Er hat high-end Softwarelösungen für einen sehr großen Anwen- derkreis analysiert, spezifiziert, umgesetzt und betrieben. Mischa Kölliker setzt sich als Kursreferent und Autor von Fachpublikationen mit den Schwerpunkten Software- Entwicklung nach CMM Qualitäts-Standard, Java Security, Spring Framework, Perfor- mance Management und Data Warehouse Engineering auseinander. Perry Pakull (perry.pakull@trivadis.com) Perry Pakull arbeitet seit Jahren als Software Eningeer, Berater, Trainer und Senior Architekt im Bereich Oracle Application Development. Er hat 20 Jahre Erfahrung in der Entwicklung und Betreuung betrieblicher Anwendungssoftware. Die Entwick- lungstools Oracle Forms, Reports, Designer setzt er seit über 10 Jahren in zahl- reichen Projekten ein. Sein Spezialgebiet ist die Analyse und die Umsetzung von Businessprozessen für Pharmakonzerne, Automobilhersteller, Halbleiterproduzenten und Großhandelsketten. Sein aktueller technischer Schwerpunkt sind Web Applika- tionen im Oracle Forms und Oracle Java Umfeld, basierend auf der Oracle Appli- cation Server Technologie. Perry Pakull ist als Autor von Kursunterlagen, Kursreferent für die Themen PL/SQL, Oracle Portal und Oracle Application Server und als Pro- jektverantwortlicher und Software Architekt für Produktionssteuerungs-, Warenwirt- schafts- und Prozessleitsysteme tätig. Peter Welkenbach (peter.welkenbach@trivadis.

Inhaltsverzeichnis Daniel Liebhart, Guido Schmutz, Marcel Lattmann, Markus Heinisch, Michael Könings, Mischa Kölliker, Perry Pakull, Peter Welkenbach Integration Architecture Blueprint Leitfaden zur Konstruktion von Integrationslösungen ISBN: 978-3-446-41704-5 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-41704-5 sowie im Buchhandel. © Carl Hanser Verlag, München Inhalt Vorwort................................................................................................................................ IX Die Autoren.......................................................................................................................... XI 1 Einleitung ................................................................................................................... 1 1.1 Hintergrund: Integriert statt isoliert.............................................................................. 2 1.2 Aufbau des Buches ..................................................................................................... 3 2 Grundlagen ................................................................................................................ 5 2.1 Einleitung ................................................................................................................... 5 2.2 Begriffe....................................................................................................................... 7 2.2.1 A2A, B2B und B2C......................................................................................... 8 2.2.2 Integrationstypen............................................................................................ 9 2.2.3 Semantische Integration und die Rolle der Daten.......................................... 11 2.2.4 Enterprise Application Integration (EAI)......................................................... 13 2.2.5 Messaging .................................................................................................... 14 2.2.6 Publish-Subscribe ......................................................................................... 15 2.2.7 Message Broker ............................................................................................ 16 2.2.8 Messaging-Infrastruktur................................................................................. 18 2.2.9 Enterprise Service Bus (ESB).......................................................................... 18 2.2.10 Middleware.................................................................................................. 21 2.2.11 Routing Schemas .......................................................................................... 23 2.3 Integrations-Architekturvarianten............................................................................... 24 2.3.1 Point-to-Point-Architektur ............................................................................. 24 2.3.2 Hub-and-Spoke-Architektur .......................................................................... 25 2.3.3 Pipeline-Architektur...................................................................................... 26 2.3.4 Service-Orientierte Architektur ..................................................................... 27 2.4 Service-Oriented Integration ..................................................................................... 29 2.4.1 Process Integration ....................................................................................... 29 2.4.2 Workflow Integration.................................................................................... 31 2.5 Data Integration ........................................................................................................ 32 V Inhalt 2.5.1 Federation.................................................................................................... 32 2.5.2 Population ................................................................................................... 33 2.5.3 Synchronisation............................................................................................ 35 2.6 EAI / EII..................................................................................................................... 37 2.6.1 Direct Connections ...................................................................................... 37 2.6.2 Broker.......................................................................................................... 38 2.6.3 Router.......................................................................................................... 40 2.7 Event Driven Architecture......................................................................................... 42 2.7.1 Einführung EDA ........................................................................................... 42 2.7.2 Event Processing........................................................................................... 44 2.8 GRID / XTP............................................................................................................... 46 2.8.1 GRID ........................................................................................................... 46 2.8.2 Einsatzgebiete .............................................................................................. 52 2.8.3 XTP (Extreme Transaction Processing)........................................................... 53 2.8.4 XTP und CEP................................................................................................ 55 2.8.5 Solid State Disks und Grids .......................................................................... 55 3 Basistechnologien .................................................................................................... 57 3.1 Einleitung ................................................................................................................. 57 3.2 Transaktionen ........................................................................................................... 59 3.2.1 Transaktionale Systeme ................................................................................ 59 3.2.2 Isolationsebenen (Isolation Levels)................................................................ 61 3.2.3 Zwei-Phasen-Commit-Protokoll (two-phase commit protocol, 2PC) ............... 64 3.2.4 XA-Transaktionen ......................................................................................... 66 3.3 OSGi........................................................................................................................ 67 3.3.1 OSGi-Architektur.......................................................................................... 69 3.3.2 OSGi Bundles .............................................................................................. 70 3.3.3 Das Kollaborative Modell ............................................................................. 71 3.4 Java Connector Architecture (JCA)............................................................................. 72 3.4.1 Einsatzgebiet ................................................................................................ 72 3.4.2 JCA Komponenten........................................................................................ 72 3.4.3 Contracts...................................................................................................... 73 3.5 Java Business Integration (JBI).................................................................................... 74 3.5.1 Die JBI-Bestandteile...................................................................................... 75 3.6 Service Component Architecture (SCA) ..................................................................... 76 3.6.1 SCA-Spezifikation......................................................................................... 77 3.6.2 SCA-Bausteine.............................................................................................. 78 3.6.3 Composite.................................................................................................... 79 3.7 Service Data Objects (SDO)...................................................................................... 80 3.7.1 SDO-Architektur........................................................................................... 80 3.7.2 Implementierte Pattern ................................................................................. 81 3.8 Prozessmodellierung ................................................................................................ 81 3.8.1 Ereignisgesteuerte Prozessketten (EPK).......................................................... 82 3.8.2 BPMN .......................................................................................................... 83 3.8.

Leseprobe Daniel Liebhart, Guido Schmutz, Marcel Lattmann, Markus Heinisch, Michael Könings, Mischa Kölliker, Perry Pakull, Peter Welkenbach Integration Architecture Blueprint Leitfaden zur Konstruktion von Integrationslösungen ISBN: 978-3-446-41704-5 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-41704-5 sowie im Buchhandel. © Carl Hanser Verlag, München 3 3 Basistechnologien Dieses Kapitel beschreibt eine Auswahl von Basistechnologien, die für die konkrete Umsetzung von Lösungen basierend auf dem Trivadis Integration Architecture Blue- print relevant sind. Abschnitt 3.2 illustriert Transaktionen und Transaktionsstrategien. Abschnitt 3.3 beschreibt die Hardware-unabhängige, dynamische Softwareplattform OGSi. Abschnitt 3.4 charakterisiert die Java Connector Architecture als allgemeine Architek- tur zur Anbindung heterogener Systeme. In Abschnitt 3.5 wird JBI (Java Business Integration) als standardisierte Beschreibung der Funktionen eines ESB dargestellt. Abschnitt 3.6 präsentiert SCA (Service Component Architecture) als Modell für den Bau von Anwendungen und Systemen, basierend auf einer SOA. In Abschnitt 3.7 wird SDO als Disconnected Data Architecture beschrieben. Abschnitt 3.8, Prozessmodellierung, stellt die wichtigsten Standards zur Modellie- rung von Geschäftsprozessen dar. 3.1 Einleitung Basistechnologien, die heute bei der Realisierung von Integrationslösungen eine Rolle spielen, sind Transaktionen und Standards wie OGSi, JCA, JBI, SCA und SDO. Transaktionen oder auch Transaktionsstrategien übernehmen in jeder Architektur eine zentrale Rolle. Die Kenntnis ihrer Möglichkeiten und Unterschiede ist entschei- dend für die Wahl geeigneter Datenzugriffsstrategien. Die wesentlichen Aspekte sind Transaktionale Systeme, Isolationsebenen, das Zwei-Phasen-Commit und die globa- len (XA-)-Transaktionen. 57 3 Basistechnologien OSGi ist eine Hardware-unabhängige, dynamische Software-Plattform, die es erleich- tert, verteilte Anwendungen und ihre Dienste zu modularisieren und über den ge- samten Lifecycle hinweg zu verwalten. Die OSGi-Plattform setzt eine Java Virtual Machine voraus und bietet darauf aufbauend ein Framework an. Die wichtigsten Be- standteile von OSGi sind die OSGi-Architektur, das Komponentenmodell (die Bund- les) und das Kollaborative Modell. JCA ist im JEE-Umfeld eine allgemeine Architektur zur Anbindung heterogener Sys- teme, wie beispielsweise Legacy-Anwendungen über eine standardisierte Schnittstel- le in Form eines sogenannten Resource-Adapters. Die Zusammenarbeit mit anderen Systemkomponenten wird durch standardisierte Schnittstellen gesichert, die in der JCA-Spezifikation festgeschrieben sind. Die JBI (Java Business Integration)-Spezifikation beschreibt die Funktionalität eines ESB in einer standardisierten Form. JBI kann auch als Service-orientierter Meta Con- tainer betrachtet werden, der eine Komponenten-Architektur realisiert. JBI arbeitet mit zwei Arten von Containern: den Service-Engines und den Binding Components. Die Services-Engines enthalten die Business-Logik, während die Binding Components nichts anderes als einen Proxy für die Service-Nutzer darstellen. SCA (Service Component Architecture) ist eine Sammlung von Spezifikationen, die ein Modell für den Bau von Anwendungen und Systemen basierend auf einer SOA beschreiben. SCA modelliert Lösungen als Sammlung von Service Components, die Dienste anbieten und Referenzen zu anderen Diensten haben. Funktionalität wird nach außen als Dienst in Form von Schnittstellen zu Verfügung gestellt. Dienstkom- ponenten verfügen über Properties, die spezifische Charakteristika der Komponente beschreiben und zu ihrer Konfiguration genutzt werden. SDO (Service Data Objects) bieten ein konsistentes Modell zur Behandlung von Da- ten, unabhängig vom Quellsystem und Quellformat. SDO realisiert eine sogenannte Disconnected Data Architecture. Obwohl SCA und SDO unabhängig voneinander Verwendung finden, bietet eine Kombination eine mächtige und flexible Möglich- keit, um verteilte Anwendungen zu erstellen. Eine wichtige Basistechnologie, die im Rahmen der meisten Integrationsprojekte verwendet wird, sind die Instrumente zur Modellierung von Geschäftsprozessen. Diese Modellierung erfolgt immer mittels graphischer Tools. Der Trivadis Integration Architecture Blueprint sieht den Einsatz graphischer Tools vor, die eine gut definierte Notation für die Modellierung unterstützen. Es existiert eine Vielzahl solcher Notati- onen. Die wichtigsten sind BPMN (Business Process Modelling Language), EPK (Er- eignisgesteuerte Prozesskette) und BPEL (Business Process Execution Language). 58 3.2 Transaktionen 3.2 Transaktionen Transaktionen oder auch Transaktionsstrategien haben in jeder Architektur eine zent- rale Rolle. Die Kenntnis ihrer Möglichkeiten und Unterschiede ist entscheidend für die Wahl geeigneter Datenzugriffsstrategien. In diesem Kapitel werden die für die Integration wesentlichen Aspekte dargestellt. Es sind dies transaktionale Systeme, Isolationsebenen, Zwei-Phasen Commit und XA-Transaktionen. Transaktionale Systeme (Transactional Systems): ermöglichen eine kontrollierte „Alles oder nichts“-Datenmanipulation. Isolationsebenen (Isolation Levels): koordinieren die parallele Transaktion beim Zugriff auf die Daten und trennen je nach den Ebenen die Sichtbarkeit von den manipulierten Daten. Es werden vier unterschiedliche Isolationsebenen – Seriali- zable, Repeatable Read, Read Commited und Read Uncommited – unterschie- den. Zwei-Phasen-Commit (Two-Phase-Commit): Das sogenannte „Zwei-Phasen-Commit“ ist der Basisalgorithmus einer Transaktion. Es verlangt von allen an einer Trans- aktion beteiligten Systemen, dass sie einem erfolgreichen Transaktionsabschluss zustimmen. XA-Transaktionen (XA Transactions): Eine XA-Transaktion ist eine standardisierte und globale Transaktion, die sich über mehrere (auch heterogene) Ressourcen erstrecken kann. 3.2.1 Transaktionale Systeme Transaktionen prozessierende Systeme sowie deren theoretische Konzepte existieren in der einen oder anderen Form seit den 70er-Jahren des vorigen Jahrhunderts und wurden vom Datenbank-Guru Jim Gray entwickelt (Lindsay 2008). Das Ziel von Transaktionen, und damit der sie unterstützenden Infrastrukturkompo- nenten, ist eine „Alles oder nichts“-Datenmanipulation im Rahmen einer sog. „Unit of Work“ (Gray, Reuter 1993). Ein kurzes Beispiel soll dies verdeutlichen: Wir möchten eine Banküberweisung tätigen. Hierzu muss der entsprechende Betrag von unserem Konto abgebucht und dem anderen Konto gutgeschrieben werden. Hierbei stellt der Vorgang der Banküberweisung bzw. seine Subaktivitä- ten (Abbuchen und Gutschreiben) und deren Datenmanipulation (Betrag von Konto abziehen, Betrag auf Konto addieren) eine „Unit-of-Work“ dar. Diese soll in einer Transaktion stattfinden, sodass keine der Subaktivitäten alleine durch- geführt wird, also nur eine Abbuchung erfolgt oder nur eine Gutschrift. Gültig sind nur beide Vorgänge in Kombination, auch im Falle von Systemfehlern. Diese Konsistenz wird durch Transaktionen erreicht. 59 3 Basistechnologien Transaction Begin of First Second Third End of Transaction Transaction Operation Operation Operation Time Abbildung 3.1 Transaktionsklammer Sämtliche Operationen in einer Transaktion werden mit einer Transaktionsklammer versehen, wie in Abbildung 3.1 dargestellt. Sie umfasst alle einzelnen Operationen einer Transaktion. Transaktionen können auf zwei Arten abgeschlossen werden: Erfolgreich – COMMIT Nicht erfolgreich – ROLLBACK Bei einem Commit werden alle in der Transaktion getätigten Änderungen im System reflektiert. Da es sich bei transaktionalen Systemen zumeist um Datenbanken oder andere persistierende Komponenten handelt, werden die Zustandsänderungen mit einem Commit dauerhaft gespeichert. Bei einem Rollback werden alle Zustandsände- rungen rückgängig gemacht. Atomare Transaktionen können geschachtelt sein (was aber viele Systeme nicht unterstützen).