Konzeption und Realisierung eines Agenten zum Einholen von Angeboten für Finanzdienstleistungen im Internet

Abbildung 5 gibt Auskunft über die technische Realisierung der einzelnen Schichten. Als oberste Schicht stellen Java Beans als gemeinsam genutzte Service-Klassen ihre Dienste den Kommunikationskomponenten zur Verfügung. Diese Dienste umfassen beispielsweise die Verarbeitung von TRSML mittels des XercesXML-Parsers und die Anbindung des RACER-Servers über die Java-API des RACER. Ebenso vorstellbar ist die Kapselung von WebService-Aufrufen zur einfacheren Verwendung durch die restlichen Komponenten. Wichtig ist überdies die Implementierung einer Überwachungsfunktion für den Trustee. Diese sollte eine Loggingkomponente enthalten, die Warnhinweise oder Fehlermeldungen des Agenten aufzeichnet. Anhand der Logeinträge kann der Betreiber oder der Wissensingenieur nachvollziehen, welche Fehler bei der Angebotseinholung aufgetreten sind. Beispielsweise kann der Trustee melden, wenn er erkannt hat, dass ein Seitenmodell eines Anbieters nicht mehr aktuell ist, oder dass der Netzwerkzugriff auf einen Anbieter komplett ausgefallen ist. Diese Informationen können [...]

- 30 Der TRS-Compiler, der Indexer und das Modellierungstool werden als JSP-Komponenten im Applikationsserver JBoss realisiert. Ein klarer Vorteil, der sich dadurch ergibt, ist die Änderbarkeit der Seitenmodelle über das Internet, da das Modellierungstool als Webanwendung vorliegt. Eine zweite Aufgabe des Wissensingenieurs ist die Modellierung des Branchenwissens. Dabei gewährt der Trustee selbst dem Wissensingenieur keine Unterstützung. Da das Branchenwissen jedoch als Ontologie realisiert ist (siehe Abschnitt 3.4.1.2), sind dafür bereits Werkzeuge existent, z.B. OILEd21. Das Branchenwissen ist nicht Teil des Trustee selbst, sondern wird dynamisch über den Zugriff per Netzwerk auf einen Reasoner, z.B. den RACER22 Server, in den Verarbeitungsprozess integriert. [...]

- 29 des Form-Tags, welchem bei der Modellierung der Anbieterseiten eine besondere Bedeutung zukommt, erscheint sinnvoll, da in dessen Eingabefelder später die Kundendaten einzutragen sind. Darüber hinaus sind noch etliche weitere Aktionen denkbar, die dem Wissensingenieur die Erstellung eines Seitenmodells in TRS vereinfachen können. Darunter fällt die Entfernung von Bildern und JavaScript-Ausdrücken aus der HTML-Seite, soweit sie Visualisierungszwecken dienen. Als Ziel des oben beschriebenen Prozesses ist ein Skelett der zu modellierenden Seite anzustreben, welches nur noch diejenigen Elemente enthält, die auch Eingang in das spätere TRS-Modell finden. Die vorverarbeitete Seite könnte dann in einem Editor vom Wissensingenieur weiterverarbeitet werden. Im Laufe der Modellierung einer Seite in TRS wird es hilfreich für den Wissensingenieur sein, den bisherigen Code auf Fehler untersuchen zu lassen. Dafür wird im Modellierungstool der TRS-Compiler zuständig sein, der mögliche Fehler oder falsche Syntax bei der Übersetzung zurückmeldet. Auch das Testen der in das Modell eingebetteten WebL-Skripts sollte vom Modellierungstool unterstützt werden. Wie Abbildung 4 zu entnehmen ist, muss die in TRS modellierte Seite noch in den XML-Dialekt TRSML übersetzt werden, um durch den Trustee nutzbar zu sein. Diesen Prozess sollte das Modellierungstool anstoßen können und eventuelle Erfolgs- und Fehlermeldungen zurückliefern. Nach der erfolgreichen Übersetzung erfolgt die Ablage des neuen Modells auf dem Server. Das Modellierungstool sollte es weiterhin erlauben, Änderungen an schon gespeicherten Seitenmodellen vornehmen zu können, falls sich die dazugehörigen Seiten im Internet ändern. Als Hinweis auf eine mögliche Seitenänderung durch den Anbieter kann der fehlgeschlagene Angebotseinholungsprozess bei einem Anbieter dienen. Besser wäre es aber, nicht mehr aktuelle Seiten vor ihrer Verwendung und vor dem möglichen Scheitern der Angebotseinholung entdecken zu können Durch die TRS-Modellierung der Anbieterseiten kann der Trustee die Syntax der Seiten erkennen. Was noch fehlt ist ein Überblick über die Art und den Inhalt der Angebote. (siehe auch Abschnitt 3.4.1.3.2 auf Seite 47 für eine genauere Betrachtung des Problems). Dazu dient der in der obigen Abbildung 4 schon gezeigte Indexer. Dieser hat die Aufgabe, eine Liste aller modellierten Seiten zu führen, in der vermerkt ist, welcher Anbieter welche Produktkategorien anbieten. Die Eingabe und Pflege dieser Daten ist ebenfalls die Aufgabe des Wissensingenieurs. Unterstützt werden kann er durch den Trustee beispielsweise, indem dieser eine graphische Benutzerschnittstelle zur Verfügung stellt, mit der die Zuordnung einer Produktkategorie zu einem Seitenmodell vereinfacht wird. Als sinnvolle Implementierung des Modellierungstools und des Indexers eignen sich JSPSeiten. Mittels HTML-Formularen kann die benötigte Editor-Funktionalität bereitgestellt werden. [...]