In der Realisierungsphase musste für jedes Subsystem eine "Make-or-Buy"-Entscheidung getroffen werden. Nach einer Bewertung existierender Lösungen und einer Gegenüberstellung des geschätzten Aufwands für die Eigenentwicklung eines Subsystems vs. der Integration einer bestehenden Lösung wurden folgende Systeme für die Integration ausgewählt [13], [14], [15], [16], [17], [18]:

• Office: Outlook 98 der Microsoft Corporation
• Content Management: Pirobase 4.0 der PiroNet AG
• Procurement: SmartStore Standard Edition 2.0 der SmartStore AG
• Kommunikation:
  • e-mail: JavaMail von Sun Microsystems, Inc.
  • Fax: sendfax - Freeware; enthalten in Linux 6.3 (i368) der SuSE GmbH
  • SMS: yaps - Freeware; enthalten in Linux 6.3 (i368) der SuSE GmbH
• Legacy: Beispiel-Partnerdatenbank der Continentale Versicherung

Der Nachweis der Praktikabilität der Integrierbarkeit dieser Systeme erfolgte durch die Entwicklung von Prototypen, d.h. "Quick-and-Dirty"-Implementierungen der in der Systemarchitektur beschriebenen Adapter. Ziel dieser Prototypen war der Beweis, dass es möglich ist, die ursprünglichen Interfaces der externen Systeme zu kapseln und ihre Schlüssel-Features über die Adapter zugänglich zu machen. Dieses Ziel wurde für alle Subsysteme erreicht, so dass der Weg für die nächste Phase des Softwareentwicklungsprozesses frei war.

Für die Phase des objekt-orientierten Entwurfs wurde die Unified Modeling Language (UML) [19], [20] verwendet. Die Schlüssel-Features aller Subsysteme wurde in Use Cases modelliert, um Business-Objekte und mögliche Abhängigkeiten zwischen den Subsystemen zu identifizieren. Aufbauend auf den Erkenntnissen aus diesem Schritt wurden anschließend konkrete Klassen für jedes Subsystem definiert. Um eine einfache Konsolidierung der Ergebnisse zu gewährleisten und spätere Änderungen an den Subsystemen zu ermöglichen, ohne davon abhängige Klassen zu berühren, wird jedes Subsystem nach außen durch eine Fassadenklasse repräsentiert. Diese Klasse stellt alle Methoden zur Verfügung, die andere Klassen benötigen, um mit dem Subsystem zu kommunizieren. Als Beispiel betrachten wir, wie eine Suchanfrage ans Legacy-System behandelt wird (Abb. 3):

Abbildung 3: Integration des Legacy-Systems

Die Integration des Legacy-System erfolgt in diesem Fall durch eine in XML konvertierte Datenbankanfrage [21]. Das große Rechteck links in der Abb. 3 stellt einen Blick in das Legacy-Subsystem dar, das wir aus vorhergehenden Abbildungen kennen. Die kleineren Rechtecke repräsentieren Klassen. Da nur die Legacy-Fassadenklasse über die Middleware mit dem Controller verbunden ist, übergibt der Controller in unserem Beispiel das Suchanfragen-Objekt nicht direkt an den Query-Encoder. Stattdessen wird die Suchanfrage der Legacy-Fassadenklasse übergeben, die es dann an den Query-Encoder weiterleitet. Diese Klasse ist ein Teil des Adapters, der das ursprüngliche Interface des externen Systems kapselt: Im Fall des Legacy-Systems erfolgen die Anfragen an die Partnerdatenbank sowie die Ergebnisse von der Partnerdatenbank auf der Basis von XML [22], [23], [24] um maximale Unabhängigkeit von Plattform- und Transportmedium zu wahren. Die XML-codierte Suchanfrage läuft über die Datenbank des Versicherungsunternehmens, und das codierte Ergebnis wird an den Adapter des Legacy-Subsystem zurückgeliefert. Dort erzeugt der Result-Decoder ein Suchergebnis-Objekt und übergibt es an die Legacy-Fassadenklasse, die es an den Workflow-Controller weiterleitet.

An diesem Beispiel wird nochmals der Zweck der Business-Objekte deutlich: Das Gesamtsystem ist unabhängig vom ursprünglichen Datenformat, mit dem ein Subsystem intern arbeitet (im Fall des Legacy-Systems: XML). Die Fassadenklassen erzeugen stattdessen Business-Objekte, die allen Controllern bekannt sind.

Nach der Konsolidierung der Entwürfe für die Subsysteme, die Controller und die Benutzerschnittstelle ging das Team zur Implementierungsphase über. Die meisten Klassen wurden in der Programmiersprache Java [25] implementiert, lediglich der Adapter für das Office-System verwendet Microsoft Visual C++ [26], um die Microsoft Outlook 98 API anzusprechen.

Abbildung 4: Homepage des Electronic Commerce Portals

Abb. 4 zeigt die Homepage des Electronic-Commerce-Portals. Nach der Authentifizierung erhält der VAD auf einen Blick alle Informationen, die zu diesem Zeitpunkt für ihn relevant sind: Persönliche Nachrichten, interessante Dokumente aus dem Content-Management-System, aktuelle Termine und fällige Aufgaben aus dem Office-System, Veranstaltungen und Artikel aus dem Procurement-System. Legacy-Anwendungen wie die Partnerdatenbank und ein Provisionierungssystem sind über Links auf der Homepage zugänglich. Eine Suchmaske erlaubt Meta-Suchen über ausgewählte Bereiche des Portals.

< Systemarchitektur | Zusammenfassung >