Konzeption und Implementierung einer modularen prototypischen Integrationslösung auf. Basis von Entwurfsmustern für asynchrone Messaging Systeme

Transkript

1 Konzeption und Implementierung einer modularen prototypischen Integrationslösung auf Basis von Entwurfsmustern für asynchrone Messaging Systeme Diplomarbeit Tobias Schuhmacher Matrikel-Nr: Studiengang Online Medien Fakultät Digitale Medien Hochschule Furtwangen University Betreuende Professoren: Prof. Wilhelm Walter Prof. Dr. Dirk Eisenbiegler

2

3 Eidesstattliche Erklärung Ich erkläre hiermit an Eides statt, dass ich die vorliegende Diplomarbeit selbständig und ohne unzulässige fremde Hilfe angefertigt habe. Alle verwendeten Quellen und Hilfsmittel sind angegeben. Ehingen, den Tobias Schuhmacher

4

5 Abstract Diplomarbeit Pattern für Integrationslösungen auf Basis asynchroner Messaging Systeme Erfolgreiche Enterprise Applikationen arbeiten heute nur noch selten in einer isolierten Umgebung. Die Kombination verschiedener Systeme, um ein größeres Maß an Funktionalität und Leistungsfähigkeit zu erreichen, stellt immer mehr ein Erfolgskriterium für die Betreiber dar. Inzwischen haben sich mehrere Technologien verbreitet, die dem Thema Software Integration auf verschiedenen Wegen begegnen. Ein vielversprechender Ansatz, um eine lose Kopplung zwischen verschiedenen Software Applikationen zu erreichen, bieten asynchrone Messaging Systeme. Die Implementierung von Integrationslösungen auf Basis von Messaging Systemen stellt die Entwickler allerdings vor neue Herausforderungen. Um eine klare und flexible Softwarearchitektur zu erreichen, haben sich inzwischen verschiedene Entwurfsmuster (s.g. Patterns) für asynchrone Messaging Systeme herauskristallisiert. In dieser Arbeit soll auf diese Patterns näher eingegangen werden. Abschließend ist ein Prototyp geplant, in dem eine praktische Anwendung einiger Patterns erfolgt. Inhaltlich sollen folgende Punkte behandelt werden: Einleitung: Software Integration Notwendigkeit von Software Integration Anforderungen an Integrationslösungen Technologien zur Software Integration. Vorstellung von Messaging Systemen. Vor- und Nachteile von asynchronen Messaging Systemen Patterns für Messaging Systeme Notation von Integration Patterns Vorstellung der Basiskonzepte - Channels - Messages (Konstruktion von Messages, einfaches/kombiniertes Messaging) - Pipes und Filter - Routing - Transformation - Endpoint Entwicklung eines Prototypen in dem zwei Software Applikationen auf Basis eines Messaging Systemes, dessen Konzeption verschiedene Integration Patterns involviert, miteinander interagieren können. Anforderungen an den Prototypen - Muster die angewendet werden

6 Technischen Rahmenbedingungen - verwendete Programmiersprache - Anforderungen an die Laufzeitumgebung, verwendetes Queuing System usw. Technische Konzeption Implementierung und Dokumentation

7 Inhaltsverzeichnis 1 Einführung Vorwort Ziel dieser Arbeit Software-Integration Notwendigkeit von Software-Integration Integrationstypen Herausforderungen bei der Einführung einer Integrationslösung Lose Kopplung Technologien zur Software-Integration File Transfer Shared Database Remote Procedure Invocation Messaging Messaging Synchrone und asynchrone Kommunikation Funktionsweise von Messaging Systemen Message-Übermittlung Send-and-forget Store-and-forward Vorteile von Messaging Systemen Nachteile von Messaging Systemen Verbreitung von Messaging Systemen Entwurfsmuster für Messaging Systeme Muster in der Software-Architektur Charakterisierung von Software-Architektur Komponente Beziehungen Sichten Funktionale und nicht-funktionale Eigenschaften Software-Entwurf Definition von Muster Kategorisierung von Mustern Bedeutung von Mustern bei der Software-Architektur Beschreibung von Mustern Notation von Entwurfsmustern Entwurfsmuster für asynchrone Messaging Systeme Message Channels Point-to-Point Channel Publish-Subscribe Channel...28

8 Guaranteed Delivery Message Constructions Command Message Document Message Event Message Request-Reply Return Address Correlation Identifier Pipes und Filter-Architektur, Message Routing Content Based Router Message Filter Recipient List Splitter Aggregator Message Transformation Content Filter Canonical Data Model Message Endpoint Messaging Gateway Polling Consumer Event-Driven Consumer Durable Subscriber System Management Control Bus Entwicklung einer Integrationslösung Ausgangssituation Beschreibung der Ausgangssituation Analyse Optimierungspotential durch Software-Integration Verstehen des Anwendungsfalls und der Problembereiche Identifikation der für die Integrationslösung relevanten Geschäftsfälle Identifikation der auszutauschenden Daten Ermittlung der geeignetsten Integrationstechnologie Vorteile von asynchronen gegenüber synchronen Verfahren Konzeption Bestandteile einer Nachricht analysieren und Nachrichtenformate festlegen Verwendung des Canonical Data Models Einsatz von XML Entwicklung eines geeigneten XML-Dokumenten-Schemas Design des Nachrichtenflusses...80

9 Entscheidungskriterien für Nachrichtenkanäle Konzeption des Nachrichtenflusses Monitoring eines Messaging Systems Crash Proof Optimierung der Performance Implementierung JMS Konzepte der JMS API Programmier-Modell der JMS API JMS Client Anwendung Einschränkungen von JMS Auswahl des JMS Providers Software Architektur Architektur der Anwendungen innerhalb der Ausgangssituation Grundlegende konzeptionelle Entscheidungen Kommunikation zwischen Messaging Komponenten und JMS Provider Konzeption der Messaging Komponenten Datensynchronisation Abschlussbemerkung Bewertung Fazit I.Abbildungsverzeichnis II.Tabellenverzeichnis III.Abkürzungsverzeichnis IV.Literaturverzeichnis V.Anhang...131

10 Es ist möglich, Gebäude durch lose Aneinanderreihung von Mustern zu bauen. Ein so konstruiertes Gebäude stellt eine Ansammlung von Mustern dar. Es besitzt keinen inneren Zusammenhalt. Es hat keine wirkliche Substanz. Es ist aber auch möglich, Muster so zusammenzufügen, dass sich viele Muster innerhalb desselben Raumes überlagern: Das Gebäude besitzt einen inneren Zusammenhalt; es besitzt viele Bedeutungen, auf kleinem Raum zusammengefasst. Durch diesen Zusammenhalt gewinnt es an Substanz. (Übersetzung aus A Pattern Language von Ch. Alexander, Quelle: [Gamma2003], S. 441)

11 Einführung 1 Einführung 1.1 Vorwort Erfolgreiche Enterprise Anwendungen arbeiten heute nur noch selten in einer isolierten Umgebung. Die Kombination verschiedener Systeme, um ein größeres Maß an Funktionalität und Leistungsfähigkeit zu erreichen, stellt immer mehr ein Erfolgskriterium für die Betreiber dar. Inzwischen haben sich mehrere Technologien verbreitet, die dem Thema Software Integration auf verschiedenen Wegen begegnen. Einen vielversprechenden Ansatz bieten asynchrone Messaging Systeme. Damit eröffnen sich neue Herausforderungen an Software-Architekten, die neue Konzeptionsweisen bei asynchroner Kommunikation berücksichtigen müssen. Um eine klare und flexible Softwarearchitektur zu erreichen, haben sich inzwischen verschiedene Entwurfsmuster (engl. Design Pattern) für asynchrone Messaging Systeme herauskristallisiert. Diese Entwurfsmuster liefern Ansätze, auf deren Basis ein effektiver, flexibler und systematisierter Software-Entwurf möglich wird. 1.2 Ziel dieser Arbeit In dieser Arbeit steht die Konzeption und Implementierung einer modularen prototypischen Integrationslösung, auf Basis von Entwurfsmustern für asynchrone Messaging Systeme, im Vordergrund. Um diesen Aufgabenbereich umfassend erschließen zu können, unterteilt sich die Arbeit in einen theoretischen und einen praktischen Teil. Beim theoretischen Teil wird auf den Kontext von Messaging innerhalb des Themenbereiches Software-Integration eingegangen und erläutert, welche Vor- und Nachteile aus dem Einsatz von Messaging entstehen. Anschließend werden Entwurfsmuster für Messaging Systeme behandelt, wo eine Auswahl an Mustern vorgestellt wird. Ziel ist nicht, neue Entwurfsmuster zu entdecken, sondern die bestehenden auszuwerten und aufzuarbeiten. Darauf aufbauend entsteht der umfangreichste Teil dieser Arbeit, in der die Analyse und Konzeption einer prototypischen Integrationslösung mit einer Auswahl von Mustern erfolgt. Das Software-Design wird darauf ausgelegt, modulare Strukturen zu schaffen um jedes Entwurfsmuster flexibel in die Integrationslösung einzubetten. Der Prototyp soll die Funktionsweise dieser Muster praxisnah darstellen, sowie die Vorteile einer Integrationslösung auf Basis eines Messaging Systems verdeutlichen. Abschließend findet eine Bewertung der Ergebnisse statt. Der praktische Teil besteht aus der Umsetzung des zuvor konzipierten Systems. Konzeption und Implementierung beanspruchten zeitlich den größten Teil dieser Arbeit. Es wird hier auf den Abdruck von Quellcode weitgehendst verzichtet. Sämtliche Source-Codes befinden sich auf einer CDRom im Anhang gespeichert. Auf dieser CD-Rom ist auch eine Ausgabe der API Dokumentation im HTML Format hinterlegt. 1

12 Software-Integration 2 Software-Integration 2.1 Notwendigkeit von Software-Integration Das Wort Integration (aus: lateinisch integer, griechisch entagros = "unberührt", "unversehrt", "ganz"), wird im deutschen als die Herstellung eines Ganzen bezeichnet. Die Integration in der Informatik, speziell in der Software-Entwicklung, dient zur Verknüpfung von verschiedenen Anwendungen. Man kann mittlerweile davon ausgehen, dass insbesonders Enterprise Anwendungen dauerhaft nicht in einer isolierten Landschaft leben können. Dies wird von Erfahrungsberichten von IT-Mitarbeitern bestätigt (Vgl. Aussage von Randy Stattford, Chief Architect IQNavigator Incorporation, siehe [Hohpe2004] Praise und Vgl. [Hohpe2004], S. xxix) Der Zeitpunkt, an denen Systeme mit anderen Systemen zusammenarbeiten müssen, ist je nach Anwendungsgebiet und Relevanz der Anwendung, innerhalb des Kontextes zum Unternehmen, verschieden. Diese zwei Szenarien sind Beispiele dafür, wann Integration erforderlich wird: das Warenwirtschaftssystem eines Unternehmens muss seine Bestände mit denen eines Online-Shop-Systems abgleichen, um Kunden die aktuelle Verfügbarkeit eines Produktes mitteilen zu können. Ein weiterer denkbarer Fall wäre, dass Pocket PCs von Kundendienst-Mitarbeiten die tagsüber erfassten Daten über Nacht mit dem Datenbestand des zentralen Firmen-Servers synchronisieren sollen. Die Integration von Anwendungen stellt häufig eine strategische Entscheidung dar. Ziel ist, mehrere informationsverarbeitende Systeme aneinander zu binden, um deren Service und Informationsgehalt zu bündeln. Dadurch wird die Möglichkeit unterstützt, Daten untereinander auszutauschen und Prozesse möglichst in Echtzeit zu verknüpfen. Enterprise Anwendungen können ein Mix aus beliebig vielen verschiedenen SoftwareAnwendungen darstellen. Dabei kann es sich um selbst erstellte Software oder um Software-Produkte von Drittherstellern handeln, die auf verschiedensten Plattformen unter Einsatz verschiedenster Technologien arbeiten. Sie können, je nach Organisation des Unternehmens, geografisch weit voneinander verteilt sein. Die Ursache für eine solch chaotisch anmutende Entwicklung liegt oftmals nicht am Versagen der verantwortlichen IT-Experten, sondern scheint auf zwei Faktoren zurückzugehen (Vgl. [Hohpe2004], S. 1ff) : 1. Die Anforderungsprofile der Unternehmen sind so different und unterliegen laufenden Fluktuationen, dass es bei Enterprise Applikation unmöglich scheint, sämtliche Bedürfnisse verschiedenster Unternehmen in einem großen Software-Produkt zu befriedigen. Beispiel sind die großen ERP-Lösungen von Firmen wie Oracle, SAP oder Peoplesoft, die oftmals nur einen Teil der geforderten Funktionalitäten unterstützen und bei denen häufig Integrationsbedarf besteht. 2. Der Einsatz verschiedener Software, die auf verschiedenen Plattformen laufen, erlaubt den Betrieben größte Flexibilität in der Auswahl der für den jeweiligen Einsatzbereich am geeignetsten Software-Lösung. 2

13 Software-Integration Um laufende Geschäftsvorgänge über mehrere Anwendungen verteilt abwickeln zu können, bedarf es der Integration dieser Anwendungen. In einer nicht integrierten IT-Landschaft können Reibungsverluste entstehen. Beispielsweise aufgrund redundanter Datenhaltung und -erfassung, Dateninkonsistenz, unterbrochener Prozessketten usw. Bereits die Durchführung einer Kundenbestellung kann eine anwendungsübergeifende Prozessabwicklung erfordern und setzt damit die Interaktion mehrerer Anwendungen voraus. 2.2 Integrationstypen Die Integration von Software-Anwendungen kann anhand verschiedener Konzepte erfolgen, die sich in vier Klassen typisieren lassen. (Vgl. [Linthicum2004], S. 6ff und [Hohpe2004], S. 5ff) 1. Informations orientiert 1.1 Daten-Replikation Viele Enterprise Applikationen benötigen Zugriff auf den gleichen Datenbestand (z. B. CRMSystem, Buchführungssystem usw.). Oftmals führen mehrere Systeme ihren eigenen Datenbestand, sodass eine Synchronisation zwischen den Datenquellen notwendig wird. Integration wird erreicht, indem Daten zwischen mehreren Datenbanken dupliziert werden. Ob die beteiligten Datenbanken von verschiedenen Herstellern stammen und eventuell sogar mit unterschiedlichen Datenmodellen arbeiten, ist hierbei nicht relevant. Die fundamentale Anforderung liegt in der Infrastruktur, die den Datenaustausch zwischen den unterschiedlichen Datenbank-Modellen und Datenbank-Schemata koordiniert. Abbildung 1: Integration durch Daten Replikation (Quelle: [Linthicum2004], S. 7) 1.2 Datenbank-Föderation Datenbank-Föderation ist die Integration von mehreren Datenbanken und DatenbankModellen in eine einzige, vereinheitlichte Sicht dieser Systeme. Eine Datenbank-Föderation kann durch Einsatz einer entsprechenden Softwarelösung erreicht werden. Die Softwarelösung fügt eine zusätzliche Abstraktionsschicht zwischen die physikalisch verteilten Datenbanken und die Anwendungen, die auf diese Datenbanken zugreifen, ein. Diese Schicht verbindet sich mit dem Datenbank-Backend und mapped die physikalischen Datenbanken zu einer virtuellen Datenbank, die nur innerhalb der Softwarelösung existiert. Sie koordiniert die Verbindung und Verteilung der Daten zwischen Anwendung und Datenbank-Backend. 3

14 Software-Integration Abbildung 2: Integration durch Daten-Föderation (Quelle: [Linthicum2004], S. 8) 1.3 Geteilte Geschäftsfunktionen (Interface Processing) Nach dem gleichen Ansatz, wie es zu redundanter Datenhaltung in Enterprise Anwendungen kommt, besteht der Trend, dass sich Funktionalitäten zwischen Anwendungen überschneiden. Geteilte Geschäftsfunktionen stellen klar definierte Schnittstellen einer Anwendung bereit. Dadurch werden Informationen und Services dieser Anwendung externalisiert und anderen Anwendungen zur Verfügung gestellt. Abbildung 3: Integration durch geteilte Geschäftsfunktionen (Quelle: [Linthicum2004], S. 9) 4

15 Software-Integration 2. Geschäftsprozess orientiert Dieser Ansatz fügt auf bereits vorhandener Schnittstellen mehrerer Anwendungen eine zusätzliche Abstraktionsschicht ein. Diese bietet einfache und zentral verwaltete Prozesse an, die auf existierende Schnittstellen der Anwendungen zugreifen und so anwendungsübergreifende Operationen erlauben. Das Ziel ist die Zusammenführung der in dem Unternehmen anfallenden Prozesse, Kapselung des Informationsflusses und der Geschäftslogik. Man erkennt, dass eine unscharfe Grenze zwischen service orientierter und geschäftsprozess orientierter Architektur besteht. Als Beispiel können Geschäftsfunktionen als Service bereitgestellt werden und Geschäftsprozesse innerhalb einer Anwendung greifen auf diese Services mittels einer service-orientierten Architektur zu. Abbildung 4: Business-to-Business Integration (Quelle: [Linthicum2004], S. 11) 3. Service orientierte Architektur (SOA) Geteilte Geschäftsfunktionen werden häufig als Service anderen Anwendungen zur Verfügung gestellt. Sobald eine Anwendung eine Sammlung von Services vorhält, wird das Management dieser Sammlung zu einer entscheidenden Funktion. Es bedarf eines zentralen Verzeichnisses, in dem alle Dienste gelistet sind. Als zweites sollte jeder Service eine Schnittstellenbeschreibung zur Verfügung stellen, damit andere Anwendungen über ein Kommunikationsabkommen verhandeln können. Entdeckung und Aushandlung sind die Schlüsselelemente einer serviceorientierten Architektur. 5

16 Software-Integration Eine SOA erlaubt mehreren Anwendungen Geschäftslogik bzw. Methoden über Web Services zu teilen. Geteilte Methoden können auf einem zentralen Server, auf den die Anwendungen Zugriff haben, gehostet werden. Alternativ können sie auch durch den Einsatz von Web Service Mechanismen, wie sie beispielsweise.net enthält, offeriert werden. Abbildung 5: Service orientierte Architektur (Quelle: [Linthicum2004], S. 17) Service orientierte Architekturen verwischen die Linie zwischen Integration und verteilten Anwendungen. Neue Anwendungen können so konzipiert sein, dass sie auf bestehende RemoteServices anderer Applikationen zugreifen. Andererseits bieten viele SOA inzwischen Werkzeuge an, die es erlauben, externe Services gleich wie lokale Methoden aufzurufen. Damit ähnelt die Entwicklung einer Applikation, die SOA umsetzt, der Entwicklung einer verteilten Anwendung. 4. Portal orientiert Portal orientierte Integration, auch als Informationsportal bezeichnet, bündelt verschiedene Oberflächen von Systemen (z. B. interne Enterprise Systeme oder externe Handelssysteme). Dadurch werden mehrere einzelne Benutzeroberflächen unter einer Oberfläche verschmolzen. Während sich andere Integrationstypen auf den Datenaustausch in Echtzeit konzentrieren, fokussiert dieser Ansatz sich darauf, die verschiedenen Informationen aus mehreren Enterprise Anwendungen in eine einzige Anwendung bzw. Oberfläche auszulagern. 6

17 Software-Integration Abbildung 6: Portal orientierte Integration (Quelle: [Linthicum2004], S. 20) 2.3 Herausforderungen bei der Einführung einer Integrationslösung Die Integration von Enterprise Anwendungen geht über die Entwicklung einer Standalone-Applikation, die auf einer Multi-Tier-Architektur aufsetzt, hinaus. Im Vergleich zum Tier-Modell, wo eine Schicht ohne die andere nicht selbstständig funktionieren kann, handelt es sich bei integrierten Applikationen um eigenständige Anwendungen, bei der jede für sich unabhängig arbeitet. Anhand loser Kopplung können Funktionen auslagert werden. Die Ansprüche, die an integrierte Systeme gestellt werden (z. B. Effizienz, Zuverlässigkeit, sicherer Datenaustausch zwischen Anwendungen usw.), erfordern eine umfassende Konzeption, da mit verschiedenen Problemfällen zu rechnen ist. (Vgl. [Hohpe2004], S. xix, S. xxix und S. 3) Das Netzwerk zwischen den integrierten Systemen kann gestört oder aufgrund von Überlastung temporär nicht verfügbar sein. Methodenaufrufe über ein Netzwerk sind langsamer als lokale Methodenaufrufe, was bei umfassender Kommunikation zwischen den Systemen zu spürbaren Performance-Einbrüchen führen kann. Die integrierten Systeme können auf Basis von völlig unterschiedlicher Soft- und Hardware betrieben werden. Bei Integrationslösungen bedarf es ausreichender Flexibilität, um mit verschiedenen Technologien kompatibel zu sein. 7

18 Software-Integration Software-Systeme unterliegen Fluktuationen. Auf Dauer ist es unvermeidbar, dass sich SoftwareKomponenten ändern, was auch die Integrationslösung betrifft. Aus diesem Grund sollte sie ein Minimum von Abhängigkeit zu anderen Systemen aufweisen und eine lose Kopplung das Ziel sein (siehe Kapitel 2.3.1). Integrationslösungen dürfen nicht als reine Kommunikationsbrücke zwischen mehreren Anwendungen gesehen werden. Sie stellen gleichzeitig eine Brücke zwischen organisatorischen Einheiten (z. B. Gruppen, Abteilungen und Filialen) eines Unternehmens dar. Die Nutzer müssen verstehen, dass sie zukünftig nicht einen Teil einer spezifischen Applikation bedienen, sondern einen Teil einer integrierten Anwendung, die sich über das gesamte Unternehmen erstreckt. Software-Integration gilt als kritischer Teil innerhalb einer Enterprise Applikation. Sobald eine wichtige Geschäftsfunktion fehlerhaft implementiert ist, können dem Unternehmen Verluste entstehen. Die korrekte Funktionsweise ist deshalb essentiell. Software-Entwickler haben oftmals keine Kontrolle über die zu integrierenden Systeme. Die Einführung einer Integrationslösung darf häufig keine Änderung des zu partizipierenden Systems erfordern, was sich nachteilig auf das System-Design auswirken kann. Aufgrund der verschiedenen zu integrierenden Systeme und der eingesetzten Technologien, können Entwicklungsprozesse einer Integrationslösung zu komplexen Vorgängen werden, deren Durchführung ein vielseitiges Entwicklerteam voraussetzt. IT-Abteilungen verfügen oft nicht über Personal mit entsprechendem Fachwissen Lose Kopplung Kopplung, im Zusammenhang mit Software Integration, bedeutet die Verknüpfung mehrerer Anwendungen, sodass beide im gewissen Umfang voneinander abhängig sind. Diese Abhängigkeit kann beispielsweise darin bestehen, dass die Anwendungen auf geteilte Methoden, Schnittstellen oder Daten zugreifen. (Vgl. [Linthicum2004], S. 28) Eines der Schlagwörter bei Integration von Enterprise Anwendungen ist lose Kopplung (engl. loose coupling) der Systeme. Ein Begriff, der mit der wachsenden Popularität von Web Services eine zentrale Stellung erhalten hat. Die Kernaussage die hinter loser Kopplung steht, ist die Reduzierung der Abkommen, die zwei Parteien (z. B. Komponenten, Anwendungen, Dienste, Programme, Anwender usw.) getroffen haben, um miteinander interagieren zu können (z. B. um gegenseitig Daten austauschen, geteilte Methoden aufzurufen usw.). (Vgl. [Hohpe2004], S. 10 und S. 15) Je mehr Abkommen zwischen zwei Parteien bestehen, desto intoleranter ist die Lösung gegen Störungen oder Änderungen. Eine lose Kopplung erlaubt mehr Flexibilität und Skalierbarkeit. Allerdings erfordert die Umsetzung von lose gekoppelten Systemen komplexere Programmiermodelle und erschwert die Konzeption, Implementierung und Fehlersuche. 8

19 Software-Integration 2.4 Technologien zur Software-Integration Inzwischen gibt es eine Unzahl an Technologien, deren Ziel in der Integration von Software-Applikationen liegt. Im Kern können vier grundlegende Verfahren unterschieden werden. Alle Verfahren besitzen natürlich Vor- und Nachteile, weshalb beim Entwurf einer Integrationslösung das für den jeweiligen Fall geeignetste Verfahren bestimmt werden sollte File Transfer Der Datenaustausch erfolgt, indem ein System eine Datei mit Daten erzeugt und ein anderes System diese Daten zu einem späteren Zeitpunkt ausliest. Der Lesevorgang findet häufig in vorgegebenen Intervallen statt. Bei den Systemen bedarf es einer Konvention über Dateiname, Dateiformat und Ort an dem das File gespeichert wird. (Vgl. [Hohpe2004], S. xxx) Abbildung 7: File-Transfer (Quelle: [Hohpe2004], S. 44) Inzwischen haben sich einige standardisierte Formate etabliert. Mainframe Systeme nutzen DataFeeds basierend auf den Datei-System-Formaten von COBOL. UNIX benutzt textbasierte Dateien und bei neueren Entwicklungen wird XML eingesetzt. Vorteile: Software-Entwickler benötigen beim File-Transfer kein Wissen über interne Strukturen der zu integrierenden Anwendung. Es bedarf keiner zusätzlichen Werkzeuge. Was allerdings bedeutet, dass die Entwickler den Großteil der Arbeit (Files erzeugen, Datenaustausch, File auswerten und löschen usw.) selbst erledigen müssen. Die Kommunikation erfolgt asynchron. Nachteile: Ein Nachteil besteht im Aufwand die Files benötigen, um erzeugt und ausgewertet zu werden. Dies ist ein Grund, warum ein Datenabgleich meist in periodischen Zyklen stattfindet. Erfolgt ein Abgleich der Systeme in zu großen Zeitabständen, kann es zum Verlust der Synchronisation dieser Systeme kommen. Grundsätzlich wäre es möglich, bei jeder Datenänderung ein File zu erzeugen (womit dieses Verfahren dem Prinzip von Messaging nahe kommt). Dies kann aber Management-Probleme auslösen, denn es muss sichergestellt sein, dass alle Files beim Empfänger ankommen und keines verlorengeht. Bei zu häufigem File-Austausch kann es zu Performance-Einbrüchen bei den beteiligten Systemen kommen. 9

20 Software-Integration Die Kapselung von Daten stellt ein wichtiger Faktor innerhalb einer Software-Architektur dar. Software-Module tauschen Daten über Methodenaufrufe aus, was bedeutet, dass eine Datenänderung einen entsprechende Methodenaufruf auslösen sollte. Bei File Transfer kann eine entfernte Anwendung, beim Auswerten eines Files, auf Datenänderungen mit einem Methodenaufruf reagieren. Der große Nachteil besteht darin, dass alle Methodenaufrufe verzögert beim Empfänger-System stattfinden. (Vgl. [Hohpe2004], S. xxx, S. 44ff, S. 50) Shared Database Mehrere Anwendungen teilen sich denselben Datenbestand. Da alle beteiligten Anwendungen auf die gleichen Daten Zugriff haben, ist ein Datenaustausch nicht notwendig. (Vgl. [Hohpe2004], S. xxx) Abbildung 8: Shared Database (Quelle: [Hohpe2004], S. 48) Vorteile: Anwendungen, die auf den gleichen Datenbestand zugreifen, erhalten immer aktuelle und durch Einsatz von Transaktion-Management-Systeme, auch immer konsistente Daten. Da SQL als Abfragesprache von gängigen Technologien und Programmiersprachen unterstützt wird, ist eine Anbindung der Anwendungen an die geteilte Datenbestände relativ gut möglich. Nachteile: Semantische Dissonanzen können zu Konflikten führen. Anwendung A erwartet unter Feld X einen anderen Wert als Anwendung B. Ein großes Problem bei geteilten Datenbanken ist, ein einheitliches Datenbankmodell für alle Anwendungen zu schaffen. Einige Anwendungen funktionieren nur mit dem von ihnen vorgegebenen Schema, was eine Adaption erfordert (sofern dies möglich ist). Sollte eine Anwendung Änderungen am Datenbank-Schema erfordern, können Kompatibilitätsprobleme mit bereits angebundenen Anwendungen auftreten. Wird die geteilte Datenbank zu stark von angebundenen Applikationen frequentiert, kann es zu Performance Engpässen kommen, was die Datenbank zum Flaschenhals werden lässt. Zugriffe auf eine geteilte Datenbank über ein WAN sind langsam. Kapselung der Daten aufgrund der offenen Datenstruktur nur schwer möglich. 10

21 Software-Integration Bei Ausfall des Datenbank-Systems kann der störungsfreie Betrieb der verschiedenen Anwendungen nicht mehr gewährleistet werden. (Vgl. [Hohpe2004], S. 47ff) Remote Procedure Invocation Durch Verwendung entsprechender Protokolle und Software ist eine Anwendung in der Lage, Funktionen eines entfernten Systems aufzurufen. Die Anwendung übergibt die notwendigen Informationen und empfängt von der entfernten Methode den Rückgabewert. Man spricht hier von entferntem Methodenaufruf. Die Kommunikation erfolgt synchron. (Vgl. [Hohpe2004], S.xxx) Abbildung 9: Remote Procedure Invocation (Quelle: [Hohpe2004], S. 51) Vorteile: Erlaubt eine klare Kapselung der Daten durch Methoden. Anwendungen greifen nicht direkt auf die Datenstrukturen einer entfernten Anwendung zu, sondern rufen deren Methoden auf. Jede Anwendung wird damit in die Lage versetzt, selbst für Konsistenz und Integrität seiner Daten zu sorgen. Änderungen in der Software sind möglich, solang bei Remote-Methoden die Methodendeklaration konsistent bleiben. Änderungen der internen Repräsentation der Daten sind möglich, ohne andere Anwendungen zu beeinflussen. Durch Kapselung ist es einfacher, semantische Dissonanzen zu beheben. Anwendungen können mehrere Schnittstellen auf ein und die selben Daten, unter Verwendung unterschiedlicher Methodendeklarationen, bieten. Inzwischen existieren mehrere Technologien, die Remote Procedure Invocation ermöglichen: CORBA, COM,.NET Remoting oder Java RMI usw. Nachteile: Jede integrierte Anwendung muss die Schnittstellendeklaration seines Nachbarn kennen. Zwar hilft die Kapselung geteilte Datenstrukturen zu vermeiden, dennoch führt Remote Procedure Invocation zu einer engen Kopplung der Systeme. Dieses Verfahren weisst geringere Performance und Zuverlässigkeit im Vergleich zu lokalen Methodenaufrufen auf, was zu langsamen und unzuverlässigen Systemen führen kann. (Vgl. [Hohpe2004], S.50ff) 11

22 Software-Integration Messaging Messaging ist ein Verfahren zur Kommunikation zwischen Software Komponenten oder Anwendungen. Die Clients können Informationen, als Nachricht (so genannte Messages) verpackt, senden und empfangen. Messaging ermöglicht eine verteilte Kommunikation, die lose gekoppelt ist. Dies wird erreicht, indem die Clients Nachrichtenkanäle zum Datenaustausch benutzen. Diese Kanäle erlauben eine asynchrone Kommunikation, bei der Sender und Empfänger keinerlei Kenntnisse voneinander benötigen. Zur Kommunikation ist es ausreichend, dass beide Zugriff auf den Nachrichtenkanal besitzen und sich über das Nachrichtenformat einig sind. (Vgl. [Haase2002], S. 9) Abbildung 10: Messaging (Quelle: [Hohpe2004], S. 54) Vorteile: Durch den Versand kleiner Datenpakete ist ein schneller Datenaustausch möglich. Semantische Dissonanzen können durch Message Translator überwunden werden. Ein Messaging System koordiniert den Übertragungsprozess und sorgt für einen zuverlässigen Nachrichtenaustausch. Die integrierten Systeme kommunizieren über Nachrichtenkanäle, wodurch sie keinerlei Details über andere Anwendungen besitzen. Eine Anwendung kennt den Nachrichtenkanal, über den es Nachrichten sendet bzw. empfängt. Es besitzt keine Kenntnisse über den Kommunikationspartner selbst. Anstelle einer Kopplung wird eine Kollaboration erreicht. Aufgrund der asynchronen Kommunikation müssen nicht beide Kommunikationspartner zur gleichen Zeit bereit sein, was eine hohe Verfügbarkeit schafft. Die integrierten Systeme greifen nicht auf Datenstrukturen anderer Anwendungen zu, wodurch eine Kapselung der Daten möglich ist. Nachteile: Konzeption, Entwicklung und Fehlersuche von Systemen die Messaging verwenden, ist komplex. Beim Ausfall des Message Bus Systems kann kein Nachrichtenaustausch mehr erfolgen, wodurch die Funktionalität der gesamten Integrationslösung beeinträchtigt werden kann. (Vgl. [Hohpe2004], S.53ff) 12