Klassifizierung und Suche Semantischer Ressourcen in verteilten Systemen

Diplomarbeit von Andreas Hollmann

Einleitung:

Semantic Web ist eines der meistgenutzten Schlagworte im Bezug auf die Zukunft des WWW. Die Notwenigkeit des Semantic Web entsteht durch die ‘Überproduktion’ von Information. Dabei werden mehr Informationen produziert, als verarbeitet werden können. Dabei verlieren die produzierten Informationen ihre Nützlichkeit, denn die Information hat nur dann einen Nutzen, wenn diese verarbeitet und in der Schlussfolgerung eines Ergebnisses berücksichtigt werden kann. Die obere Aussage wird durch die folgende Statistik belegt:

Die Anzahl der im Internet verfügbaren Webseiten und die Menge der angebotenen Services wächst stetig an. Bereits im November 2006 ergaben Schätzungen, dass die Zahl der weltweit angebotenen Seiten die Marke von 100 Millionen überschritten hat.

Die Vision des Semantic Web stammt von Tim Berners-Lee aus dem Jahr 1998. Semantic Web soll die Kommunikation zwischen Programmen, sogenannten Software Agenten, verbessern. Dazu müssen die Informationen so aufbereitet werden, dass sie nicht nur von verschiedenen Programmen auf verschiedenen Computer fehlerfrei gelesen werden können, wie beispielsweise XML, sondern auch verstanden. Die Software Agenten sollen die Bedeutung von im Internet veröffentlichen Informationen begreifen und daraus automatisch Schlussfolgerungen ziehen können. Die ‘Überproduktion’ der Daten betrifft auch das Bauwesen. So werden während der Bauwerksüberwachung viele Daten benötigt oder auch produziert.

Diese Arbeit bildet eine Brücke zwischen der Informatik und dem Bauwesen. Dabei werden die Konzepte aus dem Semantic Web durch die Integration in einer modernen Entwicklungsumgebung an die Lösung der Probleme aus dem Bauwesen angepasst. Semantic Web kann zum Einen für die Suche der benötigten Webservices, sowie dazugehörigen Berechnungsmodellen zum Einsatz kommen. Zum Anderen können die Berechnungsergebnisse, sowie die benötigten Eingabedaten ebenfalls semantisch beschrieben werden und dadurch effektiv in weiteren Projekten genutzt werden.

Gliederung:

Diese Arbeit ist in drei Kapitel aufgeteilt: im ersten Kapitel werden die theoretischen Grundlagen sowie die aktuellen Technologien und Standards kurz vorgestellt. Danach folgt das Kapitel der Synthese. Dieses beschreibt die während dieser Arbeit entdeckten Problemstellungen sowie erarbeiteten Methoden zu deren Lösung. Das letzte Kapitel beschreibt die praktische Umsetzung von in der Synthese erarbeiteten Methoden, dabei werden die aktuellen Technologien und Werkzeuge für die Anwendung in einem größeren Vorhaben diskutiert. Die Arbeit schließt mit einer Zusammenfassung und einem Ausblick.

Inhaltsverzeichnis:

Textprobe:

Kapitel 3.4, Funktionale Webservices:

Für komplexe Berechnungen im Bauwesen sind oft viele Einzelberechnungen notwendig. Die Formeln für diese Berechnungen können zum Beispiel direkt in Java implementiert und als Webservice veröffentlicht werden. Solche Webservices gehören zu funktionalen Webservices und können in einem komplexen Workflow Prozess zusammen zu einer komplexen Geschäftsprozesslogik orchestriert werden. Ein Beispiel für einen solchen Webservice bietet der während dieser Arbeit entwickelte Excavation-Webservice, der die Logik für die Berechnung der Horizontalverschiebung aus in dem Abschnitt 2.1 beschriebenen Problemantik implementiert. Im Bauwesen gibt es viele Sachverhalte, die berechnet werden müssen, was die Entwicklung von sehr vielen Webservices nötig machen würde. Wobei jeder Webservice eine bestimmte Problemstellung lösen kann. Das führt zu einer sehr hohen Webserviceanzahl, die schwer zu verwalten ist und schlecht wiederverwendbar ist. Außerdem enthalten die entwickelten Workflow Prozesse viele Web Referenzen auf viele Webservices und werden dadurch schwer begreifbar. Deswegen wurde in dieser Arbeit ein Ansatz gewählt, einen generischen Webservice für die Berechnungsmodelle zu erstellen und die mathematische Berechnung als Aspekt aus dem Webservice auszulagern. Der generische Ansatz hat sich während dieser Arbeit gelohnt, es führte zu kürzerer Entwicklungszeit, besserer Wartung, sowie höherer Software-Qualität. Ein Beispiel eines generischen Webservices stellt der Formula-Solver-Service dar. Dieser ermöglicht die Berechnung von mathematischen Gleichungen mit Hilfe eines Mathematik Parsers (Expression4J (Exp081)). Expression4J ist ein Open Source Mathematik Parser. Er implementiert viele grundlegende mathematische Funktionen wie Sinus, Cosinus oder Logarithmus. Expression4J hat eine offene API und kann um benutzerspezifische Funktionen erweitert werden. Für Differenzial- und Integralrechnung kann GattMath(Gat) verwendet werden. GathMath ist ähnlich wie Expression4J ein Open Source Projekt. Es ermöglicht die Berechnung von Integralen und Differenzialen. Bei Bedarf von Diferential- und Integralrechnung sollte eine Einbindung von GattMath als benutzerspezifische Funktion in Expression4J untersucht werden. Eventuell kann die bereits in Formula-Solver-Service angepasste Funktionalität von Expression4J um Integral- und Diferenzialrechnung ergänzt werden. Aus Performance Gründen werden die zu berechnenden Formeln auf dem Formula-Solver-Service in einer relationalen Datenbank zwischengespeichert. Die verwendete relationale Datenbank wird über das Hibernate Framework verwaltet. Dadurch wird die Datenhaltung von der Geschäftslogik des Webservices entkoppelt. So kann beispielsweise die in dieser Arbeit verwendete HSQL-Datenbank gegen eine andere nur durch das Verändern der Konfigurationsdatei von dem Hibernate-Framework ausgetauscht werden. Der Proxy-Formula-Solver-Service evaluiert das Konzept des Austausches eines Berechnungswebservices gegen einen anderen aus dem Abschnitt 2.4. Proxy-Formula-Solver-Service ist ein BPEL-Prozess, der eine bestimmte WSDL-Schnittstelle implementiert. Wenn nun anstelle des Formula-Solver-Service ein anderer Webservice für die Berechnung der mathematischen Formeln verwendet werden soll, kann ein neuer BPEL-Prozess entwickelt werden, der die gleiche WSDL-Schnittstelle implementiert und die Operationsaufrufe an einen anderen Webservice weiterleitet. Ein vereinfachter Kontrollfluss einer Operation des Proxy-Formula-Solver-Service ist in der Abbildung 32 dargestellt. Die abgebildete Operation soll eine einfache mathematische Gleichung f(a,b)=a+b mit Parametern a=3 und b=2 berechnen. Die zu berechnende Gleichung sowie die Parameter werden der execute-formula() Operation des Proxy-Formula-Solver-Service übergeben. Diese Operation ist als ein BPEL-Unterprozess implementiert, sie ruft mehrmals verschiedene Operationen des Formula-Solver-Service auf. Zuerst wird die Methode set-formula() aufgerufen. Diese Methode speichert die übergebene Gleichung f(a,b)=a+b unter einer festgelegten id in einer relationalen Datenbank des Formula-Solver-Services. Danach lässt Proxy-Formula-Solver-Service die zuvor gesetzte Formel mit übergebenen Parametern a=3, b=2 mit Hilfe von der Operation execute-formula() berechnen.