Architekturen und Technologien für EAI

Architectures and Technologies for EAI

Cyrus Mesgarzadeh 8951888 Seminararbeit für das

Seminar aus Informationswirtschaft (3230) im WS 2002/03 Anwendungsintegration in und zwischen Unternehmen (EAI - Enterprise Application Integration)

o. Univ. Prof. Dkfm. Dr. Wolfgang H. Janko Univ.-Ass. Mag. Dr. Michael Hahsler

- 1 -

Inhaltsverzeichnis 1 Einleitung ...................................................................................................................... 3

1.1 Was ist EAI................................................................................................................ 3 1.2 Das Problem .............................................................................................................. 3 1.3 Lösung mit EAI ......................................................................................................... 4

2 Andere Lösungswege..................................................................................................... 6 2.1 Schnittstellen.............................................................................................................. 6

2.1.1 Arten .................................................................................................................. 6 2.1.2 Probleme ............................................................................................................ 6 2.1.3 Kostenvergleich mit EAI .................................................................................... 6

2.2 Betriebswirtschaftliches Gesamtsystem: ERP/ERM ................................................... 8 2.2.1 Ansatz ................................................................................................................ 8 2.2.2 Probleme ............................................................................................................ 8

3 Verwendete Technologien.............................................................................................. 9 3.1 Middleware................................................................................................................ 9

3.1.1 Allgemeines ....................................................................................................... 9 3.1.2 Middleware Implementierungen ....................................................................... 11

3.2 Komponenten........................................................................................................... 11 3.3 CORBA ................................................................................................................... 12

3.3.1 Allgemeines ..................................................................................................... 12 3.3.2 Funktionsweise................................................................................................. 12 3.3.3 Umsetzungen.................................................................................................... 13

3.4 Java RMI ................................................................................................................. 14 3.4.1 Allgemein......................................................................................................... 14 3.4.2 Funktionsweise................................................................................................. 14

3.5 DCOM..................................................................................................................... 15 3.5.1 Allgemeines ..................................................................................................... 15 3.5.2 Funktionsweise................................................................................................. 15

3.6 Vergleich CORBA, Java RMI und DCOM............................................................... 16 3.7 Web Services und .NET Framework ........................................................................ 16

3.7.1 Allgemeines ..................................................................................................... 16 3.7.2 Funktionsweise................................................................................................. 17

4 EAI-Tools.................................................................................................................... 18 4.1 Marktaussichten ....................................................................................................... 18 4.2 Anbieter ................................................................................................................... 18 4.3 Kosten...................................................................................................................... 18

5 Zusammenfassung ....................................................................................................... 19 Literatur............................................................................................................................... 20 Abbildungsverzeichnis......................................................................................................... 21

- 2 -

Architekturen und Technologien für EAI

Architectures and Technologies for EAI Stichworte: Enterprise Application Integration, Schnittestellen, Middleware Keywords: Enterprise Application Integration, Interfaces, Middleware

Zusammenfassung In dieser Seminararbeit werden die Architekturen und Technologien für die Integration von heterogenen Unternehmensanwendungen besprochen und erläutert. Es wird auf die Ursachen für die Notwendigkeit von EAI – Enterprise Application Integration eingegangen und auch die bisher verwendeten traditionellen Lösungswege kurz dargestellt. Die für die Integration benötigte Middleware wird erklärt und die wichtigsten aktuellen Techniken beschrieben.

Abstract

In this seminar paper architectures and technologies dealing with integration of heterogeneous business applications will be discussed and explained. The reasons for the necessity for EAI – Enterprise Application Integration will be shown as well as traditional solutions. The middleware which is used for the integration will be explained and the most important technologies will be described.

Kernpunkte für das Management Diese Arbeit stellt das Problem von heterogenen Unternehmensanwendungen dar, die teilweise über Jahrzehnte gewachsen und eine mögliche Lösungen durch Enterprise Application Integration, kurz EAI. Ziel von EAI ist es ohne komplette Umstellung der bisherigen IT-Struktur in einem Unternehmen, den steigenden Anforderungen an die Flexibilität und Integration der eigenen Anwendungen gerecht zu werden und das nicht mehr nur für die internen Benutzer, sondern auch für Kunden, Lieferanten und anderen Partnern. Es werden Architekturen und Techniken beschrieben die dies ermöglichen sollen. Die bisherigen Lösungswege werden mit ihren Vor und- Nachteilen kurz dargestellt.

- 3 -

1 Einleitung

1.1 Was ist EAI EAI - Enterprise Application Integration - ist zu einem beliebtem Schlagwort geworden, eine Lösung für scheinbar alle Probleme, die in großen heterogenen System entstehen, zu bieten. In einem wirtschaftlichen Umfeld in dem es ein wichtiger Erfolgsfaktor ist, schneller als sein Konkurrent zu sein, muss auch die IT-Architektur eines Unternehmens dieser Schnelligkeit Rechnung tragen und immer komplexere Informationen rasch und zuverlässig, über die verschiedenen Unternehmensbereiche und die eigenen Unternehmensgrenzen hinaus, zur Verfügung stellen. Mit Hilfe von EAI und EAI Werkzeugen, die von den unterschiedlichsten Firmen angeboten werden, soll dies vollbracht werden. Diese Werkzeuge bedienen sich einer Vielzahl von Techniken um die geforderte Aufgabe zu lösen. Eine Definition von EAI und EAI-Werkzeugen kann wie folgt lauten [Asen01]:

• Unter EAI ist die prozessorientierte Integration von Anwendungssystemen und Daten in heterogenen IT-Anwendungsarchitekturen zu verstehen.

• EAI-Werkzeuge stellen Methoden und Anwendungen zur automatisierten Programm-zu-Programm-Kommunikation in heterogenen Anwendungsarchitekturen zur Verfügung.

Mit diesen Definitionen zeigt sich, dass die EAI bereits weit vor EAI-Werkzeugen greift. EAI beginnt damit, aus der Sicht der Geschäftsprozesse Integrations- und Standardisierungsanforderungen abzuleiten und endet damit, diese Anforderungen auf den Ebenen der Geschäftsprozesse, der Anwendungssysteme und der zu Grunde liegenden Infrastrukturen umzusetzen. EAI Werkzeuge kommen erst dann ins Spiel, wenn Integration auf Anwendungs- und Infrastrukturebene realisiert werden soll [Asen01]. In dieser Arbeit sollen die Architekturen und Technologien für EAI vorgestellt werden.

1.2 Das Problem In vielen großen Unternehmen haben sich in Laufe von Jahren und Jahrzehnten eine Vielzahl von unterschiedlichen Anwendungen angesammelt, die nicht teilweise nicht dafür geschaffen wurden mit anderen Anwendungen zu kommunizieren. Solche heterogenen Anwendungen sind teilweise gewachsen oder durch Zukauf von anderen Unternehmen oder Zusammenschlüssen entstanden. Die Zusammenarbeit dieser Teilsystemen wird immer wichtiger und kann quasi klassisch mit Schnittstellen zwischen den einzelnen Anwendungen gelöst werden. Es kann in großen Unternehmen aber zu einer sehr enormen Anzahl von Schnittstellen führen, da hier duzende Anwendungen auf unterschiedlichen Plattformen miteinander kommunizieren müssen. Die Programmierung und Wartung von diesen Schnittstellen ist mit erheblichen finanziellen Aufwand verbunden. Grafisch stellt sich das Problem wie folgt dar.

- 4 -

Abbildung 1: Das Problem vieler Schnittstellen [Wra00] Ein anderer Weg um dieser Mischung unterschiedlicher Systeme zu begegnen, ist die Umstellung aller Geschäftsprozesse auf ein Gesamtsystem, das auf einer gemeinsamen Softwarebasis steht. In solchen Systemen wird versucht möglichst viele Geschäftsbereiche mit standardisierten Programmmodulen abzudecken und durch das anpassen dieser Module an die Bedürfnisse des Unternehmens, den Prozess abzudecken. Einer der bekanntesten Anbieter einer solchen betriebswirtschaftliche Gesamtlösung (ERP - Enterprise Resource Planning oder ERM - Enterprise Resource Management) ist SAP. Das Ersetzen einer bestehen IT-Infrastruktur durch eine solche Lösung ist sehr zeitaufwändig und kostenintensiv. Weiters werden hierbei oft vorhandene Geschäftsprozesse auf Prozesse die das neue System vorgibt umgestellt, was auch eine Neuorganisation im Unternehmen nach sich ziehen kann. Es ist auch oft nicht möglich die hochspezialisierten vorhandenen Lösungen durch ERP Programme zu ersetzen.

1.3 Lösung mit EAI Mit EAI wird nun versucht, die Systeme die im Laufen von Jahren und Jahrzehnten in Unternehmen gewachsen und meistens nicht dafür geschaffen wurden zusammenzuarbeiten und einen Teilbereich der Geschäftsprozesse abdecken, sich als ein Gesamtsystem und einheitlicher Geschäftsprozess zu verhalten. Es wird versucht auf verschieden Ebenen eine Integration zu erreichen [BeHoLa01]:

• Prozessintegration • Anwendungsintegration • Daten-/Infrastrukturintegration

- 5 -

• Standardintegration • Plattformintegration

Es werden verschiedene Technologien verwendet [BeHoLa01]:

• CORBA (Common Object Request Broker Architecture) • Java RMI (Java Remote Method Invocation) • DCOM (Distributed Component Object Model) • EDI (Electronic Data Interchange) • XML (Extensible Markup Language) • (UML (Unified Modeling Language))

Der letzte Punkt UML steht in Klammer, da es sicht hierbei nicht um eine Technologie handelt, sondern um standardisierte Beschreibungssprache für die Spezifizierung, die Darstellung, den Aufbau und die Dokumentation von Software. Der Endzustand der erreicht werden soll, lässt sich grafisch darstellen.

Abbildung 2: EAI Infrastruktur [Wra00]

- 6 -

2 Andere Lösungswege Bevor auf EAI näher eingegangen wird, werden die zwei oben genannten traditionellen Lösungswege mit Hilfe von Schnittstellen und ERP beziehungsweise ERM System genauer dargestellt.

2.1 Schnittstellen

2.1.1 Arten Schnittestellen sind Programme die die Kommunikation und den Datenaustausch zwischen unterschiedlichen Anwendungen ermöglichen. Man diese Punkt-zu-Punkt-Schnittstellen bezeichnen. Zu diesem Zweck müssen die auszutauschenden Daten in einem definierten Format vorliegen, um von der Schnittstelle in ein ebenfalls definiertes Format umgewandelt werden zu können. Man kann drei Arten von Schnittstellen mit abfallender Komplexität unterscheiden [LeNe02]:

• Online-Schnittstelle (auf der Abwendungsebene des Integrationsmodells einschließlich Datentransformation)

• Offline-Schnittstelle (Datenaustausch einschließlich Datentransformation im Batch-Verfahren)

• Reine Datenschnittstelle ohne Datentransformation

2.1.2 Probleme Mit steigender Komplexität der Schnittstelle wird die Erstellung und Wartung immer kostenintensiver. Bei hochkomplexen Online-Schnittstellen kann die Erstellung 14.000 Euro betragen, die Betriebsführung mit 15.000 Euro und die Wartung mit 13.000 bis 16.000 Euro zu buche schlagen [LeNe02]. Es kann mit 30 bis 40 Prozent der Ausgaben für Anwendungsentwicklung für die Programmierung und Pflege von Schnittstellen gerechnet werden [SchMä01]. Wesentlich mitverantwortlich für diese Kosten ist die quadratisch ansteigende Anzahl von möglichen Schnittstellen [SchMä01].

2.1.3 Kostenvergleich mit EAI Die Kosten der Schnittstelle ergeben sich aus der Häufigkeit des Datenaustausches, da diese den Aufwand für die Betriebsführung bestimmen. Ein Datenaustausch kann stündlich, täglich, wöchentlich oder ein seltenerer standfinden, wobei vereinfachend gesagt werden kann, dass die eine Halbierung der Administrationskosten zwischen den Intervallen angenommen werden [LeNe02]. Ein Beispiel stellt die Einsparungen für eine neue Schnittstelle und die Investition in einen EAI-Lösung mit Hilfe eine EAI-Werkzeuges gegenüber mit Hilfe der Kapitalwertmethode gegenüber [LeNe02]. Folgende Ausgangsdaten werden herangezogen:

- 7 -

Unternehmen 1 Einsparungen pro Schnittstelle Investition in EAI Einmalig: 6.000 Euro 250.000 Euro Betriebsführung pro Jahr: 6.000 Euro 180.000 Euro Wartung pro Jahr: 8.000 Euro 25.000 Euro Summe pro Jahr: 14.000 Euro 205.000 Euro

Unternehmen 2 Einsparungen pro Schnittstelle Investition in EAI Einmalig: 6.000 Euro 250.000 Euro Betriebsführung pro Jahr: 14.000 Euro 180.000 Euro Wartung pro Jahr: 7.000 Euro 25.000 Euro Summe pro Jahr: 21.000 Euro 205.000 Euro Tabelle 1: Ausgangsdaten für Kostenvergleich [LeNe02] Bei Unternehmen 1 handelt es sich um einen großen deutschen Energieversorgers und bei Unternehmen 2 um ein Transportunternehmen. Die Potentiale für die Einsparungen sind unterschiedlich, da die Unternehmen einerseits externe Dienstleistungen zu ungleichen Preisen zu kaufen und andererseits unterschiedliche innerbetriebliche IT-Strukturen haben, die ungleiche Aufwendungen mit sich bringen. Die genannten Beträge sind gewichtete Durchschnittswerte. Mit den in der obigen Tabelle dargestellten Ausgangswerten wurde eine Investitionsrechnung mit der Kapitalwertmethode aufgestellt. Eine Investition ist dann sinnvoll, wenn der Kapitalwert der Summe der Investitionen und der Einsparungen größer null ist. Für Unternehmen 1 werden 70 und für Unternehmen 2 100 eingesparte Schnittstellen in fünf Jahren angenommen. Nach der nicht naher in [LeNe02] dargestellten Rechnung sollte sich das erste Unternehmen ein positiver Kapitalwert von 1 Mio. Euro und für das zweite Unternehmen ein positiver Kapitalwert von 3,3 Mio. Euro ergeben. Dies könnte nicht nachvollzogen werden. Nach eigenen Berechnungen ergibt sich ein wesentlich höherer Kapitalwert.

Jahr Einsparung Ausgabe EAI Differenz Abzinsfaktor Barwert

0 420.000 250.000 170.000 1,0000 170.000 1 980.000 205.000 775.000 0,9091 704.545 2 980.000 205.000 775.000 0,8264 640.496 3 980.000 205.000 775.000 0,7513 582.269 4 980.000 205.000 775.000 0,6830 529.335 5 980.000 205.000 775.000 0,6209 481.214

3.107.860 Tabelle 2: Unternehmen 1 mit 70 eingesparten Schnittstellen, 10 % Zinsfuss

- 8 -

Jahr Schnittstelle Ausgabe EAI Differenz Abzinsfaktor Barwert 0 600.000 250.000 350.000 1,0000 350.000 1 2.100.000 205.000 1.895.000 0,9091 1.722.727 2 2.100.000 205.000 1.895.000 0,8264 1.566.116 3 2.100.000 205.000 1.895.000 0,7513 1.423.742 4 2.100.000 205.000 1.895.000 0,6830 1.294.310 5 2.100.000 205.000 1.895.000 0,6209 1.176.646 7.533.541

Tabelle 3: Unternehmen 2 mit 100 eingesparte Schnittstellen, 10 % Zinsfuss Nach den in Tabelle 2 und 3 dargestellten Rechnungen ergeben sich für Unternehmen 1 ein Kapitalwert vom 3,1 Mio. Euro und für Unternehmen 2 ein Kapitalwert von 7,5 Mio. Euro. In dem Artikel wird von einer Wirtschaftlichkeit erst ab einer hohen Anzahl von 40 eingesparten Schnittstellen ausgegangen, jedoch die eigene Rechnung hat bei bereit 18 Schnittstellen einen positiven Kapitalwert.

2.2 Betriebswirtschaftliches Gesamtsystem: ERP/ERM

2.2.1 Ansatz ERP oder ERM Systeme versuchen die unterschiedlichen Unternehmensbereiche in Module aufzuteilen und die betriebswirtschaftlichen Daten in einer gemeinsamen Datenbank anzuspeichern. So lassen sich Unternehmensprozesse wie Finanzbuchhaltung, Controlling, Human Resource, Lagerhaltung, Warenwirtschaft usw. gemeinsam verwalten und Daten problemlos zwischen den einzelnen Bereichen austauschen. In aller Regel müssen diese Module noch intensiv an die jeweiligen Bedürfnisse des Unternehmens angepasst werden. Dieser Anpassungsvorgang wird als Customizing bezeichnet. Diese System bieten auch ihre eigene Standardschnittstellen und versuchen so die Kommunikation zu anderen Systemen zu erleichtern [SchMä01]. Viele unterschiedliche Anbieter befinden sich auf diesem Markt, darunter SAP, Navivison, Baan, Poeplesoft, Oracle oder Siebel.

2.2.2 Probleme Dieser Lösungsweg hat mit einigen Problemen zu kämpfen. Die Implementation eines solchen Systems kann sich über eine sehr langen Zeitraum ziehen und oft Jahre dauern und ist mit hohen Kosten und Risken verbunden. Weiters können meist nicht alle Altsysteme abgelöst werden, da diese hochspezialisiert hinsichtlich des Unternehmens oder der Branche sind, sodass es kein Standardmodul gibt oder die Anpassung eines Moduls an die vorhanden Geschäftsprozesse nicht möglich ist [SchMä01]. Aus diesem Grund werden in Unternehmen mitunter Prozesse umgestellt und den Abläufen des Moduls angepasst. Selbst bei Systemen des gleichen Anbieters kann das Zusammenführen von Daten problematisch sein, da diese im Regelfall unterschiedlich konfiguriert sind [SchMä01].

- 9 -

3 Verwendete Technologien

3.1 Middleware

3.1.1 Allgemeines Wie bereits beschrieben besteht die IT Infrastruktur in vielen Unternehmen aus unterschiedlichen Hardware- und Betriebssystemplattformen, unterschiedlichen Datenbanken und File Systemen, unbeweglichen existierenden Anwendungen die mit neuen Anwendungen koordiniert werden müssen und einer Mischung von LAN und WAN Protokollen. In Laufe von Jahrzehnten haben sich die Strukturen von Anwendungen stark verändert und haben sich von monolithischen Anwendungen über Client/Server eben zu den oben beschriebenen heterogenen Anwendungen entwickelt.

Abbildung 3: Entwicklung von Anwendungen mit Middleware In diesen mehrschichtigen Anwendungen wird zur Überwindung der Grenzen zwischen den einzelnen Schichten Software benötigt. Diese Software wird als Middleware bezeichnet. Middleware kann plattformübergreifend sein und greift meistens auf Standards zurück. Es ist eine Infrastruktur für verteilte Anwendungen. Middleware erleichtert die Erstellung von mehrschichtigen Anwendungen, da sich ein Programmierer nicht um die Kommunikation zwischen des einzelnen Komponenten kümmern muss. Diese wird von der Middleware Umgebung erledigt. Ein Ziel ist Entwicklungs- und Administrationskosten zu senken und Datenzugriffe zu vereinfachen. Middleware wird auch als das „/“ zwischen Client und Server bezeichnet. Eine Definition von Middleware lautet [Sch01]:

• Middleware ist Software, die für verteilte Anwendungen zur Überbrückung der Heterogenität unterschiedlicher Systeme und Netze dient.

Die drei am weitverbreitesten Basistechnologien sind CORBA, Java RMI und COM+/DCOM. Auch Transaktionsmonitore und Web Application Server fallen in den Bereich von Middleware.

- 10 -

Abbildung 4: Gesamteinordnung von Middleware [Sch01] Diese Techniken helfen Funktionalitäten einer Software, die sich möglicherweise auf einem anderen Rechner und in einem anderen Netzwerk befindet, von einer anderen Software heraus nutzbar zu machen. Die Einordnung der von Middleware kann auch aus einer anderen Richtung betrachtet werden.

Abbildung 5: Einordnung von Middleware im Zusammenhang mit Client/Server,

Transportschicht und physikalischen Netzwerk [Sch01] In diesen Beispiel macht sich ein Client mit einer Kassenanwendung einen Kontenserver zu nutze. Es erzeugt ein Objekt, dass mit Hilfe von einer Middleware sich die Methoden eines Objekt auf Serverseite zu nutze macht und durch die Transportschichten und das physikalischen Netzwerk geht. Middleware steht die verschiedensten Dienst zur Verfügung:

• Remote Procedure Call (RPC) • Message-Schnittstellen • Peer-to-Peer Schnittstellen • Directory-Dienste • Zeitdienste

- 11 -

• Sicherheit / Authentification • Verschlüsselung • Datensyntaxdienste • Verteilte Dateisysteme (NFS, AFS, DFS) • Groupware • Netzwerkmanagement

3.1.2 Middleware Implementierungen Middleware ist in vielen verschiedenen Formen verfügbar. Das DCE (Distributed Computing Environment) der Open System Foundation stellt einen Versuch dar, Middleware zu standardisieren. Es ist gleichzeitig ein anschauliches Middleware Implementierungsbeispiel. Die wichtigsten Komponenten von DCE sind der DCE RPC, die DCE Directory Services, Kerberos für die Sicherheits- und Authentifizierungsdienste, Datenrepräsentationsdienste sowie die Zeitdienste. Sie werden durch einheitliche Schnittstellen zusammengehalten und integriert. Während DCE bisher nicht sehr erfolgreich war, werden die DCE Komponenten RPC und Kerberos in größerem Umfang eingesetzt. Datenbank Middleware und Transaction Processing (TP) Monitore sind zwei heute relativ weit verbreitete Middleware Produkte. CICS, Tuxedo, die SAP Grundstruktur, sowie Groupware Produkte wie Lotus Notes, Microsoft Exchange und Novell GroupWise sind Beispiele für anwendungsspezifische geschlossene Middleware, Entwicklungsumgebungen gibt es für DCE, CORBA, Enterprise Java Beans (EJB) oder Microsoft DCOM. Web Application Server sind ebenfalls Middlewareprodukte und werden von vielen Firmen angeboten. Beispiele hierfür sind IBM WebSphere, iPlanet von Sun, Application Server von Oracle oder WebLogic von BEA. Groupware wie Lotus Notes oder MS Exchange stellen ebenfalls Middleware dar. E-Business Lösungen wie Supply Chain Management (SCM), Customer Relations Management (CRM), Electronic Commerce oder Data Warehouse sind genau so Middleware wie System Management Anwendungen wie OpenView von Hewlett-Packard, Tivoli von IBM oder TNG von Computer Associates.

3.2 Komponenten Alle größeren und komplexeren Anwendungen bestehen nicht aus einem Stück Software, sondern teilen sich in einzelne Softwarebestandteile auf. Da es nicht sinnvoll und ökonomisch ist, immer wieder einen Softwarebestandteil mit gleichen Funktionen neu zu erstellen, wird versucht wiederverwendbare Software zu entwickeln. Diese wiederverwendbaren Bausteine nennt man Komponenten. Diese Komponenten besitzen eine definierte Schnittstelle mit genau festgelegten Funktionen. Diese Funktionen können eben über diese Schnittstelle benutzt werden. Doch dieser Ansatz greift noch zu kurz in unserem Zusammenhang und entspricht OO (Objekt-Orientierter Programmierung). Mit OO wird versucht mit Hilfe von Vererbung Klassen zu erweitern und so wieder verwendbar zu machen. In einem weiteren Schritt wird nun versucht eine Komponente so zu gestalten, dass diese auch die Geschäftlogik enthält. So werden die OO Prinzipien erweitert. Eine Komponente muss auch Middleware Standards unterstützen, um in eine heterogene Umgebung eingebunden werden zu können.

- 12 -

COTS (Commercial Off The Shelf) sind kommerzielle Softwarekomponenten. Diese können in sehr unterschiedlicher Form in Erscheinung treten. Sie können auf unterschiedlichen Abstraktionsebenen und Granularitätsstufen angesiedelt sein. So können COTS als einfache programmiersprachen- und plattformspezifische Komponenten vorhanden sein, als auch als sehr komplexe grobgranulare Anwendungen, die ihrerseits wieder aus Komponenten bestehen können. COTS kapseln verschiedene Dienste und ermöglichen es, nicht immer von neuem Komponenten zu erstellen, auf die man sonst keinen Zugriff hätte. COTS werden von Firmen oder Open Source Gemeinschaften weiterentwickelt und gepflegt und erreichen so ein im Idealfall ein hohe Maß an Zuverlässigkeit und Flexibilität. COTS kann auch als Middleware auftreten und ein Framework enthalten. Beispiele hierfür sind CORBA oder J2EE (Java 2 Enterprise Edition). Es ist mit COTS möglich, schneller zuverlässige Anwendungen zu erstellen.

3.3 CORBA

3.3.1 Allgemeines Die Abkürzung CORBA steht Common Object Request Broker Architecture und ist ein Standard der von OMG (Object Management Group) herausgegeben wird. CORBA hat im Jahre 1991 mit der Version 1.0 gestartet, 1994/95 das Protokoll IIOP mit der Version 2.0 hinzugekommen. Der aktuelle Stand von CORBA wird als CORBA 3 bezeichnet und steht seit Ende 2002 zu Verfügung. CORBA 3 besteht aber nicht nur aus einer Spezifikation sondern aus zehn und umfasst eine Katalog von CORBA und IIOP Standards, wie beispielsweise Common Object Request Broker Architecture (CORBA/IIOP Version 3.0.2), CORBA Component Model (Version 3.0) oder Common Secure Interoperability (Version 3.0.1) [OMG03]. CORBA Component Model wurde neu eingeführt und startet mit der Version 3.0, obwohl keine Vorgängerversion vorhanden ist.

3.3.2 Funktionsweise CORBA dient dazu Methodenfernaufrufe zwischen Objekten durchzuführen. Wesentlichen Merkmale von CORBA sind die Ortsunabhängigkeit, die Plattformenabhängigkeit und die Sprachabhängigkeit, die für die Implementation verwendet wird. Über IDL (Interface Definition Language) kann mit Hilfe von vielen verschiedenen Programmiersprachen CORBA genutzt werden. Es ist so möglich beispielsweise mit C, C++, Java, ADA, LISP, COBOL, IDLscript, Python oder Smalltalk sich CORBA nutzbar zu machen. IDL ist eine implementationsunabhängige Beschreibungssprache, die Schnittstellen definiert und selbst daher keine Anweisung enthält. Diese Trennung von Schnittstelle und Implementation ist ein Grundbaustein für die Interoperabilität und Transparenz von CORBA Das Basiselement für die Kommunikation innerhalb von CORBA ist ORB (Object Request Broker). ORB stellt die Kommunikationsdienste zur Verfügung und kann als zentrales Organ angesehen werden. ORB verwaltet die Methodenaufrufe vom Client hin zum Server und wieder zurück zum Client. Jedes Serverobjekt stellt bestimmte Methoden zur Verfügung Es werden hierfür Schnittstellen zur Verfügung gestellt, die im nachfolgendem Diagramm dargestellt werden. Die in der Grafik dargestellten Stub und Skeleton werden in der eigenen Programmiersprache geschrieben und mit Hilfe eines IDL-Compiler kompiliert. Dabei können der Stub und

- 13 -

Skeleton eben auf Grund der reinen Schnittstellenbeschreibungseigenschaft von IDL in unterschiedlichen Sprachen geschrieben und kompiliert sein.

Abbildung 6: Architektur des ORB (in Anlehnung an [OMG03ORB]) Ein Aufruf von Client an einen Server kann statisch oder dynamisch erfolgen. Statische Aufrufe werden vom Client über den Stub an ORB weitergeleitet. Der Stub stellt die Parameter zusammen und verpackt diese zum Weiterleiten an ORB. Somit ist der Stub Verbindungsstück zwischen dem Client und ORB. Das statische Gegenstück auf der Serverseite ist der Skeleton. Er interpretiert die Parameter und reicht sie weiter an den Server. Stub und Skeleton dienen sozusagen als Proxy für den Client und den Server. Dynamische Aufrufe unterscheiden sich von den statischen Aufrufen dadurch, dass diese erst zur Laufzeit interpretiert werden und nicht kompiliert sind. Dieser Unterscheid kann auch verglichen werden mit dem Unterschied zwischen Skripten und Programmen, wobei die Skripte auch erst zur Laufzeit interpretiert werden. Dynamische Aufrufe werden vom DII (Dynamic Invocation Interface) auf der Clientseite an ORB weitergeleitet. Dieser wird erst zur Laufzeit generiert und bietet nur eine Schnittstelle, die sehr komplex ist. Auch hier gibt es eine dynamisches Gegenstück auf der Serverseite, den DSI (Dynamic Skeleton Interface). Dieser interpretiert wie der statische Skeleton die übergebenen Parameter und leitet sie vom serverseitigen ORB an das Serverobjekt weiter. Der Objektadapter gibt die vom Server beantworteten statischen und auch die dynamischen Methodenaufrufe wieder zurück an ORB. Den Objektadapter gibt es entweder als BOA (Basic Object Adapter) oder als POA (Portable Object Adapter). Weiters gibt es die Möglichkeit, das ORB ohne Zwischenschicht mit den Client respektive dem Server direkt kommunizieren können. Zur Kommunikation zwischen den client- und serverseitigen ORB wird GIOP (General Inter-ORB Protokoll) verwendet. Diese Protokoll wird verwendet, wenn ORB-Grenzen überschritten werden und es wird von verschiedenen Anbieter zur Verfügung gestellt. Speziell für die Kommunikation zwischen ORB über das Internet gibt es das IIOP (Internet Inter-ORB Protokoll), das spezifiziert, wie GIOP-Nachrichten ausgetauscht werden. CORBA bietet auch Mechanismen die die Skalierbarkeit und Fehlertoleranzen einer Anwendung möglichen. Es ist Load Balancing enthalten und auch eine Fehlertoleranz basierend auf einer standardisierten Infrastruktur mit Entität Redundanz auf Objekt Level.

3.3.3 Umsetzungen CORBA ist eine reine Spezifikation und kann daher auf jeder beliebigen Plattform umgesetzt werden, dass heißt, es ist grundsätzlich allen Betriebssystemen und Hardwareplattformen, wie einem Handheld, Mainframe oder UNIX-System, eine Implementation möglich. Anbieter von

- 14 -

Umsetzungen auf diversen Plattformen sind Inprise mit VisiBrocker für Windows, Mainframe und UNIX oder Iona mit Orbix.

3.4 Java RMI

3.4.1 Allgemein Java RMI steht für Java Remote Method Invocation und ist wie nicht wie CORBA aus mehreren Programmiersprachen heraus nutzbar, sondern auf Java beschränkt. Es wurde mit dem JDK 1.1 (Java Developer Kit) eingeführt und ermöglicht es, verteilte Objekte zu nutzen. Im JDK 2 wurden die Möglichkeiten nochmals erweitert [SUN03]. Die Einschränkung auf Java als Programmiersprache bedeutet, dass sowohl clientseitig als auch serverseitig die Objekte als Java Programmierung vorliegen müssen. Dies liegt zum größten Teil daran, dass Java RMI sich die Serialization, die von Java geboten wird, zu eigen macht. Die Serialization ermöglicht es einem Java Objekt als Stream verschickt zu werden. Dieser Vorgang wird auch als Marshaling bezeichnet. Java RMI verwendet das Java Remote Method Protocol (JRMP), dass ein proprietäres Protokoll ist und nur teilweise spezifiziert wurde. Es ist in zwei Versionen vorhanden. Die erste Version stammt aus dem JDK 1.1 und benötigt eine Skeleton Klasse auf dem Server und die zweite Version kam mit den JDK 2 und benötigt keine Skeleton Klasse aus der Serverseite [SUN03]. Damit die Java Programme ablaufen können, benötigen diese auf der Client- und Serverseite die Java Virtual Machine (JVM). Durch diesen Umstand kann Java RMI, wie Java Programme im allgemeinen, auf allen Plattformen verwendet werden, auf denen eine JVM vorhanden ist. Es gibt JVM für verschiedenste Betriebssysteme, wie Windows, UNIX, Mainframes oder Handhelds.

3.4.2 Funktionsweise Die Architektur von Java RMI besteht aus drei abstrakten Schichten.

• Stub und Skeleton Schicht • Remote Reference Schicht • Transportschicht

Abbildung 7: Schichten von Java RMI [SUN03] Die erste Schicht fängt die Aufrufe des Client an die Schnittstelle ab und leitet sie weiter an den fernaufgerufenen RMI Dienst. Hier findet man wie bei CORBA einen Stub und Skeleton, die als Proxy fungieren. Die Remote Reference Schicht weiß wie der Aufruf zu interpretieren

- 15 -

ist und verwaltet Referenzen vom Client an das Server Objekt. Im JDK 1.1 ist es eine Eins-zu-Eins-Verbindung (Unicast) und verbindet den Client zu einem laufenden und exportierten Server Objekt. Im JDK 2 ist es auch möglich einen ruhendes Objekt mittels Remote Object Activation für einen Fernausruf zu nutzen. Die Transportschicht basiert auf TCP/IP Verbindungen zwischen Computer im Netzwerk und stellt Basisverbindungen her. Wie in den meisten Schichtmodellen kann durch diese Architektur eine Schicht ausgetauscht oder weiterentwickelt werden, ohne die anderen Schichten zu beeinflussen. Damit ein Client ein Serverobjekt finden kann, verwendet RMI einen Namen- oder Verzeichnisdienst. Es stehen verschieden Namens- oder Verzeichnisdienste zur Verfügung. In RMI beinhaltet ist ein einfacher Dienst namens RMI Registry. Es kann auch Java Naming and Directory Interface (JNDI) verwendet werden. Dieser Dienst muss im Netzwerk auf einem bekannten Rechner und Port befinden. Bei RMI Registry ist das standardmäßig der Port 1099. Auf dem Rechner erzeugt ein Serverprogramm einen Remote Dienst, in dem es zuerst ein lokales Objekt erzeugt, dass den Dienst zur Verfügung stellt. Anschließend wird dieses Objekt an RMI exportiert und RMI erzeugt eine Listing-Dienst der auf Aufrufe vom Client wartet. Der Server registriert das Objekt unter einem öffentlichen Namen in der RMI Registry nach dem Export. Der Client kann nun mit einer Methode, die eine Klasse bereit hält, die Registry abfragen und eine Aufrufreferenz zum Server Objekt erhalten.

3.5 DCOM

3.5.1 Allgemeines DCOM ist die Abkürzung für Distributed Component Object Model und ist eine Erweiterung von COM (Component Object Model) der Firma Microsoft. Es unterstützt, wie die zwei oben beschriebenen Techniken auch, die Kommunikation von entfernten Objekten im LAN, WAN oder Internet [MS03]. Das Protokoll, das die Verbindung zwischen den Objekten herstellt, heißt Object Remote Procedure Call (ORPC). ORPC baut auf dem DCE RPC auf und interagiert mit COM Laufzeitdiensten. Wie bereits für COM spezifiziert ist es möglich DCOM Server Komponenten in diversen Programmiersprachen zu schreiben. Dazu zählen C++, Java, Delphi, VisualBasic oder COBOL. Auch mehrer Betriebssystemplattformen sind möglich, solange diese COM Dienste unterstützen. Microsoft hat alle Windows für COM ausgerüstet sowie Solaris und es sind Implementationen für UNIX, Linux und Mainframe der Firma Software AG mit EntireX und von der Firma Digital für Open VMS vorhanden.

3.5.2 Funktionsweise Ein DCOM Server ist in der Lage einen bestimmten Typ von Objekt seinen Dienst zur Laufzeit anzubieten. Jeder DCOM Server kann mehrere Schnittstellen mit unterschiedlichen Verhalten unterstützen. Damit ein DCOM Client eine Methode des DCOM Server aufrufen kann, eignet sich der Client einen Zeiger auf eine der Schnittstellen des Server an. Dann kann der Client beginnen, die zur Verfügung stehenden Methoden durch diesen Zeigen aufzurufen, als ob die auf dem Server vorhanden Methoden im Clientadressraum verfügbar wären.

- 16 -

3.6 Vergleich CORBA, Java RMI und DCOM In allen drei Technologien ist es möglich eine komplette Programmierung mit Java durchzuführen, jedoch würde es den Rahmen dieser Arbeit sprengen dies zu zeigen. Es sei auf [Go03] verwiesen. Stattdessen seien die Vor- und Nachteile der einzelnen Techniken in Überblick beschrieben. CORBA Java RMI DCOM Sprachunterstützung Beliebig (v.a. C++,

Java, COBOL) Nur Java Viele(Java, C++,

VB) Betriebssysteme Alle wesentlichen Alle wesentlichen Primär Windows Legacy Unterstützung Transaction und

COBOL-Binding Viele Produkte (zB WAS)

Spezielle Produkte (zB EntireX)

Oberflächenentwicklung Mit Java/WWW möglich

Mit Java/WWW möglich

VB: Sehr einfach

Angebotene Service Sehr zahlreich; praktisch verfügbar: Kerndienste

Nutzung von CORBA wesentlich

Kerndienste

Preis Mittlerer Bereich Frei verfügbar; CORAB i.d.R. zusätzlich nötig

Relativ gering

Geeignet für komplexe Anwendungen

Ja In Verbindung mit CORBA

Bedingt; primär in Microsoft Umgebungen

Tabelle 4: Vergleich CORBA, Java RMI und DCOM [Sch01] Aus dem Vergleich wird deutlich, dass die einzelnen Techniken auf die konkrete Anwendung abgestimmt werden müssen und sich pauschal keine als ungeeignet bezeichnen lässt.

3.7 Web Services und .NET Framework

3.7.1 Allgemeines Zusätzlich zu den oben beschriebenen Techniken bieten Web Services eine neue Möglichkeit Dienste entfernter Anwendungen über das Internet oder Intranet zu nützen. Das W3C (WWW Consortium) definiert einen Web Service folgendermaßen [W3C03WS]:

• Ein Web Service ist ein Softwaresystem identifiziert durch einen URI (Uniform Resource Identifiers), dass XML benutzt um öffentliche Schnittstellen und Bindungen zu definieren und zu beschreiben. Diese Definitionen können von einem anderen Softwaresystem aus gelesen werden um dann mit dem Web Service nach der Definition zu interagieren, unter der Verwendung von XML basierten Nachrichten, die mit Internetprotokollen versandet werden.

Web Services verwenden HTTP (Hypertext Transfer Protocol) und XML (Extensible Markup Language) um über SOAP Nachrichten (Simple Object Access Protocol) zu senden und empfangen. Im Gegensatz zu CORBA oder COM wurden Web Services ausdrücklich für die

- 17 -

Nutzung über das Internet entwickelt und benützt offene vom W3C definierte Standards wie HTTP, XML, SOAP, UDDI (Universal Description Discovery and Integration) und WSDL (Web Service Definition Language). Die Firmen Sun und Microsoft bieten Umgebungen an um Web Services zu erstellen. Sun als Teil von J2EE und Microsoft im Rahmen von .NET. Hier soll nur .NET näher betrachtet werden. Web Services sind Teil des .NET Framework. Das .NET Framework stellt eine Umgebung zur Verfügung, um webgestützte Anwendungen zu entwickeln und verteilen. .NET kann von verschieden Programmiersprachen aus genutzt werden, wie C, C++, VB.Net und vor allem von C# (gesprochen C Sharp). C# dient als neue an C++ angelehnte objektorientierte Programmiersprache und hat im Sinne Microsoft eine strategische Bedeutung.

3.7.2 Funktionsweise Der Aufbau einer .NET Anwendung, und Web Services sind eine solche, sieht wie folgt aus:

Abbildung 8: Aufbau einer .NET Anwendung [MS03NET] Eine mit beispielsweise mit VB wird nicht mehr in Maschinencode kompiliert (obwohl das auch noch möglich wäre), sondern einen Zwischencode (MSIL – Microsoft Intermediate Language). MSIL ist offen gelegt und dokumentiert und daher kann auch jeder Compiler einen solchen Code erzeugen. MSIL wird auch als Managed Code bezeichnet und wird erst im zur Laufzeit vom JIT (Just in Time Compiler) in nativen Code umgewandelt und in der CLR (Common Langauge Runtime) ausgeführt. Ein Web Service registriert sich bei einem UDDI Dienst, der als Verzeichnis für die angebotenen Web Services dient. Ein Client der nun diesen Service nutzen will, fragt in dem Verzeichnis nach, wo sich der Web Service befindet und kann dann so eine Verbindung direkt zu ihm herstellen. Die Anfrage der Client kann eine auf XML basierende SOAP Nachricht sein, die einen Link zum UDDI-Dienst und den Namen des Web Service enthält. Der UDDI-Dienst antwortet auf diese Anfrage mit einer Liste der verfügbaren Web Services.

- 18 -

4 EAI-Tools

4.1 Marktaussichten EAI-Tools machen sich die beschriebenen Techniken zu nutze und versuchen die Integration von Legacy Anwendungen. Es befinden sich viele Anbieter dieser Werkzeuge auf dem Markt. Der Markt für Anwendungsintegration entwickelt sich äußerst schnell und wird 2003 als größtes und am schnellsten wachsendes Segment bei der Nachfrage von Dienstleistungen durch Unternehmen eingeschätzt [BeHoLa01]. Es wird 2002 mit einem Volumen von 18 Mrd. US-Doller gerechnet. Eine weitere Studie rechnet mit einem jährlichen Wachstum von 30 % ausgehend von 5 Mrd. US-Dollar im Jahr 2000 auf 30 Mrd. im Jahr 2005 [Asen01]

4.2 Anbieter Die Liste der Anbieter ist lang und daher seien hier nur einige exemplarisch genannt. Einige der Firmen sind BEA Systems, Compuware, Fujitsu Siemens Computers, Hewlett-Packard, i7 Buisness Solutions, IBM, Iona, Microsoft, Oracle, SAP, SeeBeyond, Seeburger AG, Software AG, SUN, TIBCO oder webMethods. In dieser Aufzählung sind einige Big Player wie Microsoft oder IBM, aber auch eine Reihe Nischenfirmen, die spezialisiert auf EAI-Lösung sind. Die meisten Unternehmen bieten verschiedenen Produkte für die Integration an.

4.3 Kosten Die Kosten lassen sich in mehrere Bereiche aufteilen. Neben den Lizenzkosten, die oft erheblich sind und je nach Lizenzierungsmodell des Herstellers in verschiedenen Anwendungsfällen unterschiedlich hoch ausfallen können, sind die Investitionen für Hardware und Infrastruktur in die Rechnung mit einzubeziehen. Schulungskosten für die Implementierung und den Betrieb des Systems können ebenso entstehen wie Kosten durch die Beratungs- und Implementierungsunterstützung, die notwendig sein wird, da Projekte dieser Größenordung nicht aus den personellen Ressourcen im Unternehmen gedeckt werden können. Es kann auch bei den Integrationskonzepten notwendig sein, Geschäftsprozesse zu ändern, um die EAI-Potenziale wirklich ausschöpfen zu können. Der Umfang der notwendigen externen Beratung für die EAI-Konzeption ist ein Kostenfaktor, der aber für die Ausnutzung der EAI-Potenziale entscheidend ist. Somit lassen sich in Summe die Kosten nicht pauschal nennen, sondern hängen sehr stark vom Einzelfall ab [Asen01].

- 19 -

5 Zusammenfassung Zusammenfassend lässt sich sagen, dass der Bereich EAI und die damit in Zusammenhang stehenden Technologien ein Feld sind, die in der Gegenwart und nahen Zukunft vieler Unternehmen eine bedeutende Rolle spielen wird. Die Techniken entwickeln sich beständig weiter und die prognostizierten Marktaussichten, machen es für Anbieter von EAI-Tools interessant diese noch weiter voranzutreiben. Ein vorhergesagtes Marktvolumen von 25 bis 30 Mrd. US-Dollar für 2003 macht es für viele Anbieter interessant einzusteigen. Grosse Unternehmen wie Microsoft sind erst vor kurzen in diesem Bereich mit eigenen Lösungsansätzen tätig geworden. Ein Blick in Verzeichnisse für Anbieter und die aktuellen Artikel haben gezeigt, dass der Markt in einem gewissen Maß unübersichtlich ist. Es ist für Unternehmen die Lösungen suchen, nicht einfach diese auch zu finden. Alle Anbieter versprechen eine Lösung der Probleme mit ihren jeweiligen Techniken, die einmal das Heil in offnen mal in proprietären Ansätzen suchen. Unternehmen stellt dies vor eine große Herausforderung. Die richtige Lösung zu finden ist für die meisten Betriebe mit ihren internen Ressourcen nicht bewältigbar. Sie sind auf kompetente externe Beratung angewiesen. Es kann nicht gesagt werden, ob kleine wendigere Anbieter, die auf diesen Nischenmarkt spezialisiert sind, besser geeignet sind, in Unternehmen eine EAI-Lösung zu implementieren, als große Anbieter, wie IBM, die Kontinuität und jahrzehntelange Erfahrung in allen möglichen IT-Bereichen haben. Die Techniken um die Herausforderungen zu bewältigen sind vorhanden und der Integrationsdruck steigt beständig, da nicht nur innerbetrieblich der Informationsfluss komplexer wird, sondern auch Externe, wie Kunden, Lieferanten und andere Stakeholder, in diesen Informationsfluss eingebunden werden wollen oder müssen. Abschließend kann mit Sicherheit gesagt werden, dass dieses Thema an Bedeutung zunehmen wird und eine durchdachte und flexible Integration von Anwendungen als Erfolgsfaktor von keinem größeren Unternehmen außer Acht gelassen werden darf.

- 20 -

Literatur Bücher: [BuChPa01] Buhl, Lothar; Christ, Jörg; Pape, Ulrich: Softwaresysteme für Enterprise

Application Integration. Bang 7, ALB-HNI-Verlagsschriftenreihe, 2001. [Cu02] Cummins, Fred: Enterprise Integration: an Architecture for Enterprise Application

and Systems Integration, John Wiley & Sons Inc, 2002. [Ke02] Keller, Wolfgang: Enterprise Application Integration, Erfahrungen aus der Praxis,

dpunkt.verlag, Heidelberg, Juni 2002. [Li01] Linthicum, David: B2B Application Integration, Addison-Wesley, 2001. [MePo02] Meinhardt, Stefan (Herausgeber); Popp, Karl (Herausgeber): Enterprise Portale &

Enterprise Application Integration, HMD Praxis der Wirtschaftsinformatik, Heft 225, dpunkt.verlag, Heidelberg, Juni 2002.

[JuNaLe01] Juric, Matjaz; Nagappan, Ramesh; Leander, Rick S.; Basha, Jeelani;: Professional J2EE EAI, Wrox, 2001.

[RuMa01] Ruh, William A.; Maginnis, Francis X.; Brown, William J.: Enterprise Application Integration, Wiley 2001.

[ShStNg01] Sharma, Rahul; Stearns, Beth; Ng, Tony; Dietzen, Scott: J2EE Connector Architecture and Enterprise Application Integration, Addison Wesley, 2001.

[Za99] Zahavi, Ron: Enterprise Application Integration with CORBA Component and Web-Based Solutions, John Wiley & Sons, 1999.

Artikel: [Asen01] Asendorf, Sebastian: Der richtige Griff in den Werkzeugkasten, Diebold

Management Report 03/2001. [BeHoLa01] Bernotat, Jens; Hoch, Detlev J.; Laartz, Jürgen: EAI-Elementarer Treiber der

zukünftigen Wettbewerbsposition, Information Management & Consulting 16/2001. [Ki00] King, Nelseon: Vertikal EAI, Computer User, 08/2000. [LeNe02] Lehr, Mathias; Nelius, Ralph : Wann sich eine EAI-Lösung rechnet,

Computerwoche 39/2002. [Lu00] Lutz, Jeffrey C.: EAI Architecture Patterns, EAI-Journal 03/2000. [MH00] McHugh, Neil: A Quick Guide to Integrating the Mainframe, EAI- Journal 12/2000. [Ni02] Nießen, Christian: Die Qual der Wahl oder der Weg zum passenden EAI-Framework,

uptec AG, 09/2002. [PoMa02] Pohl, Michael; Mattern, Olaf: EAI: Mehr als nur eine Worthülse, Business 4

Enterprise, 02/2002. [SchMä01] Schott, Karsten; Mäurer, Rolf: Auswirkungen von EAI auf die IT-Architektur in

Unternehmen, Information Management & Consulting 16 (2001). [St01] Stiehl, Voker: Architekturen moderner Middleware-Lösungen im EAI-Umfeld,

Siemens Business Services, 18.1.2001. [VaRo01] Vawter, Chad; Roman, E: J2EE vs. Microsoft.NET: A comparison of building

XML-based web services, ITtoolbox EAI für Sun Mircosystems 06/2001.[Wa01] Walter, Jochen: Anwendungsintegration durch Integrationsanwendungen, DMR -

Detecon International, 01/2001.[Sch01] Schill, Alexander: Middleware im Vergleich, Referat unter http://www.rn.inf.tu-

dresden.de, 2001. [Wra00] Wrazen, Ed: Referat auf dem CSSA EAI Forum am 4.2.2000.

- 21 -

Internet: [Go03] Stand 17.1.2003: A Detailed Comparison of CORBA, DCOM and Java/RMI:

http://my.execpc.com/~gopalan/misc/compare.html [MS03] Stand 18.1.2003: DCOM Technical Overview: http://www.microsoft.com/technet/

treeview/default.asp?url=/TechNet/prodtechnol/winntas/plan/dcomtowp.asp?frame=true [MS03NET] Stand 26.1.2003: Product Overview .NET: http://msdn.microsoft.com/

netframework/productinfo/overview/default.asp [OMG03] Stand 17.1.2003: Spezifikationen für CORBA 3: http://www.omg.org/technology/

documents/corba_spec_catalog.htm [OMG03ORB] Stand 20.1.2003: ORB Basics: http://www.omg.org/gettingstarted/

orb_basics.htm [SUN03] Stand 18.1.2003: Fundamentals of RMI Short Course:

http://developer.java.sun.com/developer/onlineTraining/rmi/RMI.html [W3C03WS] Stand 26.1.2003: Web Services Architecture: http://www.w3.org/TR/ws-arch Abbildungsverzeichnis Abbildung 1: Das Problem vieler Schnittstellen [Wra00]...................................................... 4 Abbildung 2: EAI Infrastruktur [Wra00]............................................................................... 5 Abbildung 3: Entwicklung von Anwendungen mit Middleware ............................................ 9 Abbildung 4: Gesamteinordnung von Middleware [Sch01]................................................. 10 Abbildung 5: Einordnung von Middleware im Zusammenhang mit Client/Server,

Transportschicht und physikalischen Netzwerk [Sch01] ................................ 10 Abbildung 6: Architektur des ORB (in Anlehnung an [OMG03ORB]) ............................... 13 Abbildung 7: Schichten von Java RMI [SUN03] ................................................................ 14 Abbildung 8: Aufbau einer .NET Anwendung [MS03NET]................................................ 17