Danksagung

Ich möchte mich an dieser Stelle bei allen bedanken, die mir bei der Entstehung der vorliegenden Diplomarbeit hilfreich zur Seite gestanden haben.

Ich danke Herrn Prof. Dr. Holger Hinrichs für die fachliche Unterstützung sowie die Möglichkeit diese Arbeit unter seiner Betreuung anzufertigen. Besonderer Dank geht an die Kollegen der gedas Deutschland GmbH in Berlin. Herrn Henry Sirotenko möchte ich für die vielen guten Anregungen sowie die Betreuung dieser Arbeit als Zweitbetreuer danken. Herrn Andreas Lahrius und Herrn Jens Kersten gilt mein Dank für die zahlreichen Tipps und Hinweise die massgeblich zum Erfolg dieser Arbeit beigetragen haben.

Darüber hinaus möchte ich mich bei meinen Eltern für die Unterstützung während des gesamten Studiums ganz herzlich bedanken.

Inhaltsverzeichnis

1  Einleitung  1

2  Enterprise Application Integration  3

2.1  Definition und Motivation von EAI  3

2.2  Aufbau von EAI-Anwendungen  5

2.3  EAI auf Basis von XML  7

3  Komponentenbasierte Softwareentwicklung  9

3.1  Notwendigkeit für komponentenbasierte Software  9

3.2  Strukturierung von Systemen  11

4  Technologien zur komponentenbasierten Softwareentwicklung  15

4.1  Enterprise JavaBeans  15

4.1.1  Einführung in Enterprise JavaBeans  15

4.1.2  Architektur und Funktionsweise von Enterprise JavaBeans  16

4.1.3  Bestandteile einer Enterprise-Bean  19

4.1.4  Arten von Enterprise JavaBeans  21

4.1.4.1  Session Beans  21

4.1.4.1.1  Grundlagen von Session Beans  21

4.1.4.1.2  Aufbau einer Stateful Session Bean am Bei-  

spiel  eines Währungsumrechnungstools  22

4.1.4.2  Entity Beans  26

4.1.4.2.1  Grundlagen von Entity Beans  26

ii INHALTSVERZEICHNIS

4.2 CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.2.1 Einführung in CORBA . . . . . . . . . . . . . . . . . . . . . . . 35 4.2.2 Funktionsweise von CORBA . . . . . . . . . . . . . . . . . . . . 37 4.2.3 OMG-Interface Definition Language . . . . . . . . . . . . . . . . 38 4.2.4 CORBA Beispielanwendung . . . . . . . . . . . . . . . . . . . . 40 4.3 WebServices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 4.3.1 Einführung in Web Services . . . . . . . . . . . . . . . . . . . . 42 4.3.2 Architektur und Funktionsweise von Web Services . . . . . . . . 43 4.4 (Distributed)COM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.5 Bewertung und Auswahl einer Technologie für die Serverkomponenten . 49

5 Anforderungen an einen Prototypen für XML-basiertes EAI 55

5.1 Beschreibung des Vorgehensmodells . . . . . . . . . . . . . . . . . . . . 55 5.2 Zielstellung und Rahmenbedingungen . . . . . . . . . . . . . . . . . . . 56 5.2.1 Ausgangsituation . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.2.2 Verwendete Tools und Programme . . . . . . . . . . . . . . . . . 57 5.2.3 Zielstellung der Implementierung . . . . . . . . . . . . . . . . . 58

INHALTSVERZEICHNIS iii

6  Entwurf des Prototypen  61

6.1  Grundlegende Architektur der Anwendung  61

6.2  Übersicht der Funktionalitäten  64

6.3  Entwurf der Klassenhierarchie  68

6.4  Modellierung der Datenbankstruktur  70

7  Darstellung ausgewählter Implementierungsaspekte  75

7.1  Komponentenübergreifende Realisierungsaspekte  75

7.1.1  Das Connection-Object als Bindeglied zwischen Datenbank und  

Komponenten   75

7.1.2  Verwaltung fortlaufender Primärschlüsselwerte  76

7.1.3  Kommunikation zwischen JSP und Servlets  78

7.2  Implementierung der User-, Anwendungs- und Rechteverwaltung  80

7.3  Die Anwendung zum Erstellen von Stylesheets  84

7.4  Die Durchführung von Transformationen  89

7.5  Einführung und Test sowie Ergebnisse  95

8  Zusammenfassung und Ausblick  97

Anhang 99   

Abk  ürzungsverzeichnis  111

Selbstst  ändigkeiterklärung  113

Literaturverzeichnis   115

iv INHALTSVERZEICHNIS

Abbildungsverzeichnis

2.1 Integration von Unternehmensanwendungen mittels Point-to-Point Schnittstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Integration von Unternehmensanwendungen mittels Middleware . . . . . 4

2.3 Zusammenhang zwischen Nutzen und Änderungsaufwand in Abhängigkeit der verschiedenen Integrationsebenen [RWD99] . . . . . . . . . . . 6

3.1 Abhängigkeit zwischen der Granularität von Komponenten und deren Nutzen sowie Wiederverwendbarkeit . . . . . . . . . . . . . . . . . . . . 10 3.2 Unterschiedliche Ausprägungen von Mehrebenenarchitekturen . . . . . . 12

4.1 Verwendung der Three-Tier-Architektur mit EJB [DP02] . . . . . . . . . 16 4.2 Übersicht über die EJB-Architektur [GT00] . . . . . . . . . . . . . . . . 17 4.3 Übersicht über die Hierarchie der Enterpirse JavaBeans . . . . . . . . . . 21 4.4 Vergleich Stateless- und Stateful Session Beans . . . . . . . . . . . . . . 22 4.5 Architektur einer Session Bean [DP02] . . . . . . . . . . . . . . . . . . . 23 4.6 Architektur einer Entity-Bean [DP02] . . . . . . . . . . . . . . . . . . . 26 4.7 Architektur einer Message-Driven-Bean [DP02] . . . . . . . . . . . . . . 33 4.8 Object Management Architecture der OMG [GT00] . . . . . . . . . . . . 36 4.9 Verwendung der entstandenen Java-Klassen . . . . . . . . . . . . . . . . 41 4.10 Architektur von Web Services [Win01] . . . . . . . . . . . . . . . . . . . 44 4.11 Funktionsweise des UDDI Dienstes . . . . . . . . . . . . . . . . . . . . 47 4.12 Beispielhafter Ablauf eines SOAP-Aufrufs . . . . . . . . . . . . . . . . . 48 4.13 Kriterien zur Bewertung der vorgestellten Technologien . . . . . . . . . . 50

vi ABBILDUNGSVERZEICHNIS

4.14 Bewertung der Technologien . . . . . . . . . . . . . . . . . . . . . . . . 54

5.1 Angestrebter Transformationsprozess . . . . . . . . . . . . . . . . . . . 59

6.1 Prozess der Userinteraktion . . . . . . . . . . . . . . . . . . . . . . . . . 62 6.2 Übersicht über die Architektur der zu entwickelnden Anwendung . . . . . 63 6.3 Übersicht der Use-Cases des Admintools . . . . . . . . . . . . . . . . . . 65 6.4 Übersicht der Use-Cases zum Erstellen und Verwalten von Stylesheets . . 67 6.5 Übersicht der Use-Cases zum Durchführen von Transformationen . . . . 67 6.6 Klassendiagramm der Administrationsanwendung . . . . . . . . . . . . . 69 6.7 Benötigte Klassen zur Durchführung sämtlicher Transformationen . . . . 72 6.8 Beschreibung der wichtigsten Methoden . . . . . . . . . . . . . . . . . . 73 6.9 Klassendiagramm der zu erstellenden Anwendung . . . . . . . . . . . . . 74

7.1 Startseite im Portal nach User-Anmeldung . . . . . . . . . . . . . . . . . 82 7.2 Ausgangspunkt für alle administrativen Tätigkeiten . . . . . . . . . . . . 83 7.3 Fieldmapping zum Erzeugen von XSLT-Dokumenten . . . . . . . . . . . 85 7.4 Eingelesenes XML-Dokument dient als Ausgangspunkt zur Erstellung von Stylesheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Kapitel 1

Einleitung

Seit einigen Jahren gewinnt der Begriff der komponentenbasierten Softwareentwicklung in der IT-Branche ¹ mehr und mehr an Bedeutung. Der Ansatz, Software in Form einzelner, wiederverwendbarer Komponenten zu entwickeln, verspricht gegenüber traditioneller prozeduraler Softwareentwicklung zahlreiche Vorteile. Der wichtigste ist wohl die Möglichkeit, einmal entwickelte Softwarebausteine in verschiedenen Projekten verwenden zu können. Damit verbunden ist das Streben nach einer Reduzierung des gesamten Entwick-lungsaufwandes sowie der Kosten.

Eines der vielversprechensten Anwendungsgebiete für komponentenbasierte Software ist die Entwicklung von Anwendungen zur Integration von Unternehmensanwendungen (engl. Enterprise Application Integration, EAI ² ). Die Zusammenarbeit zwischen den verschiedenen Unternehmensanwendungen wird für Unternehmen, die auf einem zentralisierten und globalisierten Markt erfolgreich tätig sein wollen, von unschätzbarem Wert. Nur so wird es möglich, auf sich rasch ändernde Marktsituationen angemessen und zeitnah reagieren zu können. Dies geschieht durch die Beschleunigung und Rationalisierung der Informationsflüsse durch das Unternehmen. Aber auch die Zusammenarbeit zwischen Unternehmen kann durch EAI-Anwendungen erleichtert werden und so einen Mehrwert für alle beteiligten Partner schaffen.

Die hier vorliegende Arbeit beschäftigt sich mit der Entwicklung von wiederverwendbarer, auf Komponenten basierter Software. Zur praktischen Umsetzung wird ein Beispielszenario aus der Qualitätssicherung eines deutschen Automobilherstellers verwendet. Dabei soll ein Prototyp entwickelt werden, mit dem es möglich ist, Grafikdaten zwischen zwei Anwendungen auszutauschen. Da zum Einen die verwendeten Grafikformate auf der XML ³ Syntax basieren, zum anderen XML eine wesentliche Grundlage für moderne EAI-Anwendungen bildet, soll der Focus der Arbeit darauf gelegt sein, wie XML den

¹ IT - Informationstechnologie

² EAI - Enterprise Application Integration

³ XML - eXtensible Markup Language

2 Kapitel 1. Einleitung

Austausch von Daten zwischen Anwendungen unterstützt. Somit soll der zu entwickelnde Prototyp in der Lage sein, XML-Daten zu verarbeiten. Besonderer Wert soll dabei auf die Erstellung von Stylesheets gelegt werden, mit denen es möglich ist, die Struktur von XML-Dokumenten zu ändern.

Um eine strukturierte Einführung in den zuvor kurz beschriebenen Sachverhalt zu geben, wird im Kapitel 2 zunächst eine Einführung in das Thema EAI gegeben. Neben einer Definition wird versucht, die Gründe für die Entwicklung von EAI-Anwendungen näher zu beleuchten. Ausserdem wird sich dem allgemeinen Aufbau solcher Anwendungen gewidmet. Abschliessend folgt ein kurzer Einblick, wie XML die Integration unterstützen kann.

Die Kapitel 3 und 4 befassen sich mit der Entwicklung komponentenbasierter Softwareanwendungen. Während in Kaptel 3 die Grundlagen erläutert werden, gibt das Kapitel 4 einen umfassenden Einblick in verschiedenen Möglichkeiten zur Umsetzung dieses Ansatzes. Dazu werden die Technologien Enterprise JavaBeans (EJB ⁴ ), Common Object Request Broker Architecture (CORBA ⁵ ), WebServices sowie das (Distributed) Component Object Model ((D)COM ⁶ ) vorgestellt. Alle Technologien bieten Ansätze zur Entwicklung von Software in Komponenten. Denn Abschluss bildet ein Vergleich der vorgestellten Technologien anhand selbst gewählter Kriterien. Als Ergebnis steht die Auswahl einer Technologie, welche als besonders geeignet erscheint.

Die Abschnitte 5 bis 7 beschäftigen sich mit der prototypischen Umsetzung einer EAI-Anwendung. Dazu erfolgt zunächst eine detaillierte Beschreibung der Anwendung. Ausgehend von der bisherigen Situation wird ein Überblick über die Zielstellung der Implementierung gegeben. Darauf folgend werden die Modellierung der grundlegenden Architektur sowie einige wesentliche Implementierungsaspekte näher erläutert. Den Abschluss dieser, im Rahmen einer Diplomarbeit entstandenen Ausarbeitung bildet eine Zusammenfassung der wichtigsten Ergebnisse, sowie ein Ausblick auf mögliche Einsatzgebiete sowie Erweiterungen des entwickelten Systems.

⁴ EJB - Enterprise JavaBeans

⁵ CORBA - Common Object Request Broker Architekture

⁶ (D)COM - (Distributed) Component Object Model

Kapitel 2

Enterprise Application Integration

2.1 Definition und Motivation von EAI

Heutige Unternehmenslandschaften sind geprägt von einer Vielzahl an IT-Systemen. Um den unterschiedlichen Aufgaben eines modernen Unternehmens gerecht zu werden, bedarf es im allgemeinen mehrerer spezieller Softwaresysteme [Sai01]. Bisher war eine Integration diverser inselartiger Anwendungen sowie ein Datenaustausch untereinander nur beschränkt möglich. Dies betrifft die Kommunikation innerhalb eines Unternehmens aber auch über Unternehmensgrenzen hinweg [Nus01]. Ein bisher häufig praktizierter Ansatz zur Integration diverser Anwendungen ist die Point-to-Point Kopplung von Systemen. Dabei wird jeweils zwischen zwei beteiligten Anwendungen ein direkter Datenaustausch vorgenommen. (siehe Abb. 2.1)

Abbildung 2.1: Integration von Unternehmensanwendungen mittels Point-to-Point

Schnittstellen

4 Kapitel 2. Enterprise Application Integration

Die Nachteile einer solchen Vorgehensweise liegen auf der Hand:

• Mit Anstieg der Anwendungen steigt die Anzahl der Schnittstellen exponentiell an (Anzahl Schnittstellen = n*(n-1)/2 wobei n=Anzahl der Anwendungen)

• Wird sehr schnell unübersichtlich

• Erhöhter Aufwand bei Updates und Neueinführungen von Systemen

• Wartung ist zeitaufwendig und kostenintensiv

Ein anderer Ansatz, die Kommunikation zwischen Anwendungen zu ermöglichen, ist die Integration einer sogenannten Middleware. Dabei wird die Middleware zwischen die beteiligten Anwendungen geschaltet. (siehe Abb 2.2)

Abbildung 2.2: Integration von Unternehmensanwendungen mittels Middleware

Middleware-Produkte ermöglichen den Datenaustausch zwischen Anwendungen verschiedener Hersteller auch über Plattform- und Unternehmensgrenzen hinweg [WR00]. Dieser Ansatz ist einer der Kernpunkte des Vorgehens, welches heute weitläufig unter dem Begriff Enterprise Application Integration (EAI, dt. Integration von Unternehmensanwendungen) bekannt ist.

Da der Begriff des EAI etwas schwammig ist und unterschiedliche Ausprägungen und Definitionen existieren, soll im Folgenden der Versuch einer Kurzdefinition unternommen werden. Hauptanwendungsziel einer jeden EAI-Lösung ist das Bemühen, Anwendungen, die nicht für eine Zusammenarbeit entworfen worden sind, dazu zu bringen, in Geschäftsprozessen zu interagieren. Eine sehr treffende Definition ist die folgende:

2.2. Aufbau von EAI-Anwendungen 5

„Unter Enterprise Application Integration (EAI) versteht man die Schaffung von betrieblichen Anwendungssystemen durch die Kombination einzelner Anwendungen unter Verwendung einer gemeinsamen Middleware. [Ruh00]“

Die wichtigsten Ziele, die mit EAI verfolgt werden, seien im Folgenden kurz aufgeführt:

• Integration von Daten, Anwendungen und Prozessen

• Kostengünstiger, sicherer und aktueller Datenaustausch zwischen Anwendungen und Unternehmen

• Steigerung von Effektivität und Effizienz durch Automatisierung von Geschäftsprozessen

• Steigerung der Flexibilität der gesamten IT-Landschaft durch Verwendung einer Middleware und Vermeidung von Point-to-Point Verbindungen

Im Weiteren stellt sich die Frage, was die ausschlaggebenden Punkte für die Entwicklung von EAI-Lösungen waren. Die IT ist seit vielen Jahre ein immer wichtiger werdenden Faktor für die Wettbewerbsfähigkeit eines Unternehmens. Um am Markt Bestand zu haben, müssen Unternehmen Produktneuerungen, -verbesserungen und -innovationen vorstellen, ihre Time-to-Market reduzieren, Verwaltungskosten einsparen etc. Diese Punkte erfordern die Einführung neuer Geschäftsprozesse sowie eine extrem anpassungsfähige IT-Unterstützung. Verstärkt wird dieser Druck durch die zunehmende Globalisierung sowie die verstärkte Ausrichtung auf E-Business. Dabei werden verstärkt Geschäfte über digitale Medien abgewickelt. Die dazu benötigten Daten müssen mit hoher Geschwindigkeit (am besten in Real-Time) bereitgestellt werden. Das EAI bietet die dafür nötigen Grundlagen. Es fungiert dabei als eine Art Drehscheibe für Kommunikation, über die sämtliche interne und externe Kernanwendungen eines Unternehmens miteinander verbunden werden können [Nus01]. Im folgenden Abschnitt wird der Aufbau einer EAI-Anwendung eingehend beleuchtet.

2.2 Aufbau von EAI-Anwendungen

Nachdem die Ziele von EAI-Anwendungen beschrieben wurden, widmet sich dieser Abschnitt dem Aufbau und der Funktionsweise. EAI-Anwendungen bieten Integrationsmöglichkeiten auf drei verschiedenen Ebenen: der Datenebene, der Objektebene und der Prozessebene. Die drei Schichten bauen aufeinander auf und ergänzen sich gegenseitig. Wie weit die Integration gehen soll, muss für jedes Unternehmen selbst entschieden werden,

6 Kapitel 2. Enterprise Application Integration

Abbildung 2.3: Zusammenhang zwischen Nutzen und Änderungsaufwand in Abhängig-

keit der verschiedenen Integrationsebenen [RWD99]

da sowohl Nutzen als auch Änderungsaufwand mit jeder Ebene steigen. Dieser Zusammenhang wird in Abbildung 2.3 verdeutlicht.

Datenebene

Die einfachste und unterste Integrationsebene ist die Datenebene. Die Aufgabe auf dieser Stufe ist die Bereitstellung von Daten in dem jeweils von einer Anwendung benötigten Datenformat. Ein aktuell viel diskutierter und verwendeter Ansatz ist der Datenaustausch mit Hilfe von XML-Dateien. Dabei werden mit Hilfe von XSL ¹ -Transformationen die XML-Eingabedateien in das zuvor spezifizierte Ausgabeformat umgewandelt. Da diese Art der Integration eng mit der Datenstruktur der beteiligten Systeme verbunden ist, muss mit jeder Änderung an den Systemen auch eine Änderung an den Stylesheets erfolgen. Gerade bei Systemen die noch einer Weiterentwicklung unterliegen, kann dadurch der Aufwand ganz erheblich ansteigen. Die Integration auf Datenebene kann mit der oben bereits beschriebenen Middleware recht einfach erfolgen.

Objektebene

Auf der nächsthöheren Integrationsebene findet eine Integration in Objekten statt. Alle Daten werden als entsprechende Businessobjekte modelliert, auf denen Aktionen ausgeführt werden können. Damit sind, wie aus der objektorientierten Programmierung bekannt, alle Daten und auf ihnen auszuführenden Methoden in Objekten gebündelt. Z.B. werden in einem Objekt „Kunde“ Datenfelder wie Kundennummer, Name, Anschrift etc. aber auch Methoden wie Kunde anlegen, löschen ändern gemeinsam erstellt.

¹ XSLT - XML Stylesheet Language Transformations

2.3. EAI auf Basis von XML 7

Die Realisierung erfolgt über die sog. Hub-and-Spoke Architektur. Dabei dient der Hub als zentraler und intelligenter Integrationsserver, über den sämtliche Datentransporte abgewickelt werden. Jede Anwendung muss somit genau eine Schnittstelle zum Hub unterstützen. Dieser wiederum ist dafür verantwortlich, die Daten in einem für die jeweilige Zielanwendung verständlichen Format bereitzustellen. Nachdem er die Daten vollständig empfangen und transformiert hat, „spricht“ (spoke) der Hub die Empfänger an und leitet ihnen die Daten weiter. Eine solche zentralisierte Lösung bringt klare Vorteile durch Verringerung der administrativen Tätigkeiten und das leichte Hinzufügen und Herauslösen von Anwendungen mit sich.

Prozessebene

Um Geschäftsprozesse in einer heterogenen Landschaft systemübergreifend abzubilden, reicht eine Integration auf Daten- und Objektebene nicht aus. Vielmehr muss eine Integration auf Ebene der Prozesse erfolgen. Dieser Vorgang ist bekannt als Business Process Automatisation (BPA ² ) bzw. Business Process Integration (BPI ³ ). Dieser Vorgang spielt eine besondere Rolle bei der Entwicklung komplexer Supply Chains, bei der Prozesse über mehrere Unternehmen hinweg aneinander angepasst und aufeinander abgestimmt werden müssen. Ziel ist eine Modellierung aus Geschäftsprozessen, Geschäftsprozessschritten und Objekten. Dabei sollten die Geschäftsprozesse von den Anwendungen losgelöst werden, sodass ein Wechsel der Anwendung keine Änderungen in den Prozessen nach sich zieht.

Auf der obersten Ebene der Integration ist die Realisierung am schwierigsten. Dennoch ist sie in der Lage, den gesamten Geschäftsprozess über verschiedene Anwendungen hinweg abzubilden und bietet somit den fortschrittlichsten Ansatz.

2.3 EAI auf Basis von XML

Wie in den vorherigen Abschnitten bereits erwähnt, ist ein Grundbaustein eines EAI-Systems die Integration auf Datenebene. Damit eine Kommunikation zwischen Anwendungen erfolgen kann, bedarf es einer plattformunabhängigen Sprache zum Datenaustausch. Die Lösung für diese Herausforderung war die Entwicklung der Metasprache XML durch das World Wide Web Consortium (W3C ⁴ ). Dabei bietet XML die Möglichkeiten, Daten und Dokumente so zu beschreiben, dass ein Austausch zwischen verschiedenen Systemen ermöglicht wird. Dabei ist es uninteressant, ob sich die Systeme in einem Unternehmen befinden oder z.B. über das Internet aus verschiedenen Unternehmen verbunden werden [Gro03a].

² BPA - Business Process Automatisation

³ BPI - Business Process Integration

⁴ W3C - World Wide Web Consortium

8 Kapitel 2. Enterprise Application Integration

Beim XML-basierten Datenaustausch zwischen Anwendungen kommt meist die o.g. Middleware zum Einsatz. Das sendende Unternehmen nutzt diese, um Daten in eine vordefinierte XML-Struktur umzuwandeln. Dies erfolgt auf einem Middleware-Layer mit Hilfe zuvor erstellter Stylesheets. Die erstellten Dokumente werden z.B. über das Internet an das empfangene Unternehmen übertragen, welches seinerseits wiederum eine Umwandlung in das von ihm benötigte Format vornimmt [Lin03]. XML erleichtert ausserdem die Integration auf Objektebene. Da jedes Dokument neben den Daten auch die Beschreibung der Daten enthält, kann eine Modellierung von Objekten automatisch erfolgen. Daneben kann durch die Erstellung von Document Type Definitions (DTD ⁵ ) sichergestellt werden, dass nur gültige Dokumente generiert werden. Somit wird während des Transformationsprozesses die Identifikation und Prüfung auf Gültigkeit der Daten erleichtert [RWD99].

Zusammenfassend lässt sich sagen, dass der Einsatz von XML in EAI-Anwendungen viele Vorteile beim unternehmensweiten und unternehmensübergreifenden Datenaustausch mit sich bringt. Die Pflege von Geschäftsbeziehungen zu Partnerfirmen über das Internet kann automatisiert und somit schnell und fehlerfrei erfolgen. Zwei Beispiele aus der Praxis untermauern diese These: Intel konnte durch die Einführung von RosettaNet (ein auf XML basierendes Datenaustauschformat) seine Bearbeitungszeiten für die Annahme eines Kundenauftrages von 12 Stunden auf wenige Minuten reduzieren [Int03]. Der Flugzeughersteller Boeing konnte mit Hilfe von XML seine vorhandenen 18 Beschaffungssysteme auf 4 reduzieren [Fox03].

⁵ DTD - Document Type Definition

Kapitel 3

Komponentenbasierte

Softwareentwicklung

3.1 Notwendigkeit für komponentenbasierte Software

Ein in der Informatik lange verfolgtes, dennoch bis heute nicht erreichtes Ziel ist die Entwicklung von Softwaresystemen ohne dabei immer wiederkehrende Probleme neu lösen zu müssen. Dieser Ansatz gewinnt gerade bei den EAI-Anwendungen immer mehr an Bedeutung. Ein weiterer Schritt in die richtige Richtung ist die Softwareentwicklung auf Basis einzelner Komponenten, die zu einem Gesamtsystem zusammengesetzt werden. Komponenten können als Bausteine zur Lösung einer speziellen Aufgabe angesehen werden.

„A component is a piece of software small enough to create and maintain, big enough to deploy and support, and with standard interfaces for interoperability.“ Jed Harris, Präsident der CI Labs

Nach aussen sollen von einer Komponente lediglich die Signaturen, d.h. Parameter und Rückgabewerte, nicht aber realisierungstechnische Aspekte sichtbar sein. Diese Herangehensweise ist unter dem Begriff der Kapselung bereits aus der objektorientierten Programmierung bekannt.

Die komponentenbasierte Softwareentwicklung bringt eine Reihe von Vorteilen mit sich:

• Komponenten können so entwickelt werden, dass eine Wiederverwendung ermöglicht wird

• Die Entwicklung eines komplexen Systems kann einfacher auf mehrere kleine Teams mit konkret abgegrenzten Zuständigkeitsbereichen aufgeteilt werden

10 Kapitel 3. Komponentenbasierte Softwareentwicklung

• Entwickelte Systeme bleiben offen, sodass sie mit relativ geringem Aufwand um weitere Funktionalitäten (Komponenten) erweitert werden können

• Durch die Kombination von Komponenten verschiedener Hersteller sinkt die Abhängigkeit von jedem einzelnen Hersteller

• Durch die Wiederverwendung von Komponenten wird die Softwareentwicklung insgesamt kostengünstiger

• Die Verteilung auf mehrere Systeme wird erleichtert. (siehe nachfolgender Abschnitt)

Neben den Vorteilen sollen auch die auffälligsten Nachteile kurz Erwähnung finden:

• Wenn die Aufteilung der Komponenten zu fein gewählt wird, steigt die Kommunikation zwischen ihnen, womit zwangsläufig die Performance des Gesamtsystems sinkt

• Eine schrittweise Umstellung von Altsystemen ist nur schwer möglich, da bei diesen entsprechende Schnittstellen meist fehlen und somit eine Integration neuer Systeme in eine bestehende Systemarchitektur erschwert wird

Eine wesentliche Frage, die bei der Entwicklung von Komponenten zu klären ist, ist die nach der Granularität der Komponente. Davon direkt abhängig sind der Nutzen und die Wiederverwendbarkeit. Diesen Sachverhalt spiegelt Abbildung 3.1 wieder.

Abbildung 3.1: Abhängigkeit zwischen der Granularität von Komponenten und deren

Nutzen sowie Wiederverwendbarkeit

Wie aus der Abbildung zu erkennen ist, können grössere und komplexere Komponenten (mit geringer Granularität) nur selten verwendet werden. Wenn es aber ein Einsatzge- biet gibt, dann ist der Nutzen um so grösser. Im jeweils aktuellen Anwendungskontext

3.2. Strukturierung von Systemen 11

bleibt zu klären, in welcher Form eine Aufteilung in Komponenten als sinnvoll erscheint. Dennoch sollte jede Komponente die folgenden Eigenschaften besitzen [GT00]:

• Eine Komponente soll ganze Geschäftsobjekte kapseln und die Geschäftslogik auf diesen Objekten realisieren

• Eine Komponente soll möglichst komplette Transaktionen eines Geschäftsobjektes implementieren

• Eine Komponente ist anwendungsunabhängig und einzeln lauffähig

3.2 Strukturierung von Systemen

Mit der Einwicklung auf Basis von Komponenten, wie sie im vorherigen Abschnitt beschrieben wurde, entsteht eine Architektur, die ein System aus einer Menge von Bausteinen zusammensetzt. Obwohl diese Einteilung hauptsächlich den Prozess der Softwareentwicklung erleichtern soll, ergibt sich ein weiteres Einsatzgebiet. Durch Komponenten, welche die gesamte Funktionalität in sich kapseln, entsteht die Möglichkeit Systeme über mehrere Rechner zu verteilen. Dies wird durch die Entwicklungen und Fortschritte der letzten Jahrzehnte im Bereich der Rechenleistung und Netzwerktechnik unterstützt. In diesem Zusammenhang erfolgt eine Verteilung der Komponenten über eine sog. Multi-Ebenen-Architektur. Von jeder Ebene (auch: Schicht engl.: Tier) sollen nur die Menge aller öffentlichen Schnittstellen, nicht aber implementierungstechnische Aspekte sichtbar sein. Eine Änderung in einer Schicht sollte möglichst keine Änderungen in darüber oder darunter liegenden Schichten nach sich ziehen. Anders als bei der Kommunikation zwischen Rechnern, die über das ISO/OSI ¹ - Referenzmodell definiert wird, hat sich im Bereich der Strukturierung von Systemen über Schichten bisher kein Modell durchsetzen können. Vielmehr existieren diverse Ansätze, von denen die 4 wichtigsten im Folgenden kurz erläutert werden sollen.

Wie in Abbildung 3.2 zu sehen ist, liegen die Hauptunterschiede in der Anzahl der Schichten im Referenzmodell. One-Tier-Architektur

Das klassische Einzelplatzsystem basiert zumeist auf einer Architektur mit nur einer Schicht. Der Zugriff auf die Datenbank ist direkt in die Präsentationsschicht integriert. Diese Architektur ist hauptsächlich in kleineren Anwendungen zu finden, kann aber durch eine gemeinsame Datenbank mehrplatzfähig gemacht werden.

¹ ISO/OSI - International Standardization Organization/Open Systems Interconnect

12 Kapitel 3. Komponentenbasierte Softwareentwicklung

Abbildung 3.2: Unterschiedliche Ausprägungen von Mehrebenenarchitekturen

Two-Tier-Architektur

Ein erster Ansatz zur Multi-Tier-Architektur ist die Ausgliederung der Anfragen an die Datenbank. Dadurch kann bei komplexen Vorgängen der Netzwerkverkehr stark eingeschränkt werden. Das eigentliche Erstellen der Datenbankabfrage ist mit der Geschäftslogik weiterhin gemeinsam in der Präsentationsschicht integriert. Lediglich der Anfragestring wird an einen Datenbankserver weitergeleitet, welcher nach der Bearbeitung die Ergebnisse zurückliefert. Somit ist es möglich, einen separaten Datenbankserver aufzusetzen, um Performancevorteile zu erzielen. Three-Tier-Architektur

In der Drei-Schichten-Architektur erfolgt eine strikte Trennung zwischen Datenbank, Geschäftslogik und Präsentationsebene. Dabei kann jede dieser Schichten auf einem anderen Rechner angesiedelt sein. Somit ist es möglich, für jede Schicht die am besten geeignete Hardware zu wählen. Die Geschäftslogik läuft auf dem Applicationsserver. Als Datenbankserver kann ein Mainframe Computer zum Einsatz kommen. Die Präsentationsschicht liegt auf einem Web-Server. Dies ist das zur Zeit am meisten verbreitete Modell. Four-Tier-Architektur

In der Vier-Ebenen-Architektur erfolgt aus Sicherheits- und Skalierbarkeitsgründen eine Verteilung der Business-Logic über zwei Ebenen. Dabei wird unter die Präsentationsschicht ein Webserver geschaltet. Dieser nimmt die Anfragen vom Benutzer entgegen und leitet sie an die Applikationsschicht weiter. In dieser wird wiederum die eigentliche Business-Logic ausgeführt. Auch dieser Ansatz wird in der Praxis häufig verwendet. Obwohl zwischen der komponentenbasierten Softwareentwicklung und der Strukturierung von Software über Schichten enge Zusammenhänge bestehen, lassen sich einige klare Unterschiede herausstellen:

• Komponenten können horizontal und vertikal (über Schichten und verteilt über Rechnergrenzen hinweg), Schichten nur horizontal gegliedert werden

3.2. Strukturierung von Systemen 13

• Komponenten realisieren eine in sich abgeschlossene Funktionalität auf Ebene der Businessobjekte, eine vollständige Schicht aus der Architektur zu implementieren macht dagegen wenig Sinn

• Komponenten sind flexibler

14 Kapitel 3. Komponentenbasierte Softwareentwicklung

Kapitel 4

Technologien zur

komponentenbasierten

Softwareentwicklung

Nachdem im vorherigen Abschnitt bereits von komponentenbasierter Software und Multi-Tier-Architekturen die Rede war, soll sich der folgende Abschnitt mit den konkreten Technologien zur Umsetzung dieser Ansätze beschäftigen. Zunächst wird das Thema Enterprise JavaBeans behandelt. Im Abschnitt 4.2 geht es dann um denn Standard CORBA von der Object Management Group (OMG ¹ ). Abschnitt 4.3 ist den Web Services gewidmet, Abschnitt 4.4 dem von Microsoft entwickelten (D)COM.

4.1 Enterprise JavaBeans

4.1.1 Einführung in Enterprise JavaBeans

Enterprise JavaBeans (EJB) sind eine Spezifikation von Sun Microsystems. Sie ordnen sich in das Enterprise Konzept von Sun ein und werden als ein Komponentenmodell für die Entwicklung und Distribution von serverseitigen Java-Komponenten bezeichnet. Sie sollen die Entwicklung von verteilten, komponentenbasierten Java-Anwendungen erleichtern.

Wird versucht, die EJB’s in die im Abschnitt 3.2 vorgestellten Schichtenarchitekturen ein-zuordnen, würde man sie der Drei- bzw. Vier-Schichten-Architektur zuordnen. Abbildung 4.1 zeigt den möglichen Aufbau einer Bean. Client Schicht

¹ OMG - Object Management Group

16 Kapitel 4. Technologien zur komponentenbasierten Softwareentwicklung

Abbildung 4.1: Verwendung der Three-Tier-Architektur mit EJB [DP02]

Die Client-Schicht übernimmt die Präsentation und Darstellung der Daten. In dieser Ebene kommen hauptsächlich HTML ² , JavaScript und JSP ³ zum Einsatz. Innerhalb einer Four-Tier-Architecture kann die Client-Schicht in zwei Schichten unterteilt werden, dann laufen HTML und JavaScript im Browser des Users, JSP’s auf einem Webserver. Seitens des Clients können die Beans über das Java Naming and Directory Interface (JNDI ⁴ ) auf-gefunden werden. Die Erzeugung neuer Bean-Instanzen erfolgt über RMI ⁵ oder CORBA. Anwendungsschicht

Die Anwendungsschicht hält die eigentliche Business-Logic einer Anwendung vor. In dieser Schicht arbeiten die Beans, welche wiederum über z.B. JDBC ⁶ auf die Datenebene zugreifen können.

Datenebene

Auf der Datenebene arbeiten meist relationale Datenbankmanagementsysteme (DBMS ⁷ ). In ihnen werden alle zu einer Anwendung gehörenden Daten gehalten.

4.1.2 Architektur und Funktionsweise von Enterprise JavaBeans

In diesem Abschnitt soll die Architektur der Enterprise JavaBeans sowie die Einordnung in das Enterprise Konzept von Sun näher beleuchtet werden. Wie Abbildung 4.2 zeigt, exi-

² HTML- Hypertext Markup Language

³ JSP - Java Server Pages

⁴ JNDI - Java Naming and Directory Interface

⁵ RMI - Remote Method Invokation

⁶ JDBC - Java Database Connectivity

⁷ DBMS - Datenbankmanagementsystem