Die erste Phase im Softwarentwicklungsprozess war eine Analyse der inhaltlichen und funktionalen Anforderungen für das Electronic-Commerce-Portal. Dies erfolgte durch eine emiprische Betrachtung von sogenannten Außendienstsystemen, die bei Versicherungsunternehmen im Einsatz sind, um Möglichkeiten und Defizite zu erkennen. Darüber hinaus wurden durch Interviews und Diskussionen mit VADs die typischen Arbeitsabläufe eines VADs analysiert. Die Ergebnisse der Analyse wurden strukturiert, indem die umfassenden Arbeitsabläufe in einzelne Aktivitäten unterteilt, priorisiert und in Anforderungsformularen dokumentiert wurden. In dieser Phase des Projekts wurde erkannt, dass das Electronic-Commerce-Portal als Integrationsplattform für verschiedene heterogene Subsysteme dient. Ausgehend von einer 3-Ebenen-Architektur [7] bei der die Benutzungsoberfläche und die Datenverwaltung von der funktionalen Anwendungslogik getrennt wird, wurden in der Ebene der funktionalen Anwendungslogik zunächst die folgenden Subsysteme eines Electronic-Commerce-Portals klassifiziert:

• Office-System (OS): (1) Durch das Office-System werden sowohl Adressen resp. Kontakte als auch Termine verwaltet. Bei Adressen und Kontakten werden harte und weiche Daten unterschieden. Durch das Office-System werden nur weiche Daten verwaltet; dies sind Daten, die der VAD für seine persönlichen Zwecke erfasst (z.B. Besuchshistorie, Anmerkungen zu Verträgen, etc.).
   
• Content-Management-System (CMS): Die Bereitstellung von Informationen durch das Versicherungsunternehmen für die VADs, aber auch durch die VADs für das Versicherungsunternehmen und andere VADs wird durch das CMS verwaltet. Auf der Basis eines Berechtigungskonzepts sind Innendienst- und Außendienstmitarbeiter in der Lage, größere Informationen (Prospekte, Handbücher, Gesetzestexte, Urteile, Marketingstrategien, etc.) zur Verfügung zu stellen, so dass der VAD auf diese Informationen zur Unterstützung seiner Arbeit zugreifen kann.
   
• Procurement-System (PS): Die Beschaffung von Verbrauchsmaterial einerseits und die Inanspruchnahme von Dienstleistungen (Seminare, Kurse, Veranstaltungen, Schulungen, Immobilienvermittlung etc.) andererseits ist für Versicherungsunternehmen, wenn sie zentral erfolgt, ein wichtiger Kostenfaktor. Sämtliche VADs, aber auch Innendienstmitarbeiter können aus einem zentralen Katalog Produkte und Dienstleistungen auswählen.
   
• Legacy-System (LS): Ein Partnermanagementsystem oder ein Provisionierungssystem liefert Informationen (Verträge, Risiken, etc.) über private und gewerbliche Kunden bzw. bietet die Möglichkeit, eine individuelle Tarifierung durchzuführen. Diese Systeme sind als Hostanwendungen realisiert und können über eine XML-Schnittstelle in das Electronic-Commerce-Portal integriert werden.
   
• Kommunikationssystem (KS): Das Kommunikationssystem stellt die Schnittstelle zu den Techniken der Telekommunikation dar. Texte und Benachrichtigungen können in Form von e-Mails oder SMS-Nachrichten, aber auch als Fax versandt werden. Durch das Terminplanersystem gesteuert werden diese Texte und Benachrichtungen jeweils zu vorher bestimmten Zeitpunkten versandt.
   
• Suchsystem (SS): Um im gesamten ECP nach Inhalten suchen zu können, bietet das Suchsystem Funktionen zur kontextsensitiven Suche an. Dies umfasst neben der Möglichkeit der Volltextsuche auch die Suche nach bestimmten Merkmalen von Informationen.
   
• Portal-Administrationssystem (PAS): Durch das PAS werden Funktionen zur Verfügung gestellt, die das Auswerten von Protokolldateien und deren graphische Präsentation ermöglichen. Darüberhinaus wird durch das PAS sichergestellt, dass der Benutzer des Portals sich nur einmal dem Portal gegenüber identifizieren muss.

Die Benutzeroberfläche als Zugang zum Electronic-Commerce-Portal ist mit der Hypertext Markup Language (HTML) realisiert worden. Zur Datenverwaltung wird, sofern die einzelnen Subsysteme über keine eigene Datenverwaltung verfügen, ein relationales Datenbank-Managementsystem verwendet.

Abbildung 1: Systemarchitektur

Die Funktionalität der Subsysteme Office, Content Management, Procurement und Kommunikation wird durch bereits existierende, externe Systeme bereitgestellt, die über Adapter (Kreise in Abb. 1) in das Electronic-Commerce-Portal integriert werden. Durch die Kombination der Funktionalität verschiedener Subsysteme entstehen neue Funktionen des Gesamtsystems, die sich an den Geschäftsprozessen der Benutzer orientieren: Um z.B. einen wichtigen Vertragsstichtag aus dem Legacy-System "Partnerdatenbank" zu lesen, einen entsprechenden Eintrag in den Terminkalender des Office-Systems zu schreiben und das rechtzeitige Versenden einer Erinnerung über das Kommunikationssystem zu veranlassen, wäre bei getrennten Subsystemen eine Reihe von unterschiedlichen Tätigkeiten erforderlich. Im Electronic-Commerce-Portal kann der VAD diese Aufgabe hingegen in wenigen Schritten lösen.

Die dazu notwendige Verknüpfung von Tätigkeiten und Konsolidierung von Daten wird durch Controller geleistet, die als Gehirn des Electronic-Commerce-Portals betrachtet werden können: Sie erhalten vom Benutzer Aufträge zur Ausführung komplexer Geschäftsprozesse, steuern daraufhin die Subsysteme entsprechend an und liefern die konsolidierten Daten an den Anwender zurück.

Die Subsysteme werden nicht direkt vom Benutzer angesprochen und treten nicht selbst mit ihm in Kontakt. Aus diesem Grund wurden Such- und Administrationssystem nicht als externe Systeme, sondern als Controller klassifiziert, da sie aktiv Informationen von den anderen Systemen anfordern oder ihnen übergeben. Alle weiteren Geschäftsprozesse werden vom Workflow-Controller realisiert und gesteuert.

Die externen Systeme verfügen über ein oder mehrere Schnittstellen (APIs), durch die die jeweilige Funktionalität genutzt werden kann. Jedes externe System wird daher über genau einen Adapter mit der zentralen Middleware verbunden. Jeder Adapter stellt der Middleware eine Menge von Methoden zur Verfügung, die die ursprüngliche Schnittstelle des externen Systems kapseln. Auf diese Weise muss das (möglicherweise komplizierte) ursprüngliche Interface nicht öffentlich bekannt sein, um die Funktionalität des Subsystems zu nutzen. Stattdessen können andere Subsysteme einfach die Methoden benutzen, die vom Adapter zur Verfügung gestellt werden. Um zum Beispiel eine e-Mail über das Kommunikationssystem zu versenden, genügt es, die entsprechende Methode des Kommunikations-Adapters aufzurufen, die sich dann darum kümmert, aus den übergebenen Parametern eine RFC822-konforme Nachricht [8] zu konstruieren, eine Sitzung mit dem SMTP-Server aufzubauen und die e-Mail zu versenden. Zudem erlaubt die Kapselung, externe Systeme einfach auszutauschen: Wenn das ursprüngliche Interface eines Systems sich ändert, muss nur dessen Adapter umgeschrieben werden, während alle anderen Subsysteme unberührt bleiben.

Der Benutzer interagiert hauptsächlich über einen Web-Browser mit dem Electronic-Commerce-Portal. Dies hat wichtige Auswirkungen auf den Kontrollfluss im System. In traditionellen Software-Systemen kann der Dialog-Ablauf zum Großteil vom System selbst bestimmt werden: Zum Beispiel muss nur eine modale Dialogbox geöffnet werden, um den Nutzer zur Ausführung einer bestimmten Aktion zu zwingen, bevor er irgendetwas anderes tun kann [9]. Im Web werden dagegen alle Aktionen vom Benutzer initiiert. Der Server kann keine Informationen zum Browser "pushen", die der Benutzer nicht angefordert hat (2).

Infolgedessen bleiben die externen Systeme (Office, Content Management etc.) des Electronic-Commerce-Portals passiv und reagieren nur auf Benutzeranforderungen, die ihnen auf dem in Abb. 2 dargestellten Pfade übermittelt werden:

Abbildung 2: Kommunikation innerhalb des Electronic-Commerce-Portals

Jede Benutzeraktion wie das Anklicken eines Links or das Absenden eines Formulars erzeugt einen HTTP-Request [10], der von einem zentralen Dispatcher empfangen wird. Der Dispatcher liest den HTTP-Request-String, baut aus seinen Inhalten ein Request-Objekt und leitet es an den Controller weiter, der für die Behandlung der angeforderten Aufgabe verantwortlich ist: Der Search-Controller und der Admin-Controller implementieren die Funktionalität der zuvor erwähnten Systeme Suche und Portal-Administration; alle anderen Transaktionen, an denen externe Systeme beteiligt sind, werden vom Workflow-Controller gehandhabt.

Die Controller werten die Request-Objekte aus, die ihnen vom Dispatcher übergeben werden. Je nach Art des Requests senden sie Befehle oder Anfragen an die externen Systeme, konsolidieren die Ergebnisse und schicken sie zum Dispatcher zurück. Um dies zu leisten, muss der spezifische Arbeitsablauf (Workflow) zur Erfüllung eines jeden Requests im jeweiligen Controller fest einprogrammiert sein. Wird zum Beispiel der Request empfangen, in allen externen Systemen nach einer bestimmten Person zu suchen, so fragt der Search-Controller das Office-, Content-Management- und Legacy-System ab und schickt die kombinierten Ergebnisse als Response-Objekt zum Dispatcher zurück.

Der Dispatcher leitet das vom Controller erhaltene Response-Objekt an den Formatter weiter. Dieses Subsystem ist für die Konvertierung des Response-Objekts in ein Format verantwortlich, das vom Endgerät des Nutzers dargestellt werden kann. In den meisten Fällen wird das gewünschte Ausgabeformat Hypertext Markup Language (HTML) [11] sein, die von einem breiten Spektrum an Endgeräten verarbeitet werden kann. Für exotischere Endgeräte wie WAP-Telefone und Organizer können andere Formatter Ausgabeformate wie Wireless Markup Language (WML) erzeugen. Diese Flexibilität ist ein wesentlicher Vorteil der Trennung zwischen Formatter und Controller: Da die Implementierung der Benutzerschnittstelle in einem einzigen System konzentriert ist, kann die visuelle Darstellung von Informationen geändert oder ergänzt werden, ohne die Subsysteme ändern zu müssen, die diese Informationen zur Verfügung stellen.

Aufgrund von Performance-Abwägungen und besonderen Systemanforderungen laufen die meisten externen Subsysteme sowie der Web-Server auf getrennten Rechnern. Diese verteilte Architektur erfordert eine Middleware wie CORBA oder RMI, um Methodenaufrufe und Objektübergaben zwischen den verschiedenen Subsystemen zu koordinieren. Der Gebrauch der Middleware ist innerhalb einzelner Subsysteme wie der Benutzerschnittstelle natürlich nicht nötig: Der Dispatcher ruft zum Beispiel direkt eine Methode des Formatters auf, um ein Response-Objekt zu übergeben, das er von einem Controller erhalten hat.

Der Dispatcher und die Controller könnten jedoch auf verschiedenen Rechnern laufen. Aus diesem Grund tauschen sie Objekte über die Middleware aus. Zwei Modelle zur Kommunikation wurden dazu in der Entwurfsphase des Projekts in Betracht gezogen:

1. Publisher/Subscriber-Modell: Der Dispatcher veröffentlicht ein Request-Objekt über die Middleware und gibt seine Verfügbarkeit mit einem Event bekannt, das den Typ des Requests beschreibt. Die Controller können Events abonnieren, die für sie relevant sind, und eine Kopie der entsprechenden Request-Objekte von der Middleware erhalten.
    
2. Expliziter Controller-Aufruf: Der Dispatcher entscheidet in Abhängigkeit vom Typ des Requests, welche(n) Controller er aufrufen muss, um das Request-Objekt über die Middleware zu übergeben.

Im Publisher/Subscriber-Modell wird der Dispatcher effektiv auf einen Mechanismus zur Konvertierung von HTTP-Request-Strings in Request-Objekte reduziert, da er nicht weiß, welcher Controller für welchen Request-Typ verantwortlich ist. Dies scheint zunächst eine elegante Entkopplung darzustellen, bei genauerer Betrachtung werden jedoch einige Fallstricke offensichtlich: Obwohl der "sendende" Teil des Dispatchers nicht geändert werden muss, wenn ein neuer Controller zur Abonnenten-Liste hinzugefügt wird, muss der "empfangende" Dispatcher-Teil dennoch darauf vorbereitet werden, Response-Objekte von dem zusätzlichen Controller anzunehmen. Im Hinblick auf den Aufwand für die Definition von Schnittstellen zwischen dem Dispatcher und den Controllern bringt das Publisher/Subscriber-Modell keine Vorteile gegenüber dem expliziten Controller-Aufruf: Sowohl Dispatcher als auch Controller müssen wissen, welche Attribute für welche Request-Objekte definiert sind - unabhängig davon, wie die Objekte transportiert werden. Weitere Probleme entstehen aus der Multi-User-Umgebung des Electronic-Commerce-Portals: Der Dispatcher muss wissen, welches vom Controller zurückgelieferte Response-Objekt mit welchem ihm übergebenen Request-Objekt korrespondiert. Beim expliziten Controller-Aufruf wird diese Zuordnung implizit vom Aufruf-Stack der Middleware übernommen. Im Publisher/Subscriber-Modell müsste jedes Request-Objekt (und die zwischen Controllern und Subsystemen ausgetauschten Objekte) mit einem eindeutigen Schlüssel versehen werden, um die eingehenden Response-Objekte zuzuordnen - ein unnötiger Overhead.

Controller und Subsysteme kommunizieren durch den Austausch von Business-Objekten [12], d.h. Einheiten, die zentrale Bedeutung für den Workflow im Electronic-Commerce-Portal besitzen. Die folgenden Business-Objekte sind darum allen Controllern und Subsystemen bekannt:

• Benutzer
• Kontakt
• Termin
• Aufgabe
• Nachricht
• Shop-Artikel
• Bestellung
• Bestellhistorie
• Suchanfrage
• Suchergebnis

Um zum Beispiel einen Termin einzutragen, erzeugt der Workflow-Controller ein Termin-Objekt aus den vom Dispatcher empfangenen Daten und gibt es an eine Methode des Office-Subsystems weiter, die den Termin in den Kalender des Benutzers einträgt. Wenn der Benutzer angibt, dass er rechtzeitig per e-Mail an den Termin erinnert werden möchte, erzeugt der Workflow-Controller zusätzlich ein Nachricht-Objekt, verbindet es mit einer Kopie des Termin-Objekts und gibt es an das Kommunikationssystem weiter, wo es in die Warteschlange für e-Mail-Nachrichten eingereiht und zum gewünschten Zeitpunkt versandt wird.

1. Die Verwaltung von Daten erfolgt einerseits traditionell durch ein Hostsystem, z.B. IBM MVS (für die sogenannten harten Daten) und zusätzlich durch ein Office-System, z.b. IBM Lotus oder MS Office (für die sogenannten weichen Daten). Der Zugriff auf die harten Daten erfolgt durch eine XML-Schnittstelle, wodurch auch eine Synchronisation der harten und weichen Daten möglich ist. (zurück)
    
2. Dies gilt für eine Benutzerschnittstelle aus einfachen HTML-Seiten. Natürlich wäre es möglich, auf der Client-Seite ein Java-Applet laufen zu lassen, das Informationen anzeigt, die ihm vom Server zugepushed werden. Dies würde jedoch einen Java-fähigen Browser erfordern und somit die meisten derzeit verfügbaren mobilen Endgeräte wie WAP-Telefone, Organizer etc. ausschließen. Einfaches HTML dagegen stellt die geringsten Anforderungen an die Zielplattform, und die Subsysteme, die es produzieren, können einfach modifiziert werden, um ähnliche Formate wie Wireless Markup Language (WML) zu erzeugen. (zurück)

< Einleitung | Realisierung >