Enterprise Application Integration 1

Größe: px
Ab Seite anzeigen:

Download "Enterprise Application Integration 1"

Transkript

1 Westfälische Wilhelms-Universität Münster Ausarbeitung Enterprise Application Integration 1 im Rahmen des Seminars Softwaretechnik Jan Korves Themensteller: Prof. Dr. Herbert Kuchen Institut für Wirtschaftsinformatik Praktische Informatik in der Wirtschaft

2 Inhaltsverzeichnis 1 Einleitung Grundlegende Definition, Ursachen und Anwendungsfelder von EAI Definition Enterprise Application Integration Ursachen für die Entstehung von EAI Wichtige Anwendungsfelder von EAI Architektur und Fähigkeiten von EAI-Servern EAI-Referenzarchitektur Prozessschicht Kommunikationsschicht Protokoll-Adapterschicht Weitere Funktionalitäten von EAI-Servern Funktionale Eigenschaften Nichtfunktionale Eigenschaften Integrationsmethoden Integration über die Benutzungsschnittstelle Integration über Funktionsaufrufe Integration über Datenbanken Integration über Komponenten Kommunikationsarten Synchrone Kommunikation Asynchrone Kommunikation Middleware Technische Realisierung Zusammenfassung und Ausblick Literaturverzeichnis II

3 Kapitel 1: Einleitung 1 Einleitung Der Großteil der heute in Unternehmen eingesetzten Anwendungen wurde ohne die Absicht entwickelt, Verbindungsmöglichkeiten zu anderen Systemen zu schaffen. Weiterhin bieten zugekaufte Standardsoftwareprodukte, mit Ausnahme einiger Softwareprodukte des gleichen Herstellers, meist wenige standardisierte Schnittstellen zu den in großer Zahl vorhandenen älteren, so genannten Legacy-Systemen. Untersuchungen von Deloitte and Touche haben ergeben, dass sogar ca. 75% aller Systeme eines Unternehmens Legacy-Anwendungen sind [Ju01, S. 6]. Demzufolge existiert in den meisten größeren Firmen eine Vielzahl heterogener Softwaresysteme, auch als Stovepipe Applications bezeichnet, welche zudem vorwiegend in verschiedenen Sprachen geschrieben wurden, auf unterschiedlichen Betriebssystemen eingesetzt werden und auf ungleichen Datenhaltungen basieren. Das Hauptziel einer jeden Unternehmung, wettbewerbsfähig zu bleiben und den Unternehmensgewinn zu maximieren, kann nur dadurch erreicht werden, die Informationssysteme ständig zu modernisieren und zu verbessern. Um dieses Ziel zu erreichen sowie eine gemeinsame Nutzung vieler unterschiedlicher Internetapplikationen, eine Einbindung von Standardsoftware und einen Zusammenschluss mit einem anderen Unternehmen zu ermöglichen, wird es dringend erforderlich, diese Stovepipe Applications miteinander zu verbinden. Die Kosten, die durch die Versuche entstehen, alle vorhandenen Softwaresysteme miteinander zu verbinden, sind sehr hoch. Forrester Research schätzt, dass ca. 30 Prozent aller IT-Kosten für die Integration von Unternehmensanwendungen verwendet werden, und laut der Gartner Group sind dies sogar 35% [Ka02, S. 1]. Auf Grund dieser äußerst hohen Kosten kam es zu der Entwicklung von spezieller Enterprise Application Integration-Software, kurz auch als EAI-Software bezeichnet. Mit ihr wird versucht, einzelne Insellösungen innerhalb einer Unternehmung effizient und kostengünstig zu verbinden, so dass Informationen und Geschäftslogik für alle Anwendungen gleichzeitig verfügbar werden, ohne dass alle vorhandenen Softwaresysteme durch standardisierte Systeme ersetzt werden müssen. Ziel dieser Seminararbeit ist es, die aktuell im Einsatz befindlichen Funktionalitäten von EAI-Produkten zu erläutern. Dazu werden dem Leser in Kapitel 2 zunächst grundlegende Definitionen und Begriffe nahe gebracht, während im Hauptteil in Kapitel 3 die Architektur und Fähigkeiten eines EAI-Systems beschrieben werden. Abschließend werden im 4. Kapitel die Ergebnisse der Arbeit zusammengefasst und ein Ausblick auf praktische Beispiele von EAI-Lösungen gegeben. 3

4 Kapitel 2: Grundlegende Definition, Ursachen und Anwendungsfelder von EAI 2 Grundlegende Definition, Ursachen und Anwendungsfelder von EAI 2.1 Definition Enterprise Application Integration Eine allgemeingültige Definition von Enterprise Application Integration existiert nicht. Darüber hinaus lässt sich die Definition von EAI aus zwei verschiedenen Perspektiven betrachten. Aus der Geschäftsperspektive betrachtet wird EAI als der Wettbewerbsvorteil bezeichnet, den ein Unternehmen erhält, wenn alle Anwendungen zu einem einheitlichen Informationssystem integriert werden. In dieser Seminararbeit zur Softwaretechnik steht demgegenüber aber der andere Gesichtspunkt, die technische Perspektive, im Vordergrund. Hierbei bezieht sich EAI auf den Prozess heterogene Anwendungen, Funktionen und Daten zu integrieren, um die gemeinsame Nutzung von Daten und die Integration von Geschäftsprozessen durch alle Anwendungen hinweg zu ermöglichen. Diese Integration soll hierbei ohne große Änderungen der existierenden Anwendungen und Datenbanken durch effiziente Methoden in Bezug auf Kosten und Zeit erreicht werden [Ju01, S. 4, Ke02, S. 5 und Ka02, S. 79, 80]. Weiterhin ist eine Abgrenzung zwischen Enterprise Application Integration und Business-to-Business-Electronic-Commerce sinnvoll, da die Werkzeuge, die in beiden Bereichen zum Einsatz kommen, strukturell ähnlich konzipiert sind. Der Begriff EAI beschreibt die Beschleunigung und Rationalisierung von Informationsflüssen innerhalb eines Unternehmens, während beim B2B-E-Commerce der Handel zwischen Unternehmen rationalisiert wird [Ke02, S. 6, 7]. 2.2 Ursachen für die Entstehung von EAI Die Entstehung von EAI lässt sich größtenteils auf drei verschiedene Gründe zurückführen. Zunächst ist hierbei die schnelle Verbreitung des Internets mit den damit verbundenen unzähligen Internetapplikationen, welche durch das Aufkommen vieler Internetfirmen (dot-coms) entstanden ist, zu nennen. Viele Firmen fingen während dieser Zeit damit an, die Möglichkeiten des E-Business und des Internets zu erkennen, und versuchten dementsprechend ihre Geschäftsprozesse neu zu gestalten, um sie zu automatisieren und damit Kosten zu sparen. Weiterhin entstanden zu jener Zeit sehr viele neue Firmen, deren Geschäftsmodelle ausschließlich auf dem Internet basierten, wie z. B Suchmaschinen, -Provider, Internet-Versandhändler, elektronische Auktionshäuser und Vergleichsplattformen. Nach und nach wuchs die Anzahl verschiedener Internetapplikationen in diesen Unternehmen sehr stark an, so dass es notwendig wurde, die Anwendungen miteinander zu verbinden. Dies, wie auch die Neugestaltung der Ge- 4

5 Kapitel 2: Grundlegende Definition, Ursachen und Anwendungsfelder von EAI schäftsprozesse, kann nur erreicht werden, wenn alte und neue Anwendungen integriert und existierende Systeme für Nachrichten aus dem Internet zugänglich gemacht werden, so dass alle Anwendungen, die an einem Geschäftsvorfall beteiligt sind, problemlos miteinander kommunizieren können. Laut [Ke02, S. 12] wird dies als das primäre Einsatzfeld für EAI-Technologien bezeichnet. Der zweite Trend, der sich in Unternehmen abzeichnet, ist, dass immer mehr Enterprise Resource Planning-Softwareprodukte (ERP-Softwareprodukte) anstatt selbst entwickelter Software eingesetzt werden. ERP-Software ist Standardsoftware, die von größeren Unternehmen für sekundäre Geschäftsprozesse wie Rechnungswesen, Materialwirtschaft usw. eingesetzt wird. Firmen, die solche Systeme vertreiben, sind z. B. SAP, Baan, Peoplesoft und Oracle. Die Schwierigkeit hierbei besteht darin, diese ERP- Software in die bestehende Anwendungslandschaft des Unternehmens zu integrieren. Auch dieses Problem wird aktuell mittels so genannter GlueWare, wie z. B. EAI-Tools angegangen. Unter GlueWare versteht man Software, die eine Verbindung zwischen einzelnen Softwarekomponenten schafft. Die dritte Ursache, die zur Entstehung von EAI beigetragen hat, ist das immer häufigere Auftreten von Übernahmen und Fusionen zwischen Unternehmen aller Größenordnungen. Hierbei wird meist die Strategie verfolgt, das Anwendungsportfolio des einen Fusionspartners zu behalten und die Bestände des anderen in das beibehaltene System zu integrieren [Ke02, S ]. 2.3 Wichtige Anwendungsfelder von EAI Da es mitunter sehr viele Anwendungsfelder für den Einsatz von EAI gibt, soll in diesem Kapitel nur auf die wichtigsten drei eingegangen werden. Hierzu gehören Multichannel-Architekturen, Application to Application-Integration (A2A-Integration) sowie die Geschäftsprozessintegration, welche im Folgenden näher erläutert werden [Ke02, S ]. Heutzutage besteht die DV-Landschaft in Unternehmen größtenteils aus mehreren Verkaufssystemen (Front-Office), so z. B. Vertriebskanäle wie Internet und Callcenter, welche mit einem oder mehreren Kernssystemen (Back-Office), in denen die Geschäftslogik aufbereitet wird, zusammenarbeiten. Die möglichen Architekturen, die hierbei auftreten können, werden als n:1 und n:m Multichannel-Architekturen bezeichnet. n:1 bedeutet in diesem Fall, dass n Frontend-Anwendungen mit einer Backend-Anwendung verbunden sind und n:m besagt, dass n Frontend-Anwendungen mit m Backend- Anwendungen untereinander in Verbindung stehen. Die EAI-Technologie, die hier zum Einsatz kommt, besteht aus einer Art Middleware, die eine Kommunikationsmöglich- 5

6 Kapitel 2: Grundlegende Definition, Ursachen und Anwendungsfelder von EAI keit zwischen Front-Office und Back-Office schafft. In Abb. 1 wird ein n:1 Multichannel-Szenario zum einen mit dem Einsatz und zum anderen ohne die Verwendung einer EAI-Lösung dargestellt. Während in der klassischen n:1 Multichannel-Situation ohne EAI jeweils ein eigener Kanal mit individueller Schnittstelle die Front-Office-Systeme mit dem Back-Office-System verbindet, können in der Situation mit EAI die individuellen Schnittstellen durch eine normierte Schnittstelle ersetzt werden, so dass die Erstellungs- und Wartungskosten verringert werden. Auf den Begriff Middleware sowie Transformationstechniken, Adapter und Schnittstellen wird im Verlauf des Kapitels 3 noch genauer eingegangen. normierte Transformationstechniken (T) normierte Adapter (A) normierte Schnittstellen (S) Front-Office Anw.1 Front-Office Anw.1 T A Front-Office Anw.2 Back-Office Kernanwendung Front-Office Anw.2 T A normierte Transportprotokolle (Middleware) S Back-Office Kernanwendung Front-Office Anw.3 Front-Office Anw.3 T A klassische Situation ohne EAI neue Situation mit EAI Abbildung 1: n:1 Multichannel-Situation mit und ohne EAI Quelle: [Ke02, S. 17] Unter der A2A-Integration wird das Vorgehen bezeichnet, viele Inselanwendungen eines Unternehmens, welche zudem auf unterschiedlichen Servern liegen können, zu verbinden. Das Problem dieser Maßnahme liegt darin, dass die Wartungskosten sehr hoch sein können, wenn sehr viele Verbindungen und Schnittstellen vorliegen. Im schlechtesten Fall kann es zu O(n²)-Verbindungen zwischen den Applikationen kommen, wenn jede Anwendung direkt mit jeder anderen Anwendung verbunden wird. Dies wird als Spaghetti-Kommunikations-Architektur bezeichnet. Eine EAI-Lösung als Bus- oder Hub & Spoke-Architektur bietet sich in diesem Fall an, so dass die Anzahl möglicher Verbindungen auf O(n) reduziert werden kann. Bei einer Bus-Architektur werden Informationen, die in einer Anwendung entstehen, auf einen zentralen Bus gesendet und über diesen Weg den an den Bus angebundenen Applikationen zur Verfügung gestellt. In einer Bus-Architektur gibt es keinen zentralen Server, der die Verteilung der einzelnen Nachrichten koordiniert, der zentrale Bus leitet die Nachrichten lediglich weiter und verteilt sie an die an den Bus angebundenen Systeme. Die Applikationen entscheiden hierbei selbst über die Relevanz der Informationen, und nehmen sie ggf. nach dem 6

7 Kapitel 2: Grundlegende Definition, Ursachen und Anwendungsfelder von EAI Publish/Subscribe-Prinzip, auf welches in Kapitel näher eingegangen wird, auf. Demgegenüber gibt es bei der so genannten Hub & Spoke-Architektur eine zentrale Informationsdrehscheibe, in diesem Fall einen zentralen EAI-Server, mit der alle Anwendungen und Systeme gleichberechtigt verbunden sind. Dieser zentrale EAI-Server, über die die gesamte Kommunikation der einzelnen Anwendungen abläuft, wird als Hub bezeichnet und steuert und überwacht den gesamten Datenverkehr zwischen den einzelnen Systemen [Ha02]. Abb. 2 zeigt diese 3 Architekturen noch einmal grafisch. Abbildung 2: Spaghetti-Kommunikations-, Hub & Spoke- und Bus-Architektur Ein weiteres wichtiges Anwendungsfeld, in dem EAI-Technologien gewinnbringend eingesetzt werden können, ist die so genannte Geschäftsprozessintegration. Bei der Steuerung von Geschäftsprozessen ist es notwendig, dass alle beteiligten Systeme zusammenarbeiten. EAI-Software wird in diesem Fall dazu genutzt, diese Systeme zu integrieren, indem die einzelnen Aktivitäten eines Geschäftsprozesses auf mehrere Anwendungen zugreifen können (Abb. 3). Hierbei kann es zu drei Arten der Anbindungen kommen. Dies sind die Integration über die Oberfläche, die funktionale Integration sowie die Integration über Daten. Im Kapitel 3.2 werden diese näher erläutert. Geschäftsprozess Ak. 1 Ak. 2 Ak. 3 Ak. 5 Ak. 6 Ak. 4 Anw. 1 Anw. 2 Anw. 3 Anw. 4 Abbildung 3: Geschäftsprozessintegration Quelle: [Ke02, S. 26] 7

8 3 Architektur und Fähigkeiten von EAI-Servern Den Einsatzgebieten für EAI-Technologie, die in Kapitel 2.3 angesprochen wurden, kann mit einer Lösung begegnet werden, die sich EAI-Integrationsserver nennt. In dieser Seminararbeit wird dieser Begriff für alle Arten von EAI-Lösungen gebraucht. Zunächst wird in diesem Kapitel eine EAI-Referenzarchitektur mit ihren funktionalen Eigenschaften vorgestellt. Anschließend werden weitere funktionale und nichtfunktionale Eigenschaften von EAI-Integrationsservern dargelegt. Zum Abschluss des Kapitels wird noch auf die Integrationsmethoden, Kommunikationsarten und den Begriff der Middleware näher eingegangen, da sie einer weiteren Erläuterung bedürfen. Alle diese Charakteristika sind für die Auswahl und das Design eines EAI-Integrationsservers und den damit verbundenen Kosten von enormer Wichtigkeit und sollten deswegen für jedes Unternehmen entsprechend unterschiedlich betrachtet werden. 3.1 EAI-Referenzarchitektur Die technischen Eigenschaften, die ein EAI-Integrationsserver bereitstellt, lassen sich zu einer EAI-Referenzarchitektur zusammenfassen, welche in Abb. 4 dargestellt ist. Neben dieser Referenzarchitektur kann ein weiteres EAI-Architekturmodell in [Ka02, S. 100] nachgelesen werden, welches sich aber von diesem Modell nicht grundlegend unterscheidet. In den folgenden Ausführungen werden die 3 Schichten Prozessschicht, Kommunikationsschicht und Protokoll-Adapterschicht sowie die durch sie abgedeckten Funktionalitäten näher erläutert. http Legacies Weitere Abbildung 4: EAI-Referenzarchitektur Quelle: [Ke02, S. 43] 8

9 3.1.1 Prozessschicht In der Prozessschicht können einfache Aufgaben zu komplexen Diensten miteinander verknüpft werden. Die Integration mehrerer Anwendungen entlang eines Geschäftsprozesses wird letztendlich durch diese EAI-Komponente gesteuert. Dazu werden Funktionalitäten geboten, erweiterte Geschäftslogiken zu definieren und eigene Geschäftsregeln festzulegen. Zum einen kann Geschäftslogik, die nicht in den zu integrierenden Anwendungen zur Verfügung steht, in einem EAI-Integrationsserver aus mehreren Diensten zusammengesetzt oder in den vorhandenen Servern nachprogrammiert werden. Zum anderen können Geschäftsregeln bestimmt werden, wodurch Teile eines Geschäftsprozesses abhängig von Bedingungen ausgewählt werden. Gesteuert werden diese Funktionalitäten durch einzelne Prozesse, die dazu in der Lage sind, Nachrichten zu verschicken und zu empfangen. Ein Prozess, der eine Nachricht verschickt hat, gelangt hierbei solange in einen schlafenden Zustand, bis er durch eine andere Nachricht wieder aufgeweckt wird. Weiterhin können diese Funktionalitäten, die mit der Prozessschicht abgedeckt werden, in drei verschiedene Gruppen aufgeteilt werden. Dies sind die Prozessmodellierung, die Prozesssteuerung und die Prozesskontrolle. Die Prozessmodellierung stellt die Werkzeuge zur Verfügung, um einzelne Aufgaben miteinander zu verknüpfen, Ressourcen und Reihenfolgen zuzuordnen sowie Subprozesse zu definieren. Ein denkbares Werkzeug ist das ARIS-Toolset mit den ereignisgesteuerten Prozessketten (EPK). Ferner wird im Rahmen der Prozesssteuerung die Ausführung der einzelnen Arbeitsschritte innerhalb eines modellierten Geschäftsprozesses ermöglicht. Um die entsprechenden Nachrichten nacheinander an die richtigen Anwendungen leiten zu können, bedarf es einer engen Kopplung mit der Kommunikationsschicht, welche im folgenden Abschnitt erläutert wird. Schließlich gestattet die Prozesskontrolle die automatische Protokollierung und Überwachung der Fortschritte aller Geschäftsprozesse. Auf diese Weise können Statusinformationen abgerufen werden, Alarme bei Zeitüberschreitungen definiert und statistische Analysen erstellt werden. Dieser Vorgang wird auch als Prozessmonitoring bezeichnet [Ke02, S , Ka02, S ] Kommunikationsschicht Eng mit der Prozessschicht verbunden ist die Kommunikationsschicht. Sie ist hauptverantwortlich für den Transport von Nachrichten zwischen Sendern und Empfängern, so dass die Kommunikation unter verschiedenen Anwendungen sowie der Austausch von Informationen ermöglicht werden. Zunächst ist es hierbei von Interesse, welche EAI- Infrastruktur eingesetzt und welche Kommunikationsart verwendet wird. 9

10 So lassen sich unter einer EAI-Infrastruktur die drei grundlegenden Modelle Punkt-zu- Punkt (P2P)-Infrastrukturen, Bus-Infrastrukturen und EAI-Server unterscheiden. Diese Modelle basieren auf den in Kapitel 2.3 angesprochenen Architekturen zur A2A- Integration (Spaghetti-Kommunikations-, Bus- und Hub & Spoke-Architektur) und werden in diesem Abschnitt hinsichtlich ihrer Funktionalität näher betrachtet. Eine P2P-Infrastruktur zeichnet sich dadurch aus, dass die Kommunikation über immer denselben Protokollstack zwischen zwei gleichen Teilnehmern (Peers) erfolgt. Ein derartiges Beispiel ist Distributed Computing Environment (DCE), ein Konzept für die Festlegung von Diensten und Werkzeugen, die die Erzeugung, Benutzung und Administration von verteilten Anwendungen unterstützt. Hierbei wird die Verbindung zwischen Sender und Empfänger über so genannte Remote Procedure Calls (RPCs) ermöglicht. Ein RPC ist ein Netzwerkprotokoll aus der fünften und sechsten Schicht des I- SO/OSI-Modells. Durch diesen Mechanismus kann über ein Netzwerk die direkte Kommunikation zwischen einzelnen, auf verschiedenen Systemen ablaufenden Komponenten, ermöglicht werden. Hierbei wird einer lokalen Anwendung durch so genannte Stubs die Funktionalität der entfernten Anwendung zur Verfügung gestellt. Ein Stub ist eine Kopie des entfernten Objektes, die aber nur die einzelnen Methoden als Interface bereitstellt, jedoch nicht implementiert. Aufrufe einer Methode am Stub werden über eine Middleware, welche später in Kapitel 3.5 näher erläutert wird, an das entfernte Objekt übergeben und dort ausgeführt. Bei Aufruf einer Funktion im Stub wird diese über die RPC-Laufzeitumgebung an die entfernte Anwendung übertragen, bearbeitet und das Ergebnis zurückgegeben. Für den Benutzer ist dieser Vorgang völlig transparent, er arbeitet auf entfernten Objekten mit deren Funktionen, als wären sie lokal in seiner Umgebung vorhanden. Die Middleware übernimmt dabei die Verwaltung der Objekte und die Kommunikation. Das zweite Modell Bus-Infrastrukturen, wie z. B. die objektorientierte Common Object Request Broker Architecture (CORBA), basiert auf dem Gedanken, alle Nachrichten über Adapter in eine intern einheitliche Form zu konvertieren. CORBA ist eine standardisierte, sprachunabhängige objektorientierte Middleware, die Protokolle und Dienste für das Erstellen verteilter Anwendungen in heterogenen Umgebungen, definiert. Unter anderem bietet sie Zugriff auf entfernte Objekte über entfernte Methodenaufrufe. Dieser Mechanismus ähnelt sehr stark dem Grundprinzip eines RPCs. Der Unterschied liegt neben der Objektorientierung in der Bezeichnung der Stubs sowie in der Anzahl und Mächtigkeit der angebotenen Dienste. Während bei einem RPC von Stubs (genauer Client und Server-Stub) gesprochen wird, werden diese in CORBA Client-IDL-Stub (IDL für Interface Definition Language) und Static Skeleton bezeichnet. Darüber hinaus bietet CORBA im Gegensatz zu RPC eine Fülle an weiteren Diensten. Eine Liste mit derartigen CORBA-Diensten kann in [Or96] nachgelesen werden. 10

11 Die Idee der dritten und letzten Variante einer EAI-Infrastruktur ist es, zentrale EAI- Server zu verwenden, an welche die Nachrichten übermittelt und wo sie auch zentral behandelt werden. Dies entspricht in etwa einer Hub & Spoke Architektur, wie sie in Kapitel 2.4 beschrieben wurde. Ein Beispiel für einen solchen Server ist Vitria BusinessWare. Auf diese und weitere EAI-Server wird in der an diese Ausarbeitung anschließenden Seminararbeit Enterprise Application Integration 2 detailliert eingegangen. Die Kommunikationsart ist nach den beiden Typen synchron und asynchron zu unterscheiden. Bei synchroner Kommunikation ist der Sender an den Empfänger gekoppelt und kann erst weiterarbeiten, sobald er eine Antwort vom Empfänger erhält. Der vorhin angesprochene RPC ist ein Beispiel der synchronen Kommunikation. Die asynchrone Kommunikation unterscheidet sich dahingehend, dass der Sender nach dem Verschicken seiner Nachricht nicht mehr an den Empfänger gekoppelt ist und somit an anderen Dingen weiterarbeiten kann. Eine genauere Betrachtung der einzelnen Kommunikationsstile synchroner und asynchroner Kommunikation wird in Kapitel 3.4 vorgenommen. Neben dem einfachen Transport von Nachrichten muss die Kommunikationsschicht weitere Aufgaben erfüllen. Es müssen Daten in entsprechende Formate umgewandelt als auch Synchronisationsdienste bereitgestellt werden. Die Transformation von Daten wird notwendig, wenn aus verschiedenen Datenbanksystemen Informationen ausgelesen werden und in einer standardisierten Nachricht an eine Zielanwendung weitergesendet werden sollen. Die Datensätze aus verschiedenen relationalen und objektorientierten Datenbanken müssen dann in ein einheitliches Format, wie z. B. das in EAI- Infrastrukturen am häufigsten genutzte Format XML, transformiert werden. Dazu kommen aus dem Data-Warehouse-Umfeld bekannte Extraktion-Transformation- Laden-Tools (ETL-Tools) zum Einsatz. So können Daten entweder über Algorithmen transformiert, oder durch Look-up-Tabellen auf entsprechende Schemata gemapped werden. Der alleinige Einsatz von XML bedeutet aber noch keine Normierung. Sofern XML als Format für den Inhalt von Nachrichten verwendet wird, sollte es weiterhin eine zentrale Stelle im Unternehmen sowie auch unternehmensübergreifend geben, die die Vokabulare und Dokumentenformate einheitlich festlegt. Des Weiteren dienen die Synchronisationsdienste der internen Regelung von zeitlichen Abläufen beim Nachrichtenversand. Die Verwaltung von Nachrichtenschlangen (Message-Queues) gehört dabei zu einer zentralen Aufgabe. Erreichen eine Anwendung mehrere Nachrichten zur gleichen Zeit, sind diese entweder zu verwerfen, mit Prioritäten zu versehen oder einfach nur in eine Warteschlange einzureihen. Die Länge von Schlangen muss genauso festgelegt werden, wie maximale Wartezeiten und Garantien für Weiterleitung und Zustellung von Nachrichten. 11

12 Wie in dem Abschnitt zur Prozessschicht dargelegt, können Nachrichten zum einen durch einen Prozess in der Prozessschicht entstehen und zum anderen auch extern durch einen Adapter in der Protokoll-Adapterschicht ausgelöst werden. Die Kommunikationsschicht stellt somit die zentrale Schicht dieser Referenzarchitektur dar, welche den Transport der Nachrichten erledigt und die anderen beiden Schichten verbindet [Ke02, Kap. 3, 4 und Ka02, Kap. 4] Protokoll-Adapterschicht Vervollständigt wird die EAI-Referenzarchitektur durch die Protokoll-Adapterschicht. Sie ist für die Umwandlung von externen Auslösern, wie z. B. s, http-requests, Funktionsaufrufen, Datenbankupdates und anderen externen Ereignissen in das interne Nachrichtenformat des EAI-Servers zuständig. Dafür werden in dieser Schicht wiederum Funktionalitäten, zum einen des Transports von Nachrichten und zum anderen der Datentransformation in genormte Nachrichtenformate, bereitgestellt. Der Unterschied zu der Kommunikationsschicht liegt in der Tatsache, dass diese Datentransformation zwischen einem externen System und dem EAI-Integrationsserver und nicht innerhalb des EAI-Servers stattfindet. Adapter sind Softwarebausteine, welche die Kopplung verschiedener Anwendungen ermöglichen. Da Adapter stets an die spezifischen Schnittstellen der einzelnen Anwendungen angepasst werden müssen, existiert eine Vielzahl unterschiedlicher Ausprägungen. Durch Integrationslösungen angebotene, vorgefertigte Adapter können sich dabei nur auf generelle Standards konzentrieren, da die Vielfalt der Schnittstellen von Altsystemen nicht abzubilden ist. In der Rechnerkommunikation kommen z. B. Standards wie TCP/IP, IPX, X.500 oder SPX zum Einsatz. Der Austausch von Daten kann über Standards wie OAGIS, EDIFACT, XML oder ANSI geregelt sein. Nicht jede Altanwendung muss sich zwingend eines Standards bedienen. Selbstdefinierte Datenformate und Kommunikationsmechanismen sind besonders in Altanwendungen verbreitet. So kommen in der Anwendungslandschaft von vielen Unternehmen Systeme zum Einsatz, die vor vielen Jahren geschrieben wurden und neben TCP/IP zur Kommunikation auf keine weiteren Standards zurückgreifen. Die Anpassung und Entwicklung von Adaptern ist folglich für jedes Integrationsprojekt neu durchzuführen und somit fester Bestandteil jeder EAI-Lösung [Ke02, Kap. 3,4 und Ka02, S. 100, 101]. 3.2 Weitere Funktionalitäten von EAI-Servern Nachdem im vorherigen Kapitel einige funktionale Charakteristika anhand einer EAI- Referenzarchitektur beschrieben wurden, geht es in diesem Abschnitt um weitere funktionale und nichtfunktionale Eigenschaften, die für das Design und die damit verbunde- 12

13 nen Kosten eines EAI-Softwaresystems von enormer Wichtigkeit sind und noch nicht in der EAI-Referenzarchitektur erwähnt wurden Funktionale Eigenschaften Zu den technischen Funktionalitäten, auf die bei dem Einsatz eines EAI-Systems zu achten ist, gehört die Qualität der Nachrichtenübermittlung. Im Idealfall wird eine Auslieferung der gesendeten Nachrichten vollständig garantiert. Überdies ist eine hohe Konnektivität eine weitere wichtige Fähigkeit, die ein EAI-Server bieten sollte. Unter Konnektivität wird die Möglichkeit der Verständigung des EAI-Servers mit möglichst vielen Programmier- und Betriebssystemumgebungen verstanden. Außerdem sollten weitere Aufgaben, wie die Bestimmung des Weges einer Nachricht vom Sender bis zum Empfänger (Routing), eine Ordnung in den Nachrichten für einen Überblick über alle Nachrichtentypen und -formate sowie ein Namensdienst, bereitgestellt werden. Ein Namensdienst ermöglicht die Verwendung symbolischer Namen statt technischer Bezeichner von Objekten. Daneben sind auch verschiedene Sicherheitskonzepte wichtige funktionale Eigenschaften eines EAI-Systems. In diesem Zusammenhang sind eine verschlüsselte Kommunikation, Authentifizierung und Autorisierung der Benutzer sowie ein Auditing notwendig. Bei der Authentifizierung wird versucht, die einen Dienst anfordernde Person oder anforderndes System eindeutig zu identifizieren, während bei der Autorisierung Berechtigungen geprüft werden. Das Auditing zeichnet schließlich alle Aktivitäten im Netzwerk genau auf und ermöglicht die Rückverfolgung von Angriffen. Für die Bereitstellung dieser Sicherheitskonzepte gibt es zwei Möglichkeiten. Entweder müssen sie selber implementiert werden oder es werden im Falle der Nutzung eines Integrationsservers, der auf eine spezielle Implementierung aufsetzt, dessen Sicherheitsdienste genutzt. Z. B. können bei einer CORBA-Implementierung die CORBA Sicherheitsdienste genutzt werden [Ke02, S , Ka02, S ]. Die Kosten für die Aufrechterhaltung und Wartung von EAI-Systemen sind ein weiterer wichtiger Gesichtspunkt, der bei EAI-Infrastrukturen beachtet werden sollte. Vor allem ist es von großem Interesse, eine Verfügbarkeit des Systems für 24 Stunden pro Tag, 7 Tage die Woche zu gewährleisten. Um diese ständige Verfügbarkeit zu erreichen, sollte das EAI-System über eine Lastverteilung auf mehrere Server (Load-Balancing) und eine gegenseitige Vertretung bei Ausfall (Fail-over) verfügen. Weiterhin sollten Fähigkeiten, wie Fernüberwachung von Systemen (Monitoring), Systemwiederherstellung nach Abstürzen (Recovery) sowie geeignete Mechanismen zum Auffinden und Beseitigen von Programmfehlern (Debugging) vorhanden sein. Auch eine plattformunabhängige Verteilung der Laufzeitkomponenten auf mehrere Rechner, welche sich nicht auf die 13

14 Verwaltung des Systems auswirkt (Transparente Verteilbarkeit), sollte als Kriterium für die Auswahl eines EAI-Servers beachtet werden [Ke02, S ] Nichtfunktionale Eigenschaften Zu den nichtfunktionalen Eigenschaften eines EAI-Softwaresystems zählt vor allem die Performance. Als Performance wird die Antwortzeit auf eine bestimmte Anfrage bezeichnet. Je schneller ein System auf eine Eingabe reagiert, desto besser ist die Performance. Allein im Falle einer schlechten Performance wird ein EAI-System, bei dem alle anderen funktionalen Eigenschaften sehr gut sind, nicht zum Einsatz kommen, da es von den Benutzern nicht akzeptiert werden würde. Ein derartiges Beispiel ist ein Online-Shop, der mehrere Minuten für den Aufbau einer neuen Seite braucht. Als zusätzliche nichtfunktionale Eigenschaften sind hierbei eine mögliche Performanceverbesserung durch Hinzufügen weiterer Hardware-Ressourcen (Skalierbarkeit), die Zuverlässigkeit des gesamten Systems, die Qualität der mitgelieferten Tools sowie die Markenposition des Herstellers zu nennen. Da aktuell sehr viele EAI-Anbieter vorhanden sind, ist davon auszugehen, dass ein Großteil dieser Anbieter in naher Zukunft verschwinden wird und wenige große Anbieter übrig bleiben werden [Ke02, S ]. 3.3 Integrationsmethoden Wie in Kapitel 2.3 angesprochen gibt es 3 verschiedene Methoden, nach denen vorgegangen werden kann, unterschiedliche Systeme in einem Unternehmen zu integrieren. Diese drei Methoden, bei denen die Integration über Benutzungsschnittstellen, Funktionsaufrufe und Datenbanken vollzogen wird, orientieren sich an der aus dem Software- Engineering gängigen 3-Schichtenarchitektur (Präsentationsschicht, Geschäftslogikschicht und Datenhaltungsschicht) für betriebliche Informationssysteme [Ba01], welche auch als Präsentations-, Funktions- und Datenebene bezeichnet werden können. Diese, wie auch eine technische Variante der Integration über Benutzungsschnittstellen, die so genannte Integration über Workflow, sind in Abb. 5 dargestellt. Zu Ende dieses Unterkapitels wird noch auf eine weitere, immer mehr eingesetzte Integrationsmethode, auf die Integration von Komponenten, eingegangen. Der Einsatz in einem Unternehmen beschränkt sich hierbei nicht nur auf die eine oder andere Integrationsmethode, sondern meist auf alle in verschieden starken Ausprägungen [Ke02, S. 60, 61]. 14

15 System A Benutzungsschnittstelle Anwendungskern Datenhaltung System B Benutzungsschnittstelle Anwendungskern Datenhaltung Integration über Workflow Integration der Benutzungsschnittstellen Integration über Funktionsaufrufe Integration über föderierte Datenbanken Abbildung 5: Integrationsmethoden Quelle: [Ke02, S. 60] Integration über die Benutzungsschnittstelle Bei der Integration über die Benutzungsschnittstelle wird auf die Präsentationsschicht der Anwendungen zugegriffen. Besonders alte Anwendungen bieten lediglich grafische Eingabedialoge anstelle von Schnittstellen zum Zugriff auf Funktionen an. In solchen Fällen muss die integrierende Anwendung gegenüber dem Altsystem wie ein menschlicher Benutzer auftreten, Daten in die Benutzeroberfläche einpflegen und Ergebnisse auslesen. Die Idee hierbei ist, neue Benutzungsschnittstellen auf alte aufzusetzen. Diese nehmen Daten entgegen, pflegen sie in die Benutzungsschnittstelle der Altanwendung ein, lesen die entsprechenden Ergebnisse aus und stellen sie dem Anwender auf seiner neuen Benutzerschnittstelle dar. Dies kann durch verschiedene Techniken realisiert werden. Eine dieser Techniken ist die so genannte Screen Scraping Technik. Sie liest Daten an verschiedenen Bildschirmkoordinaten oder aus Datenflüssen ab und wandelt sie in die benötigten Formate um. Die Web-Integration mit Frames ist ein weiteres Verfahren, bei dem einzelne Frames verschiedener Web-Server in einer neuen Anwendung vereint werden. Darüber hinaus eignen sich auch Workflow-Management-Tools für die Oberflächenintegration mehrerer existierender Anwendungen. Derartige Tools verwalten Instanzen von Geschäftsprozessen, die aus einer Folge von Aktivitäten bestehen. Um Informationen zwischen Benutzungsschnittstellen verschiedener Systeme entlang der Aktivitäten eines Geschäftsprozesses auszutauschen, wird in diesem Fall wiederum die Screen-Scraping- Technik eingesetzt. Das Ziel, das durch diese Integration erreicht werden soll, ist eine bessere Benutzbarkeit und Funktionalität sowie eine konsistente Führung durch die Geschäftsprozesse zu schaffen. Der Nachteil dieser Vorgehensweise liegt darin, dass nur auf die durch die 15

16 Benutzeroberfläche der Altanwendung zur Verfügung gestellten Funktionalitäten zugegriffen werden kann [Ke02, S , Ka02, S. 62, 63] Integration über Funktionsaufrufe Die Integration über Funktionsaufrufe stützt sich auf die von den Anwendungen angebotenen Funktionalitäten. Die Anwendungen stellen dabei Anbieter von Diensten dar. Geschäftsprozesse, die aus einer Vielzahl einzelner Tätigkeiten bestehen, welche von verschiedenen Anwendungen ausgeführt werden, können auf diese Weise die benötigten Funktionen direkt ansprechen und aufrufen. Einfach ausgedrückt wird aus einer Anwendung die Funktionalität einer anderen Anwendung aufgerufen. Darüber hinaus ist es von Interesse, ob eine Anwendung eine fremde Funktionalität auf demselben Rechner oder auf einem anderen Rechner aufruft. Während im ersteren Fall keine besondere Infrastruktur erforderlich ist, werden im letzteren Fall Infrastrukturen wie DCE oder CORBA benötigt, damit entfernte Methodenaufrufe genutzt werden können [Ke02, Kap. 4, Ka02, S ] Integration über Datenbanken Bei der Integration über Datenbanken wird direkt auf die von den verschiedenen Anwendungen erzeugten Daten zugegriffen. Dies geschieht ohne Umwege über die Funktions- oder Präsentationsschicht. Eine Modifikation der Datenbanken oder der Anwendungslogik der zu integrierenden Anwendung ist somit nicht erforderlich. Der direkte Zugriff auf die Datenbasen dient dem gemeinsamen Gebrauch oder dem Abgleich redundanter Daten zwischen den Anwendungen. Als technische Realisierungsmöglichkeiten bietet sich neben dem direkten Zugriff auf die Datenbestände die gemeinsame Nutzung föderierter Datenbanken über Middleware an, auf welche in Kapitel 3.5 genauer eingegangen wird [Ke02, S. 67,68, Ka02, S.63-65] Integration über Komponenten Eine weitere Integrationsform ist die Integration über Komponenten. Eine Komponente stellt in diesem Fall ein Stück Software mit einer Schnittstelle dar. Zu dieser Variante der Integration können drei verschiedene Fälle unterschieden werden [Ke02, S ]. Zunächst besteht mit einem so genannten Plug-in die Möglichkeit eine Softwarekomponente in ein anderes Softwareprodukt einzuklinken. Hierbei muss das Softwareprodukt, in das sich eingeklinkt wird, über eine vordefinierte Schnittstelle verfügen, so dass für die Nutzung der anderen Softwarekomponente eine Erweiterung (Plug-in) programmiert werden kann. Weit verbreitete Beispiele für Plug-ins sind das Adobe Rea- 16

17 der/acrobat Plug-in oder der Macromedia Flash Player für die verschiedenen Webbrowser. Darüber hinaus ist es möglich, vorgefertigte Komponenten mittels eines Klebstoffs, welcher als GlueWare bezeichnet wird, zu integrieren. Die zentrale Idee dieses Vorgehens liegt in der Tatsache, dass mehrere Softwarekomponenten über Skriptsprachen relativ schnell integriert werden können. Wie bereits in Kapitel 2.2 beschrieben wird GlueWare vorzugsweise für die Integration von ERP-Software in die im Unternehmen bereits vorhandenen Anwendungen genutzt. Als letztes Szenario ist die Integration von Komponenten in so genannten Containern von Bedeutung. Durch die Verwendung eines Containers werden dem Anwendungsentwickler bestimmte Basisdienste wie z. B. Transaktionen, Persistenz und Zugriff auf entfernte Objekte geschenkt. Der Vorteil dieses Vorgehens liegt darin, dass der Programmierer im günstigsten Fall nur noch fachlichen Code schreiben muss, um die Komponenten zu erstellen sowie miteinander zu verbinden [Ku04, S.33]. 3.4 Kommunikationsarten Wie bereits in Kapitel angesprochen lassen sich die zwei verschiedenen Kommunikationsarten synchron und asynchron unterscheiden. Dieser Abschnitt dient der Erläuterung der dazugehörigen Kommunikationsstile, welche in einem EAI-Integrationsserver Verwendung finden können [Ke02, S und S ]. Überdies können Kommunikationsvorgänge neben diesem Unterscheidungsmerkmal zusätzlich noch nach den Kriterien verbindungslos- oder verbindungsorientiert sowie direkte- oder Warteschlangenkommunikation unterschieden werden. Im Gegensatz zu diesen beiden Kriterien wird die Kommunikationsart in [Ka02, S. 103] nur nach dem unterstützten Adressierungsmechanismus (Uni-, Broad- und Multicasting) charakterisiert, welche aber nicht so ausführlich ist, und auf welche deswegen in dieser Arbeit nicht näher eingegangen wird. Verbindungsorientiert bedeutet, dass Sender und Empfänger eine Verbindung aufbauen, Nachrichten austauschen, und anschließend diese Verbindung wieder trennen. Typischerweise ist dies ein synchroner Prozess, welcher aber auch asynchron sein kann. Demgegenüber bezeichnet verbindungslose Kommunikation einen Vorgang, bei dem der Sender keine Verbindung mit dem Empfänger eingeht. Im Allgemeinen weiß der Sender in diesem Fall nicht einmal, ob jemand seine Nachricht empfangen oder verarbeitet hat. Bei direkter Kommunikation wird die Nachricht ohne Umwege direkt vom 17

18 Sender zum Empfänger übermittelt. Eine Kommunikation mit Warteschlangen bietet hingegen eine Garantie für die Auslieferung der Nachrichten. Der Vorteil dieses Modells gegenüber der direkten Kommunikation liegt in der Tatsache, dass der Empfänger nicht aktiv sein muss, wenn der Sender ihm eine Nachricht schickt [Li99, S. 115] Synchrone Kommunikation Synchrone Kommunikation bedeutet, dass die Sender nach Verschicken der Nachricht solange blockieren, bis sie eine Antwort oder ein Ergebnis vom Empfänger erhalten. Dieses Verhalten, welches auch als Request/Reply-Stil bezeichnet wird, ist nur dann sinnvoll, wenn davon ausgegangen werden kann, dass der Empfänger empfangsbereit ist und schnell antworten kann. Anderenfalls, z. B. bei Absturz des Empfängers, könnte es dazu kommen, dass der Sender auf unbestimmte Zeit auf eine Antwort wartet und sich somit keinen anderen Aufgaben widmen kann. Aufgrund dieses Nachteils wird in der Mehrzahl von EAI-Systemen nicht die synchrone, sondern die asynchrone Kommunikation verwendet. Bevor auf diese im nächsten Abschnitt eingegangen wird, werden zunächst zwei Varianten der synchronen Kommunikation vorgestellt, die synchrone Einwegkommunikation sowie das synchrone Polling. Das Spezielle an der synchronen Einwegkommunikation im Gegensatz zur normalen synchronen Kommunikation liegt darin, dass der Empfänger, bevor er die Anfrage bearbeitet, eine Empfangsbestätigung an den Sender zurückschickt. Diese Variante ist in dem Fall von Vorteil, wenn der Sender lediglich wissen muss, dass seine Anfrage angekommen ist und bearbeitet wird. Bei der anderen Variante des synchronen Pollings fragt der Sender in bestimmten Zeitintervallen nach, ob seine Anfrage erledigt wurde und somit eine Antwort zurückgegeben werden kann. In der Zwischenzeit kann der Sender seine interne Verarbeitung fortsetzen. Erst wenn diese Nachfrage Erfolg hat, arbeitet der Sender mit dem Ergebnis weiter. Beide dieser Varianten haben den Vorteil, dass die Zeit, in der der Sender nicht weiterarbeiten kann, reduziert wird. Folglich wird der eigentliche Nachteil der synchronen Kommunikation ein wenig abgeschwächt [Ke02, S.80-82] Asynchrone Kommunikation Bei asynchroner Kommunikation, auch Message Passing genannt, arbeitet der Sender nach dem Abschicken einer Nachricht bereits weiter, ohne auf eine Antwort zu warten. Die Anfrage verbleibt dann unter Umständen längere Zeit in der Anfrageschlange beim Empfänger, ohne den Prozess komplett zu blockieren. Eine solche Entkopplung ermöglicht eine sehr flexible Arbeitsweise der Anwendungen. Neben dem Begriff Message 18

19 Passing wird dies auch als fire and forget bezeichnet. Die beiden hier in Frage kommenden Varianten sind die Broadcasting- und Publish/Subscribe-Kommunikation. Beim Broadcasting schickt der Sender die Nachricht über einen öffentlichen Kanal ab. Jeder Empfänger, der Zugang zu diesem Nachrichtenmedium hat, kann die Nachrichten verwerten oder nicht. Die grundsätzliche Idee hinter der Publish/Subscribe-Kommunikation ähnelt der des Broadcastings mit dem Unterschied, dass die Nachricht nur an Empfänger zugestellt wird, die im Vorhinein diese Nachricht oder das Thema der Nachricht abonniert haben [Ke02, S und Ju01 S.345] 3.5 Middleware Middleware ist eine Software, die es unabhängigen und verteilten Software-Produkten gestattet, miteinander zu interagieren, indem sie die jeweiligen Interaktionshindernisse beseitigt und die Interaktion gegebenenfalls durch Eigenleistungen unterstützt oder mitgestaltet. Durch einen homogenisierten Zugang zum Netzwerk wird ein plattformunabhängiger Datenaustausch zwischen Anwendungen unterschiedlicher Art ermöglicht [Rö01, S.10]. Aufgrund der begrifflichen Ähnlichkeit zu dem Hauptbegriff dieser Arbeit, wird hier zunächst eine Differenzierung zur Enterprise Application Integration vorgenommen. Der Unterschied zur EAI liegt darin, dass sich Middleware auf die interne Kommunikationsinfrastruktur eines Informationssystems bezieht, während EAI auf die externe Kommunikationsinfrastruktur zwischen verschiedenen Informationssystemen bezogen ist. Daher ist Middleware im Gegensatz zu EAI nicht in der Lage Geschäftsprozesse, die auf mehrere Systeme zugreifen, abzubilden. Middleware kann deshalb auch als zentraler Bestandteil von EAI-Lösungen gesehen werden, welcher die Integration auf Datenebene unterstützt. Der Informationsaustausch wird hierbei zwischen zwei oder mehreren Anwendungssystemen innerhalb einer heterogenen IV-Landschaft ermöglicht [Ka02, S. 102]. Grundsätzlich können vier Typen von Middleware unterschieden werden. Diese sind die Nachrichten-, Komponenten-, Datenbank- und Transaktionsorientierte-Middleware [Ka02, S. 104]. Für die im Abschnitt 3.3 besprochene Integration über Funktionsaufrufe kommt die Nachrichten- und die Komponentenorientierte Middleware in Frage, während für die Integration über Datenbanken, wie der Name es schon sagt, Datenbankorientierte Middleware eingesetzt wird [Ke02, S. 86]. Nachrichtenorientierte Middleware (MoM) ermöglicht den angebundenen Anwendungen eine Kommunikation durch die Nachrichtenweitergabe über Punkt-zu-Punkt- 19

20 Verbindungen. Durch die MoM wird eine standardisierte Schnittstelle zur Kommunikation zwischen heterogenen Plattformen angeboten. Ein Client muss also nur das Format der Nachrichten kennen und kann auf diese Weise mit jeder dieser über die Middleware angebundenen Anwendung in Verbindung treten, ohne deren spezifische Schnittstellen zu kennen. Hier können Nachrichten sowohl Datenstrukturen enthalten als auch Funktionsaufrufe darstellen. Eine Integration kann also auf Daten- und Funktionsebene vollzogen werden. Die Nachrichten werden automatisch an die entsprechenden Empfänger weitergeleitet. Dazu müssen alle Teilnehmer über Adapter mit der Middleware verbunden werden. Durch den Einsatz von Adressierungskonzepten werden sowohl Punkt-zu- Punkt-Verbindungen ermöglicht als auch Gruppenkommunikation im Sinne von Broadcasting und Publish/Subscribe Diensten. Zudem verfügt das Kommunikationssystem neben den Adressierungs- und Routingfunktionen auch über Verwaltungsmechanismen für Nachrichtenschlangen (Message Queues). Die Kommunikation kann wiederum entweder synchron ablaufen oder aber asynchron [Ka02, S ]. Die meisten EAI- Lösungen basieren jedoch auf einer MoM, die sich vorwiegend der asynchronen Kommunikation bedient. Dies hat unter anderem die Gründe, dass mit asynchroner Kommunikation, welche eine sehr allgemeine Kommunikationsform ist, alle anderen Formen nachgebildet werden können sowie dass sie hervorragend für lose gekoppelte Systeme geeignet ist. Weitere Ursachen können in [Ke02, S. 86] nachgelesen werden. Komponentenorientierte Middleware, auch Distributed Object Technology (DOT) genannt, ermöglicht den Aufruf von Funktionen verteilter und heterogener Anwendungen. Zur Integration auf Funktionsebene wird nach dem Grundprinzip der Remote Procedure Calls, oder in Java der Remote Method Invocation (RMI), verfahren. Die Middleware verwaltet hierbei die Objekte und steuert die Kommunikation. Die Kommunikation findet meist synchron nach dem Request/Reply Schema statt, das heißt, der Sender blockiert solange, bis er eine Antwort erhält. Ein etablierter Standard ist CORBA. Eingesetzt wird DOT auch in Microsofts Distributed Component Object Model (DCOM/COM+) mittels versionierter Interfaces (DLL) und bei J2EE mittels Enterprise Java Beans (EJB) [Ka02, S und Ke02, S ]. Datenbankorientierte Middleware ist die klassische Middleware-Form, die über einheitliche Schnittstellen den Zugriff auf heterogene Datenbestände ermöglicht. Ziel dieser Software ist die integrierte Sicht auf verteilte Daten im Sinne einer einzelnen virtuellen Datenbank. So kann jeder Client über eine einheitliche Schnittstelle an der virtuellen Datenbank Anfragen an jede beliebige, mit der Middleware verbundene Datenbank stellen und zwar ohne sich deren Ort bewusst zu sein oder ihre spezifische Syntax zu kennen. Für den Benutzer erfolgt der Ablauf also völlig transparent. Zur technischen Realisierung wird durch die Middleware entweder direkt auf die Schnittstellen der einzelnen Datenbanken zugegriffen, oder es werden Standardschnittstellen im Sinne von Call Le- 20

Enterprise Application Integration

Enterprise Application Integration 2008 AGI-Information Management Consultants May be used for personal purporses only or by libraries associated to dandelon.com network. Wolfgang Keller Enterprise Application Integration Erfahrungen aus

Mehr

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

Mehr

Enterprise Application Integration Erfahrungen aus der Praxis

Enterprise Application Integration Erfahrungen aus der Praxis Enterprise Application Integration Erfahrungen aus der Praxis Teil 1: Begriffe, Anwendungen Tutorial NODs 2002, Wolfgang Keller and Generali 2001, 2002, all rights reserved 1 Überblick Abgrenzung des Begriffes

Mehr

Hauptseminar Management von Softwaresystemen. Techniken der System-Integration EAI, Middleware, SOA, CORBA

Hauptseminar Management von Softwaresystemen. Techniken der System-Integration EAI, Middleware, SOA, CORBA Hauptseminar Management von Softwaresystemen Techniken der System-Integration EAI, Middleware, SOA, CORBA Betreuerin: Referent: Ulrike Hammerschall Alexey Krivoborodov Agenda Motivation Arten der Verteilung

Mehr

Einsatz von Applikationsservern. Untersucht am Beispiel des Sybase Enterprise Application Server

Einsatz von Applikationsservern. Untersucht am Beispiel des Sybase Enterprise Application Server Einsatz von Applikationsservern Untersucht am Beispiel des Sybase Enterprise Application Server Architektur von Datenbanksystemen Client / Server Modell (2 Schichten Modell) Benutzerschnittstelle Präsentationslogik

Mehr

1 Entwicklung der Anwendungslandschaften von Versicherungsunternehmen

1 Entwicklung der Anwendungslandschaften von Versicherungsunternehmen EAI in einer Versicherung: Erschließung von Bestandssystemen mit EAI 89 1 Entwicklung der Anwendungslandschaften von Versicherungsunternehmen Da Versicherungen vor allem Informationsverarbeiter sind, betreiben

Mehr

Guten Tag! CampusSource. Die CSE Integration Platform. CampusSource Engine. Christof Pohl Softwareentwicklung Medienzentrum Universität Dortmund

Guten Tag! CampusSource. Die CSE Integration Platform. CampusSource Engine. Christof Pohl Softwareentwicklung Medienzentrum Universität Dortmund Engine Die CSE Integration Platform Guten Tag! Christof Pohl Softwareentwicklung Medienzentrum Universität Dortmund Integriertes Informationsmanagement mit der Engine - A2A vs. EBI Folie 2 Integration

Mehr

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble Vertiefungsarbeit von Karin Schäuble Gliederung 1. Einführung 3. Rahmenbedingungen in der heutigen Marktwirtschaft 3.1 Situation für Unternehmen 3.2 Situation für Applikationsentwickler 4. Lösungskonzepte

Mehr

Stand September 2010. TransConnect Die Plattform für skalierbare Anwendungsintegration

Stand September 2010. TransConnect Die Plattform für skalierbare Anwendungsintegration Stand September 2010 TransConnect Die Plattform für skalierbare Anwendungsintegration Herausforderungen für EAI-Lösungen Spezialisierte Anwendungssysteme ERP CRM ecommerce Gesundheitswesen Produktion Herausforderungen

Mehr

Softwareentwicklung mit Enterprise JAVA Beans

Softwareentwicklung mit Enterprise JAVA Beans Softwareentwicklung mit Enterprise JAVA Beans Java Enterprise Edition - Überblick Was ist J2EE Java EE? Zunächst mal: Eine Menge von Spezifikationen und Regeln. April 1997: SUN initiiert die Entwicklung

Mehr

Remote Communications

Remote Communications HELP.BCFESDEI Release 4.6C SAP AG Copyright Copyright 2001 SAP AG. Alle Rechte vorbehalten. Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher

Mehr

Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung

Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung IBM WebSphere Process Server Seminar Business Process Management und Workflow-Technologie: Grundlagen, Produkte, Forschung AGENDA 1. Überblick 2. WebSphere Process Server 3. Komponenten 4. Präsentation

Mehr

CORBA. Systemprogrammierung WS 2006-2007

CORBA. Systemprogrammierung WS 2006-2007 CORBA Systemprogrammierung WS 2006-2007 Teilnehmer: Bahareh Akherattalab Babak Akherattalab Inhaltsverzeichnis: Verteilte Systeme Vergleich zwischen lokale und verteilte Systeme Verteilte Anwendungen CORBA

Mehr

Entwicklung von Web-Anwendungen auf JAVA EE Basis

Entwicklung von Web-Anwendungen auf JAVA EE Basis Entwicklung von Web-Anwendungen auf JAVA EE Basis Java Enterprise Edition - Überblick Prof. Dr. Bernhard Schiefer Inhalt der Veranstaltung Überblick Java EE JDBC, JPA, JNDI Servlets, Java Server Pages

Mehr

Kap. 6 Message-Oriented Middleware (MOM)

Kap. 6 Message-Oriented Middleware (MOM) Kap. 6 Message-Oriented Middleware (MOM) 6.1Asynchrone Prozedur- bzw. Methodenaufrufe Lose Kopplung von Komponenten 6.2Queued Transactions Entkopplung von Client/Server-Transaktionen 6.3Publish/Subscribe-Techniken

Mehr

1 Einleitung. Betriebswirtschaftlich administrative Systeme

1 Einleitung. Betriebswirtschaftlich administrative Systeme 1 1 Einleitung Data Warehousing hat sich in den letzten Jahren zu einem der zentralen Themen der Informationstechnologie entwickelt. Es wird als strategisches Werkzeug zur Bereitstellung von Informationen

Mehr

Kap. 6 Message-Oriented Middleware (MOM)

Kap. 6 Message-Oriented Middleware (MOM) Kap. 6 Message-Oriented Middleware (MOM) G 6.1Asynchrone Prozedur- bzw. Methodenaufrufe Lose Kopplung von Komponenten G 6.2Queued Transactions Entkopplung von Client/Server-Transaktionen G 6.3Publish/Subscribe-Techniken

Mehr

Districurement. New Economy Districurement Page 1

Districurement. New Economy Districurement Page 1 Districurement Titel des Lernmoduls: Districurement Themengebiet: New Economy Gliederungspunkt im Curriculum: 2.2.1.3.2 Zum Inhalt: Durch www-orientierte Beschaffungsansätze und Kooperationen mit den Partnern,

Mehr

EAI. Integration. EAI Version 0.9 1

EAI. Integration. EAI Version 0.9 1 EAI Enterprise Application Integration EAI Version 0.9 1 Heterogene Informationssysteme KIS DRG Grouper Stand-alone Anwendung (Windows) PACS Client-Server Anwendung (Java, LINUX, Caché) QM-System Client-Server

Mehr

Wrapper und Konnektoren geht die Rechnung auf?

Wrapper und Konnektoren geht die Rechnung auf? Wrapper und Konnektoren geht die Rechnung auf? Klaudia Hergula DaimlerChrysler AG Forschung und Technologie Wissensaustausch / Austauschgruppe (FTK/A) HPC 0516, Epplestr. 225, D-70546 Stuttgart klaudia.hergula@daimlerchrysler.com

Mehr

Message Oriented Middleware am Beispiel von XMLBlaster

Message Oriented Middleware am Beispiel von XMLBlaster Message Oriented Middleware am Beispiel von XMLBlaster Vortrag im Seminar XML und intelligente Systeme an der Universität Bielefeld WS 2005/2006 Vortragender: Frederic Siepmann fsiepman@techfak.uni bielefeld.de

Mehr

COMMON OBJECT REQUEST BROKER ARCHITECTURE. Dmytro Pyvovar Otto-von-Guericke Universität Magdeburg

COMMON OBJECT REQUEST BROKER ARCHITECTURE. Dmytro Pyvovar Otto-von-Guericke Universität Magdeburg COMMON OBJECT REQUEST BROKER ARCHITECTURE Dmytro Pyvovar Otto-von-Guericke Universität Magdeburg Gliederung Motivation Was ist CORBA? Object Management Architecture (OMA ) Interface Definition Language

Mehr

PROZESSE INTEGRIEREN leicht gemacht EFFIZIENTE PROZESSE

PROZESSE INTEGRIEREN leicht gemacht EFFIZIENTE PROZESSE PROZESSE INTEGRIEREN leicht gemacht DURCH TransConnect Geschäftsprozesse ableiten mit der Universal Worklist (UWL) Integrationsszenarien effektiver verwalten und transportieren Optimierte Personalverwaltung

Mehr

Whitepaper Walkyre Enterprise Resource Manangement

Whitepaper Walkyre Enterprise Resource Manangement Whitepaper Walkyre Enterprise Resource Management Seite 1 Whitepaper Walkyre Enterprise Resource Manangement Stand 15.11.2004 Inhalt 1. Hinweis... 2 2. Grundsätzliches zur Funktionalität... 3 3. Der Walkyre-Client...

Mehr

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Ziele Common Object Request Broker Architecture CORBA Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Object Management Group Spezifiziert den CORBA-Standard

Mehr

Mit EAI-Technologie zur IT- Modernisierung!

Mit EAI-Technologie zur IT- Modernisierung! Mit EAI-Technologie zur IT- Modernisierung! Dr. Raimund Binder, Leiter Operative Anwendungsentwicklung Generali Office Service & Consulting AG, Wien Email: raimund.binder@generali.at http://www.objectarchitects.de/eai/

Mehr

Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft

Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft Harald Lange sd&m Lübecker Str. 1 22087 Hamburg harald.lange@sdm.de Abstract: Mit der Einführung eines Buchungs-

Mehr

Musterlösung Übungsblatt 1 Netzprogrammierung WS 05/06

Musterlösung Übungsblatt 1 Netzprogrammierung WS 05/06 Musterlösung Übungsblatt 1 Netzprogrammierung WS 05/06 Block Verteilte Systeme und Middleware 1. Beschreiben Sie die Entwicklung verteilter Systeme von einer Zentralisierung bis zu Peer-to-Peer. Nicht

Mehr

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com Web Services Java Praktikum SS 2010 Gerald.Ehmayer@borland.com 1 Web Services Einführung Definition, Eigenschaften, Anwendungen... JAX-RPC Überblick, Architektur... JAX Übersicht, Architektur Java Praktikum

Mehr

Erstellung eines Frameworks für Shop Systeme im Internet auf Basis von Java

Erstellung eines Frameworks für Shop Systeme im Internet auf Basis von Java Erstellung eines Frameworks für Shop Systeme im Internet auf Basis von Java Präsentation zur Diplomarbeit von Übersicht Java 2 Enterprise Edition Java Servlets JavaServer Pages Enterprise JavaBeans Framework

Mehr

SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen

SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen Daniel Liebhart SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen ISBN-10: 3-446-41088-0 ISBN-13: 978-3-446-41088-6 Inhaltsverzeichnis Weitere Informationen oder Bestellungen

Mehr

EDI/XML Datentransaktionen über System- und Unternehmensgrenzen. Referent: Jan Freitag

EDI/XML Datentransaktionen über System- und Unternehmensgrenzen. Referent: Jan Freitag EDI/XML Datentransaktionen über System- und Unternehmensgrenzen Referent: Jan Freitag Warum EDI? Internet bedeutender Wirtschaftsfaktor Nur wenige Unternehmen steuern Geschäftsprozesse über das Internet

Mehr

DDM9000 : Kurz und bündig

DDM9000 : Kurz und bündig LTE Consulting GmbH Ihr Partner für InformationsLogistik DDM9000 : Kurz und bündig Kennen Sie das? Langes Suchen nach Unterlagen, aktuellen Dokumenten und anderen Informationen Wo sind wichtige, aktuelle

Mehr

8.4 Überblick und Vergleich weiterer ERP-Systeme. G Oracle Applications 11 G PeopleSoft 7 G J.D. Edwards One World G BaanERP

8.4 Überblick und Vergleich weiterer ERP-Systeme. G Oracle Applications 11 G PeopleSoft 7 G J.D. Edwards One World G BaanERP 8.4 Überblick und Vergleich weiterer ERP-Systeme G Oracle Applications 11 G PeopleSoft 7 G J.D. Edwards One World G BaanERP Kapitel 8: ERP-Einführung 32 Architektur von Oracle Applications 11 G Logische

Mehr

VS12 Slide 1. Verteilte Systeme. Vorlesung 12 Sebastian Iwanowski FH Wedel

VS12 Slide 1. Verteilte Systeme. Vorlesung 12 Sebastian Iwanowski FH Wedel VS12 Slide 1 Verteilte Systeme Vorlesung 12 Sebastian Iwanowski FH Wedel Mögliche Plattformen für Web Services VS12 Slide 2 VS12 Slide 3 Java-Software für verteilte Systeme J2EE: Java 2 Enterprise Edition

Mehr

Architekturen. DB-Anwendungen: Aufgaben. Aufteilung der Funktionen. ƒ Datenbankanwendungen

Architekturen. DB-Anwendungen: Aufgaben. Aufteilung der Funktionen. ƒ Datenbankanwendungen Architekturen ƒ Datenbankanwendungen Aufgaben und Komponenten Aufteilung ƒ Architektur Web-basierter Anwendungen HTTP-basierte Architekturen Applet-basierte Architekturen Vorlesung Internet-Datenbanken

Mehr

Verteilte Systeme - 1. Übung

Verteilte Systeme - 1. Übung Verteilte Systeme - 1. Übung Dr. Jens Brandt Sommersemester 2011 1. Rechnerverbünde Kommunikationsverbund: Beispiele: E-Mail (SMTP, POP/IMAP), Instant Messaging (XMPP, IRC, ICQ,...), Newsgroups (NNTP)

Mehr

Inhaltsverzeichnis. Vorwort 13. Kapitel 1 Einleitung 17. Kapitel 2 Architekturen 51. Kapitel 3 Prozesse 91

Inhaltsverzeichnis. Vorwort 13. Kapitel 1 Einleitung 17. Kapitel 2 Architekturen 51. Kapitel 3 Prozesse 91 Inhaltsverzeichnis Vorwort 13 Kapitel 1 Einleitung 17 1.1 Definition eines verteilten Systems................................ 19 1.2 Ziele........................................................ 20 1.2.1

Mehr

Klausur Verteilte Systeme Was versteht man unter verteilte Systeme

Klausur Verteilte Systeme Was versteht man unter verteilte Systeme Was versteht man unter verteilte Systeme Ein Verteiltes System ist ein System in dem Hardware- und Softwarekomponenten, die sich auf miteinander vernetzten Computern befinden miteinander kommunizieren

Mehr

Evaluation of Java Messaging Middleware as a Platform for Software Agent Communication

Evaluation of Java Messaging Middleware as a Platform for Software Agent Communication Evaluation of Java Messaging Middleware as a Platform for Software Agent Communication Frank Kargl Torsten Illmann Michael Weber Verteilte Systeme Universität Ulm {frank.kargl torsten.illmann weber} @informatik.uni-ulm.de

Mehr

Enterprise Java Beans Einführung

Enterprise Java Beans Einführung Enterprise Java Beans Einführung Vorlesung 8 Ralf Gitzel ralf_gitzel@hotmail.de 1 Themenübersicht Ralf Gitzel ralf_gitzel@hotmail.de 2 Übersicht EJBs im JEE Umfeld Verschiedene Typen von EJBs Von der Javaklasse

Mehr

Architektur einer GDI: Service-oriented Architecture (SOA)

Architektur einer GDI: Service-oriented Architecture (SOA) Modul 6: Voraussetzungen einer GDI Vertiefende Dokumente I Stand: 24.01.2012 Architektur einer GDI: Service-oriented Architecture (SOA) Zu den Hauptargumenten für eine Geodateninfrastruktur zählen unter

Mehr

Architekturen. Von der DB basierten zur Multi-Tier Anwendung. DB/CRM (C) J.M.Joller 2002 131

Architekturen. Von der DB basierten zur Multi-Tier Anwendung. DB/CRM (C) J.M.Joller 2002 131 Architekturen Von der DB basierten zur Multi-Tier Anwendung DB/CRM (C) J.M.Joller 2002 131 Lernziele Sie kennen Design und Architektur Patterns, welche beim Datenbankzugriff in verteilten Systemen verwendet

Mehr

Leistung schafft Vertrauen

Leistung schafft Vertrauen SOA Hintergrund und Praxis visionäre Praxis oder praxisnahe Vision Toni Gasser Integration Services 27. Oktober 2010 Leistung schafft Vertrauen Private Banking Investment Banking Asset Management Seite

Mehr

ITS Business Integrator

ITS Business Integrator IBI Weboberfläche zur Datenintegration Location Viewer Asset-Management Smallworld GIS Monitoring Planung Bau Wartung Entstörung Integration Der ITS Business Integrator (IBI) ist eine offene Plattform

Mehr

EAI in einem Versicherungsunternehmen

EAI in einem Versicherungsunternehmen EAI in einem Versicherungsunternehmen Nicht alles was man kaufen kann, muss man auch (sofort) einsetzen... Wolfgang Keller, Plattform-Management, Generali Office Service & Consulting AG, Wien Email: wolfgang.keller@generali.at

Mehr

Middleware. Host. Versuch einer Einleitung. dumme Terminals stellen Ausgaben dar und nehmen Eingaben an

Middleware. Host. Versuch einer Einleitung. dumme Terminals stellen Ausgaben dar und nehmen Eingaben an Middleware Versuch einer Einleitung Host dumme Terminals stellen Ausgaben dar und nehmen Eingaben an Mainframe enthält vollständige Anwendung Typ. COBOL, C Mainframe contd.! Nachteile! Mainframe ist teuer

Mehr

InQMy Application Server Flexible Softwareinfrastruktur für verteilte Anwendungen

InQMy Application Server Flexible Softwareinfrastruktur für verteilte Anwendungen InQMy Application Server Flexible Softwareinfrastruktur für verteilte Anwendungen IN-Q-My Title Company (Name) / 1 Agenda Firmenübersicht ebusiness Evolution InQMy Application Server Architektur Zusammenfassung

Mehr

-Testen verteilter Anwendungen

-Testen verteilter Anwendungen -Testen verteilter Anwendungen Seminar Simulation und Bildanalyse mit Java im SS04 Konstantin Tjo, Urs Pricking Testen verteilter Anwendungen 1 Übersicht Einführung in verteilte Anwendungen RMI (Remote

Mehr

SOAP Simple Object Access Protocol

SOAP Simple Object Access Protocol Informatikseminar Tobias Briel Überblick 1. Einführung - was ist? 2. Middlewaretechnologie 3. Aufbau von Nachrichten 4. Vergleiche 5. Beispielanwendung 6. Zusammenfassung 1 Einführung was ist Soap? neue

Mehr

LMU. Grundlagen verteilter Systeme. Vorlesung am 12. Mai 2009. Dr. Frank Sarre. Lehr- und Forschungseinheit für Programmierung und Softwaretechnik

LMU. Grundlagen verteilter Systeme. Vorlesung am 12. Mai 2009. Dr. Frank Sarre. Lehr- und Forschungseinheit für Programmierung und Softwaretechnik LMU Ludwig- Maximilians- Universität München Lehr- und Forschungseinheit für Programmierung und Softwaretechnik Vorlesung am 12. Mai 2009 Serviceorientiertes egovernment Grundlagen verteilter Systeme Dr.

Mehr

Enterprise Application Integration. Sascha M. Köhler Software Architekt

Enterprise Application Integration. Sascha M. Köhler Software Architekt Sascha M. Köhler Software Architekt Agenda 2 01 Herausforderungen unserer Kunden 02 Lösungsdefinition 03 PROFI Angebot 04 Zusammenfassung Der IT-Gemüsegarten ITK Systeme sind auf Grund von Funktionen &

Mehr

Integrating Architecture Apps for the Enterprise

Integrating Architecture Apps for the Enterprise Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Motivation und Grundkonzept Inhalt Problem Ursache Herausforderung Grundgedanke Architektur

Mehr

6 Architektur-Mittel (WOMIT)

6 Architektur-Mittel (WOMIT) 6 Architektur-Mittel (WOMIT) Abb. 6-1: Positionierung des Kapitels im Ordnungsrahmen. Dieses Kapitel befasst sich mit der WOMIT-Dimension des architektonischen Ordnungsrahmens, indem es grundlegende Konzepte

Mehr

Kap. 7 IS-Infrastruktur: Zusammenfassung

Kap. 7 IS-Infrastruktur: Zusammenfassung Kapitel 7: Zusammenfassung Teil I. 1 Kap. 7 IS-Infrastruktur: Zusammenfassung In Teil I haben wir verschiedene Middleware-Lösungen zur Entwicklung (komplexer), verteilter Informationssysteme kennengelernt

Mehr

09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten

09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten Aktuelle Themen der Wirtschaftsinformatik Zusammenfassung 09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten 1 Serverseitige Webprogrammierung

Mehr

Standardisierte Integration und Datenmigration in heterogenen Systemlandschaften am Beispiel von Customer Relationship Management

Standardisierte Integration und Datenmigration in heterogenen Systemlandschaften am Beispiel von Customer Relationship Management Standardisierte Integration und Datenmigration in heterogenen Systemlandschaften am Beispiel von Customer Relationship Management Inauguraldissertation zur Erlangung des akademischen Grades eines Doktors

Mehr

3 Anwendungsarchitektur und Entwicklungsumgebung

3 Anwendungsarchitektur und Entwicklungsumgebung 21 3 Anwendungsarchitektur und Bei den Entwicklern von Web-basierten Dialogsystemen hat sich im Laufe der Zeit eine Vorgehensweise im Design von Anwendungen entwickelt, dies es ermöglicht, flexible Web-Dialoge

Mehr

18 Entwicklung verteilter Systeme

18 Entwicklung verteilter Systeme 18 Entwicklung verteilter Systeme 18.0 Einführung Lernziele Verteilte Systeme 18.1 Charakteristika verteilter Systeme Entwurfsfragen Kommunikationsmodelle Middleware 18.2 Client-Server-Systeme Prozesse

Mehr

Einführung in die OPC-Technik

Einführung in die OPC-Technik Einführung in die OPC-Technik Was ist OPC? OPC, als Standartschnittstelle der Zukunft, steht für OLE for Process Control,und basiert auf dem Komponentenmodel der Firma Microsoft,dem Hersteller des Betriebssystems

Mehr

OSS/J als Basis für Enterprise Application Integration

OSS/J als Basis für Enterprise Application Integration OSS/J als Basis für Enterprise Application Integration Geschäftsprozessgesteuerte EAI im Telekommunikationsbereich r A business of PwC Agenda OSS-Architekturen als Integrationsherausforderung OSS/J als

Mehr

IVY. White Paper. Microsoft Dynamics NAV Workflow Controller Powered by Xpert.ivy

IVY. White Paper. Microsoft Dynamics NAV Workflow Controller Powered by Xpert.ivy White Paper IVY Microsoft Dynamics NAV Workflow Controller Powered by Xpert.ivy Business Process Management (BPM) unterstützt den gesamten Lebenszyklus von Geschäftsprozessen. BPM-Lösungen liefern Technologie

Mehr

SE2-10-Entwurfsmuster-2 15

SE2-10-Entwurfsmuster-2 15 Architektur und Skalierbarkeit SE2-10-Entwurfsmuster-2 15 Skalierbarkeit Skalierbarkeit bedeutet die Anpassung einer Software an wachsende Last: Interaktionsfrequenz Nutzerzahl Anpassung durch Hinzufügen

Mehr

Modul Software Komponenten 10 Komponentenarchitektur

Modul Software Komponenten 10 Komponentenarchitektur Modul Software Komponenten 10 Komponentenarchitektur Teil 3 Peter Sollberger Eine erste CORBA Anwendung Inhalt Dienstag, 4. November Object Request Broker CORBA Architektur und Komponenten (Teil 1) Übung:

Mehr

1. Was bedeutet EAI? 2. Worin liegen die Vorteile? 3. Worin liegen die Nachteile? 4. EAI-Markt

1. Was bedeutet EAI? 2. Worin liegen die Vorteile? 3. Worin liegen die Nachteile? 4. EAI-Markt Referate-Seminar WS 2001/2002 Veranstaltungsort: Giessen Datum: 03. April 2002 Fachbereich: Wirtschaftsinformatik Referentin: Übersicht 2. Worin liegen die Vorteile? 3. Worin liegen die Nachteile? Seite

Mehr

Enterprise Portale & Enterprise Application Integration

Enterprise Portale & Enterprise Application Integration EP & - & Enterprise Application Integration Jörg Streibhardt Technische Universität Dresden EP & 21. Januar 2005 / Seminar Rechnernetze Gliederung Enterprise Application Integration EP & - EP & & Enterprise

Mehr

16.4 Wiederverwendung von COTS-Produkten

16.4 Wiederverwendung von COTS-Produkten 16.4 Wiederverwendung von COTS-Produkten COTS = commercial of the shelf im Handel erhältliche Software-Produkte Anpassung für Kunden ohne Änderung am Quellcode Quellcode in der Regel nicht einsehbar (Ausnahme

Mehr

Web 2.0 Software-Architekturen

Web 2.0 Software-Architekturen Web 2.0 Software-Architekturen Servlets als Controller einer MVC Web Architektur Prof. Dr. Nikolaus Wulff HTTP und HTML Das HyperText TransferProtokoll (HTTP) beschreibt eine einfache verbindungslose Kommunikation,

Mehr

IT-Kompaktkurs. Datenbanken Skript zur Folge 10. Prof. Dr. Dieter Rummler Fachhochschule Deggendorf

IT-Kompaktkurs. Datenbanken Skript zur Folge 10. Prof. Dr. Dieter Rummler Fachhochschule Deggendorf IT-Kompaktkurs Skript zur Folge 10 Prof. Dr. Dieter Rummler Fachhochschule Deggendorf Client Server Architektur Zunächst zur grundsätzlichen Unterscheidung zwischen File-Server Datenbank und Server-Datenbank

Mehr

Service Oriented Architectures

Service Oriented Architectures Service Oriented Architectures Einführung in die Integration verschiedener Anwendungssysteme - Problematik und allgemeine Architektur Julia Weisheitel (WI5773) Inhalt Überblick Probleme und Entscheidungen

Mehr

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. Java Remote Method Invocation Teil 1

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. Java Remote Method Invocation Teil 1 UNIVERSITÄT LEIPZIG Mainframe Internet Integration Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013 Java Remote Method Invocation Teil 1 Object Request Broker el0100 copyright Abt. Technische

Mehr

Verschiedene Arten des Datenbankeinsatzes

Verschiedene Arten des Datenbankeinsatzes 1 Beispiele kommerzieller DBMS: Kapitelinhalt Was charakterisiert und unterscheidet verschiedene Einsatzbereiche für. Welche prinzipiell unterschiedlichen Anforderungen ergeben sich für das DBMS bei Ein-

Mehr

Inhaltsverzeichnis. Daniel Liebhart, Guido Schmutz, Marcel Lattmann, Markus Heinisch, Michael Könings, Mischa Kölliker, Perry Pakull, Peter Welkenbach

Inhaltsverzeichnis. Daniel Liebhart, Guido Schmutz, Marcel Lattmann, Markus Heinisch, Michael Könings, Mischa Kölliker, Perry Pakull, Peter Welkenbach sverzeichnis Daniel Liebhart, Guido Schmutz, Marcel Lattmann, Markus Heinisch, Michael Könings, Mischa Kölliker, Perry Pakull, Peter Welkenbach Integration Architecture Blueprint Leitfaden zur Konstruktion

Mehr

Business Process Management und Enterprise Service Bus

Business Process Management und Enterprise Service Bus Business Process Management und Enterprise Service Bus Gegner oder doch eine gute Ergänzung? Author: Date: Markus Demolsky Soreco International 08. November 2010 Vortragender Warum über Integration nachdenken?

Mehr

Workflow Management: Workflow (1)

Workflow Management: Workflow (1) Workflow Management: Workflow (1) Abgrenzung: Geschäftsprozeß Vorgang (Aktivität) Arbeitsablauf (Workflow) Arbeitsschritt (Work Item) Otto-von-Guericke-Universität Magdeburg Fakultät für Informatik Institut

Mehr

Relationale Datenbanken Kursziele

Relationale Datenbanken Kursziele Relationale Datenbanken Kursziele DB Grundlagen Daten-Modellierung Relationales Modell und DB => Praxis: Mit SQL als Anfragesprache Mit MySQL als DB RDB 1-1 Kursinhalt (Tage) 1. DB Einleitung / Entity-Relationship

Mehr

Kundenanforderungen. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 24.05.2013

Kundenanforderungen. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 24.05.2013 Software Komponenten FS13 Gruppe 03 Horw, 24.05.2013 Bontekoe Christian Estermann Michael Moor Simon Rohrer Felix Autoren Bontekoe Christian Studiengang Informatiker (Berufsbegleitend) Adresse Telefon

Mehr

Lastenheft. Zielbestimmungen. Produkteinsatz. swp11-4. 3. Mai 2011. Franz Teichmann, Robert Röÿling swp11-4 3. Mai 2011

Lastenheft. Zielbestimmungen. Produkteinsatz. swp11-4. 3. Mai 2011. Franz Teichmann, Robert Röÿling swp11-4 3. Mai 2011 Lastenheft swp11-4 3. Mai 2011 Zielbestimmungen In der heutigen Geschäftswelt stehen mittelständische Unternehmen vor dem Dilemma, einerseits interne und externe Kommunikation in angemessener Weise gewährleisten

Mehr

Berichte aus der Medizinischen Informatik und Bioinformatik. Günther Schadow. Krankenhauskommunikation mit HL7

Berichte aus der Medizinischen Informatik und Bioinformatik. Günther Schadow. Krankenhauskommunikation mit HL7 Berichte aus der Medizinischen Informatik und Bioinformatik Günther Schadow Krankenhauskommunikation mit HL7 Analyse, Implementation und Anwendungeines Protokollstandards für medizinische Datenkommunikation

Mehr

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. Java Connection Architecture Teil 3

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. Java Connection Architecture Teil 3 UNIVERSITÄT LEIPZIG Mainframe Internet Integration Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013 Java Connection Architecture Teil 3 CICS Transaction Gateway el0100 copyright W. G. Spruth,

Mehr

J2EE Connector Architecture

J2EE Connector Architecture J2EE Connector Architecture Erik Graf Hochschule der Medien Studiengang Medieninformatik Ausarbeitung zur Vorlesung Design Patterns SS 2004 1 Zusammenfassung Die Absicht dieser Ausarbeitung ist es einen

Mehr

Warum EJB Technologie (1)?

Warum EJB Technologie (1)? Datenbanken und Informationssysteme 2 SS 2004 Prof. Dr. Stefan Böttcher Universität Paderborn Datenbanken und Informationssysteme 2 - Prof. Dr. Stefan Böttcher - SS 2004 Folie EJB - 1 Warum EJB Technologie

Mehr

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Agenda Mobile Agenten allgemein JADE - Java Agent DEvelopment Framework Anwendungsfall

Mehr

SaaS-Referenzarchitektur. iico-2013-berlin

SaaS-Referenzarchitektur. iico-2013-berlin SaaS-Referenzarchitektur iico-2013-berlin Referent Ertan Özdil Founder / CEO / Shareholder weclapp die Anforderungen 1.000.000 registrierte User 3.000 gleichzeitig aktive user Höchste Performance Hohe

Mehr

Verteilte Echtzeit-Systeme

Verteilte Echtzeit-Systeme Seminar im SS06 Verteilte Echtzeit-Systeme Prof. Sergei Gorlatch Dipl.-Inf. Jens Müller jmueller@uni-muenster.de Einsteinstr. 62, Raum 705, Tel. 83-32746 Westfälische Wilhelms-Universität Münster Fachbereich

Mehr

TECHNISCHE PRODUKTINFORMATION CARUSO

TECHNISCHE PRODUKTINFORMATION CARUSO 1111 TECHNISCHE PRODUKTINFORMATION CARUSO TECHNISCHE PRODUKTINFORMATION Seite 0/7 Inhalt 1 Systemdefinition............2 2 Technische Details für den Betrieb von CARUSO......2 2.1 Webserver... 2 2.2 Java

Mehr

ODEX Enterprise. ODEX Enterprise. Beratungsbüro Kasch GmbH & Co. KG. Beratungsbüro Kasch GmbH & Co KG Hemsener Weg 73 D-29640 Schneverdingen

ODEX Enterprise. ODEX Enterprise. Beratungsbüro Kasch GmbH & Co. KG. Beratungsbüro Kasch GmbH & Co KG Hemsener Weg 73 D-29640 Schneverdingen ODEX Enterprise Beratungsbüro Kasch GmbH & Co. KG ODEX Enterprise Im Firmenalltag müssen Geschäftsdokumente zuverlässig und effizient ausgetauscht werden, ansonsten drohen schwerwiegende finanzielle Konsequenzen.

Mehr

Vorlesung. Modelle für Geschäftsprozesse und Services. Prof. Dr. Karsten Wolf

Vorlesung. Modelle für Geschäftsprozesse und Services. Prof. Dr. Karsten Wolf Vorlesung Modelle für Geschäftsprozesse und Services Prof. Dr. Karsten Wolf Was ist ein Geschäftsprozess? Beispiele: Bearbeitung eines Schadensfalls in einer Versicherung Kreditüberprüfung in einer Bank

Mehr

Inhaltsverzeichnis. Enterprise Java im Überblick. Technologien der Java2 Enterprise Edition

Inhaltsverzeichnis. Enterprise Java im Überblick. Technologien der Java2 Enterprise Edition Inhaltsverzeichnis Vorwort 13 I Enterprise Java im Überblick 1 Bedeutung von Enterprise Java und IBM WebSphere 21 1.1 Enterprise Java 23 1.1.1 Anforderungen 23 1.1.2 E-Business 30 1.1.3 Java 36 1.2 IBM

Mehr

Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC. Alexander Scholz

Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC. Alexander Scholz Hochverfügbar und Skalierung mit und ohne RAC Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC Alexander Scholz Copyright its-people Alexander Scholz 1 Einleitung Hochverfügbarkeit

Mehr

JE Web Services. Hinweise. Beschreibung. Doku.-Version: 1.0 Letzte Änderung: 02.02.2011

JE Web Services. Hinweise. Beschreibung. Doku.-Version: 1.0 Letzte Änderung: 02.02.2011 Beschreibung Hinweise Doku.-Version: 1.0 Letzte Änderung: 02.02.2011 http://www.jacob-computer.de/kontakt.html software@jacob-elektronik.de Inhaltsverzeichnis 1. Inhaltsverzeichnis Hinweise... 1 1. Inhaltsverzeichnis...

Mehr

17 Komponentenbasiertes Software-Engineering

17 Komponentenbasiertes Software-Engineering 17 Komponentenbasiertes Software-Engineering 17.0 Einführung Lernziele Grundlagen, Prinzipien und Probleme des CBSE 17.1 Komponenten und Komponentenmodelle Komponenten und ihre Eigenschaften Komponentenmodelle

Mehr

Analysen sind nur so gut wie die Datenbasis

Analysen sind nur so gut wie die Datenbasis Analysen sind nur so gut wie die Datenbasis Datenaufbereitung und Sicherung der Datenqualität durch den kontextbasierten MIOsoft Ansatz. Daten gelten längst als wichtiger Produktionsfaktor in allen Industriebereichen.

Mehr

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. WebSphere Application Server Teil 4

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. WebSphere Application Server Teil 4 UNIVERSITÄT LEIPZIG Mainframe Internet Integration Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013 WebSphere Application Server Teil 4 Leistungsverhalten el0100 copyright W. G. Spruth,

Mehr

EDI Datenaustausch und Konvertierung Funktionsumfang & Services

EDI Datenaustausch und Konvertierung Funktionsumfang & Services cleardax EDI Datenaustausch und Konvertierung Funktionsumfang & Services Einleitung Hauptfunktionen Datenaustausch (Anbindungsmöglichkeiten) Konvertierung Mappings Zusatzleistungen und Funktionen cleardax

Mehr

TransConnect Business Integration Platform. universeller Server zur Integration von Daten, Anwendungen und Geschäftsprozessen

TransConnect Business Integration Platform. universeller Server zur Integration von Daten, Anwendungen und Geschäftsprozessen TransConnect Business Integration Platform universeller Server zur Integration von Daten, Anwendungen und Geschäftsprozessen Einleitung TransConnect ist die zentrale Serverplattform für den Aufbau einer

Mehr

Transaktionsmonitore und Applikationsserver

Transaktionsmonitore und Applikationsserver Transaktionsmonitore und Applikationsserver Marc Monecke monecke@informatik.uni-siegen.de Praktische Informatik Fachbereich Elektrotechnik und Informatik Universität Siegen, D-57068 Siegen 13. Juni 2003

Mehr

1 Problematik eines uneinheitlichen Verständnisses der SOA... 201. 2 SOA als unternehmensweites Architekturkonzept... 203

1 Problematik eines uneinheitlichen Verständnisses der SOA... 201. 2 SOA als unternehmensweites Architekturkonzept... 203 Mehr als alter Wein in neuen Schläuchen 199 1 Problematik eines uneinheitlichen Verständnisses der SOA... 201 2 SOA als unternehmensweites Architekturkonzept........... 203 3 Struktur einer SOA..................................

Mehr

Microsoft Dynamics NAV Technische Details

Microsoft Dynamics NAV Technische Details Microsoft Dynamics NAV Technische Details INHALT Microsoft Dynamics NAV Technische Details........................................ [3] Infrastruktur.............................................. [3] Systemanforderungen.....................................

Mehr

0. Inhaltsverzeichnis

0. Inhaltsverzeichnis 0. Inhaltsverzeichnis 0. Inhaltsverzeichnis...1 1. Kurze Einführung WebService Architektur...2 1.1 Synchrones Modell:...2 1.2 Asynchrones Modell:...2 1.3 Vorteile:...3 1.4 Voraussetzungen...3 2. Testseite

Mehr