ASPEKTE DES EMPIRISCHEN SOFTWARE ENGINEERING IM UMFELD VON ENTERPRISE APPLICATION INTEGRATION LÖSUNGEN

Größe: px
Ab Seite anzeigen:

Download "ASPEKTE DES EMPIRISCHEN SOFTWARE ENGINEERING IM UMFELD VON ENTERPRISE APPLICATION INTEGRATION LÖSUNGEN"

Transkript

1 ASPEKTE DES EMPIRISCHEN SOFTWARE ENGINEERING IM UMFELD VON ENTERPRISE APPLICATION INTEGRATION LÖSUNGEN Daniel Reitz, Andreas Schmietendorf, Reiner Dumke Evgeni Dimitrov, Jens Lezius, Thomas Schlosser Arbeitsgruppe Softwaretechnik Software Measurment Laboratory (SMLab) Otto-von-Guericke-Universität Magdeburg Fakultät Informatik Institut für Verteilte Systeme Postfach 4120, Magdeburg T-Systems Nova GmbH, Entwicklungszentrum Berlin, KG STE T-Systems Nova EZ Berlin Postanschrift: Postfach 652, Berlin Hausadresse: Wittestr. 30H, Berlin

2 2

3 3 Abstrakt Die kommenden Jahre werden durch einen ständigen Wandel von Geschäftsprozessen geprägt sein, welche durch Informationssysteme effizient zu unterstützen sind. So genannte Enterprise-Application-Integration-Lösungen (kurz EAI) spielen in diesem Kontext eine zunehmend wichtigere Rolle, dem sich auch das Software-Engineering stellen muss. EAI-Lösungen zeichnen sich durch eine intelligente Vorgehensweise bei der Realisierung benötigter Schnittstellen zwischen den zu integrierenden Anwendungen aus. Während auf technischer Ebene eine weitgehende Entkopplung der zu integrierenden Anwendungen angestrebt wird, sollen Geschäftprozesse möglichst variabel zusammengeschaltet werden können. Die Vision ist es neue Integrationsanforderungen auf der Basis bestehender technischer Lösungen einfach konfigurieren zu können und notwendige Entwicklungsarbeiten auf ein Minimum zu beschränken. Im Rahmen dieses Preprints werden potentielle Einflusskriterien aufgezeigt und auf ausgewählte Notationen, Methoden und Tools zur Unterstützung des Software Engineering von EAI-Lösungen eingegangen. Darüber hinaus werden erste im praktischen Umfeld gewonnene empirische Erfahrungen wiedergegeben, die wesentliche Aufgaben auf dem Gebiet der technologiebezogenen- als auch Grundlagenforschung zur Effizienz komplexer Systeme implizieren. Die vorliegende Arbeit wurde in Kooperation zwischen dem Software Messlabor der Ottovon-Guericke-Universität Magdeburg und der Kompetenzgruppe System- und Technologieentwicklung des EZ Berlin innerhalb der T-Systems International erarbeitet.

4 4

5 5 Inhaltsverzeichnis 1 EINFÜHRUNG UND MOTIVATION 9 2 VERFÜGBARE LÖSUNGSANSÄTZE IM EAI-UMFELD Historische Entwicklung der EAI Schichtenmodell der Applikationsintegration Integrationslevel Datenaustausch mit XML Dienste von EAI-Lösungen Produkte im EAI-Umfeld 18 3 MIDDLEWARETECHNOLOGIEN FÜR DEN EAI-EINSATZ Kommunikationsformen Datenbankzugriffsmechanismen und -middleware Remote Procedure Call (RPC) Distributed Object Middleware Messageorientierte Middleware Komponentenorientierte Middleware Web Services Middlewareeinsatz in EAI-Projekten 31 4 BEISPIELE PRAKTISCHER IMPLEMENTIERUNGEN IM EAI-UMFELD Realisierung eines Common Information Bus Überblick zur Architektur der Integrationslösung Details der Integrationsapplikation Der CIB Agent EAI-SIM Anforderungen Realisierungskonzept Beschreibung der Lösung Ausblick und Weiterentwicklung 39 5 VORGEHENSWEISE ZUR IMPLEMENTIERUNG VON EAI-LÖSUNGEN Überblick zum Vorgehen Phasen eines Integrationsprojektes 41

6 6 6 MESS- UND BEWERTUNGSANSÄTZE FÜR EAI-LÖSUNGEN Potentielle Bewertungsaspekte Produktbewertung Prozessbewertung Ressourcenbewertung Aufwand- und Nutzensbetrachtungen von EAI-Projekten Verwendung von Integration Points Nutzensbetrachtungen Empirische Schnittstellenbetrachtungen Empirische Analysen einer EAI Integrations-Applikation Analyse der Version Analyse der Version Bewertung und Erkenntnisse Performanceanalyse einer EAI Integrations-Applikation Ziele und verfügbare Arbeiten Performancegerechte EAI-Entwicklung EAI-konformes Lastmodell Testdurchführung Ausgewählte Ergebnisse 65 7 ZUSAMMENFASSUNG 67 QUELLENVERZEICHNIS 68 ANLAGEN 70

7 7 Abbildungsverzeichnis Abbildung 1: Applikations- und Schnittstellen Spagetti 10 Abbildung 2: Unternehmensapplikationen mit EAI-Plattform 11 Abbildung 3: EAI-Schichtenmodell 13 Abbildung 4: Level der Integration 15 Abbildung 5: AIM Key Market Segments Forecast; in Millions USD 19 Abbildung 6: Lizenzumsatz im EAI-Markt bis Abbildung 7: Einordnung der Middleware in das OSI-Schichtenmodell 20 Abbildung 8: Kommunikationsbus für verteilte Anwendungen 21 Abbildung 9: Synchrone Kommunikation 22 Abbildung 10: ODBC-Kopplungsarchitektur [Conrad 1997] 23 Abbildung 11: Funktionsweise von RPC 24 Abbildung 12: OSF DCE Architektur 25 Abbildung 13: Die OMG Objekt Management Architektur (OMA) 26 Abbildung 14: Message-Queue basierte Kommunikation 27 Abbildung 15: EJB Architektur 28 Abbildung 16: Web Service Architektur 30 Abbildung 17: AIM Key Market Segments, License Sales 2001 in Mio. US-Dollar 31 Abbildung 18: Übersicht zur System-Architektur 33 Abbildung 19: Prinzip der Softwarearchitektur der Integrationsapplikation 34 Abbildung 20: Architektur des CIB-Agenten 35 Abbildung 21: EAI-SIM Homepage 38 Abbildung 22: EAI-SIM Webanwendung 39 Abbildung 23: Vorgehensweise zur Implementierung einer EAI-Lösung 40 Abbildung 24: Prinzip zur Ermittlung der Integration Points 50 Abbildung 25: Ungerichteter Graph mit 4 Knoten und 6 Kanten 52 Abbildung 26: potentielle Schnittstellen im Peer-to-Peer Netz und bei einer EAI-Lösung 53 Abbildung 27: Anzahl der Systeme und Schnittstellen 54 Abbildung 28: Ausprägung der verwendeten Session Beans 55 Abbildung 29: Ausprägung der verwendeten Entity Beans 56 Abbildung 30: Zusammenhang zwischen Bean-Klasse und Home-Interface 56 Abbildung 31: Umfangsanalyse von Session Beans (kurz SB) 57 Abbildung 32: Ausprägung der Entity Beans 58 Abbildung 33: Verhältnis zwischen Remote-Interface und Bean-Klasse 58 Abbildung 34: Session Bean und Bean-Klasse 59 Abbildung 35: Entity Bean und Bean-Klasse 60 Abbildung 36: Session Bean und Remote Interface 60 Abbildung 37: Entity Beans und Remote-Interfaces 60 Abbildung 38: Generisches Lastmodells der EAI-Anwendung 63 Abbildung 39: Übersicht zu genutzten Hard- und Softwaresystemen 64 Abbildung 40: Ergebnisse des Benchmarks (hier Laufzeit der Nachricht) 65

8 8 Tabellenverzeichnis Tabelle 1: Bespiele für CORBA-Services 26 Tabelle 2: Beispiele für EJB-Container Dienste 29 Tabelle 3: Vorschläge für die Analyse der Produktfeatures 47 Tabelle 4: Vorschläge für die Analyse der Produktperformance 47 Tabelle 5: Vorschläge für die Ermittlung der Plattformkosten 48 Tabelle 6: Ergebnis der Schnittstellenanalyse 53 Tabelle 7: Verweilzeiten der Bearbeitung (alle Zeiten der Tabelle in ms) 66

9 9 1 Einführung und Motivation Die zunehmende Globalisierung und Dynamisierung der Märkte ruft weiträumig agierende Unternehmen hervor, die innerhalb so genannter VACs (Value Added Communities) ihre wirtschaftlichen Zielstellungen verfolgen (siehe dazu auch [Means 2000]). Im Rahmen sowohl strategischer als auch zeitweiser Partnerschaften (dies impliziert auch eine Zusammenarbeit auf Anforderung) erfolgt eine gemeinsame Vermarktung von Produkten, die Integration von Produktions- und Lieferantenbeziehungen, der gemeinsame Zugriff auf Informationen und Services beteiligter Unternehmen sowie der Zugriff auf technische und auch auf menschliche Ressourcen. Wenngleich diese Form der Zusammenarbeit auch schon vor vielen Jahrzehnten angestrebt wurde, ermöglichen erst der Einsatz und vor allem die Integration rechnergestützter Informationssysteme die effiziente Umsetzung dieser Idee. Da die im Rahmen von VACs agierenden Unternehmen typischerweise eine gewachsene Anwendungslandschaft mitbringen und eine Neuentwicklung vorhandener Softwareanwendungen keine wirtschaftlich vertretbare Lösung darstellt, gilt es vorhandene und zukünftige Anwendungen so zu gestalten, dass diese mit anderen IT-Systemen auf der Basis standardisierter Schnittstellen interagieren können. Mit derartig integrierten Systemen sind sowohl unternehmensweite als auch unternehmensübergreifende Geschäftsprozesse möglichst durchgängig zu gestalten. In diesem Zusammenhang wird dann von so genannten EAI-Lösungen gesprochen. Die folgende ins Deutsche übersetzte Definition charakterisiert derartige Systeme noch einmal zusammenfassend (in Anlehnung an [Juric 2002, S. 12]): Mittels EAI können Daten und Geschäftsprozesse auf der Basis netzwerkbasierter Applikationen oder Datenquellen unternehmensweit genutzt werden. Frühe Software- Programme, wie z.b. Bestands- und Personalverwaltung, Verkaufssysteme und Datenbanksysteme, wurden weitgehend unabhängig voneinander entwickelt, ohne die potentiellen Interaktionen zwischen diesen Systemen zu berücksichtigen. Diese wurden unter Verwendung der jeweils aktuellen Technologien auf spezielle Kundenbedürfnisse hin entwickelt, wobei häufig proprietäre Systeme entstanden. Mit dem zunehmenden Wachstum der Unternehmen und der Erkenntnis, Daten und Funktionen einer Applikationen austauschen und unternehmensweit nutzen zu können, erfolgte die Investition in entsprechende EAI-Lösungen. Die letzten Jahrzehnte waren insbesondere durch die fortwährende Entwicklung immer neuer Applikationen geprägt, welche häufig nur ausgewählte Funktionen eines umfassenden Geschäftsprozesses berücksichtigen. Somit entstand in vielen Firmen eine große Anzahl an unabhängig voneinander entwickelten proprietären und autonomen Anwendungen (teilweise mit eigener Datenhaltung), die ausschließlich über direkte Punkt-zu-Punkt (Peer-to-Peer) Verbindungen miteinander kommunizieren. Mit Abbildung 1 soll ein so genanntes Spagetti- Netzwerk beispielhaft dargestellt werden. Die dort aufgeführten Abkürzungen haben dabei die folgenden Bedeutungen: CRM Customer Relationship Management, ERP Enterprise Ressource Planning und SOP Sales Order Processing. Der Nachteil einer solchen Struktur liegt in einer kaum noch zu beherrschenden Systemkomplexität. Bedingt durch die dezentralistischen Datenhaltungen der einzelnen Applikationen können Redundanzen an Daten und Funktionalitäten entstehen, die Inkonsistenzen möglich machen. Änderungen und Erweiterungen am System mit neuen Technologien, Applikationen oder Produkten sind sehr aufwendig und erschweren damit die Integration weiterer Systeme (beispielsweise bei Akquisitionen, Fusionen und Globalisierungsprojekten) und die Skalierbarkeit bei neuen Anforderungen. Je größer die Anzahl der verschiedenen Systeme ist, desto höher werden die Kosten für die Administration und Wartung; die Sicherheit, die Stabilität und die Performance und damit auch der Time-to-Market Wert können sich verschlechtern.

10 10 Abbildung 1: Applikations- und Schnittstellen Spagetti Aktuelle Herausforderungen liegen im Zusammenschluss vorhandener, aber auch in neu zu entwickelnden Systemen. Dabei wird sowohl die Integration unternehmensinterner Systeme angestrebt als auch die Integration von Systemen über Unternehmensgrenzen hinaus. Ebenfalls im Fokus stehen die Integration der Nutzerzugänge durch die Verwendung webbasierter Portale und die Möglichkeit, für Kunden auf ausgewählte Informationen zuzugreifen. In diesem Zusammenhang spielen so genannte Multi-Channel-Zugänge (z.b. WAP, Web, PDA,...), welche die Verwendung unterschiedlichster Endgeräte ermöglichen, eine wesentliche Rolle. Mit der Implementierung von Enterprise Application Integration Lösungen werden die folgenden konkreten Zielstellungen verfolgt: Integration heterogener Systemwelten, Vermeidung von redundanten Daten und Funktionalitäten, Minimierung der Systemkomplexität, Steigerung der Änderbarkeit, Erweiterbarkeit und Skalierbarkeit des Gesamtsystems, Vereinfachung der Wartung und Administration, Automatisierung und Dynamisierung von Geschäftsprozessen, Zentralisierung der Kontrolle durchgeführter Zugriffe, Optimierung der GP-Performance (time to market), Vereinfachte Anbindung an Zulieferer, Partner und Kunden (B2B, B2C), Senkung der Gesamtkosten. Erreicht werden kann das durch die Einführung einer zentralen Integrationsschicht und die Ersetzung der vielen Punkt-zu-Punkt Verbindungen durch jeweils eine Schnittstelle pro System zur EAI-Plattform (siehe Abbildung 2). Die Datenhaltung wird zentralisiert und ein einheitliches Datenformat zum Nachrichtenaustausch eingeführt. Erst dadurch entsteht die Möglichkeit systeminterne und systemübergreifende Geschäftsprozesse computergestützt zu modellieren und dann automatisiert ablaufen zu lassen. Das Unternehmen kann flexibler auf Anforderungsänderungen reagieren.

11 11 ERP E-Commerce CRM Legacy Systeme EAI-Plattform Kunden Datenbank SOP Produkt Datenbank Call Center Abbildung 2: Unternehmensapplikationen mit EAI-Plattform Im Zusammenhang mit der Implementierung von EAI-Lösungen gewinnen die Themenstellungen der Konvergenz zunehmend an Bedeutung. Konvergenz bezieht sich auf die Nutzung von Diensten über Länder-, aber auch Unternehmensgrenzen hinaus. Ein Kunde möchte z.b. an verschiedenen Orten der Welt seine wohlbekannten Dienste (z.b. Weiterleitung der im Home-Office eingehenden Anrufe) vorfinden und die Leistungen nur auf einer Rechnung nachvollziehen können. Unternehmen müssen sich diesen Anforderungen aus technologischer und geschäftlicher Sicht stellen. Dementsprechend sind konvergenzsichernde Technologien und Geschäftsmodelle zu etablieren. Der Fokus sollte dabei auf der Kundensicht liegen. Die Konvergenz-Landschaft wird durch die Kundenanforderungen getrieben, die mittels durchgängiger und integrierter Netzwerke und Services zu erfüllen sind. Dabei ist eine wachsende Anzahl potentieller Endgeräte zu unterstützen. Der vorliegende Preprint dient, ausgehend von einer verbalen Beschreibung grundlegender EAI-Technologien, als eine erste Übersicht zu möglichen empirischen Analysen in diesem Bereich. Erste Ansätze und industrielle Untersuchungen verdeutlichen die Prägnanz für die Anwendung derartiger Technologien und fokussieren den Forschungsbedarf für die Systembeherrschung unter den Bedingungen gewählter Komplexitätsmodelle.

12 12 2 Verfügbare Lösungsansätze im EAI-Umfeld Nach der Einführung im vorhergehenden Abschnitt soll als Nächstes auf den Begriff EAI etwas näher eingegangen werden. Dazu gehört ein kurzer historischer Abriss über die Entwicklung der EAI, die Vorstellung von involvierten Technologien, Integrationsstrategien und auf dem Markt angebotenen Produkte für EAI-Lösungen. 2.1 Historische Entwicklung der EAI 1 In den fünfziger und sechziger Jahre waren Anwendungen in Unternehmen noch sehr einfach gestrickt, was Funktionalität und Umfang betraf. Eine Zusammenarbeit zwischen den Applikationen war damals nicht notwendig bzw. sinnvoll. Durch Einführung von Festplattenspeichern und Datenbanktechnologien Ende der Sechziger, Anfang der Siebziger, konnten Programmierer direkt auf Informationen zugreifen, ohne den Umweg über sequentielle Dateien gehen zu müssen. In dieser Zeit wurde damit begonnen, über die Integration von Unternehmensdaten nachzudenken. In den Achtzigern begann man immer mehr den Wert und die Notwendigkeit von Applikationsintegration zu verstehen. In dieser Zeit entstanden einige der Middlewaretechnologien, die teilweise auch heute noch genutzt werden (RPC 1982, CORBA 1989). Viele der Anwendungen aus den siebziger Jahren mussten an die neuen Herausforderungen der IT-Abteilungen der Untenehmen angepasst werden. Durch die Versuche, bestehende ältere Systeme zu integrieren, kam allerdings die Neuentwicklung zu kurz. Ein Großteil der bestehenden Energien wurde darauf ausgerichtet, existierende Applikationen mit immer neuen benötigten Features auszustatten. Zwei neue Technologien sollten Anfang der neunziger Jahre antreten, um die Probleme der Applikationsintegration zu lösen: Enterprise Ressource Planning 2 (ERP) und Data Warehousing 3. Beide haben verschiedene Ausrichtungen. ERP integriert die operationalen Aspekte eines Unternehmens und Data Warehousing die anfallenden Daten. Die Weiterentwicklung dieser Technologien und die Entstehung von neuen (z.b. messageorientierte Middleware Mitte der Neunziger) resultiert in der EAI, wie wir sie heute vorfinden. Dazu gehören beispielsweise Strategien wie das Supply Chain Management (SCM), die Business-to-Business Integration (B2B) sowie die Business Prozess Integration (BPI). 2.2 Schichtenmodell der Applikationsintegration Eine automatisierte Abbildung der Geschäftsprozesse auf die IV-Struktur eines Unternehmens ist, wie schon festgestellt wurde, nur über die Integration der beteiligten Applikationen möglich. Wie man sich sicher vorstellen kann, ist dies, abhängig von der Größe des Unternehmens, ein relativ aufwändiger und kostenintensiver Prozess, da eine große Anzahl von unternehmensspezifischen Einflussfaktoren berücksichtigt werden muss. Eine einfache Install and Run - Lösung ist somit kaum realisierbar. Um den Umfang und die Komplexität der Aufgaben, die bei EAI-Projekten anfallen, besser verstehen zu können, soll hier ein Schichtenmodell vorgestellt werden, das die Aspekte der Unternehmensintegration aufeinander aufbauender Teilgebieten zuordnet und notwendige Tätigkeiten entsprechend zuteilt. 1 Quelle: William Inmon, "A Brief History of Integration." (www.eaijournal.com) 2 COMMUNICATIONS OF THE ACM, February 2003/Vol. 46 No 2: Enterprise Integration with ERP and EAI 3 Siehe auch [Mattison 1996]

13 13 Abbildung 3: EAI-Schichtenmodell Abbildung 3 zeigt eine Möglichkeit für ein solches EAI-Schichtenmodell. Auf die einzelnen Ebenen soll im Folgenden etwas detaillierter eingegangen werden: Plattform-Integration Die Plattform-Integration bildet die unterste Ebene des EAI- Schichtenmodells. Auf dieser Stufe ist es notwendig, die zugrunde liegenden Hard- und Softwarearchitekturen im heterogenen Unternehmensnetzwerk miteinander zu verbinden. Integration bedeutet hier, die Kommunikation zwischen den Unternehmensapplikationen möglichst effizient und sicher zu ermöglichen. Dazu muss u.a. zwischen verschiedenen Netzwerktypen, Hardwareplattformen und Betriebsystemen mit eigenen Technologien und Strategien zum Informationsaustausch, vermittelt werden. Ein Beispiel ist hier die Umstellung eines heterogenen Firmennetzwerkes auf das einheitliche und von fast allen Systemen unterstützte TCP/IP-Protokoll. Middleware-Integration Bei heutigen Unternehmen kann davon ausgegangen werden, dass ein Grossteil der existierenden Applikationen über die schon oben erwähnten Peer-to-Peer Verbindungen direkt miteinander kommuniziert. In diesen Fällen kommt eine so genannte Middlewaresoftware zum Einsatz, die den Nachrichtenaustausch ermöglicht. Bei der Integration der beteiligten Applikationen und der damit verbundenen Ersetzung der direkten Verbindungen durch Schnittstellen zur EAI-Plattform müssen diese Middlewaretechnologien durch die EAI- Middleware ausgetauscht und die Systeme daran angepasst werden. Ist dies nicht möglich, wird es notwendig, spezielle Adapter, die die Kommunikation ermöglichen, einzusetzen. Typische Middlewareansätze sind beispielsweise DCE RCP, COM+/DCOM, CORBA und EJB (mehr zum Thema Schnittstellen und Middleware siehe Abschnitt 3). Daten-Integration Eine der Schlüsselaufgaben in EAI-Projekten ist sicherlich die Integration der verschiedenen applikationsspezifischen Datenbanken zu einer unternehmensweiten Datenbasis mit zentralisiertem Zugriff über die EAI- Plattform. Dazu ist es notwendig, dass Unternehmensdaten, inklusive dem jeweiligen Speicherort und dem Datenbankschema, für jede Applikation identifiziert und katalogisiert werden und dass ein unternehmensweites Metadatenmodell er-

14 14 stellt wird, um gezielt auf die Informationen zugreifen zu können. Soweit möglich, sollten Datenbanken zusammengefasst werden, um unnötige Redundanzen zu vermeiden und Inkonsistenzen ausschließen zu können. Eine weitere Aufgabe dieser Ebene ist die Einführung eines einheitlichen Datenaustauschformates, für das sich beispielsweise XML (siehe auch Abschnitt 2.4) anbieten würde. Applikations-Integration Auf der Höhe dieser Integrationsebene besteht nur noch eine eher abstrakte Sicht auf die zugrunde liegende IV-Struktur des Unternehmens. Hier besteht die Aufgabe darin, die Daten und Funktionalitäten der Applikationen dem Gesamtsystem zur Verfügung zu stellen. Erleichtert oder erst ermöglicht werden dadurch beispielsweise automatisierte Verbindungen zwischen dem Back-Office und dem Front-Office, B2B-Lösungen und ein integrierter Web- Auftritt. Die Integration der Applikationen auf dieser Stufe ist die Vorraussetzung für ein integriertes Unternehmen auf Geschäftsprozessebene. GUI-Integration Wenn für alle integrierten Applikationen eine zentralisierte und einheitliche Nutzeroberfläche zur Verfügung gestellt wird, spricht man von der GUI-Integration. Potentiell geeignet sind dafür Web-Technologien, die einen Zugriff über das Internet/Intranet ermöglichen. Geschäftsprozess-Integration Hierbei handelt es sich um die höchste Stufe der EAI. Um Geschäftsprozesse integrieren zu können, ist es notwendig, dass existierende Geschäftsprozesse identifiziert, kombiniert und automatisiert werden. Dazu gehört die Verknüpfung von Aufgaben, Prozeduren, Organisationen, Informationsströmen und Anwendungen, die an den verschiedenen Geschäftsprozessen beteiligt sind. 2.3 Integrationslevel Neben dem Schichtenmodell aus dem vorhergehenden Abschnitt trifft man häufig in der Literatur 4 auf die Level der Integration, bei denen die Darstellung der Komplexität der Applikationsintegration und die Verteilung der Tätigkeiten im Vordergrund stehen. Die im Folgenden kurz vorgestellten EAI-Level (siehe auch Abbildung 4) dienen zur Festlegung des Umfanges der Integration aus Sicht des Unternehmens: Data-Level EAI Data-Level EAI ist aufgrund der geringen Kosten und des damit verbundenen geringen Risikos für viele Firmen der Einstiegspunkt in die Enterprise Application Integration. Integriert wird bei diesem Level auf der Ebene der Datenhaltung (siehe Abschnitt 2.2, Daten- Integration) und umgeht damit die Stufe der Applikations-Integration. Eine Anpassung der Zielanwendungen ist in den meisten Fällen nicht notwendig. Für die Data-Level EAI existieren zwei Ansätze. Beim ersten Ansatz werden Daten zwischen Datenbanken durch die periodische oder ereignisgesteuerte Synchronisation von Datenbankinhalten ausgetauscht. Diese Lösung entspricht virtuell der Punkt-zu-Punkt Kommunikation und kann somit in fast allen Fällen eingesetzt werden. Sollen Daten zwischen Datenbanken mit verschiedenen Datenbankmodellen (z.b. relational und objektorientiert) ausgetauscht werden, muss man diese transformieren. Der zweite Ansatz geht von einer Föderation der Datenbanken aus. Dabei wird anhand einer Middleware eine Schnittstelle auf ein unternehmensweites virtuelles Datenmodell geschaffen, unter dem alle Datenbanksysteme, unabhängig vom Hersteller, vom Modell und vom Schema, 4 B. Lublinsky - Achieving the Ultimate EAI Implementation,

15 15 zusammengefasst werden. Alle Applikationen haben somit einen zentralisierten Zugriff auf alle Unternehmensdaten. Abbildung 4: Level der Integration Message-Level EAI Auf diesem Level erfolgt der Informationsaustausch zwischen den Applikationen auf der Basis von Nachrichten. Das heißt, dass die Applikationen direkt miteinander kommunizieren können, ohne den Umweg über die Datenbanken nehmen zu müssen, wobei allerdings voraussetzt wird, dass diese Art der Kommunikation von den zu integrierenden Systemen direkt unterstützt werden muss. Der Vorteil liegt hierbei in dem besser zu kontrollierenden Informationsaustausch. Message-Level EAI ist aufwendiger als die Data-Level EAI, da die Applikationen mit Mechanismen und Schnittstellen zum Austausch von Nachrichten erweitert werden müssen. Im Gegensatz zu den Punkt-zu-Punkt Verbindungen wird hier der Publish-Subscribe Ansatz verfolgt. Bei einem Business-Event veröffentlicht die auslösende Applikation eine entsprechende Nachricht im Netzwerk. Eine andere Applikation, der Abonnement, holt sich aufgrund einer speziellen Kennzeichnung die Nachricht ab und kann dann damit weiterarbeiten. Der Nachteil bei diesem EAI-Level liegt im höheren Aufwand gegenüber der Data-Level EAI und in der ebenfalls hohen Kopplung der einzelnen Systeme untereinander. Process-Level EAI Bei der Prozess-Level EAI handelt es sich um die Form der Applikations-Integration, wie sie mit diesem Artikel eigentlich dargelegt werden soll. Die Integration erfolgt hier auf Basis von Geschäftsprozessen, wobei die EAI-Middleware als Workflow-Engine fungiert und damit sozusagen den Mittelpunkt der IV-Struktur des Unternehmens bildet. Alle Unternehmens- Applikationen sind entweder direkt oder über zwischengeschaltete Adapter mit ihr verbunden. Sie hat die Aufgabe, Schnittstellen für die existierenden Anwendungen bereitzustellen, den

16 16 nachrichtenbasierten Informationsaustausch anhand definierter Geschäftsprozesse im System zu routen und die ausgetauschten Daten zwischen applikationsspezifischen Formaten zu transformieren. Es existieren zwei Ansätze für die Implementation der Process-Level EAI: Message Broker und Application Server. Während sich Message Broker rein auf das Routen der Nachrichten beschränken und damit die Geschäftsprozess-Logik in den Anwendungen belassen, verlagern Application Server diese in die EAI-Plattform. Dadurch erhöhen sich noch einmal die Flexibilität, die Erweiterbarkeit und die Skalierbarkeit des Systems, allerdings auch gleichzeitig der Aufwand bei der Umsetzung. Die Geschäftsprozess-Integration ist die am weitesten fortgeschrittene Form der EAI. Sie erlaubt es einem Unternehmen, die Effizienz von Prozessen zu steigern, Kosten zu sparen und auf Kundenbedürfnisse besser zu reagieren. Welches Level aber letztendlich eingesetzt wird, ist von den Bedürfnissen des Unternehmens und den aufzubringenden Kosten abhängig. Gerade bei kleineren Firmen mit einer überschaubaren IV-Struktur und relativ kleinem Budget kann die Integration auf Daten- oder Nachrichtenebene durchaus genügen. 2.4 Datenaustausch mit XML Mit dem Start eines EAI-Projektes in einem Unternehmen muss man sich über ein einheitliches Datenformat Gedanken machen, da ansonsten die ständigen Transformationen zwischen den proprietären Formaten die Fehleranfälligkeit und die Laufzeit von Transaktionen im System erhöhen. Als ein de facto Standard für Datenbeschreibungssprachen im EAI-Umfeld hat sich XML (extensible Markup Language) durchgesetzt. Sie ist plattformunabhängig, menschenlesbar und wird von einer großen Anzahl an EAI bezogenen Produkten und Unternehmensapplikationen mit Import- und Export-Funktionen unterstützt. XML ist an sich, auch wenn es der Name anders impliziert, keine Markup 5 -Language, sondern stellt vielmehr eine Menge von Regeln dar, um neue Markup-Languages zu erzeugen. Entstanden ist XML als eine vereinfachte Teilmenge der Standard Generalized Markup Language (SGML), welche 1987 von Dr. Charles Goldfarb, Ed Mosher und Ray Lorie aus der GML in einen Industrie-Standard (ISO 8879) überführt wurde. Von ihr stammt beispielsweise auch HTML ab. GML (Generalized Markup Language) wurde ursprünglich entwickelt, um Kennzeichen, beispielsweise für das Layout oder den Font, in Texten für das Verlagswesen zu formalisieren. Heute dienen Markups allgemein dazu, die logische Struktur eines Dokumentes vom Inhalt zu trennen. Diese Struktur wird dazu genutzt, den Zweck der enthaltenen Daten zu beschreiben. Man spricht in diesem Falle auch von Meta-Daten. Eine mit XML definierte Markup- Language besteht aus einer Anzahl von Markup Tags (Kombination aus Wörtern und Sonderzeichen zur Beschreibung des Zwecks der Daten) und einer für die Dokumente spezifischen Baumstruktur. Die Tags und die Baumstruktur (oder Content Model) werden in der DTD- Datei (DTD Document Type Definition) niedergeschrieben. Mehr zum Thema XML findet sich u.a. in [Daconta 2000]. 2.5 Dienste von EAI-Lösungen An eine moderne EAI-Plattform werden eine Menge Anforderungen gestellt. Sie sollte möglichst performant, skalierbar, offen und sicher sein. Sie sollte die Geschäftsprozessintegration genauso unterstützen wie die Business-to-Business Integration und die Integration aller Nutzeroberflächen der beteiligten Applikationen. Des Weiteren sollte sie über entsprechende Tools leicht zu administrieren sein, möglichst viele Standard-Applikationen und Hard- und 5 Extensible Markup Language Erweiterbare Textauszeichnungs/Textkennzeichnungs-Sprache

17 17 Softwarearchitekturen unterstützen, und sie sollte eine spezifische Entwicklungsumgebung mitbringen, um eine Anpassung der IV-Struktur des Unternehmens zu ermöglichen. Welche Dienste muss eine solche EAI-Lösung also anbieten, um die an sie gerichteten Bedürfnisse befriedigen zu können? Die folgende Liste stellt eine Übersicht über die wichtigsten EAI- Services dar: Plattform- und Protokollmanagement Dazu gehört die Unterstützung einer Vielzahl von Hard- und Softwareplattformen, Middlewaretechnologien im heterogenen Unternehmensnetzwerk und verschiedener Kommunikationsprotokolle. Synchronous, Asynchronous Support Je nach Aufgabenstellung kann die Nutzung eines synchronen oder eines asynchronen Datenaustausches sinnvoller sein. Des Weiteren ist es möglich, dass verschiedene Middlewarelösungen im Unternehmen im Einsatz sind, die nur eine der beiden Strategien unterstützen. Daher sollte eine EAI-Lösung Dienste zur Nutzung des synchronen oder asynchronen Datenaustausches und zur Vermittlung zwischen den beiden Technologien (Bridging) anbieten. Security Management Eine sehr wesentliche aber auch sehr komplexe und verantwortungsvolle Aufgabe ist das Security Management. Unternehmensdaten sind oftmals sehr sensibel und dürfen daher auf keinen Fall in die falschen Hände geraten. Eine EAI-Lösung hat daher die Aufgabe, wirkungsvolle Mechanismen für die Verschlüsselung von Kommunikation und Daten und zur Authentifizierung von Nutzern und Nutzergruppen anzubieten, um spezielle Bereiche und Informationen nur ausgewählten Personen zur Verfügung zu stellen. Daten Transformation und Mapping Dazu gehören Dienste zur weiter oben bereits erwähnten Umwandlung von proprietären Datenformaten in das einheitliche XML-Format, sowie Mechanismen zum Parsen von XML-Dateien und Nachrichten Daten- und Nachrichten-Persistens Die persistente Speicherung von Daten und Nachrichten in Knotenpunkten von Übertragungseinrichtungen und Servern dient zur Sicherung der Zuverlässigkeit von Kommunikationswegen und zur Wahrung der Konsistenz des Gesamtsystems beim Ausfall von einzelnen Systemen, die an der Übermittlung und Verarbeitung der Daten und Nachrichten beteiligt sind. Sollte es zu einem Ausfall kommen, so kann zur Wiederherstellung der Konsistenz mit Hilfe der gespeicherten Informationen ein Rollback durchgeführt werden. Transaktionsverwaltung Operationen auf Datenbankinhalten bestehen grundsätzlich aus einer Anzahl von schreibenden und/oder lesenden Zugriffen. Transaktionen sind Datenbankoperationen, die die ACID Eigenschaften besitzen. ACID steht für: o Atomicity Eine Operation wird entweder vollständig oder gar nicht ausgeführt. Falls eine Operation nicht vollständig ausgeführt wird, müssen alle vorgenommenen Änderungen rückgängig gemacht werden, um die Konsistenz zu wahren.) o Consistency Durch eine Transaktion darf die Konsistenz der Datenbank nicht gefährdet werden. Daher müssen nach der entsprechenden Operation Überprüfungen der Integritätsbedingungen vorgenommen werden. o Isolation Eine Person darf nur auf Daten zugreifen, die von keiner anderen Person bearbeitet werden. Sie hat damit einen exklusiven Zugriff.

18 18 o Durability Nach einer erfolgreichen Transaktion müssen die Ergebnisse der Operation persistent in der Datenbank vorliegen. Alle nachfolgenden Operationen beziehen sich damit auf den aktualisierten konsistenten Inhalt der Datenbasis. Die Transaktionsverwaltung hat die Aufgaben die ACID-Eigenschaften für Transaktionen zu garantieren und eine Abarbeitungsfolge (Scheduling) für Operationen von verschiedenen Nutzern festzulegen. Routing Services Da in einem integrierten Unternehmen die Applikationen im Idealfall nicht mehr direkt miteinander kommunizieren, hat die EAI-Plattform die Aufgabe, die Nachrichten und Informationen anhand von definierten Geschäftsprozessen weiterzuleiten. Des Weiteren sollte sie den Anwender bei der Eingabe und Definition dieser Geschäftsprozesse vorzugsweise mit einem grafischen Editor unterstützen. Load-Balancing Load-Balancing bedeutet die Aufteilung von Anfragen an gleichwertige Server, um eine möglichst gleichmäßige Lastverteilung und damit minimale Antwortzeiten zu erreichen. Error- und Exception-Handling Sollte eins der Systeme oder eine Übertragungseinrichtung ausfallen, so hat die EAI-Plattform die Aufgabe betroffene Systeme und Personen (z.b. den Administrator) zu informieren und wenn möglich, geeignete Gegenmaßnahmen zu ergreifen. Um solche Ausfälle selbständig erkennen zu können, müssen der Zustand und die Konsistenz des Gesamtsystems ständig ü- berwacht werden. 2.6 Produkte im EAI-Umfeld Bei EAI-Plattformen arbeiten oft verschiedene Einzellösungen Hand in Hand. Eine mit der Integration beauftragte IV-Abteilung oder Firma hat hier entweder die Möglichkeit, eine am Markt befindliche Komplettlösung von einem Hersteller einzusetzen und die existierende IV- Infrastruktur darauf anzupassen, oder sie verfolgt den so genannten best of breed Ansatz, bei dem mehrere Teillösungen von verschiedenen Herstellern, die auf das Unternehmen und auf die bestehende Situation am besten zugeschnittenen sind, ausgewählt und kombiniert werden. Der erste Ansatz hat den Vorteil, dass alle Komponenten aus einer Hand kommen und die Zusammenarbeit somit gewährleistet ist. Die Kosten für das Training der Mitarbeiter und für die Integration der Applikationen sind im Gegensatz zum zweiten Ansatz verhältnismäßig gering. Nachteilig dabei ist aber, dass Teilkomponenten, die spezielle Bedürfnisse eines Unternehmens nur eingeschränkt oder gar nicht befriedigen, in den wenigsten Fällen ausgetauscht werden können. Wurde erst einmal eine Plattform ausgewählt, ist man von ihr sowie von den angebotenen Leistungen und verwendeten Technologien abhängig. Ein späterer Wechsel auf eine andere Plattform ist mit einem unverhältnismäßig hohen Aufwand verbunden. Hinzu kommt, dass aufgrund ihrer hohen Spezialisierung eine Einzellösung eine Aufgabe oft besser erfüllen kann als die Teillösungen einer EAI-Plattform, welche möglichst viele Bereiche abdecken wollen. Produkte für das EAI-Umfeld kommen typischerweise aus den Bereichen Middleware, TP Monitore, Message Broker, Application Server, Web-Portal-Software und Geschäftsprozessmodellierung. Werden von einem Hersteller diese verschiedenen Teilprodukte als eine integrierte Komplettlösung angeboten, spricht man von einem EAI-Framework (beispielsweise angeboten von Herstellern wie IBM, TIBCO oder Vitria).

19 19 Abbildung 5: AIM Key Market Segments Forecast; in Millions USD 6 Eine an der Universität Magdeburg in Kooperation mit der T-Systems GmbH durchgeführte Studienarbeit [Winkler 2002] hat das Marktpotential für Lösungen im gesamten EAI-Umfeld näher beleuchtet. Grundlage für die Untersuchung waren Studien einer größeren Anzahl unterschiedlicher Marktforschungsunternehmen, wie beispielsweise der Gartner Group, der Seeburger AG oder Wintergreen Research. Ausgehend von den Ursachen für die Notwendigkeit der Integration, der Marktsituation für bestehende EAI-Lösungen und von Trends in diesem Bereich, wurden Marktanteile aktueller EAI-Anbieter und reale und potentielle Umsätze untersucht und dargestellt. Lizenzumsatz in Mrd. US$ 20 17, ,8 4,4 2,2 0,29 0,55 1, Abbildung 6: Lizenzumsatz im EAI-Markt bis Die Abbildung 5 und die Abbildung 6 zeigen Auszüge aus den Ergebnissen der Studie. Dargestellt werden der aktuelle und der zu erwartende Umsatz mit entsprechenden Produkten im EAI-Umfeld. 6 Quelle: Gartner Dataquest. [Gartner 2001] 7 Quelle: Wintergreen Research

20 20 3 Middlewaretechnologien für den EAI-Einsatz Aufgrund der heutzutage oft verwirrenden Begriffsvielfalt stellen wir zunächst die folgende Definition an den Anfang: Definition: Middleware ist eine Menge von spezialisierten (general purpose) Diensten, die zwischen der Systemplattform (Hardware + Betriebssystem) und den Anwendungen angesiedelt sind und deren Verteilung unterstützen. Der Einsatz moderner Middlewaretechnologien ist eine der wichtigsten Vorraussetzungen für die Integration von Applikationen in heterogenen Firmennetzwerken. Durch sie wird es einer Applikation ermöglicht, auf die Daten und Funktionalitäten einer anderen Applikation zuzugreifen und das unabhängig davon, ob sich die Applikation im eigenen oder in einem Partnerunternehmen befindet. Applications Application 1 Application 2 Middleware Application-Layer Presentation-Layer Session-Layer Application-Layer Presentation-Layer Session-Layer Data transport services Transport-Layer Network-Layer Data-Layer Physical-Layer Transport-Layer Network-Layer Data-Layer Physical-Layer Data transfer Abbildung 7: Einordnung der Middleware in das OSI-Schichtenmodell 8 Geht man vom OSI-Schichtenmodell 9 für Netzwerke aus, positioniert sich die Middleware in den obersten drei Schichten: Applikation, Präsentation und Sitzung (siehe Abbildung 7). Sie definiert dabei auf Grundlage des darunter liegenden Netzwerkes die Kommunikations- Mechanismen zwischen den einzelnen Applikationen. Zum Einsatz einer Middlewarelösung muss diese auf den zu integrierenden Systemen überhaupt zur Verfügung stehen, es muss die Fachlichkeit der entsprechenden Schnittstelle im Mittelpunkt der Spezifikation bzw. des Design stehen und sie sollte über ausreichende Mechanismen zur Transaktionssicherung verfügen bzw. Möglichkeiten zur Verschlüsselung und Authentifizierung anbieten. Ein weiterer sehr wichtiger Punkt beim Einsatz einer Middlewarelösung ist die Offenheit der angebotenen Schnittstellen, da es in vielen Fällen notwendig werden kann, verschiedene Technologien zu kombinieren. In vielen Firmen existieren noch so genannte sehr spezielle Legacy-Systeme, die teilweise ihre eigene Middlewaretechnologie verwenden. Wenn diese nicht ausgetauscht oder angepasst werden können, müssen Schnittstellen zwischen den ein- 8 aus [Searin 1999, Seite 5] 9 siehe beispielsweise [Tanenbaum 1997]

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

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

Aktuelle Ansätze für Web Service basierte Integrationslösungen. Andreas Schmietendorf, Jens Lezius, Evgeni Dimitrov Daniel Reitz, Reiner Dumke

Aktuelle Ansätze für Web Service basierte Integrationslösungen. Andreas Schmietendorf, Jens Lezius, Evgeni Dimitrov Daniel Reitz, Reiner Dumke Aktuelle Ansätze für Web Service basierte Integrationslösungen Arbeitsgruppe Softwaretechnik Software Measurement Laboratory SMLab Andreas Schmietendorf, Jens Lezius, Evgeni Dimitrov Daniel Reitz, Reiner

Mehr

Vorlesung. Informationssysteme. Prof. Dr. Hans Czap. Lehrstuhl für Wirtschaftsinformatik I. Email: Hans.Czap@uni-trier.de

Vorlesung. Informationssysteme. Prof. Dr. Hans Czap. Lehrstuhl für Wirtschaftsinformatik I. Email: Hans.Czap@uni-trier.de Vorlesung Grundlagen betrieblicher Informationssysteme Prof. Dr. Hans Czap Email: Hans.Czap@uni-trier.de - II - 1 - Inhalt Kap. 1 Ziele der Datenbanktheorie Kap. 2 Datenmodellierung und Datenbankentwurf

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

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

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

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

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

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

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

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

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

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

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

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221 Oracle 10g und SQL Server 2005 ein Vergleich Thomas Wächtler 39221 Inhalt 1. Einführung 2. Architektur SQL Server 2005 1. SQLOS 2. Relational Engine 3. Protocol Layer 3. Services 1. Replication 2. Reporting

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

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

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

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

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

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

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

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

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

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

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

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

Curret Topics in BPM and EA

Curret Topics in BPM and EA Curret Topics in BPM and EA IV WS 2011 Introduction Competence Center EA/Dr.-Ing. Marten Schönherr 1 Agenda Ausgangssituation Komplexität, technische und fachliche Heterogenität Argumentation Terminologie

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

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

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

Etablierung serviceorientierter Architekturen mit Web Services

Etablierung serviceorientierter Architekturen mit Web Services Etablierung serviceorientierter Architekturen mit Web Services Vorlesung im (Entwicklung von Serviceangeboten) 1 Agenda Einsatzbereiche von Web Service basierten Angeboten Übersicht zur Java-System Application

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

Komponentenmodelle II

Komponentenmodelle II Komponentenmodelle II DCOM / CORBA Detlef Streitferdt Technische Universität Ilmenau DCOM Architektur Client Proxy Stub Component CoCreateInstance Security Provider DCE RPC Protocol Stack Security Provider

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

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

Sun ONE. Sun Open Net Environment. Architektur für Web-Services on Demand. Dr. Rainer Eschrich rainer.eschrich@sun.com

Sun ONE. Sun Open Net Environment. Architektur für Web-Services on Demand. Dr. Rainer Eschrich rainer.eschrich@sun.com Sun ONE Sun Open Net Environment Dr. Rainer Eschrich rainer.eschrich@sun.com Architektur für Web-Services on Demand Sun ONE Vision Wie kann Software dem Kunden helfen? Kostenreduktion: Wie? In dem man

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

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

CRONOS CRM Online for OS

CRONOS CRM Online for OS www.osram-os.com CRONOS CRM Online for OS B. Blanz, S. Eichinger 08.09.2014 Regensburg Light is OSRAM Customer Relationship Management Online for OS Page 1. Vorstellung des Projekts CRONOS 04 2. Anforderungsanalyse

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

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

Implementierung von Geschäftsprozessen in der Verwaltung mit Hilfe von SOA

Implementierung von Geschäftsprozessen in der Verwaltung mit Hilfe von SOA E-Gov Fokus Geschäftsprozesse und SOA 31. August 2007 Implementierung von Geschäftsprozessen in der Verwaltung mit Hilfe von SOA Im Vortrag werden die Vor- und Nachteile von Geschäftsprozessen in der öffentlichen

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

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

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

Andreas Emhart Geschäftsführer Alegri International Group

Andreas Emhart Geschäftsführer Alegri International Group Andreas Emhart Geschäftsführer Alegri International Group Agenda Vorstellung Alegri International Überblick Microsoft Business Intelligence Sharepoint Standard Business Intelligence Tool Excel Service

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

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

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching

1 Einleitung. 1.1 Caching von Webanwendungen. 1.1.1 Clientseites Caching 1.1 Caching von Webanwendungen In den vergangenen Jahren hat sich das Webumfeld sehr verändert. Nicht nur eine zunehmend größere Zahl an Benutzern sondern auch die Anforderungen in Bezug auf dynamischere

Mehr

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA Liste der Handbücher Liste der Benutzerhandbücher von MEGA MEGA 2009 SP4 1. Ausgabe (Juni 2010) Die in diesem Dokument enthaltenen Informationen können jederzeit ohne vorherige Ankündigung geändert werden

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

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

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

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

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

Workflow, Business Process Management, 3.Teil

Workflow, Business Process Management, 3.Teil Workflow, Business Process Management, 3.Teil 12. Januar 2004 Der orliegende Text darf für Zwecke der Vorlesung Workflow, Business Process Management des Autors erielfältigt werden. Eine weitere Nutzung

Mehr

Komplexität der Information - Ausgangslage

Komplexität der Information - Ausgangslage Intuition, verlässliche Information, intelligente Entscheidung ein Reisebericht Stephan Wietheger Sales InfoSphere/Information Management Komplexität der Information - Ausgangslage Liefern von verlässlicher

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

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

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

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

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

e-business - Patterns Stefan Brauch (sb058) -- Julian Stoltmann (js057)

e-business - Patterns Stefan Brauch (sb058) -- Julian Stoltmann (js057) e-business - Patterns Stefan Brauch (sb058) -- Julian Stoltmann (js057) 1 e-business Patterns??? e-business Patterns Architekturen, die sich über die Zeit bewährt haben. Pattern-Fundgrube web-basierte

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

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

10. Seminar GIS & INTERNET, 11. Sept. 2007

10. Seminar GIS & INTERNET, 11. Sept. 2007 Service-orientierte Architektur (SOA) und Geodateninfrastruktur (GDI): dienstbare GIS-Komponenten Dr.-Ing. Jens Hartmann, Account Manager 10. Seminar GIS & INTERNET, 11. Sept. 2007 Agenda Motivation Service-orientierte

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

Dataport IT Bildungs- und Beratungszentrum. HTML- Grundlagen und CSS... 2. XML Programmierung - Grundlagen... 3. PHP Programmierung - Grundlagen...

Dataport IT Bildungs- und Beratungszentrum. HTML- Grundlagen und CSS... 2. XML Programmierung - Grundlagen... 3. PHP Programmierung - Grundlagen... Inhalt HTML- Grundlagen und CSS... 2 XML Programmierung - Grundlagen... 3 PHP Programmierung - Grundlagen... 4 Java - Grundlagen... 5 Java Aufbau... 6 ASP.NET Programmierung - Grundlagen... 7 1 HTML- Grundlagen

Mehr

Wir befinden uns inmitten einer Zeit des Wandels.

Wir befinden uns inmitten einer Zeit des Wandels. Wir befinden uns inmitten einer Zeit des Wandels. Geräte Apps Ein Wandel, der von mehreren Trends getrieben wird Big Data Cloud Geräte Mitarbeiter in die Lage versetzen, von überall zu arbeiten Apps Modernisieren

Mehr

Abbildung 3-1: Clients und Server C+S

Abbildung 3-1: Clients und Server C+S Abbildung 3-1: Clients und Server C+S Abbildung 3-2: Interaktions-koordinations-arten Abbildung 3-3: Zuverlässige Nachrichtenübertragung a) durch individuell quittierte Nachrichten b) durch Quittierung

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

Transaktionsverwaltung

Transaktionsverwaltung Transaktionsverwaltung VU Datenbanksysteme vom 21.10. 2015 Reinhard Pichler Arbeitsbereich Datenbanken und Artificial Intelligence Institut für Informationssysteme Technische Universität Wien Transaktionsverwaltung

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

Business Rules und SOA. Parallelen und Synergien

Business Rules und SOA. Parallelen und Synergien Business Rules und SOA Parallelen und Synergien White Paper Januar 2008 Innovations Software Technology GmbH, 2008. Alle Rechte vorbehalten. Weitergabe und Vervielfältigung dieser Publikation oder von

Mehr

Von ODBC zu OLE DB. Neue Möglichkeiten der Datenintegration. Harald Gladytz, Team Vertrieb ESRI Niederlassung Leipzig

Von ODBC zu OLE DB. Neue Möglichkeiten der Datenintegration. Harald Gladytz, Team Vertrieb ESRI Niederlassung Leipzig Von ODBC zu OLE DB Neue Möglichkeiten der Datenintegration Harald Gladytz, Team Vertrieb ESRI Niederlassung Leipzig Von ODBC zu OLE DB Begriffsbestimmung ODBC, OLE DB, COM, ADO... Unterschiede zwischen

Mehr

Diplomarbeit: evidence goes Azure

Diplomarbeit: evidence goes Azure 0 Diplomarbeit: evidence goes Azure Pflichtenheft Projekt: Thema: Version: 1.1 evidence goes Azure evidence in der Cloud betreiben _MasterThesis.docx Abstract: Den.net basierenden Applikationsserver evidence

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

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

A Generic Database Web Service for the Venice Lightweight Service Grid

A Generic Database Web Service for the Venice Lightweight Service Grid A Generic Database Web Service for the Venice Lightweight Service Grid Michael Koch Bachelorarbeit Michael Koch University of Kaiserslautern, Germany Integrated Communication Systems Lab Email: m_koch2@cs.uni-kl.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

SOA und Prozessmanagement: Herausforderung und aktuelle Arbeiten

SOA und Prozessmanagement: Herausforderung und aktuelle Arbeiten SOA Prozessmanagement: Herausforderung aktuelle Arbeiten Projekt-Kurzvorstellung beim Gründungstreffen des EMISA-Arbeitskreises Entwicklung agiler, prozessorientierter Informationssysteme Reiner Siebert,

Mehr

Whitepaper. wir wissen wie

Whitepaper. wir wissen wie Whitepaper wir wissen wie Aufgabenstellung Lösung Der Markt bietet unzählige EAI Tools. Diese sind meist sehr umfangreich und dem entsprechend sehr teuer. Um diese Tools einzusetzen, braucht ein Projekt

Mehr

Koordination Kommunikation Bahn. KoKoBahn. Projektpartner. Laufzeit. Travemünder Datenverbund GmbH, Lübeck. dbh Logistics IT AG, Bremen

Koordination Kommunikation Bahn. KoKoBahn. Projektpartner. Laufzeit. Travemünder Datenverbund GmbH, Lübeck. dbh Logistics IT AG, Bremen Koordination Kommunikation Bahn KoKoBahn Berlin, 09. / 10. Dezember 2010 Projektpartner Travemünder Datenverbund GmbH, Lübeck dbh Logistics IT AG, Bremen Laufzeit 01.06.2008 31.05.2011 Die Komplexität

Mehr

ENTWICKLUNGS- UND LAUFZEITUMGEBUNG DER CSE: ECLIPSE UND JBOSS. Piotr Kasprzak

ENTWICKLUNGS- UND LAUFZEITUMGEBUNG DER CSE: ECLIPSE UND JBOSS. Piotr Kasprzak ENTWICKLUNGS- UND LAUFZEITUMGEBUNG DER CSE: ECLIPSE UND JBOSS Piotr Kasprzak Agenda Laufzeitumgebung Java EE (J2EE) Motivation APIs / Technologien JBoss Entwicklungsumgebung Eclipse Ausblick Java EE -

Mehr

Kapitel 1 Überblick Content Management und Digitale Bibliotheken

Kapitel 1 Überblick Content Management und Digitale Bibliotheken Kapitel 1 Überblick Content Management und Digitale Bibliotheken Prof. Dr.-Ing. Stefan Deßloch Geb. 36, Raum 329 Tel. 0631/205 3275 dessloch@informatik.uni-kl.de 1 Überblick Was ist Content? Daten, Dokumente,

Mehr

Integration Services - Dienstarchitektur

Integration Services - Dienstarchitektur Integration Services - Dienstarchitektur Integration Services - Dienstarchitektur Dieser Artikel solle dabei unterstützen, Integration Services in Microsoft SQL Server be sser zu verstehen und damit die

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

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

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

MICROSOFTS CLOUD STRATEGIE

MICROSOFTS CLOUD STRATEGIE MICROSOFTS CLOUD STRATEGIE Sebastian Weber Head of Technical Evangelism Developer Platform & Strategy Group Microsoft Deutschland GmbH Slide 1 WAS IST CLOUD COMPUTING? Art der Bereitstellung von IT-Leistung

Mehr

GEDS Dienstleistungen. Software Engineering

GEDS Dienstleistungen. Software Engineering GEDS Dienstleistungen Software Engineering GEDS Software Engineering Übersicht Leistungen Methoden Vorgehen Projektablauf Technologien Software Engineering Leistungen Auftragsprogrammierung Wir übernehmen

Mehr

high technologie for vpn- and firewall- solutions

high technologie for vpn- and firewall- solutions high technologie for vpn- and firewall- solutions msm net ingenieurbüro meissner Am Porstendorferweg 4 D 07570 Niederpöllnitz Inhaltsverzeichnis 1. Wir über uns 2. VPN Lösungen mit stationärer Technik

Mehr

Verteilungsmechanismen in verschiedenen RDBMS

Verteilungsmechanismen in verschiedenen RDBMS Verteilungsmechanismen in verschiedenen RDBMS Vorlesung im Wintersemester 2013 (Analyse verschiedener RDBMS-Produkte hinsichtlich angebotener Verteilmechanismen) Prof. Dr. Andreas Schmietendorf 1 Zielstellung

Mehr

DWH Szenarien. www.syntegris.de

DWH Szenarien. www.syntegris.de DWH Szenarien www.syntegris.de Übersicht Syntegris Unser Synhaus. Alles unter einem Dach! Übersicht Data-Warehouse und BI Projekte und Kompetenzen für skalierbare BI-Systeme. Vom Reporting auf operativen

Mehr

Hauptseminar Wartung von Softwaresystemen

Hauptseminar Wartung von Softwaresystemen Hauptseminar Wartung von Softwaresystemen Legacy Migrationsstrategien 13. Dezember 2005 Seite 1 Überblick 1. Einführung und Definitionen 2. Migrationsstrategien 3. Migration bei verschiedenen Systemstrukturen

Mehr

Prüfungsberatungs-Stunde Datenbanksysteme 1 (Dbs1)

Prüfungsberatungs-Stunde Datenbanksysteme 1 (Dbs1) Prüfungsberatungs-Stunde Datenbanksysteme 1 (Dbs1) Herbstsemester 2013/14 Prof. S. Keller Informatik HSR Januar 2014, HS13/14 Dbs1 - Prüfungsvorbereitung 1 Dbs1 Ziele Grundlagenwissen in folgenden Gebieten

Mehr