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

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

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

Java 2, Enterprise Edition Einführung und Überblick

Java 2, Enterprise Edition Einführung und Überblick Universität aiserslautern AG Datenbanken und Informationssysteme Seminar Datenbank-Aspekte des E-Commerce Java 2, Enterprise Edition Einführung und Überblick m_husema@informatik.uni-kl.de Vortragsinhalte

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

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

Enterprise Service Bus

Enterprise Service Bus Enterprise Service Bus Christopher Weiß 25.01.2010 Gliederung 1 Motivation und Einordung Integrationsformen 2 Definition und Eigenschaften Definitionen Eigenschaften 3 Aufbau und Konzepte Aufbau Produkte

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

Enterprise Application Integration Erfahrungen aus der Praxis

Enterprise Application Integration Erfahrungen aus der Praxis Enterprise Application Integration Erfahrungen aus der Praxis Teil 3: Fallstudien EDS und Vitria Tutorial NODs 2002, Wolfgang Keller and Generali 2001, 2002, all rights reserved 1 Überblick EDS ein selbstgebautes

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

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

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

Seminarvortrag Serviceorientierte Softwarearchitekturen

Seminarvortrag Serviceorientierte Softwarearchitekturen Seminarvortrag Serviceorientierte Softwarearchitekturen vorhandene Altsysteme Gliederung Einführung Grundlegende Modelle Grundlegende Komponenten Architekturen 2 Einführung Altanwendung und Altsysteme?

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

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

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

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

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

Einflussfaktoren auf eine Softwarearchitektur und ihre Wechselwirkungen Entwurfsentscheidungen systematisieren

Einflussfaktoren auf eine Softwarearchitektur und ihre Wechselwirkungen Entwurfsentscheidungen systematisieren 1 Einflussfaktoren auf eine Softwarearchitektur und ihre Wechselwirkungen Entwurfsentscheidungen systematisieren W3L AG info@w3l.de 2011 2 Agenda Softwarearchitektur und Architekturentwurf Definition Überblick

Mehr

Kommunikation und Kooperative Systeme

Kommunikation und Kooperative Systeme Kommunikation und Kooperative Systeme Teil II Verteilte Dienste und Anwendungen Nik Klever FB Informatik - FH klever@fh-augsburg.de Einführung Begriffsbestimmung Kommunikation: Austausch, Übermittlung

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

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

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

B2B für meine Geschäftspartner

B2B für meine Geschäftspartner B2B für meine Geschäftspartner Michael Stapf Oracle Deutschland B.V. & Co. KG Frankfurt Schlüsselworte B2B, Business-to-Business, Geschäftspartnerintegration, Elektronische Geschäftskommunikation Einleitung

Mehr

Webservices. 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung. Hauptseminar Internet Dienste

Webservices. 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung. Hauptseminar Internet Dienste Hauptseminar Internet Dienste Sommersemester 2004 Boto Bako Webservices 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung Was sind Web Services? Web Services sind angebotene

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

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

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

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

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

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

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

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

Enterprise Computing Einführung in das Betriebssystem z/os. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth WS2012/2013. WebSphere MQ Teil 3

Enterprise Computing Einführung in das Betriebssystem z/os. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth WS2012/2013. WebSphere MQ Teil 3 UNIVERSITÄT LEIPZIG Enterprise Computing Einführung in das Betriebssystem z/os Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth WS2012/2013 WebSphere MQ Teil 3 Trigger el0100 Copyright W. G. Spruth,

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

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

Enterprise Application Integration Erfahrungen aus der Praxis

Enterprise Application Integration Erfahrungen aus der Praxis Enterprise Application Integration Erfahrungen aus der Praxis Teil 4: EAI und.net, EAI und J2EE Tutorial NODs 2002, Wolfgang Keller and Generali 2001, 2002, all rights reserved 1 Überblick EAI und....net

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

Kap. 3 Verteilte Objektverwaltung

Kap. 3 Verteilte Objektverwaltung Kap. 3 Verteilte Objektverwaltung 3.1 Einführung in die verteilte Objektverwaltung (Distributed Object Management, DOM) Anforderungen Kurzübersicht Java RMI Microsoft COM+ CORBA 3.2 Der CORBA-Standard

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

EAI - Enterprise Application Integration

EAI - Enterprise Application Integration EAI - Enterprise Application Integration Jutta Mülle WS 2005/2006 EAI - Folie 1 Überblick und Begriffsbildung Zusammenfassung und Ausblick hinweise EAI - Folie 2 Conclusion EAI Enterprise Application Integration

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

SOAP Integrationstechnologie für verteilte Middlewarearchitekturen?

SOAP Integrationstechnologie für verteilte Middlewarearchitekturen? SOAP Integrationstechnologie für verteilte Middlewarearchitekturen? Großer Beleg Christian Wurbs Zwischenbericht http://www.inf.tu-dresden.de/~cw6 cw6@inf.tu-dresden.de Überblick 2 Aufgabenstellung CORBA

Mehr

Error-Hospital für Oracle SOA Suite

Error-Hospital für Oracle SOA Suite Error-Hospital für Oracle SOA Suite Markus Lohn esentri AG Ettlingen Schlüsselworte Fusion Middleware, SOA, SOA Suite Einleitung Die Entwicklung von Services mit der SOA Suite erfolgt überwiegend deklarativ

Mehr

3 Programmiermodelle für parallele und verteilte Systeme

3 Programmiermodelle für parallele und verteilte Systeme 3 Programmiermodelle für parallele und verteilte Systeme Das vorherrschende Programmiermodell für parallele und verteilte Systeme ist das Client Server Modell. Das Client Server Modell ist unabhängig von

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

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

Autorisierung. Sicherheit und Zugriffskontrolle & Erstellen einer Berechtigungskomponente

Autorisierung. Sicherheit und Zugriffskontrolle & Erstellen einer Berechtigungskomponente Autorisierung Sicherheit und Zugriffskontrolle & Erstellen einer Berechtigungskomponente Dokumentation zum Referat von Matthias Warnicke und Joachim Schröder Modul: Komponenten basierte Softwareentwickelung

Mehr

Jump Project. Softwarelösungen für professionelles Projektmanagement

Jump Project. Softwarelösungen für professionelles Projektmanagement Jump Project Softwarelösungen für professionelles Projektmanagement Jump Project Office Übersichtliche Dokumentenstruktur und schneller Zugriff auf alle wichtigen Funktionen. Steuern Sie Ihre Projekte

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

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

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

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

Inhaltsverzeichnis: Definitionen Informationssysteme als Kommunikationssystem Problemlösende Perspektiven Allgemeine System Annäherung Fazit

Inhaltsverzeichnis: Definitionen Informationssysteme als Kommunikationssystem Problemlösende Perspektiven Allgemeine System Annäherung Fazit Informationssysteme Inhaltsverzeichnis: Definitionen Informationssysteme als Kommunikationssystem Problemlösende Perspektiven Allgemeine System Annäherung Fazit Definitionen: Informationen Informationssysteme

Mehr

Web Services. XML, WSDL, SOAP und UDDI Einblicke und Ausblicke. 31.03.2003 J.M.Joller 1

Web Services. XML, WSDL, SOAP und UDDI Einblicke und Ausblicke. 31.03.2003 J.M.Joller 1 Web Services XML, WSDL, SOAP und UDDI Einblicke und Ausblicke 31.03.2003 J.M.Joller 1 Inhalt Architekturen Main Stream.NET J2EE und Applikations-Server Sicht der Anbieter Java J2EE J2EE versus.net Web

Mehr

In diesem Kapitel werden wir nun mehrere Anwendungen von XML in der betrieblichen Praxis vorstellen. Sie sollen XML bei der Arbeit zeigen.

In diesem Kapitel werden wir nun mehrere Anwendungen von XML in der betrieblichen Praxis vorstellen. Sie sollen XML bei der Arbeit zeigen. 181 In diesem Kapitel werden wir nun mehrere Anwendungen von XML in der betrieblichen Praxis vorstellen. Sie sollen XML bei der Arbeit zeigen. Wir beginnen mit dem Startup-Unternehmen Seals GmbH aus Frankfurt,

Mehr

ObjectBridge Java Edition

ObjectBridge Java Edition ObjectBridge Java Edition Als Bestandteil von SCORE Integration Suite stellt ObjectBridge Java Edition eine Verbindung von einem objektorientierten Java-Client zu einer fast beliebigen Server-Komponente

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

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

JOB MANAGEMENT MIT DEM SAP SOLUTION MANAGER. Whitepaper

JOB MANAGEMENT MIT DEM SAP SOLUTION MANAGER. Whitepaper JOB MANAGEMENT MIT DEM SAP SOLUTION MANAGER. Whitepaper Wussten Sie, dass lediglich der kleinere Teil der Datenverarbeitung in Ihrem System von End-Anwendern generiert wird? Der größere Teil der Informationen

Mehr

Massively Scalable Enterprise Applications. Chris Bernhardt

Massively Scalable Enterprise Applications. Chris Bernhardt Massively Scalable Enterprise Applications Chris Bernhardt Allgemein Einsatzgebiete BizTalk Server Engine Management Enterprise Single Sign-On Neuheiten und Beispiele Quellen Agenda 28.01.2010 Microsoft

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

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

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

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

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

Client/Server-Systeme

Client/Server-Systeme Frühjahrsemester 2011 CS104 Programmieren II / CS108 Programmier-Projekt Java-Projekt Kapitel 3: /Server-Architekturen H. Schuldt /Server-Systeme Ein zweischichtiges /Server-System ist die einfachste Variante

Mehr

Ein Beispiel. Ein Unternehmen will Internettechnologien im Rahmen des E- Business nutzen Welche Geschäftsprozesse?

Ein Beispiel. Ein Unternehmen will Internettechnologien im Rahmen des E- Business nutzen Welche Geschäftsprozesse? Ein Beispiel Ein Unternehmen will Internettechnologien im Rahmen des E- Business nutzen Welche Geschäftsprozesse? Dipl.-Kfm. Claus Häberle WS 2015 /16 # 42 XML (vereinfacht) visa

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

Der Einsatz von CORBA in verteilten EDA-Tools

Der Einsatz von CORBA in verteilten EDA-Tools Der Einsatz von CORBA in verteilten EDA-Tools Frank Grützmacher Technische Universität Ilmenau Fakultät für Elektrotechnik und Informationstechnik Fachgebiet Mikroelektronische Schaltungen und Systeme

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

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

Microsoft.NET und SunONE

Microsoft.NET und SunONE Microsoft.NET und SunONE, Plattformen und Application Service Providing Agenda Einordnung.NET und SunONE Kurzvorstellung Gegenüberstellung Zusammenfassung ASP (Application( Service Providing) ) und Ausblick

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

Übungen zu Softwaretechnik

Übungen zu Softwaretechnik Prof. Dr. Dr. h.c. M. Broy Lösungsblatt 11 Dr. H. Ehler, S. Wagner 23. Januar 2004 Übungen zu Softwaretechnik Aufgabe 16 Qualitätseigenschaften Broker-Pattern Beurteilen Sie das in Aufgabe 15 benutzte

Mehr

Java und XML 2. Java und XML

Java und XML 2. Java und XML Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Praktische Informatik und Medieninformatik Fachgebiet Telematik Java und XML Hauptseminar Telematik WS 2002/2003

Mehr

Enterprise Applikation Integration und Service-orientierte Architekturen. 08 Einführung Service-Orientierte Architekturen

Enterprise Applikation Integration und Service-orientierte Architekturen. 08 Einführung Service-Orientierte Architekturen Enterprise Applikation Integration und Service-orientierte Architekturen 08 Einführung Service-Orientierte Architekturen Ist SOA immer noch aktuell? Prof. Dr. Holger Wache http://bhc3.files.wordpress.com/2009/07/gartner-emerging-technologies-hype-cycle-2009.png?w=552&h=451

Mehr

Agenda. Clients aus drei verschiedenen Perspektiven: Was ist ein Dialog? Komponentenarchitektur innerhalb eines Dialoges

Agenda. Clients aus drei verschiedenen Perspektiven: Was ist ein Dialog? Komponentenarchitektur innerhalb eines Dialoges Komponentenbasierte Client-Architektur Hamburg, 16.11.2007 Bernd Olleck IT-Beratung Olleck Agenda Clients aus drei verschiedenen Perspektiven: Technische Infrastruktur Fachliche Sicht Aufgaben eines Clients

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

Vorwort... 11 Azure Cloud Computing mit Microsoft... 12 Danksagungen... 13 Kontakt zum Autor... 13

Vorwort... 11 Azure Cloud Computing mit Microsoft... 12 Danksagungen... 13 Kontakt zum Autor... 13 Inhaltsverzeichnis Vorwort... 11 Azure Cloud Computing mit Microsoft... 12 Danksagungen... 13 Kontakt zum Autor... 13 Einleitung... 15 Zielgruppe... 16 Aufbau... 16 Inhalt der einzelnen Kapitel... 17 Systemanforderungen...

Mehr

ALE-Szenarien der Anlagenbuchhaltung

ALE-Szenarien der Anlagenbuchhaltung ALE-Szenarien der Anlagenbuchhaltung HELP.FIAA Release 4.6C SAP AG Copyright Copyright 2001 SAP AG. Alle Rechte vorbehalten. Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind,

Mehr

SAP Mobile Platform MÜNSTER 10.04.2013. best practice consulting Aktiengesellschaft Raboisen 32 20095 Hamburg T +49 40 303752-0 F +49 40 303752-77

SAP Mobile Platform MÜNSTER 10.04.2013. best practice consulting Aktiengesellschaft Raboisen 32 20095 Hamburg T +49 40 303752-0 F +49 40 303752-77 MÜNSTER 10.04.2013 SAP Mobile Platform best practice consulting Aktiengesellschaft Raboisen 32 20095 Hamburg T +49 40 303752-0 F +49 40 303752-77 E info@bpc.ag W www.bpc.ag Seite 1 18.04.2013 Agenda Einleitung

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

Technische Anforderungen. zum Empfang. von XML-Nachrichten

Technische Anforderungen. zum Empfang. von XML-Nachrichten Technische Anforderungen zum Empfang von XML-Nachrichten 25.11.2004 Peer Uwe Peters 2 1 Inhaltsverzeichnis 1 INHALTSVERZEICHNIS... 2 2 ZIEL DIESES DOKUMENTS... 3 3 KONTEXT... 3 4 SENDEWEG... 4 5 ERREICHBARKEIT...

Mehr

Rollen- und Rechtekonzept

Rollen- und Rechtekonzept Inhaltsverzeichnis Rollen- und Rechtekonzept 1. Ziele...1 2. Konzeption zur Realisierung durch Access Control List und im Management-Interface...2 2.1. Ansatz...2 2.2. Safety oder Security...2 2.3. User-

Mehr

30 Jahre Server Von Transaktionssystemen zu Web-Services

30 Jahre Server Von Transaktionssystemen zu Web-Services 30 Jahre Server Friedrich-Alexander-Universität Erlangen-Nürnberg Institut für Informatik Lehrstuhl für Informatik 6 (Datenbanksysteme) Anlass! "Java (EJB,. ) ist ja so langsam!"! "Aber CICS ist inzwischen

Mehr

Multiuser Client/Server Systeme

Multiuser Client/Server Systeme Multiuser /Server Systeme Christoph Nießner Seminar: 3D im Web Universität Paderborn Wintersemester 02/03 Übersicht Was sind /Server Systeme Wie sehen Architekturen aus Verteilung der Anwendung Protokolle

Mehr

Orlando-Workflow. Elektronischer Beleglauf. Ausbaustufe der Orlando-Archivierung

Orlando-Workflow. Elektronischer Beleglauf. Ausbaustufe der Orlando-Archivierung Beleglenkung papierlos und digital vor der Verbuchung Effektives Management der Belege wird immer mehr zum Muss für jedes Unternehmen, welches effizient und gewinnbringend wirtschaften möchte. Die Steuerung

Mehr

Geschäftsprozesse und Entscheidungen automatisieren schnell, flexibel und transparent. Die BPM+ Edition im Überblick

Geschäftsprozesse und Entscheidungen automatisieren schnell, flexibel und transparent. Die BPM+ Edition im Überblick Geschäftsprozesse und Entscheidungen automatisieren schnell, flexibel und transparent. Die BPM+ Edition im Überblick Software Innovations BPM BRM Die Software-Suite von Bosch Alles drin für besseres Business!

Mehr

Peter Körner Adobe Systems Berlin, 3. Juni 2005

Peter Körner Adobe Systems Berlin, 3. Juni 2005 Interactive Forms based on Adobe Software: Überblick Peter Körner Adobe Systems Berlin, 3. Juni 2005 Einleitung Anwendungsszenarios Technologie Einleitung Anwendungsszenarios Technologie Anforderungen

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

COMOS/SAP-Schnittstelle

COMOS/SAP-Schnittstelle COMOS/SAP-Schnittstelle White Paper Optimierter Datenaustausch zwischen COMOS und SAP Juni 2010 Zusammenfassung Ein konsistenter Datenaustausch zwischen Engineering-Anwendungen und ERP-Systemen ist heutzutage

Mehr

Java Beans Enterprise Java Beans. Eine kurze Einführung in die Welt der Bohnen

Java Beans Enterprise Java Beans. Eine kurze Einführung in die Welt der Bohnen Java Beans Enterprise Java Beans Eine kurze Einführung in die Welt der Bohnen Java Beans Einführung Stefan Sauer Was ist ein Java Bean? Beans sind Komponenten. Einmal schreiben Überall wiederverwerten

Mehr

Informationssystemanalyse Use Cases 11 1

Informationssystemanalyse Use Cases 11 1 Informationssystemanalyse Use Cases 11 1 Use Cases Slide 1 Als ein populäres Mittel um Anforderungen zu erfassen und Systeme zu beschreiben, werden Use Cases benutzt. Sie bilden die Basis für eine umfassendere

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

GeoShop Netzwerkhandbuch

GeoShop Netzwerkhandbuch Technoparkstrasse 1 8005 Zürich Tel.: 044 / 350 10 10 Fax.: 044 / 350 10 19 GeoShop Netzwerkhandbuch Zusammenfassung Diese Dokumentation beschreibt die Einbindung des GeoShop in bestehende Netzwerkumgebungen.

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

Datenbank-basierte Webserver

Datenbank-basierte Webserver Datenbank-basierte Webserver Datenbank-Funktion steht im Vordergrund Web-Schnittstelle für Eingabe, Wartung oder Ausgabe von Daten Datenbank läuft im Hintergrund und liefert Daten für bestimmte Seiten

Mehr

Autor: Peter Seemann Seminar: Softwarearchitekturen Betreuer: Benedikt Meurer

Autor: Peter Seemann Seminar: Softwarearchitekturen Betreuer: Benedikt Meurer Autor: Peter Seemann Seminar: Softwarearchitekturen Betreuer: Benedikt Meurer *Was sind Web Services? *Beispiele für Web Services *Web Service Architektur *Web Services Technologien *Fazit 2 *Übertragungsstandard

Mehr

Workflowmanagement. Business Process Management

Workflowmanagement. Business Process Management Workflowmanagement Business Process Management Workflowmanagement Workflowmanagement Steigern Sie die Effizienz und Sicherheit Ihrer betrieblichen Abläufe Unternehmen mit gezielter Optimierung ihrer Geschäftsaktivitäten

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