Service Oriented Architecture - Webservices. zur Verwendung in Location Based Services. Diplomarbeit

Transkript

1 Service Oriented Architecture - Webservices zur Verwendung in Location Based Services Diplomarbeit Universität Rostock Fakultät für Informatik und Elektrotechnik Institut für Informatik Lehrstuhl für Informations- und Kommunikationsdienste vorgelegt von: Grube, Ralf geboren am in Bergen auf Rügen Matrikelnummer Betreuender Hochschullehrer: Herr Prof. Dr. rer. nat. Clemens H. Cap 2. Gutachter: Herr Prof. Dr.-Ing. habil. Peter Forbrig Betreuer: Herr Dr.-Ing. Thomas Mundt Abgabedatum:

2 Aufgabenstellung In einer Reihe vorheriger studentischer Arbeiten ist wiederholt der Bedarf nach einer Funktionsbibliothek für den Umgang mit Ortsinformationen im weiteren Sinne aufgefallen. Es sollen mindestens folgende Funktionen realisiert werden: Umwandlung von Positionsangaben in verschiedene Koordinatensysteme Abstands- und Flächen- und Volumenberechnung Richtungsberechnung Speicherung von Positionsangaben für einen Zeitraum Es ist mit einer großen Vielzahl von verschiedenen Clients zu rechnen. Um eine möglichst flexible Softwarearchitektur zu erhalten, sollen die genannten Funktionen in einer Service-oriented Architecture (SOA) als XML Webservices zur Verfügung gestellt werden und über eine UDDI Registry beschrieben werden. Aus den angebotenen Diensten soll eine möglichst große Anzahl verschiedener Anwendungen komponiert werden können. Idealerweise werden die entwickelten Dienste weltweit für andere Nutzer verfügbar gemacht. Dabei sind folgende Teilaufgaben notwendig: Betrachtung von Koordinatensystemen und Funktionen darauf Analyse existierender Frameworks für die Geo-Informationsverarbeitung Betrachtung des Standes der Forschung beim Thema Semantic Web Einarbeitung in SOA / XML Webservices / UDDI und Aspekte der Programmierung Sammlung und Kategorisierung der notwendigen Funktionen Konzeption einer Diensteauswahl, die möglichst alle Aspekte ohne großen Aufwand abdeckt Implementierung zumindest eines Teils der Dienste, Implementierung von Testfällen für die Dienste i

3 Erklärung Hiermit erkläre ich, dass ich die Diplomarbeit selbstständig angefertigt und keine anderen als die angegebenen Hilfsmittel und Quellen verwendet habe. Die Arbeit hat in gleicher oder ähnlicher Form noch keiner anderen Prüfungsbehörde vorgelegen. Die schriftliche und die elektronische Form dieser Ausarbeitung ist identisch. Rostock, Ralf Grube ii

4 Kurzfassung Für die Programmierung von Location Based Services (LBS) benötigt man grundlegende geographische Funktionen, wie z.b. die Entfernungs- oder Richtungsbestimmung und Koordinatentransformationen. Diese sind momentan als Programmiersprachen-abhängige Funktionsbibliotheken verfügbar, die direkt auf dem System des Dienstes installiert sein müssen. Die Entwicklung im Bereich der geographischen Datenverarbeitung geht dagegen hin zu Dienste-orientierten Komponenten, die eine gewisse Funktionalität bereitstellen. Das Ziel der Arbeit ist es, auch die grundlegenden Funktionen als atomare Dienste bereitzustellen. Dadurch wird eine höhere Flexibilität im Entwurf von LBS erreicht werden. Des weiteren wird der Dienste-basierte Ansatz genutzt, um den klassischen Zugriff auf eine Funktionsbibliothek (Lesen der Dokumentation, manuelle Auswahl und Einbindung der gewünschten Funktion) zu erweitern. Dazu wird ein Suchprozess vorgestellt, der Anfragen an eine Wissensbasis (Ontologie) mit der Suche nach Webservices in einer Universal Description, Discovery and Integration (UDDI) Registry kombiniert. Somit wird die Nutzung der hier vorgestellten WebLibrary (kurz BLib) teilweise automatisiert und dadurch vereinfacht. Neben den nötigen Grundlagen wird in der Arbeit das Konzept zur Umsetzung der Idee erläutert. Des weiteren erfolgt eine prototypische Implementierung, um den Ablauf des automatisierten Suchprozesses untersuchen zu können. Die Ergebnisse der Arbeit werden anschließend noch an Testfällen evaluiert. Abstract Implementation of location-based services (LBS) requires the provision of fundamental geographic functions, like calculation of distance and angular relationships and coordinate transformations. These are currently made available through language dependent libraries, which have to be installed directly on the LBS system. One emerging trend in geographic information technology consists of service-oriented components providing support for specific functionality. This thesis aims at also providing fundamental geographic functions in the form of such atomic services. This should result in increased flexibility in the design of LBS solutions. The service-oriented approach will further be used to expand the traditional means for using a library (study of documentation and manual selection and integration of desired function). This will be supported by a search process that combines queries to a knowledge base (ontology) with a search for Web services in a UDDI registry. Use of the library will thus be simplified based on partial automation. The thesis introduces fundamental issues and discusses an approach for implementation of the proposed methodology. A prototype implementation is presented, aimed at investigating the automated search process. Finally, results are evaluated on the basis of several test cases. Categories and Subject Discriptors C.2.4 [Computer-Communication Networks]:Distributed Systems - distributed applications General Terms Design, Languages Keywords Geographic information technology, Geodesy, GML, Service-oriented architecture, Webservice, UDDI, WSDL, SOAP, Library, Semantic Web, Ontology, RDF, OWL, SPARQL iii

5 Inhaltsverzeichnis 1 Einleitung Motivation und Zielstellung Aufbau der Arbeit Grundlagen Einführung in die Service-orientierte Architektur Einführung zu Webservices Schnittstellenbeschreibung: WSDL Kommunikation: SOAP Verzeichnisdienste: UDDI Nichtfunktionale Dienstbeschreibung und -komposition Standardisierung in der Geoinformatik Geography Markup Language (GML) Grundlagen des semantischen Webs RDF, RDF-S und OWL OWL-S SPARQL - Eine Anfragesprache für RDF-basierte Wissensbasen Verwandte Arbeiten Das Projekt Geoserver Frameworks für semantische Webservices WSMO METEOR-S Eine Dienste-basierte geographische Funktionsbibliothek Motivation Eine Ontologie für geographische Funktionen Der Maschinen-gestützte Zugang zur Bibliothek Die Funktionsbibliothek als Webservices Die erweiterte Suche von Funktionen Der Einsatz von GML als Transportsprache iv

6 5 Implementierung Die Funktionen als Webservices Die UDDI Registry mit den Diensten Die Ontologie in OWL Die Ontologie-Anfragen mit SPARQL Die Dienste in OWL-S Die Projektstruktur und das Deployment Evaluierung Kritische Betrachtung Einfache Nutzbarkeit Genauigkeit, Performanz und Stabilität Vergleich der Ergebnisse mit GeoTools Vergleich der Rechendauer mit GeoTools Test des Lastverhaltens Einfache Wartung Anwendbarkeit Zusammenfassung und Ausblick Zusammenfassung Ausblick Literaturverzeichnis 75 A Ausgewählte XML-Schemas 79 B Abbildungen von ausgewählten Ontologien 81 C UML-Diagramme von ausgewähltem Source-Code 84 v

7 Tabellenverzeichnis 6.1 Durchschnittliche Abweichung (EW) des Webservice-Ergebnis vom Geotools-Ergebnis relativ zum letzteren (in %) und die Standardabweichung (SA) Durchschnittliche Rechenzeit (EW) der Webservice-Berechnung relativ zur GeoTools-Berechnung und die Standardabweichung (SA) - Lokaler Webservice-Aufruf Durchschnittliche Rechenzeit (EW) der Webservice-Berechnung relativ zur GeoTools-Berechnung und die Standardabweichung (SA) - Remote Webservice-Aufruf Absolute Rechenzeit (EW) der Webservice-Berechnung (in ms) und die Standardabweichung (SA) - Lokaler Webservice-Aufruf Absolute Rechenzeit (EW) der Webservice-Berechnung (in ms) und die Standardabweichung (SA) - Remote Webservice-Aufruf 68 vi

8 Abbildungsverzeichnis 2.1 Das SOA-Dreieck Der SOA-Stack nach [WCL05] Aufbau von WSDL Das UDDI Informationsmodell aus [BEH + 02] Die thematisch abgegrenzten Module der GML [CDL + 04] Semantic Web Stack (W3C) Drei einfache Aussagen als RDF-Tripel Die Verknüpfung mehrerer Aussagen Einführung von Klassen und deren Instanzen Einführung von Klassenhierarchien mit RDF-S Defintion inverser Eigenschaften mit OWL Oberste Ebene der Service Ontologie [MBH + 04] Ontologie über das Service Profil [MBH + 04] ServiceGrounding, Abbildung von OWL-S auf WSDL [MBH + 04] Die Beziehung der verschiedenen WSMO-Projekte Zwei Sichten auf eine Funktionsbibliothek Taxonomie innerhalb der geographischen Funktionsbibliothek. 34 vii

9 4.3 Die Beziehungen der Webservices Spezifikationen untereinander ([Erl05]) Vergleich klassischer und Service-orientierter Software ([Erl05]) Der Ablauf von der ersten Abfrage bis zur Rückgabe des WSDL- Dokuments SOAP Request für die Berechnung einer Entfernung SOAP Response mit der berechneten Entfernung Schematischer Aufbau der Dienste-Veröffentlichung in die UD- DI Registry Ein Eintrag über ein Binding in der Registry Definition eines ServiceProfiles Alternativer Ansatz für den erweiterten Suchprozess Projektstruktur der Implementierung Fehler nach dem ersten Generierungsschritt mit gsoap Fehler nach dem zweiten Generierungsschritt mit gsoap B.1 Auszug aus der GML Ontologie B.2 Taxonomie nach EPSG Definition B.3 Auszug aus der Ontologie der EPSG Definitionen C.1 Anwendungslogik eines Webservices am Beispiel des OperationMethodsTransformationServices C.2 Klassendiagramm der UDDI Implementierung viii

10 Listings 2.1 Eine mögliche SPARQL-Anfrage Die Wurzel einer Dienstbeschreibung Die Deklaration der verwendeten Parameter Die Operationen und deren Nachrichten Das Binding an ein Protokoll Die Defintion des Dienstes und seiner Operationen Die Defintion eines Binding-tModels nach dem uddidetails- XMLSchema Beginn eines OWL-Dokuments Die Defintion des Dienstes und seiner Operationen Das Ontologie-Modell im Jena-Framework Eine Anfrage im XML-Format Die Anfrage als String Das Erzeugung und Stellen einer Anfrage Das Ergebnis der Anfrage im XML-Format A.1 Das GML Application Schema mit eigenem Namespace A.2 Das Schema zur Beschreibung von SPARQL-Queries ix

11 Abkürzungen API AXIOM COM CORBA DARPA DAML DTD EPSG ESSI GIS GML GPS HTML HTTP IETF IOPE IT J2EE Application Programming Interface AXIs Object Model Component Object Model Common Object Request Broker Architecture Defense Advanced Research Projects Agency DARPA Agent Markup Language Document Type Definition European Petroleum Survey Group European Semantic Systems Initiative Geographische Informationssysteme Geography Markup Language Global Positioning System Hypertext Markup Language Hypertext Transfer Protocol Internet Engineering Task Force Input Output Precondition Effects Informationstechnik Java2 Enterprise Edition x

12 KB LBS LSDIS METEOR-S MIME MWSAF MWSCF MWSDI OASIS OGC OIL OWL-S OWS PDA QoS RDF RDF-S RPC SAAJ SMTP SOA SPARQL SQL StAX Knowledge Base Location Based Service Large Scale Distributed Information Systems Managing End-To-End OpeRations: for web Services Multipurpose Internet Mail Extensions METEOR-S Web Service Annotation Framework METEOR-S Web Service Composition Framework METEOR-S Web Services Discovery Infrastructure Organization for the Advancement of Structured Information Standards Open Geospatial Consortium Ontology Interchange Language OWL for Services OGC Web Service Personal Digital Assistant Quality of Service Resource Description Framework RDF Schema Remote Procedure Call SOAP with Attachments API for Java Simple Mail Transfer Protocol Service-oriented Architecture SPARQL Protocol and RDF Query Language Structured Query Language Streaming API for XML xi

13 TC UDDI URI UML UN/CEFACT W3C WFS WMS WSDL WS-I WSML WSMO WSMX WWW XML XSLT Technical Committee Universal Description, Discovery and Integration Uniform Resource Identifier Unified Modeling Language United Nations Centre for Trade Facilitation and Electronic Business World Wide Web Consortium Web Feature Service Web Map Service Web Service Decription Language Web Services Interoperability Organization Web Service Modeling Language Web Service Modeling Ontology Web Service Modelling execution environment World Wide Web extended Markup Language Extensible Stylesheet Language Transformation xii

14 Kapitel 1 Einleitung Die vorliegende Arbeit beschäftigt sich mit der Konzeption und einer prototypischen Implementierung einer Dienste-basierten geographischen Funktionsbibliothek. Dabei bestimmen zwei Motive das Vorgehen. Zum einen soll eine Programmiersprachen-unabhängige API für Entwickler geschaffen werden, deren Dokumentation in Form einer Ontologie hinterlegt ist. Mit Hilfe von Anfragen ist es möglich, das gespeicherte Wissen an den Entwickler zu vermitteln. Durch die zusätzliche Verknüpfung mit der Dienst-Suche soll direkt die Schnittstelle zur Funktion auffindbar sein. Somit wird der Zugriff auf die implementierte Fachlichkeit einer solchen Bibliothek vereinfacht. Zum anderen ist es das Ziel, Funktionalität auf mobile Endgeräte zu bringen, deren Laufzeitumgebungen nicht die nötigen Ressourcen für den Betrieb von großen Funktionsbibliotheken bereitstellen. In diesem Kapitel gibt es zunächst eine kurze Motivation, bevor anschließend der Aufbau der Arbeit erklärt wird. 1.1 Motivation und Zielstellung Laut Open Geospatial Consortium (OGC) ist die Definition eines Location Based Service (LBS) wie folgt [BWN + 05]: A LBS is a wireless-ip service that uses geographic information to serve a mobile user. Any application service that exploits the position of a mobile terminal. 1

15 1.1. MOTIVATION UND ZIELSTELLUNG Zur Bereitstellung dieser Dienste benötigt man unter anderem mathematische Funktionen zur Koordinatentransformation für die Berechnung von Entfernungen, Winkeln, Flächen und Volumen sowie weitere Hilfsfunktionen zur Umrechnung von Einheiten. Diese können gerade in der sphärischen Trigonometrie sehr komplex sein und sind nicht ohne weiteres jedermann geläufig. Aus diesem Grund gibt es auf dem Markt eine Reihe von Funktionsbibliotheken, die mathematische Funktionen für den Einsatz im geographischen Umfeld zusammenfassen und über eine Application Programming Interface (API) den Entwicklern zur Verfügung stellen. In der Regel sind die Funktionen hinsichtlich relevanter Größen wie Genauigkeit und Performanz optimiert. Die API ist inhärent Programmiersprachen-abhängig, sodass es eine Vielzahl von verschiedenen Bibliotheken für die unterschiedlichen Sprachen gibt. Beispiele dafür sind die in Java geschriebene GeoTools-Bibliothek 1 und das in C++ programmierte GeoDLL 2. Entwickelt man Dienste in einem heterogenen Umfeld, bringt der Einsatz unterschiedlicher Bibliotheken Nachteile mit sich. Zum einen muss sich der Entwickler in verschiedene APIs einarbeiten und zum anderen ist es möglich, Abweichungen bei den Ergebnissen zu erhalten, je nachdem welche mathematische Funktion zugrunde liegt und welche Genauigkeit implementiert wurde. Des Weiteren braucht man für die Nutzung des vollen Umfangs einer solchen Funktionsbibliothek genügend Ressourcen, die auf einem mobilen Endgerät nicht zwingend vorhanden sind. Ein weiterer Grund, die Idee der Dienste-basierten Funktionsbibliothek zu verfolgen, ist die aktuelle Entwicklung im Bereich der Geographischen Informationssystem (GIS). Klassische GIS sind monolithische System, die die Bereitstellung, Verarbeitung und Auswertung von geographischen Daten übernehmen. Deren Funktionalität wird nun in einzelne Komponenten zerlegt und über eine Netzwerkschnittstelle angeboten [dl05]. Ein Beispiel dafür sind Kartendienste, die für ausgewählte Regionen Kartenmaterial zur Verfügung stellen 3. Darauf aufbauend, ermöglicht dann die Komposition einzelner Dienste, komplexere Anfragen zu bearbeiten. Ein Beispiel dafür ist die Routenplanung und -visualisierung, für die man einen Kartendienst, einen Geocoding-Dienst (Umwandlung von Adressen in geographische Koordinaten) und einen Dienst zur Berechnung von Routen kombiniert geot d.htm#geodll

16 1.2. AUFBAU DER ARBEIT Während es für höherwertige Dienste bereits eine Vielzahl von Angeboten online gibt, sind die grundlegenden Funktionen bisher lediglich in den beschriebenen Funktionsbibliotheken vorhanden. Ein Grund dafür ist sicherlich die verschlechterte Performanz von Diensten durch die erhöhte Abstraktion und die zusätzliche Kommunikation [ACKM03]. Dieser Overhead fällt bei grundlegenden Rechenoperationen mehr ins Gewicht als bei komplexeren Diensten. Dennoch ergeben sich auch eine Reihe von Vorteilen durch die Umsetzung mit Hilfe der neuen Architektur. Die existierenden, offenen Standards und die breite Werkzeug-Unterstützung bei Dienste-basierten Architekturen erleichtern die Erstellung von Anwendungen. So sind die Schnittstellen Maschinenverarbeitbar und eine Rechner-gestützte Suche gehört ebenfalls dazu. Die bereits angesprochenen Probleme der Heterogenität werden umgangen und dadurch wird eine größere Flexibilität im Entwurf von LBSs gewonnen. Somit ergeben sich folgende Ziele für die Arbeit: Erstellung von Webservices zur Berechnung grundlegender geographischer Funktionen Bereitstellung einer UDDI Registry zum Auffinden der Webservices Erstellung einer Wissensbasis über die Domäne der geographischen Funktionen Erweiterung der Webservices-Suche durch Integration der Wissensbasis in den Suchprozess 1.2 Aufbau der Arbeit Nach diesem folgt in Kapitel 2 eine kurze Einführung in die Grundlagen, auf denen die Arbeit aufbaut. Das sind Service-oriented Architectures (SOAs), Webservices, das semantische Web und Standardisierung in der Geoinformatik. Anschließend wird in Kapitel 3 eine Übersicht zu verwandten Arbeiten gegeben. In Kapitel 4 wird das Konzept zur Realisierung der Dienste-basierten, geographischen Funktionsbibliothek vorgestellt. Einen Überblick über die prototypische Implementierung des Konzepts folgt dann in Kapitel 5. Dort werden die wichtigsten Details an Diagrammen und Code-Beispielen erörtert sowie der Aufbau des gesamten Projekts gezeigt. 3

17 1.2. AUFBAU DER ARBEIT In Kapitel 6 erfolgt eine Evaluierung der Arbeit. Dazu wurden Testfälle erstellt und durchgeführt, deren Ergebnisse dort analysiert und erörtert werden. Die Diplomarbeit schließt mit einer Zusammenfassung und dem Ausblick auf weitere Problemstellungen in dem Kontext der Arbeit. 4

18 Kapitel 2 Grundlagen Im folgenden wird ein Überblick über die wichtigsten Grundlagen dieser Arbeit gegeben. Dazu wird zunächst eine Einführung in die SOA gegeben und anschließend mit Webservices eine von deren Umsetzungen vorgestellt. Diese Arbeit ist keine Anwendung nach den Prinzipien einer SOA, sondern hat mit den geographischen Funktionen einen Teil einer solchen Anwendung im Kontext der LBS identifiziert und als atomare Dienste umgesetzt.dennoch sollten die Grundlagen der SOA bekannt sein, um die Einführung von Webservices nachvollziehen zu können. Ein weiteres zentrales Thema, das in diesem Kapitel kurz vorgestellt wird, ist das Semantic Web und dessen Technologien. Diese werden für eine semantische Beschreibung der Dienste verwendet sowie als Wissenbasis für die Domäne der geographischen Funktionen. Abschließend wird noch auf die Standards der Geoinformatik eingegangen, wovon speziell die Geography Markup Language (GML) für den Transport der Daten in dieser Arbeit verwendet wird. 2.1 Einführung in die Service-orientierte Architektur Service-Orientierung steht für eine ideale Vision der Welt, in dem alle Ressourcen sauber abgegrenzt und einheitlich beschrieben sind [Erl05]. Die SOA ist der vorerst letzte Schritt der Abstraktion auf Programmierebene hin zur 5

19 2.1. EINFÜHRUNG IN DIE SERVICE-ORIENTIERTE ARCHITEKTUR Beherrschung immer komplexer werdender Softwaresysteme. Die bisherige Entwicklung reicht von den Anfängen in der Assemblerprogrammierung über die prozeduralen bis zu den objektorientierten Sprachen. Ziel jeder neuen Entwicklung ist es, aufkommende Anforderungen an die Informationstechnik (IT) beherrschbar zu machen. Das Konzept der SOA wurde entwickelt, um die heute dynamischen Geschäftsprozesse von Unternehmen kostengünstiger und schneller durch die IT abzubilden. Dabei stehen zum Teil neue, aber auch bereits bekannte Konzepte im Mittelpunkt einer SOA. Eine der zentralen Ideen ist die Modularisierung, die schon seit jeher eine Möglichkeit darstellt, Komplexität zu mindern und Wiederverwendung zu ermöglichen. Dazu werden funktionale Blöcke zusammengefasst und an den entsprechenden Stellen eingebunden. Neu ist beim SOA-Konzept, dass es kein die Applikation überspannendes Objektsystem mehr gibt. Dieses war Teil der bisher eingesetzten Techniken in verteilten Systemen wie Java2 Enterprise Edition (J2EE), Common Object Request Broker Architecture (CORBA) oder Component Object Model (COM). Da alle ihr eigenes zueinander inkompatibles Objektsystem einsetzten, stieß man spätestens an der Unternehmensgrenze auf Probleme. Es war nicht ohne weiteres möglich, externe Dienstleister ohne Schwierigkeiten und mit den nötigen Qualitäts- Standards in die eigene IT-Landschaft einzubinden. Es sei denn diese setzten auf die gleiche Technologie wie das eigene Unternehmen. Eine SOA weist eine Reihe von Merkmalen auf, um die Anforderungen an sie erfüllen zu können. Als erstes ist da die lose Kopplung zu nennen. Diese verspricht ein dynamisches Binden zur Laufzeit auf Dienstebene, d.h., die konkrete Implementierung für eine gewisse Funktionalität steht zur Entwicklungszeit nicht fest. Der Vorteil für ein solches Vorgehen ist eine hohe Flexibilität für zukünftige Veränderung und auch bzgl. der Auswahl der Dienste nach nicht funktionalen Kriterien. So könnte eine Anwendung, die die Bestellung von Rohstoffen für eine Firma übernimmt, denjenigen Zulieferdienst mit dem niedrigsten Tagespreis auswählen. Und das jeden Tag aufs Neue, ohne dass ein Entwickler Teile der Anwendung ständig neu implementieren muss. Um eine SOA mit loser Kopplung und dynamischem Binden realisieren zu können, bedarf es eines Verzeichnisdienstes, der zum Veröffentlichen durch den Dienstanbieter und zum Suchen durch den Dienstnutzer verwendet werden kann. Die Abbildung 2.1 zeigt das Zusammenspiel zwischen den 3 Akteuren. Die technische Unterteilung der Architektur in verschiedene Schichten zeigt Abbildung 2.2. Dabei bauen die waagerechten Schichten von unten nach 6

20 2.2. EINFÜHRUNG ZU WEBSERVICES Abbildung 2.1: Das SOA-Dreieck oben aufeinander auf, während die Suche nach Diensten und die Verhandlung von Richtlinien zwischen zwei Diensten auf allen Ebenen stattfindet. Die Beschreibung des Dienstes in Maschinen-verarbeitbarer Form ist ein weiteres wichtiges Kriterium für eine SOA. Sowohl die rechnergestützte Suche nach Diensten als auch das dynamische Binden von Diensten durch beliebige Anwendungen benötigen diese Eigenschaft. Der Einsatz von offenen Standards ist daher unerlässlich für eine SOA. Im Folgenden werden die wichtigsten Standards aus der Welt der Webservices, des Semantic Web und der Geoinformatik kurz vorgestellt. 2.2 Einführung zu Webservices Der Begriff Webservices umfasst eine Vielzahl von Standards, die zusammen eine lose gekoppelte Architektur von Diensten ermöglichen. Ihre Anfänge haben die Webservices im Jahr 2000, als im Mai die erste Spezifikation von SOAP 1 in der Version 1.1 vom World Wide Web Consortium (W3C) veröffentlicht wurde [BEK + 00] und im März des Folgejahres die Spezifikation von der Web Service Decription Language (WSDL) in der Version 1.1 [CCMW01] hinzukam. Damit waren Standards für die Beschreibung von Webservices und für die Kommunikation zwischen den Diensten vorhanden. Beide basieren auf der extended Markup Language (XML). Für die endgültige Verbreitung von Webservices fehlte noch der Verzeichnisdienst. 1 Früher war dies das Akronym für Simple Object Access Protocol, wurde aber mit der Version 1.2 abgeschafft. 7

21 2.2. EINFÜHRUNG ZU WEBSERVICES Abbildung 2.2: Der SOA-Stack nach [WCL05] Dieser wurde erstmals im Juni 2002 von der Organization for the Advancement of Structured Information Standards (OASIS) in der Version 1.0 herausgebracht und heißt UDDI. Laut W3C ist die Definition eines Webservices wie folgt: A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using Hypertext Transfer Protocol (HTTP) with an XML serialization in conjunction with other Web-related standards. (August 2003) Der Einsatz im Web zur Kommunikation von zwei Maschinen war der Ansatz zur Entwicklung von Webservices. Bis dahin wurde das Web ausschließlich zur Bereitstellung von multimedialen Inhalten zur Verarbeitung durch den Menschen mittels eines Browsers benutzt. Um das volle Potenzial des Internets auch für den maschinengestützten elektronischen Handel auszunutzen, 8

22 2.2. EINFÜHRUNG ZU WEBSERVICES war die Einführung von Webservices nötig. Die Spezifikation von offenen Standards spielt eine zentrale Rolle für die Funktionsfähigkeit von Webservices und damit für deren Akzeptanz und Verbreitung. Für die Standardisierung im Bereich der Internet-Techniken haben sich in den letzten Jahren mehrere Gremien etabliert. Diese sollen hier nur kurz genannt werden, mit einem Verweis auf deren Webseiten, wo man nähere Informationen zu den einzelnen Organisationen finden kann. W3C, OASIS, Internet Engineering Task Force (IETF), United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT), Der Standardisierungsprozess selbst ist nicht immer klar definiert. So ist es üblich in der Informatik Spezifikationen einzelner Gruppen oder Unternehmen aufgrund ihrer starken Relevanz für die IT-Industrie nachträglich durch eines der Gremien standardisieren zu lassen bzw. als Quasi-Standards gelten zu lassen [KF04]. Durch diesen dezentralen Charakter der Standardisierung kommt es dazu, dass teilweise mehrere Standards bzw. Spezifikationen zu einem Sachverhalt existieren. Gerade in der jungen Technologie der Webservices ist das sehr stark bemerkbar. Ein weiteres Problem ist der Standard selbst. Auf der einen Seite darf er nicht zu strikt definiert sein, um zukünftige Entwicklungen zuzulassen und ihn dennoch abwärtskompatibel gestalten zu können. Auf der anderen Seite führt eine zu ungenaue Spezifikation zu Spielraum für Interpretationen bei den Herstellern. Dadurch können zwei Implementierungen eines Standards dennoch inkompatibel sein [DJM05]. Dieser Problematik widmet sich die Arbeit der Web Services Interoperability Organization (WS-I) 2, welche keine eigenen Standards veröffentlicht, sondern die Anwendung der bestehenden Standards koordiniert und somit Richtlinien zur Entwicklung kompatibler Webservices erstellt. Die WS-I veröffentlicht Profile zu den verschiedenen Aspekten von Webservices. So gibt es neben dem Basic Profile, das sich mit der Verwendung der 2 9

23 2.2. EINFÜHRUNG ZU WEBSERVICES grundlegenden Standards (WSDL, SOAP) beschäftigt, noch das Attachments Profile, das Basic Security Profile und zukünftig auch noch das Reliable Secure Profile. In der vorliegenden Arbeit sind die Richtlinien des Basic Profile in der Version umgesetzt worden. Bei den nun folgenden Erläuterungen zu den einzelnen Spezifikationen sind an den entsprechenden Stellen Anmerkungen zum Basic Profile 1.1 vorhanden Schnittstellenbeschreibung: WSDL Die Beschreibung der Schnittstelle eines Webservices in Maschinen-lesbarer Form ist eine zentrale Aufgabe der Standards WSDL und WS-Policy. Erstere liegt seit März 2006 in der Version 2.0 beim W3C vor. In der vorliegenden Diplomarbeit ist noch mit dem alten Standard 1.1 gearbeitet worden. Dies liegt an der weiteren Verbreitung von Werkzeugen zum Umgang mit der alten Version von WSDL. Zudem stehen Konverter auf der Seite 4 des W3C bereit, die zukünftig bei ausreichender Verbreitung und Unterstützung des neuen Standards 2.0 leicht die Portierung auf diesen ermöglichen. Abbildung 2.3: Aufbau von WSDL 1.1 Somit wird hier nur kurz auf die WSDL 1.1 eingegangen. In Abbildung 2.3 sieht man den Aufbau eines WSDL-Dokuments. Dabei erfolgt eine Untertei- 3 die derzeitig aktuelle Version mit einem Final-Status

24 2.2. EINFÜHRUNG ZU WEBSERVICES lung der Beschreibung in einen konkreten und einen abstrakten Teil und in diese drei Bereiche: Was bietet der Webservice an? (abstrakt) Wie kann man ihn einbinden? (konkret) Wo ist er erreichbar? (konkret) Im Abschnitt <types/> werden die Datenstrukturen definiert, die in den in <message/> definierten Nachrichten verwendet werden. Zur Definition kann man XML-definierende Sprachen wie XML-Schema oder die Document Type Definitions (DTDs) benutzen, aber auch nicht XML-basierte Sprachen sind erlaubt. Die WSDL-Spezifikation empfiehlt den Einsatz von XML-Schema, welcher auch am weitesten verbreitet ist. Um aus den Nachrichten Operationen zu formen, benutzt man den Abschnitt <porttype/>. Dazu definiert man Operationen mit Hilfe eines Input- und eines Output-Elementes. Somit kann man vier verschiedene Arten von Operationen formen: One-Way, d.h., lediglich eine Input-Message Request-Response, d.h., auf eine Input- folgt eine Output-Message Solicit-Response, d.h., erst der Output, dann der Input Notification, d.h., die Operation besteht nur aus einer Ouput-Message Obwohl alle vier Typen in WSDL definiert werden dürfen, besteht durch die zur Verfügung stehenden Möglichkeiten zum Binden lediglich eine Unterstützung für die ersten beiden Arten von Operationen 5. Erst durch die Einführung der WS-Addressing Spezifikation lassen sich auch die beiden anderen Typen binden. Nachdem nun abstrakt definiert wurde, welche Operationen der Webservice anbietet, wird im Abschnitt <binding/> festgelegt, welches Protokoll unterstützt wird, d.h., wie die Kommunikation mit dem Dienst aussieht. Dabei ist es durchaus vorstellbar, mehrere unterschiedliche Protokolle für eine Operation anzubieten. Die WSDL-Spezifikation unterstützt über einen erweiterbaren Mechanismus unter anderem SOAP, HTTP oder Multipurpose Internet Mail Extensions (MIME). Entscheidet man sich für SOAP, so wie 5 inbound operations, d.h., der Input kommt zuerst 11

25 2.2. EINFÜHRUNG ZU WEBSERVICES alle in dieser Arbeit entstandenen Dienste, legt man zusätzlich noch das Transport-Protokoll fest. Zumeist ist das HTTP oder aber das Simple Mail Transfer Protocol (SMTP). Neben dem Protokoll und dem Transport wird im Binding-Teil auch noch die Enkodierung der Nachrichten festgelegt. Diese bestimmt, in welcher Form die definierten Teile (engl. part) der Nachricht bei der Kommunikation später serialisiert bzw. deserialisiert werden. Zur Verfügung stehen zwei Attribute mit je 2 Belegungen. Zum einen sind das RPC und DOCUMENT für das Attribute style. Erstere entspricht dem klassischen Remote Procedure Call und legt fest, dass im SOAP-Rumpf (engl. body) ein Kindelement mit dem Namen der aufzurufenden Methode enthalten ist, das dann wiederum die Parameter bzw. die definierten Teile enthält. Wählt man den Document-Style enthält der SOAP-Rumpf alle definierten Teile der Nachricht nacheinander als Kindelement, d.h., es werden lediglich XML-Dokumente ausgetauscht, deren Interpretation dann in der Implementierung des Dienstes erfolgt. Das zweite Attribut use hat die Werte LITERAL und ENCODING. Letzterer wurde in Verbindung mit der Angabe einer Enkodierung dazu genutzt, die zuvor abstrakt definierten Datentypen einer Nachricht auf die definierte Art zu serialisieren und dementsprechend auch wieder zu deserialisieren. Nach den Richtlinien des Basic Profiles der WS-I soll dieser Ansatz nicht mehr verwendet werden, weil er in der Vergangenheit zu Inkompatibilitäten geführt hat. Somit bleibt nur noch LITERAL übrig, welches die Datentypen nach den Regeln des definierenden XML-Schemas in normales XML de-/serialisiert. Im letzten Abschnitt <service/> werden nun Endpunkte (engl. port) definiert, an denen die zuvor erstellten Bindings erreichbar sind. Dabei handelt es sich um eine Adresse in einem Netzwerk, welche dem gewählten Transport- Protokoll entsprechen muss Kommunikation: SOAP Eines der Hauptprobleme bzgl. der Kommunikation, denen sich eine lose gekoppelte verteilte Architektur stellen muss, ist es, sämtliche inhärenten Hindernisse eines Netzwerkes zu überwinden. Dazu zählt die Heterogenität, aber auch Schutzmechanismen wie Firewalls. Hier setzt SOAP an. Es ist ein auf XML basierendes, unidirektionales und zustandsloses Kommunikations- Protokoll, welches die Semantik der ausgetauschten Nachrichten nicht interpretiert [WCL05]. 12

26 2.2. EINFÜHRUNG ZU WEBSERVICES SOAP spezifiziert Nachrichten zum Austausch von Daten. Eine Nachricht besitzt einen Umschlag (engl. envelope). Darin enthalten sind null oder mehrere Kopf-Elemente (engl. header) und ein Körper-Element (engl. body). Eine Nachricht besitzt einen Sender, einen ultimativen Empfänger und eine beliebige Anzahl an Knoten (engl. node), die die Nachricht verarbeiten können und sie dann zum Ziel routen. Im body befindet sich die Nutzlast (engl. payload) der Daten, während die header Informationen für die Zwischen- Knoten enthalten können. Damit folgt es dem Aufbau der anderen gängigen Kommunikations-Protokolle. Für den eigentlich Transport wird SOAP an ein bestehendes Protokoll wie HTTP oder SMTP gebunden. Damit lassen sich auch installierte Firewalls ohne weiteren Aufwand überwinden. Die Definition des Bindings legt fest, wie SOAP mit Hilfe des darunterliegenden Protokolls versendet wird. So wird beispielsweise bei HTTP ein GET - oder ein POST -Request mit dem darin enthaltenen SOAP-Umschlag generiert und gesendet Verzeichnisdienste: UDDI Verzeichnisdienste sind ein wesentlicher Bestandteil in SOAs und somit auch bei den Webservices. UDDI entstammt einer gemeinsamen Entwicklung von Ariba, Microsoft und IBM. Es besteht aus einem oder mehreren replizierten, zentralen Verzeichnissen und verschiedenen APIs, welche in Form von Diensten Funktionalität zum Veröffentlichen und Suchen von Einträgen bereitstellen. Des Weiteren gibt es Webservices für die Authentisierung von Clients, zum Replizieren der Verzeichnisse sowie eine Monitoring API, um über Änderungen informiert werden zu können. Es gibt folgende drei Versionen: UDDIv1, UDDIv2 und UDDIv3. Letztere wurde im Oktober 2004 veröffentlicht und erweitert die zweite Version hauptsächlich um Funktionen für eine bessere Replizierung von Einträgen zwischen Registries, um digitale Signaturen für gespeicherte Informationen und um die Unterstützung von Richtlinien zum flexiblen Einsatz in unterschiedlichen Kontexten [HLMR]. Die vorliegende Implementierung verwendet die Version 2 [BDE + 02], weil die genannten Verbesserungen nicht unmittelbar benötigt werden für die gestellten Anforderungen. Des Weiteren ergab sich die Version aus der Auswahl der benutzten Werkzeuge, die die Version 3 noch nicht unterstützen. 13

27 2.2. EINFÜHRUNG ZU WEBSERVICES In einem UDDI-Verzeichnis werden Webservices durch vier Informationen charakterisiert [BEH + 02]. Ein businessentity-element beschreibt den Namen, Adresse und sonstige Kontaktdaten einer Organisation, die Webservices bereitstellt. Ein businessservice-element fasst eine Gruppe von zusammenhängenden Webservices zusammen, die durch eine Organisation zur Verfügung gestellt werden. Ein bindingtemplate-element informiert über die technischen Details zur Nutzung eines Webservices und wird dazu einem businessservice- Element zugeordnet. Ein tmodel 6 -Element ist ein generischer Container zur Speicherung jeglicher Arten von Spezifikationen (z.b. WSDL, Semantik, Klassifikation). Abbildung 2.4 zeigt die Beziehung der vier Elemente zueinander. Zudem ist ein fünftes Element zu sehen, mit dessen Hilfe sich verschiedene businessentity Einträge in Beziehung setzen lassen. Das ist beispielsweise bei großen Konzernen sinnvoll, dessen Tochterunternehmen sich selbstständig in die Registry eintragen und somit dann untereinander verbunden werden können. Jedes definierte Element bekommt einen eindeutigen Schlüssel, über den es dann von anderen Einträgen referenziert wird. Die Suche ist möglich nach Namen, Schlüsseln, Werten aus zuvor definierten Kategorien oder auch nach einer kompletten Spezifikation (z.b. Welches Unternehmen implementiert dieses WSDL-Dokument?). Dazu werden die tmodel, die die gesuchten Spezifikationen beschreiben in ein sogenanntes Category Bag gespeichert und in der Anfrage übergeben. Letzteres wird auch als technischer Fingerabdruck bezeichnet, da alle tmodel zusammen, den oder die gewünschten Entitäten hinreichend genau beschreiben. UDDI hat einige vordefinierte Kategorien für die Einordnung von Unternehmen und deren Dienste nach Geschäftszweigen oder nach Standorten (z.b. ISO ). Des Weiteren ist es erlaubt, eigene Kategorien einzuführen und für die Klassifikation zu benutzen. 6 steht für technisches Modell

28 2.2. EINFÜHRUNG ZU WEBSERVICES Abbildung 2.4: Das UDDI Informationsmodell aus [BEH + 02] Nichtfunktionale Dienstbeschreibung und -komposition Neben den beschriebenen Basis-Spezifikationen kommen weitere für die Beschreibung von Quality of Service (QoS) Aspekten und für die Dienstkomposition zum Einsatz. Unter ersterem fasst man WS-ReliableMessaging, WS- Transaction und WS-Security zusammen. An den Namen erkennt man bereits den jeweiligen Zweck der Spezifikationen. Sie werden benötigt, um den Einsatz von Webservices in sensiblen Geschäftsprozessen zu ermöglichen. Die Dienstkomposition spielt eine wesentliche Rolle für das Design von SOAs. Sie ermöglicht die Wiederverwendung von atomaren Diensten für die Erstellung von neuen Anwendungen auf eine flexible Art und Weise. Man unterteilt die Sprachen zur Beschreibung von Dienstkompositionen in zwei Kategorien: Orchestration und Choreography. BPEL ist eine Sprache, die zur ersten Kategorie gehört. Sie befindet sich derzeit im Standardisierungsprozess 8 bei der OASIS. Weiterführende Informationen können dort eingeholt werden. 8 home.php?wg abbrev=wsbpel 15

29 2.3. STANDARDISIERUNG IN DER GEOINFORMATIK 2.3 Standardisierung in der Geoinformatik Der Einsatz von Standards in einer SOA ist nicht nur auf technische Bereiche beschränkt, sondern ist auch für die implementierte Fachlichkeit sehr nutzbringend. Da die Funktionsbibliothek im Bereich der Geoinformatik anzusiedeln ist, werden hier nachfolgend kurz die wichtigsten Gremien und deren Standards aufgeführt. Das Technical Committee (TC) 211 der ISO beschäftigt sich mit der Standardisierung im Bereich der Geoinformatik. Die Standards mit den Nummern 191xx spezifizieren eine Infrastruktur und die benötigten Dienste zur Handhabung von geographischen Informationen. Dabei werden das Management, die Erfassung, die Verarbeitung, die Analyse, der Zugriff, die Präsentation und die Übertragung abgedeckt [KF04]. Neben der ISO hat das OGC erheblichen Anteil an der Entwicklung von Standards für die geographische Datenverarbeitung. Als externes Liaison Member wirken dessen Experten in den Arbeitsgruppen des TC 211 bei der Erstellung der ISO-Standards mit. So ist die GML (ISO 19136) eine Umsetzung der abstrakten ISO-Standards, speziell von ISO (Spatial Schema) und ISO (Schema for coverage geometry and functions), durch das OGC. Eine weitere wichtige Organisation mit Einfluss auf die Standardisierung in der Geoinformatik ist die European Petroleum Survey Group (EPSG). Da die Suche und das Erschließen von Ölvorkommen einhergeht mit der Positionsbestimmung in vielen Teilen der Welt, hat sich im Laufe der Zeit erhebliches Wissen im Bereich der Koordinaten-Operationen angesammelt. Die einzelnen Firmen haben sich in der EPSG organisiert und ihr Wissen zusammen getragen, sodass sie voneinander profitieren können. Die EPSG hat die Domäne der Koordinaten-Operationen durch klar definierte Begriffe und deren Beziehungen zueinander abgegrenzt. Des Weiteren wurde ein Datenbank erstellt, die die Informationen der Domäne in geordneter Form vorhält und den Zugriff darauf ermöglicht. Zu den Informationen gehören die Definition von Einheiten, Koordinatensystemen und deren Achsen, geographische Daten, Ellipsoide, Koordinaten-Referenz-Systeme und mathematische Operationen für die Konversion und Transformation. Die einzelnen Begriffe werden in Beziehung zueinander gesetzt und mit konkreten Zahlen-Werten unterlegt. Ein Beispiel dafür ist die Transformation von Koordinaten in ED50 nach WGS84. Ersteres Koordinaten-Referenz- 16

30 2.3. STANDARDISIERUNG IN DER GEOINFORMATIK System basiert auf dem Ellipsoid International 1924 und dem Datum European Datum 1950, letzteres auf dem Ellipsoid WGS84 und dem World Geodetic System Die Transformation beinhaltet die Verschiebung des Ursprungs des Ellipsoiden, d.h., es liegt die geozentrische Translation als mathematische Operation zugrunde. Der konkrete Translations-Vektor für diese Transformation ist in einer Tabelle der Datenbank abgelegt und wurde zumeist empirisch ermittelt. Er ist auch nicht gleich für das gesamte Gebiet von ED50, sondern wurde als beste Lösung für kleinere Regionen bestimmt. So gibt es für die angesprochene Transformation bereits 39 verschiedene Konfigurationen in der Datenbank, die sich nicht nur in den Parametern,sondern auch in den verwendeten mathematischen Operationen unterscheiden können. Zur besseren Indizierung hat die EPSG für alle definierten Begriffe eine Id vergeben, angefangen bei den Einheiten bis hin zu Koordinaten-Operationen. Dabei handelt es sich um einen positiven, ganzzahligen Wert. Dieser wird in dieser Arbeit aufgegriffen und für zusätzlich definierte Begriffe erweitert. Genaueres dazu folgt im Abschnitt 5.2 auf Seite Geography Markup Language (GML) Die GML [CDL + 04] wurde anfänglich vom OGC entwickelt und befindet sich derzeit im Standardisierungsprozess der ISO. Sie dient dem Transport und der Speicherung geographischer Daten und übernimmt somit eine wichtige Position für die Interoperabilität in der Geoinformatik. Auch in dieser Arbeit wurde sie als Sprache zur Übermittlung der Parameter und Rückgabewerte der Funktionen gewählt. GML lässt sich gut in einem WSDL-Dokument verwenden, da sie auf XML basiert und in XML-Schema beschrieben ist. Das gesamte Schema der GML ist sehr umfangreich und daher für eine bessere Anwendbarkeit in Module mit gewissen Schwerpunkten unterteilt. In Abbildung 2.5 ist diese Unterteilung und die Beziehung der Module untereinander zu sehen. Da auch die einzelnen Module nicht immer komplett in einer Anwendung benötigt werden, sieht die Spezifikation die Bildung von Profilen vor. Dabei handelt es sich um gültige Untermengen der Sprache, die man durch Weglassen der nicht gebrauchten Elemente und Typen erhält. Da das generische Vokabular der GML in der Regel nicht die spezifischen Anforderungen einer Anwendung abdeckt, wird in der Spezifikation die Er- 17

31 2.3. STANDARDISIERUNG IN DER GEOINFORMATIK Abbildung 2.5: Die thematisch abgegrenzten Module der GML [CDL + 04] 18

32 2.4. GRUNDLAGEN DES SEMANTISCHEN WEBS stellung eines Application Schema definiert. Dieses erweitert ein Profil um eigene Definition und muss dafür seinen eigenen Namensraum verwenden. Im Listing A.1 auf Seite 79 sieht man als Beispiel das Application Schema, das in dieser Arbeit verwendet wird. Das zugrunde liegende Profil ist aus Platzgründen lediglich auf der beigelegten CD zu sehen. 2.4 Grundlagen des semantischen Webs Den Begriff des Semantic Web gibt es schon seit Ende des letzten Jahrzehnts. Er beschreibt die Vision eines verbesserten Webs in Form von Inhalten, die nicht nur vom Menschen, sondern auch von Maschinen verarbeitet werden können. Dadurch erhöht sich der Nutzen des Internet für dessen Anwender. Ein Beispiel ist die ungenaue Suche nach Stichwörtern im klassischen World Wide Web (WWW), die durch intelligente Agenten im Semantic Web verbessert werden soll. Abbildung 2.6: Semantic Web Stack (W3C) Die Grundvoraussetzung für diese Vision ist eine Maschinen-verarbeitbare Darstellung von Wissen über sämtliche multimediale Ressourcen im Web. Dazu wurde aufbauend auf XML und Uniform Resource Identifiers (URIs) ein Stapel an Sprachen entwickelt. Abbildung 2.6 zeigt die einzelnen aufeinander aufbauenden Schichten des Semantic Web. Mit den Sprachen soll die Bildung von Ontologien ermöglicht werden. Genaueres dazu und zu den Hauptbestandteilen des Stack folgen in den nächsten Abschnitten. 19

33 2.4. GRUNDLAGEN DES SEMANTISCHEN WEBS Abbildung 2.7: Drei einfache Aussagen als RDF-Tripel RDF, RDF-S und OWL Die Standardisierung vom Resource Description Framework (RDF) [KC04] und RDF Schema (RDF-S) [BG04] wird durch die RDFCore Working Group 9 und OWL [SD04] durch die Web Ontology Group 10 des W3C geleitet. Das RDF ist ein Modell zum Beschreiben von beliebigen Ressourcen. Diese beinhalten sowohl physische Dinge als auch Konzepte, die lediglich in der menschlichen Gedankenwelt existieren. Kurzum alle Dinge, für die es einen Namen gibt, lassen sich beschreiben. Dazu ist im RDF ein Tripel, bestehend aus Subjekt(zu beschreibende Ressource), Prädikat(Beziehung zu einer anderen Ressource) und Objekt(Wert des Subjekts bzgl. des Prädikats) definiert. Die Tripel werden als Aussagen bezeichnet, d.h., man macht mit Hilfe des Prädikats und des Objekts eine Aussage über das Subjekt. Drei einfache Aussagen sind beispielsweise: Ein 3-dimensionales, kartesisches Koordinatensystem hat eine X-Achse und hat eine Y-Achse und hat eine Z-Achse. Abbildung 2.7 zeigt die graphische Notation dieser drei Aussagen. Das Subjekt steht am Pfeilanfang, das Prädikat direkt am Pfeil und das Objekt am Pfeilende. Zur Benennung aller drei Bestandteile werden URIs verwendet. Das Objekt kann zudem auch ein Literal sein, d.h., ein atomarer Wert mit einem bekannten Datentyp (z.b. String, Integer). Die hier gezeigten Beispiele sind aus Platzgründen ohne ihren Namensraum dargestellt. Man sieht also nur den lokalen Teil der URI. Die vollständige Bezeichnung für das Koordinatensystem ist http: // wwwiuk. informatik. uni-rostock. de: 8091/ ws/ GeoFunctions/ owl/ epsgdefinitions. owl# CartesianCS2D. Die durchgängige Verwendung von URIs ermöglicht es, auch ein Prädikat oder ein Objekt (außer ein Literal) in einer neuen Aussage als Subjekt zu betrachten. Dadurch ergibt sich ein Geflecht aus Dingen und deren Beziehun

34 2.4. GRUNDLAGEN DES SEMANTISCHEN WEBS Abbildung 2.8: Die Verknüpfung mehrerer Aussagen gen zueinander. Wie in Abbildung 2.8 zu sehen ist, wurde das obige Beispiel ergänzt um die Aussagen Das 3-dimensionale, geozentrische Koordinaten- Referenz-System WGS84 ist definiert durch das Datum World Geodetic System 1984 und durch ein 3-dimensionales, kartesisches Koordinatensystem. Das RDF stellt einige vordefinierte Begriffe zur Verfügung. Mit Hilfe des Prädikats type lässt sich z.b. eine einfache Einteilung in Klassen realisieren. So ist das Objekt einer Aussage mit diesem Prädikat die Klasse und das dazugehörige Subjekt deren Instanz. Letztere wird im Bereich der Ontologien auch Individuum genannt. Ein anderer Ausdruck für das Prädikat ist die Eigenschaft (engl. property). Mit Hilfe der Klasseneinteilung ist es nun möglich, die Begriffe aus dem ersten Beispiel als Individuen allgemeinerer Klassen zu betrachten. Abbildung 2.9 zeigt die Einführung der Klasse CartesianCS, zu der sowohl das 2- als auch das 3-dimensionale kartesische Koordinatensystem gehört. Ähnlich verhält es sich mit der Klasse CoordinateSystemAxis, die als Verallgemeinerung aller Koordinatensystem-Achsen fungiert. Abbildung 2.9: Einführung von Klassen und deren Instanzen 21

35 2.4. GRUNDLAGEN DES SEMANTISCHEN WEBS Um nun das einfache Klassenkonzept zu erweitern und Domänen-spezifische Vokabulare einführen zu können, gibt es RDF-S. Diese Erweiterung des RDF- Vokabulars ermöglicht, ähnlich wie bei den objektorientierten Sprachen, die Bildung von Klassen-Hierarchien. Damit können die für eine Klasse definierten Eigenschaften auch vererbt werden. Im Gegensatz zur Objektorientierung wird bei RDF-S ein Eigenschaften-zentrierter Ansatz verfolgt, d.h., bei der Definition der Eigenschaften werden diesen Klassen zugewiesen. Letzteres wird in Abschnitt 5.3 auf Seite 52 noch einmal genauer gezeigt. In Abbildung 2.10 ist die Einführung einer Oberklasse von CartesianCS zu sehen. Die Klasse CoordinateSystem fasst alle Arten von Koordinaten- Systemen zusammen. Als zusätzliches Beispiel wurde hier noch die Klasse der polaren Koordinaten-Systeme definiert. Zugleich wurde die Eigenschaft has CoordinateSystemAxis ebenfalls verallgemeinert und an oberster Stelle in der Hierarchie verankert, sodass alle Unterklassen und die Individuen diese erben können. Abbildung 2.10: Einführung von Klassenhierarchien mit RDF-S Es werden neben weiteren die folgenden Begriffe 11 und deren Bedeutung definiert: Class ist die Klasse aller Klassen Property ist die Klasse aller RDF Eigenschaften (Prädikate) Resource ist die Klasse aller Ressourcen range legt den Wertebereich einer Eigenschaft fest 11 bei großgeschriebenen Begriffen handelt es sich um Klassen bei kleingeschriebenen um Eigenschaften 22

36 2.4. GRUNDLAGEN DES SEMANTISCHEN WEBS domain legt den Definitionsbereich einer Eigenschaft fest subclassof ermöglicht die Bildung von Klassen-Hierarchien Wie gesehen, ermöglicht RDF-S die Bildung von Taxonomien in verschiedenen Domänen. Es wurden aber eine Reihe von Anwendungsfällen für das semantische Web von der Web Ontology Working Group identifiziert, die eine mächtigere Sprache zur Beschreibung von Ontologien benötigen [AvH04]. Der Begriff Ontologie stammt aus der Philosophie und beschreibt die Lehre vom Sein, d.h., die Ordnungs-, Begriffs- u. Wesensbestimmungen des Seienden. Fehlende Konzepte bei RDF-S sind u.a.: Kardinalitäten Definition von disjunkten Klassen Boolsche Operatoren (z.b. Vereinigung, Durchschnitt) für die Kombination bestehender zu neuen Klassen Definition von inversen oder transitiven Prädikaten Mit OWL, die aus der DARPA Agent Markup Language (DAML) und der Ontology Interchange Language (OIL) hervorgegangen ist, wurde eine Sprache standardisiert, die all die geforderten Konzepte einführt. Die formale Semantik der OWL basiert teilweise auf der Beschreibungslogik und unterstützt somit das Maschinen-gestützte Schlussfolgern. Dadurch ist es möglich, automatisch die Konsistenz einer Ontologie zu überprüfen, eine Klassifizierung der beschriebenen Konzepte vorzunehmen (Bildung einer Taxonomie) und die Zugehörigkeit von Instanzen zu gewissen Klassen zu ermitteln. OWL existiert in 3 Dialekten : OWL-Full, OWL-DL, OWL-Lite. Dabei unterscheiden diese sich in der Ausdrucksfähigkeit und dadurch aber auch in der Entscheidbarkeit. Während OWL-Full die mächtigste Kategorie darstellt und man unter Umständen eine Ontologie hat, die automatisches Schlussfolgern nicht zulässt, sind in OWL-Lite viele Konstrukte verboten, sodass sicher gestellt wird, dass das Schlussfolgern in akzeptabler Zeit geschehen kann. Welchen Dialekt man benutzt, hängt von der Domäne ab, die man beschreiben muss und von den Anforderung an die Ontologie. OWL-DL 12 ist entscheidbar und bietet auch eine ausreichende Mächtigkeit. 12 das DL steht für Description Logic 23

37 2.4. GRUNDLAGEN DES SEMANTISCHEN WEBS Abbildung 2.11: Defintion inverser Eigenschaften mit OWL In Abbildung 2.11 sieht man die Verallgemeinerung des Beispiels aus Abbildung 2.8. Die Aussage ist, dass ein Koordinaten-Referenz-System immer durch ein Datum und ein Koordinaten-System definiert ist. Andersherum kann man ebenso feststellen, dass ein Datum bzw. ein Koordinaten-System immer mit mindestens einem Koordinaten-Referenz-System assoziiert ist. Diese sich gegenseitig bedingenden Aussagen können durch die Definition zweier Eigenschaften, die zueinander invers sind, mit Hilfe von OWL ausgedrückt werden OWL-S Die bestehenden Standards bei Webservices eignen sich vorrangig zur syntaktischen Beschreibung von Diensten. Die Bedeutung des Dienstes und seiner Ein- und Ausgabedaten muss derzeit noch von einem Entwickler erschlossen und verarbeitet werden und bleibt der Maschine verwehrt. Diese Lücke soll u.a. durch die Anwendung von OWL geschlossen werden. Dazu wurde eine Ontologie zur Beschreibung speziell von Webservices erstellt. Unter dem Namen OWL for Services (OWL-S) [MBH + 04] hat die Defense Advanced Research Projects Agency (DARPA) diese veröffentlicht. Die Abbildung 2.12 zeigt die oberste Ebene der Ontologie. Die Wurzel ist die Service Klasse, die über jeweils ein Property mit dem ServiceProfile, dem ServiceModel und dem ServiceGrounding verbunden ist. OWL-S wurde entwickelt, um die Suche, die Komposition, die Ausführung 24

38 2.4. GRUNDLAGEN DES SEMANTISCHEN WEBS Abbildung 2.12: Oberste Ebene der Service Ontologie [MBH + 04] sowie das Monitoring von Webservices automatisieren zu können. Dadurch soll es autonomen Software-Agenten gelingen, beliebige Aufgaben durch die Auswahl der entsprechenden Dienste zu erledigen. Das ServiceProfile dient dabei der Beschreibung des Dienstes nach dem Input Output Precondition Effects (IOPE) Modell. Abbildung 2.13 zeigt die entsprechende Ontologie. Mit Hilfe des Profils ist eine ausgereiftere Suche nach Diensten möglich, da durch die Klassen und deren Beziehungen zueinander die Semantik von Diensten besser erschlossen werden kann. ServiceProcess beschreibt die Interaktion mit einem Dienst. Es dient der automatischen Komposition von Diensten, ist dabei aber selber kein ausführbares Programm, sondern spezifiziert lediglich die möglichen Wege, auf denen ein Dienstnutzer mit dem Dienst interagieren kann. Das ServiceGrounding bietet ein generisches Konzept zur Bindung an eine bestehende Dienst- Beschreibungssprache. Derzeit ist dies lediglich für WSDL genau spezifiziert. Mit Hilfe des Groundings werden die abstrakten Konzepte des Profils und des Prozesses auf die konkrete technische Beschreibung eines Dienstes abgebildet. Die Abbildung 2.14 zeigt das nochmal modellhaft. 25

39 2.4. GRUNDLAGEN DES SEMANTISCHEN WEBS Abbildung 2.13: Ontologie über das Service Profil [MBH + 04] SPARQL - Eine Anfragesprache für RDF-basierte Wissensbasen In der zwischenmenschlichen Kommunikation kann der Transfer von Wissen durch eine Anfrage ausgelöst werden. Um dieses Konzept auch in der Maschinenwelt anwenden zu können, bedarf es einer Anfragesprache, die es ermöglicht, die in einer Ontologie hinterlegten Informationen zu extrahieren. SPARQL Protocol and RDF Query Language (SPARQL) ist eine solche Anfragesprache für RDF-basierte Wissensbasen. Sie liegt bei der RDF Data Access Working Group 13 des W3C aktuell als ein Working Draft vor [PS06]. Sie ist Daten-orientiert und findet somit nur direkt in der Ontologie gespeicherte RDF-Tripel, d.h., die Sprachdefinition enthält keinen Inferenzmechanismus. Listing 2.1: Eine mögliche SPARQL-Anfrage 1 PREFIX g e o :<h t t p : //wwwiuk. i n f o r m a t i k. uni r o s t o c k. de:8091 /ws/ GeoFunctions / owl / e p s g D e f i n i t i o n s#> 2 SELECT? coordsystem 3 WHERE 4 {? coordsystem r d f : t y p e geo:coordinatesystem. 5? coordsystem geo: has CoordinateSystemAxis geo: GeocentricX } Listing 2.1 zeigt eine mögliche Anfrage an die kleine Beispiel-Ontologie, die

40 2.4. GRUNDLAGEN DES SEMANTISCHEN WEBS Abbildung 2.14: ServiceGrounding, Abbildung von OWL-S auf WSDL [MBH + 04] in Abschnitt sukzessiv erstellt wurde. Zunächst wird ein PREFIX definiert, den man später in der Anfrage verwenden kann. Danach folgen nach dem SELECT die gebundenen Variablen der Anfrage. Das sind diejenigen, deren Wert als Ergebnis ausgegeben werden soll. Im Unterschied dazu kann man weitere ungebundene Variablen als eine Art Platzhalter in den where- Klauseln definieren, deren Endbelegung nicht ausgegeben wird. Im letzten Abschnitt nach WHERE folgt die Angabe verschiedener Kriterien in Form von RDF-Tripeln, die die möglichen Werte für die gesuchte Variable beschränken. In diesem Beispiel werden alle Individuen der Klasse CoordinateSystem gesucht (Zeile 4), die eine Koordinaten-Achse vom Typ GeocentricX haben (Zeile 5). Als Ergebnis dieser Anfrage erhält man die beiden Instanzen CartesianCS2D und CartesianCS3D. Ersterer würde wegfallen, wenn man den Typ in Zeile 5 auf geo:geocentricz ändert. 27

41 Kapitel 3 Verwandte Arbeiten Die Standardisierungsaktivitäten der ISO und des OGC zeigen das internationale Interesse an der vereinheitlichten Darstellung von geographischen Informationen. Die Umstellung auf Dienst-orientierte Anwendungen, die über ein Netzwerk zur Verfügung gestellt werden ist dabei ein zentrales Thema. Dies ermöglicht die Komposition von den verschiedensten einfachen Diensten zu beliebigen, komplexen geographischen Informationssystemen. Im folgenden sollen hier zwei Projekte kurz vorgestellt werden. Das ist zum einen der Geoserver, der die Referenzimplementierung des Web Feature Service (WFS) [V + 05] darstellt und zudem noch die Web Map Service (WMS) [dlb + 06] Spezifikation implementiert. Zum anderen handelt es sich um Projekte aus dem Bereich der Semantic Webservices, die andere Ansätze als OWL-S verfolgen. Weiterführende Informationen sind auf den angegebenen Webseiten zu erhalten. 3.1 Das Projekt Geoserver Der Geoserver 1 implementiert die WFS und WMS Spezifikation des OGC und ermöglicht somit das Speichern und Editieren sowie das Darstellen von geographischen Daten. Die Zielstellung von diesem Projekt ist es, das geospatiale Web zu ermöglichen. Dabei handelt es sich analog zum WWW um ein Netzwerk aus Servern, die Informationen speziell aus dem geographischen Bereich bereitstellen und verarbeiten können. Die Darstellung von Karten

42 3.2. FRAMEWORKS FÜR SEMANTISCHE WEBSERVICES sowie das Anlegen von großen Datenbanken mit geographischen Daten in einem einheitlichen Format sind dabei nur zwei Aspekte. Der Server ist eine Opensource Implementierung und soll für das geospatiale Web die Stellung einnehmen, die der Apache Webserver für das WWW hat. Dies ermöglicht ein einfaches Partizipieren für jedermann und somit eine große Community, die die Entwicklung im Bereich der geographischen Informationsverarbeitung voranbringen soll. 3.2 Frameworks für semantische Webservices Im Abschnitt wurde mit OWL-S eine Spezifikation vorgestellt, die für die semantische Erweiterung von Webservices eingesetzt wird. Da in dem Bereich momentan sehr aktiv geforscht wird, gibt es mit Web Service Modeling Ontology (WSMO) 2 und Managing End-To-End OpeRations: for web Services (METEOR-S) 3 zwei alternative Ansätze. Diese sollen im Folgenden nur kurz vorgestellt werden WSMO WSMO ist ein konzeptioneller Unterbau zur Beschreibung von semantischen Webservices. Sie ist ein Projekt der European Semantic Systems Initiative (ESSI) 4, welche wiederum die Bündelung mehrerer europäischer Forschungsprojekte im Bereich von semantischen Systemen ist. Die Web Service Modeling Language (WSML) 5 setzt die WSMO um und formalisiert sie somit. Letztlich wird mit der Web Service Modelling execution environment (WSMX) noch eine Ausführungsumgebung für Dienste, die nach der WSMO beschrieben sind, definiert. Abbildung 3.1 veranschaulicht noch einmal die Beziehungen der drei Teilprojekte. Das Ziel dieser Initiative ist es, die Modellierung von Geschäftsprozessen mit Hilfe von semantisch angereicherten atomaren Diensten zu automatisieren. Anschließend kann mit dem Framework der Prozess ausgeführt werden und auch ein Monitoring ist möglich

43 3.2. FRAMEWORKS FÜR SEMANTISCHE WEBSERVICES Abbildung 3.1: Die Beziehung der verschiedenen WSMO-Projekte METEOR-S METEOR-S ist ein Projekt des Large Scale Distributed Information Systems (LSDIS) Lab der Universität von Georgia. Es umfasst eine Reihe von Arbeiten für die semantische Beschreibung von Webservices. Es wurde mit WSDL-S eine Erweiterung von WSDL entwickelt, die über Annotationen die herkömmliche Dienstbeschreibung mit semantischen Formulierungen verbindet [AFM + 05]. Letztere können dabei in verschiedenen Repräsentationen vorliegen. So ist die Einbindung von Ontologien in OWL möglich oder auch solche, die mit der WSMO verfasst wurden. Weiterhin wurde mit dem METEOR-S Web Service Annotation Framework (MWSAF) eine Umgebung geschaffen, die Algorithmen für ein semiautomatisches Annotieren von bestehenden Dienstbeschreibungen bereitstellt. Dieses soll für den Übergang von klassischen Webservices zu semantischen Webservices genutzt werden [POSV04]. Durch den rechnergestützten Erweiterungsmechanismus verspricht man sich eine praktikablere Einführung als von den anderen existierenden Frameworks. Um eine volle Abdeckung des gesamten Webservice Lebenszyklus zu erreichen, bietet das METEOR-S Projekt noch die METEOR-S Web Services Discovery Infrastructure (MWSDI) als Erweiterung des UDDI Standards. Damit können die semantischen Annotationen bei der Suche nach Webservices verwendet werden [VSS + 05]. Und letztlich gehört auch noch das METEOR-S Web Service Composition Framework (MWSCF) dazu, welches die Komposition von Webservices zu Prozessen und deren Ausführung unterstützt [SMSV 5]. 30

44 Kapitel 4 Eine Dienste-basierte geographische Funktionsbibliothek Im Rahmen vorangegangener Studien- und Diplomarbeiten im Kontext der LBSs war stets die Nutzung grundlegender, geographischer Funktionen, wie z.b. Koordinatentransformationen oder Richtungs- und Entfernungsberechnung, nötig. Die Entwicklungen wurden in verschiedenen Programmiersprachen durchgeführt und forderten dadurch die Anwendung unterschiedlicher geographischer Funktionsbibliotheken zur Berechnung von grundsätzlich gleichen Sachverhalten. Zudem wurde nach einem Weg gesucht, die geographischen Funktionen auch auf Ressourcen-armen Geräten nutzen zu können. Kern der Arbeit ist es, eine Funktionsbibliothek für geographische Funktionen bereitzustellen, deren API in den meisten Programmiersprachen genutzt werden kann. Zusätzlich soll die Nutzung dieser API für einen Entwickler durch eine Maschinen-gestützte Suche benötigter Funktionen erleichtert werden. Um den Suchprozess noch zu verbessern, wird eine Wissensbasis mit Hilfe einer Ontologie erstellt. Diese beschreibt das Wesen der Domäne der geographischen Funktionen, d.h., welche Begriffe gibt es und wie stehen die in Beziehung zueinander. Dieses Kapitel umfasst die Idee und ein Konzept zur Umsetzung. Vor der Erläuterung wird noch eine kurze Motivation gegeben. 31

45 4.1. MOTIVATION 4.1 Motivation Die Beherrschung immer komplexerer Softwaresysteme geht einher mit dem Konzept der Modularisierung. Dabei werden atomare Bestandteile des Systems separat entworfen, implementiert und getestet. Die getrennte Implementierung mit anschließendem Test erfordert eine getrennte Übersetzung und die spätere Einbindung zur Laufzeit der Anwendung. Der Vorteil ergibt sich aus der Komposition der einzelnen stabilen Module, welche die Fehlersuche vereinfachen oder sogar ganz vermeiden können. Außerdem erhält man optimierte effiziente Software für spezielle Problemstellungen [FKV95]. Funktionsbibliotheken haben sich als Mittel der Modularisierung lange bewährt und liegen für zahlreiche Aufgaben in den verschiedenen Programmiersprachen vor. Sie speichern neben der implementierten Funktion auch alle weiteren wichtigen Informationen zum korrekten Einbinden [Dau85]. Die Hauptziele bei der Entwicklung einer Funktionsbibliothek sind nach [FKV95] die Anwendbarkeit, die Effizienz, eine einfache Nutzbarkeit sowie eine einfache Wartung. Abbildung 4.1 zeigt zwei Sichten auf eine Funktionsbibliothek. Zum einen gibt es die Entwicklungsphase. Während dieser geht es um die Auswahl der benötigten Funktionen aus der API und die Einbettung in den Code. Zum anderen geht es um das Laufzeitverhalten der Bibliothek. Je nach Programmiersprache liegt die eingebundene Funktion dann in kompilierter oder interpretierbarer Form vor. Sie wird aufgerufen und liefert im Fall einer mathematischen Funktion ihr Ergebnis zurück, welches dann in der weiteren Abarbeitung verwendet wird. Dadurch ergeben sich die Anforderungen an die Funktionsbibliothek, die ebenfalls in der Abbildung 4.1 zu sehen sind. Während zur Laufzeit die Performanz und die Stabilität im Vordergrund stehen, geht es zur Entwicklungszeit um die gute Dokumentation der API. Letztere ist gerade im Opensource- Bereich oft unvollständig oder hält nicht mit den herausgegebenen Releases Schritt, sodass Code-Beispiele nicht mehr funktionieren, da Klassen eventuell nicht mehr existieren oder deren Schnittstelle sich verändert hat. Dies kann zu einem erschwerten Einsatz der Funktionsbibliothek und damit auch zu längeren Entwicklungszeiten und letztlich dadurch zu höheren Kosten führen. Weiterhin ist durch falschen Gebrauch der Funktionen auch die Stabilität der Anwendung zur Laufzeit sowie die Korrektheit der Ergebnisse gefährdet. Letzteres bedingt höhere Testaufwände und damit auch wieder 32

46 4.1. MOTIVATION Abbildung 4.1: Zwei Sichten auf eine Funktionsbibliothek steigende Kosten. Eine Maschinen-gestützte Suche von den benötigten Funktionen der Bibliothek kann helfen, diese Probleme zu lösen. Ein weiterer bestehender Nachteil, resultierend aus der vorherrschenden Heterogenität bei Systemen und Programmiersprachen, ist die Abweichung der Ergebnisse mathematisch identischer Methoden durch unterschiedliche Genauigkeiten während des Berechnungsprozesses. Somit ist ein Vergleich von Ergebnissen nur innerhalb der begrenzten Anwendung einer einzigen Funktionsbibliothek gültig. Darum ist es sinnvoll, die Heterogenität zu überwinden und eine Implementierung zur Benutzung in allen bzw. möglichst vielen Programmiersprachen und Systemen zu erstellen. Diese eine Implementierung der Bibliothek liegt dabei zentral, für alle Anwendungen zugänglich, vor und erweitert somit das Konzept der Shared Libraries über die Systemgrenzen hinaus. Ein weiterer Vorteil ist der mögliche breite Einsatz dieser neuartigen Funktionsbibliothek ohne großen Aufwand für redundante Implementierungen. 33

47 4.2. EINE ONTOLOGIE FÜR GEOGRAPHISCHE FUNKTIONEN Abbildung 4.2: Taxonomie innerhalb der geographischen Funktionsbibliothek 4.2 Eine Ontologie für geographische Funktionen Um dem Nutzer einer geographischen Funktionsbibliothek (Entwickler) den Aufbau und damit die Nutzung der Bibliothek erklären zu können, muss man zunächst das Wesen von geographischen Funktionen beschreiben. Das bedeutet, die Begriffe aus dem Umfeld und deren Zusammenhänge müssen erörtert werden, damit der unerfahrene Entwickler die Idee hinter der API versteht. Solch einen Ansatz verfolgen die klassischen Bibliotheken, indem sie die API-Dokumentation mit einer Einführung in die Welt der Koordinatentransformation oder auch der sphärischen Trigonometrie beginnen und dann zu den eigentlich Code-Beispielen überleiten. Der Ansatz dieser Arbeit geht einen Schritt weiter und hinterlegt das Wissen in einer Wissensbasis (Ontologie), welche den Rechner-gestützten Zugang zu den Informationen erlaubt. Im Gegensatz dazu kann der Adressat bei einer textuellen Dokumentation nur der Mensch, in dem Fall der Entwickler, sein. Die Ontologie ist in OWL geschrieben und basiert somit auf RDF-Tripeln (s. Abschnitt 2.4.1, Seite 20). Es ist möglich über Anfragen auf das Wissen zuzugreifen. Dazu folgt im Abschnitt 4.5 genaueres. Hier werden kurz die wesentlichen Details der Wissensbasis vorgestellt. Zur Veranschaulichung wird hier bereits die graphische Notation von RDF verwendet, da sie sich sehr gut dazu eignet, das Wesen einer Domäne zu kommunizieren. Zunächst definiert die Ontologie die benötigten Begrifflichkeiten und eine hierarchische Beziehung zwischen diesen. Abbildung 4.2 zeigt die graphische 34

48 4.3. DER MASCHINEN-GESTÜTZTE ZUGANG ZUR BIBLIOTHEK Repräsentation des Baumes. Die Wurzel der Domäne 1 ist GeographicFunction, d.h., alle weiteren definierten Konzepte gehören zu dieser Klasse. Darunter erfolgt eine Unterscheidung nach einfachen und komplexen Funktionen. Erstere unterteilen sich weiter in Funktionen zur Berechnung von Entfernungen, Winkeln, Flächen, Volumen und solchen zur Umrechnung von Einheiten. Letztere beinhalten die speziellen Transformationen und Konversionen und die zugrunde liegenden mathematischen Funktionen. Diese Ontologie über den grundsätzlichen Aufbau der geographischen Funktionsbibliothek wird ergänzt durch zwei weitere, die in Abbildung B.1 und B.2 im Anhang zu sehen sind. Eine verfeinert die Begrifflichkeiten im Umfeld der Koordinatenoperationen gemäß der EPSG und die andere beschreibt grundlegende Begriffe aus der GML, womit man die Rück- und Übergabe-Parameter näher klassifizieren kann. Die Hierarchie wird ergänzt durch Instanzen (Individuen) der Konzepte. Zusammen bildet diese Einheit eine Knowledge Base (KB). 4.3 Der Maschinen-gestützte Zugang zur Bibliothek Nachdem nun die Grundlage geschaffen ist, den Inhalt der Bibliothek Maschinen-verarbeitbar zu beschreiben, braucht man einen Ansatz, der folgende Eigenschaften hat, damit er den gestellten Anforderungen genügt: 1. Einen Zugang zu den Funktionen unter Einbeziehung der Wissensbasis bieten. 2. Unabhängigkeit von Programmiersprachen 3. Einsetzbarkeit auf Geräten mit geringen Ressourcen 4. API-ähnliche Schnittstelle zum Einsatz in beliebigen Anwendungen Der einfachste Weg dazu ist der Aufruf der Funktionen über eine Schnittstelle, die von allen Programmiersprachen beherrscht wird. Hierfür bietet sich die Netzwerkschnittstelle an, d.h., man kodiert den Aufruf in einem einheitlichen Format und schickt dieses über ein gängiges Netzwerkprotokoll zu 1 Die erste Klasse unterhalb von owl:thing ist der Einstieg in die Domäne 35

49 4.3. DER MASCHINEN-GESTÜTZTE ZUGANG ZUR BIBLIOTHEK einem Endpunkt. Letzterer muss das Format verarbeiten können und sendet das Ergebnis des Aufrufes zurück. Somit kann man die zweite, dritte und vierte der geforderten Eigenschaften umsetzen. Diese als Remote Procedure Call (RPC) bezeichnete Vorgehensweise lässt sich gut durch eine Dienste-orientierte Architektur realisieren. Die Funktion wird dabei als Dienst an einer Adresse im Netzwerk zur Verfügung gestellt und kann dort von beliebig vielen Clients genutzt werden. Zwei Fragen stellen sich in dem Kontext: Wie findet der Nutzer der Funktionen diese an einem beliebigen Netzwerk-Endpunkt? Welches Format benutzt man zur Kodierung der Funktionsaufrufe, damit ein breiter Einsatz möglich ist? Bei der Beantwortung der Fragen übernehmen offene Standards eine wichtige Rolle. Sie ermöglichen die lose Koppelung zwischen den Diensten und einen allgemein bekannten Weg zum Auffinden dieser. Webservices sind die ausgereifteste Umsetzung einer SOA heutzutage. In ihrem Umfeld wurden Standards geschaffen, die die Kommunikation über das Netzwerk ermöglichen (SOAP). Des Weiteren existiert mit WSDL eine etablierte Sprache zur Beschreibung der Dienste. Die Suche der benötigten Funktionen erfolgt dabei über die UDDI Registry. Dieser inhärente Suchmechanismus einer SOA (s. Abbildung 2.1 auf Seite 7) bietet zugleich einen optimalen Ausgangspunkt zur Einbindung der beschriebenen Ontologie in den Suchprozess und damit die Erfüllung der ersten geforderten Eigenschaft. Umgekehrt betrachtet erweitert man die Basis-Standards zu Recht, da die Suchfähigkeiten von UDDI nicht ausreichend sind und die Stärke von WSDL eher in der technischen und nicht in der inhaltlichen Beschreibung der Dienste liegt. Da die Parameter für den Funktionsaufruf sowie deren Ergebnisse serialisiert über das Netzwerk übertragen werden müssen, ist auch hier eine etablierte Sprache notwendig. Im Umfeld der Webservices ist XML-Schema das am weitesten verbreitete Format zur Beschreibung dieser Informationen. In der Domäne der geographischen Daten gibt es mit der von der ISO standardisierten GML eine Sprache, die die benötigten Elemente und Typen in XML-Schema beschreibt. Abbildung 4.3 fasst die Beziehungen der einzelnen Standards zueinander nochmal zusammen. 36

50 4.4. DIE FUNKTIONSBIBLIOTHEK ALS WEBSERVICES Abbildung 4.3: Die Beziehungen der Webservices Spezifikationen untereinander ([Erl05]) 4.4 Die Funktionsbibliothek als Webservices Der Einsatz von Webservices ist nicht nur ein gutes Mittel zur Überwindung der Heterogenität, sondern bietet alle Voraussetzungen für den Maschinengestützten Zugang zu den geographischen Funktionen. Denn eine zentrale Anforderung an die Webservice-Standards war und ist es weiterhin, die Verarbeitung durch Maschinen zu gewährleisten. Dadurch erhält man die Möglichkeit, den Zugang zu den Funktionen besser als die herkömmliche Dokumentation für den Entwickler zu gestalten. Dazu folgen im Abschnitt 4.5 genauere Informationen. Ein weiteres wichtiges Kriterium ist die Anwendbarkeit der neuen Bibliothek. Die Abbildung 4.4 zeigt, wie die Komplexität einer SOA durch weitere Abstraktion der bisherigen Konzepte beherrschbar gemacht wird. Dies führt zu hohen Aufwänden während der Entwicklung, wenn man die komplette Implementierung per Hand erledigen muss. Deshalb ist eine Unterstützung durch Werkzeuge bei der Umsetzung einer SOA unabdingbar. Die Verwendung der etablierten Standards SOAP, WSDL und UDDI gewährleistet das Vorhandensein zahlreicher Werkzeuge für die Entwicklung in vielen Programmiersprachen. 37

51 4.4. DIE FUNKTIONSBIBLIOTHEK ALS WEBSERVICES Abbildung 4.4: Vergleich klassischer und Service-orientierter Software ([Erl05]) Aber auch der Einsatz solcher Standards ist keine Erfolgsgarantie für einen reibungslosen Betrieb in einem heterogenen Umfeld. Gerade WSDL ist so konzipiert, dass durch eingebaute Erweiterungsmöglichkeiten Inkompatibilitäten entstehen können. Um diesen aus dem Weg zu gehen, gibt es Richtlinien, definiert durch das WS-I 2, welche den Standard soweit einschränken wie nötig, damit später im Betrieb keine Probleme entstehen. Die Umsetzung dieser Richtlinien ist eine zentrale Anforderung an die Implementierung in der Arbeit. Mit der OGC Web Service (OWS) Spezifikation gibt es bereits einen Standard zur Erstellung von Webservices im geographischen Umfeld. Er ist die Grundlage für alle veröffentlichten Dienste-Spezifikationen des OGC. Das vorliegende Konzept berücksichtigt diesen Standard nicht, wofür es folgende Gründe gibt: 1. Die Performanz steht bei der Umsetzung der geographischen Funktionsbibliothek im Mittelpunkt, da es sich durchweg um grundlegende mathematische Funktionen handelt. Da die Umsetzung mit Hilfe von Webservices per se eine Verlängerung der Antwortzeit (Serialisierung, Latenz) nach sich zieht, muss ein möglichst schlanker Ansatz für die zu übertragenen Daten benutzt werden. Dagegen sieht der OWS Standard eine Reihe zusätzlicher Metadaten für den Aufruf des Dienstes vor, die in dem vorliegenden Kontext nicht benötigt werden. 2. Die drei hier benutzten Webservices Standards sind nicht von Beginn

52 4.5. DIE ERWEITERTE SUCHE VON FUNKTIONEN an in den OWS Spezifikationen berücksichtigt worden, d.h., es gibt keine konkrete Referenz für die Umsetzung der Dienste mit WSDL, SOAP und UDDI. Dies führt zu Problemen bei der Erstellung und dem Auffinden der geforderten standardisierten Methoden. Erst nach und nach werden diese in die weitere Planung integriert, sodass man zukünftige Änderung des Standards abwarten sollte [Kie06]. 4.5 Die erweiterte Suche von Funktionen Die implizite Suche der Dienste über eine Registry in einer SOA ermöglicht bereits einen Maschinen-gestützten Zugang zu der Funktionsbibliothek. UD- DI stellt dafür u.a. eine Suche nach Namen und einen erweiterbaren Mechanismus zur Definition von anderen Suchkriterien bereit. Letzterer führt ein Kriterium ein, indem er gültige Werte dafür festlegt. Hierbei werden aber keine Beziehungen der Begriffe untereinander berücksichtigt. Ein Beispiel dafür sind die Begriffe Koordinatenoperation, Koordinatentransformation und Koordinatenkonversion. Die letzten beiden sind jeweils eine Spezialisierung des ersten und damit eine Untermenge von diesem, d.h., jede Koordinatentransformation ist auch eine Koordinatenoperation. Trägt man nun einen Dienst in UDDI ein und klassifiziert ihn beispielsweise als Koordinatenkonversion würde eine Suche nach allen Koordinatenoperationen diesen nicht anzeigen. Ein weiterer Nachteil der klassischen Suche in UDDI ist die fehlende Unterstützung einer Suche nach Parametern des Dienstes. So ist es nicht möglich, sich alle Dienste mit bestimmten Rück- und Übergabeparametern ausgeben zu lassen. Das lässt sich durch die Integration von OWL-S in UDDI umgehen. Dabei ist es möglich ein Profil eines Dienstes als Suchanfrage zu verwenden (s. Abschnitt auf Seite 2.4.2). Es bleibt noch offen, wie der Entwickler an das Profil der gewünschten Funktion kommt. Will er es selber erstellen, benötigt er einen geeigneten Editor und eine gewisse Erfahrung im Umgang mit OWL-S. Da man letzteres nicht voraussetzen kann, wird die Suche erweitert. Der komplette Suchprozess aus Sicht des Entwicklers ist schematisch in Abbildung 4.5 dargestellt. Er umfasst mehrere Schritte und bindet die Ontologie dabei zweimal ein. Der erste Schritt der Suche ist eine Anfrage an die Wissensbasis mittels SPARQL. Dabei ist es möglich, ähnlich einer Structured Query Language 39

53 4.5. DIE ERWEITERTE SUCHE VON FUNKTIONEN Abbildung 4.5: Der Ablauf von der ersten Abfrage bis zur Rückgabe des WSDL-Dokuments (SQL)-Anfrage, Informationen nach bestimmten Kriterien aus der KB herauszufiltern. Neben den Ein- und Ausgabeparametern gibt es weitere Eigenschaften der geografischen Funktionen. Folgende Kriterien wurden zusätzlich eingeführt: Area of Use wird im Kontext von Koordinatenoperationen für die Bestimmung des Anwendungsgebietes der jeweiligen Operation benutzt. Accuracy gibt für alle implementierten Funktionen eine obere Abschätzung der Genauigkeit der Ergebnisse an. Die Anfragen sind im Rahmen der prototypischen Umsetzung zunächst nur vordefiniert und dienen lediglich dem Nachweis der Machbarkeit. Vorstellbar wären auch Anfragen in natürlichem Text mit anschließender Extraktion der Kriterien durch entsprechende Analysen. Als Ergebnis erhält man Klassen der Ontologie, die man dann mit Hilfe von Extensible Stylesheet Language Transformation (XSLT) in ein gültiges OWL-S Profil transformieren kann. Dieses Profil dient wiederum als Anfrage in einem dritten Schritt an die erweiterte UDDI Registry. Durch die Verbindung der Registry und den in Abschnitt 4.2 beschriebenen Ontologien ist es möglich, ein Matching nach Konzepten aus diesen durchzuführen. Aufgrund des semantischen Gehalts des Profils bekommt man im Idealfall die gewünschte Funktion in Form eines WSDL-Dokuments. Dieses wird dann vom Entwickler zur Umsetzung des Funktionsaufrufes verwendet. 40

54 4.6. DER EINSATZ VON GML ALS TRANSPORTSPRACHE Zur Verdeutlichung wird im Folgenden der Ablauf des Suchprozesses an einem kleinen Beispiel gezeigt. Der Entwickler sucht eine Funktion zur Berechnung der Entfernung zwischen einem deutschen und einem lettischen Flughafen. Die Lage vom ersteren ist durch GPS-Koordinaten definiert, deren Koordinaten-Referenz-System (CRS) WGS84 ist. Die Lage vom lettischen ist in einer alten Datenbank zu finden, worin die Koordinaten in Pulkovo1942(83) gegeben sind. Zunächst muss also die Vereinheitlichung des zugrunde liegenden CRS vorgenommen werden und anschließend die Entfernungsberechnung für eine weite Distanz. Somit wird eine Anfrage an die Wissensbasis nach einer Koordinatenoperation gestellt, die als Quell-CRS Pulkovo1942(83) und als Ziel-CRS WGS84 hat. Als Ergebnis bekommt man den Verweis auf das Individuum Pulkovo ToWGS84 der Klasse CoordinateTransformation. Damit und der entsprechenden XSLT Transformation wird automatisch das OWL-S Profil des Dienstes CoordinateTransformationService erzeugt. Dieses wird für die Anfrage an die Registry verwendet und als Ergebnis bekommt man einen Verweis auf das zum Dienst gehörende WSDL-Dokument, welches dann zum Generieren des Clients benutzt wird. Ähnlich läuft es dann für die Entfernungsberechnung ab. Gesucht wird eine Funktion aus dem Bereich der Distanzmessung, die für große Distanzen geeignet ist (Berücksichtigung der Erdkrümmung). Das Ergebnis ist ein Verweis auf das Individuum GreatCircleDistance der Klasse DistanceCalculation. Nach der entsprechenden XSLT Transformation kann das OWL-S Profil für die UDDI-Anfrage verwendet werden, die dann einen Verweis auf die WSDL- Beschreibung des Dienstes DistanceCalculationService liefert. 4.6 Der Einsatz von GML als Transportsprache Der Einsatz von Standards umfasst nicht nur den technischen Bereich. Auch fachlich, auf der Seite der geographischen Informationen, wird im Rahmen dieser Arbeit auf die standardisierte GML zurückgegriffen. Dadurch lässt sich die Implementierung leichter in verteilte Geographische Informationssysteme (GIS) integrieren, die ebenfalls auf den ISO Standard setzen. Abbildung B.1 im Anhang zeigt die in den Dienstsignaturen verwendeten Typen von der GML. Der gml:pointtype ist dabei das zentrale Element für 41

55 4.6. DER EINSATZ VON GML ALS TRANSPORTSPRACHE die Eingabe und zum Großteil auch für die Rückgabe. Er transportiert dabei die Koordinaten in Form einer gml:directposition, die ein Verweis auf das zugrunde liegende Koordinaten-Referenz-System beinhaltet. Lediglich die einfachen Funktionen haben reelle Zahlen bzw. entsprechende Einheiten als Rückgabewert. Die Koordinatentransformationen sollen aus Gründen der Effizienz gleich mehrere Punkte auf einmal transformieren können. Die Über- und Rückgabe mehrerer Punkte wird durch das gml:pointarray ermöglicht. Die Angabe des zugrunde liegenden Koordinaten-Referenz-Systems bei Punkten ist optional. Wird es weggelassen, kann das System keine Überprüfung der Korrektheit der Eingabeparameter vornehmen. 42

56 Kapitel 5 Implementierung In diesem Kapitel soll die prototypische Implementierung der beschriebenen geographischen Funktionsbibliothek erläutert werden. Dazu wird zunächst in Abschnitt 5.1 und 5.2 die Umsetzung der Funktionen als Webservices und deren Integration in eine UDDI Registry erklärt. Danach folgt in 5.3 und 5.4 die technische Beschreibung der Ontologie sowie der Implementierungen einiger exemplarischer Anfragen auf die erstellte Wissensbasis. Der Abschnitt 5.5 erläutert die Umsetzung der Erweiterung des klassischen UDDI Ansatzes um die semantische Komponente. Dazu wird kurz ein Projekt vorgestellt, welches den technischen Rahmen bietet, sowie die implementierten OWL-S Ontologien und deren Zusammenspiel. Der letzte Abschnitt 5.6 zeigt den logischen Aufbau der gesamten Implementierung. Die benutzte Projektstruktur und der Prozess des Einrichtens auf einem Server werden kurz vorgestellt. 5.1 Die Funktionen als Webservices Die zentrale Komponente des Prototyps sind die Webservices. Sie sind mit WSDL in der Version 1.1 [CCMW01] beschrieben. Die Entscheidung gegen die aktuelle Version 2.0 [RCWM06] beruht auf der geforderten Anwendbarkeit. Die neueste Version wurde erst im April 2006 offiziell verabschiedet. Der Autor verspricht sich von der älteren Version eine breitere und ausgereiftere Werkzeugunterstützung. Zudem gibt es automatische Konvertierer 1 von

57 5.1. DIE FUNKTIONEN ALS WEBSERVICES WSDL 1.1 nach 2.0. Für den Betrieb eines Webservice benötigt man dessen WSDL-Beschreibung, die Anwendungslogik, d.h., die implementierte Funktionalität des Dienstes, und einen Container, der beide Teile zusammenführt. Ein solcher Container benötigt in der Regel eine Verarbeitungseinheit für SOAP-Nachrichten und einen Mechanismus, um die in WSDL beschriebenen Teile des Webservice auf eine technische Basis abzubilden. Es muss also das im Binding spezifizierte Protokoll, die De-/Serialisierung der definierten Typen und die Zuordnung von abstrakten Operationen zu konkret implementierten Funktionen beherrscht werden. Die derzeitige Anwendungslogik ist in Java geschrieben und läuft auf einem Apache Tomcat 2 Server in der Apache Axis2 3 Umgebung. Apache Axis 4 ist eines der am weitesten verbreiteten Frameworks für Webservices. Es bietet als Container die genannten Funktionen, um Dienste bereitstellen zu können. Dabei unterstützt es WSDL 1.1, SOAP in den Versionen 1.1 [BEK + 00] und 1.2 [HMG + 03] und die SOAP with Attachments API for Java (SAAJ) 1.1 von Sun. Axis2 ist nun eine neue Implementierung dieses Frameworks. Die Version 1.0 wurde im Mai 2006 veröffentlicht. Der Name Axis2 wurde gewählt um den fast komplett neuen Ansatz dieser Version zu dokumentieren. Das Axis Framework weist gewisse Nachteile auf, die die Unterstützung der voranschreitenden Webservice Standards behindern. Zudem erreicht Axis2 durch den Einsatz von der Streaming API for XML (StAX) und seinem eigenen leichtgewichtigen Objektmodell (AXIs Object Model (AXIOM)) eine deutliche Steigerung der Geschwindigkeit bei der Verarbeitung der auf XML basierenden SOAP Nachrichten. Zum Erstellen von Webservices gibt es zwei Ansätze: 1. Contract-first bedeutet erst das WSDL-Dokument anzulegen und darauf aufbauend den Code zu generieren bzw. generieren zu lassen 2. Code-first bedeutet demnach das Gegenteil, d.h., erst wird die Anwendungslogik geschrieben und daraus dann das WSDL-Dokument generiert

58 5.1. DIE FUNKTIONEN ALS WEBSERVICES Der zweite Ansatz bringt einige Nachteile mit sich. So ist die Anpassung der Schnittstelle (WSDL) an den Code keine gute Praktik zur Erstellung von Komponenten, weil die Nutzer einer Komponente eine stabile Schnittstelle brauchen und der Code in der Regel weiter entwickelt wird. Zudem hat der Entwickler weniger Einfluss auf die Erstellung der Schnittstelle, was auch nicht im Sinn einer Dienste-orientierten Vorgehensweise ist. Aus diesen Gründen wurden die Webservices dieser Arbeit nach dem ersten Ansatz erstellt. Listing 5.1: Die Wurzel einer Dienstbeschreibung <?xml version= 1. 0 encoding= UTF 8?> <d e f i n i t i o n s name= D i s t a n c e C a l c u l a t i o n S e r v i c e targetnamespace= h t t p : //wwwiuk. i n f o r m a t i k. uni r o s t o c k. de/ws/ GeoFunctionServices xmlns= h t t p : // schemas. xmlsoap. org / wsdl / xmlns:soap= h t t p : // schemas. xmlsoap. org / wsdl / soap / x m l n s : t n s= h t t p : //wwwiuk. i n f o r m a t i k. uni r o s t o c k. de/ws/ GeoFunctionServices xmlns:xsd= h t t p : //www. w3. org /2001/XMLSchema xmlns:gml= h t t p : //www. o p e n g i s. net /gml > Die Erstellung des WSDL-Dokuments soll am Beispiel des Dienstes zur Berechnung von Entfernung veranschaulicht werden. Das Listing 5.1 zeigt den Beginn des Dokuments, wo man neben der typischen XML-Auszeichnung das Wurzelelement <definitions/> sieht. Hierin werden alle benötigten Namespaces deklariert. Der Basis-Namensraum für alle erstellten XML-Dokumente dieser Arbeit ist welcher dann noch um einen entsprechenden Kontext ergänzt wird. Somit erhält man für alle Dienstbeschreibungen als TargetNamespace Listing 5.2: Die Deklaration der verwendeten Parameter <types> <schema targetnamespace= h t t p : //www. o p e n g i s. net /gml xmlns= h t t p : //www. w3. org /2001/XMLSchema xmlns:wsdl= h t t p : // schemas. xmlsoap. org / wsdl / elementformdefault= q u a l i f i e d > <import namespace= h t t p : //wwwiuk. i n f o r m a t i k. uni r o s t o c k. de/ws/ GeoFunctionServices schemalocation= geows. xsd /> </ schema> </ types> Im Listing 5.2 ist die Deklaration der Typen zu sehen, die als Parameter in den Operationen des Dienstes verwendet werden. Dabei wird auf das in 4.6 beschriebene Application Schema der GML zurückgegriffen. Dieses ist als XML-Schema in der Datei 5 geows.xsd gespeichert und wird unter dem gleichen Namensraum wie die Dienste importiert. 5 der Inhalt der kompletten Datei befindet sich im Anhang 45

59 5.1. DIE FUNKTIONEN ALS WEBSERVICES Listing 5.3: Die Operationen und deren Nachrichten <message name= c a l c G r e a t C i r c l e D i s t a n c e > <part name= pointfrom type= gml:pointtype /> <part name= pointto type= gml:pointtype /> </ message> <message name= c a l c G r e a t C i r c l e D i s t a n c e R e s p o n s e > <part name= r e s u l t type= x s d : d o u b l e /> </ message> <porttype name= DistanceCalculationPortType > <o p e r a t i o n name= c a l c u l a t e G r e a t C i r c l e D i s t a n c e > <input message= t n s : c a l c G r e a t C i r c l e D i s t a n c e /> <output message= t n s : c a l c G r e a t C i r c l e D i s t a n c e R e s p o n s e /> </ o p e r a t i o n> </ porttype> Das Listing 5.3 zeigt die Definition der abstrakten Operationen mit deren enthaltenen Nachrichten. Letztere bekommen bei der Definition einen Namen und enthalten die Parameter, die mit ihnen übertragen werden. Da die Dienste der Funktionsbibliothek durchweg RPC-basiert sind, gibt es für jede Operation eine Request-Nachricht mit den Übergabeparametern - in diesem Fall calcgreatcircledistance mit den beiden Punkten pointfrom und pointto - und eine Response-Nachricht mit dem Rückgabewert - hier calcgreatcircledistanceresponse mit result. Letztlich erstellt man noch einen porttype, der die Operation (calculategreatcircledistance) definiert. Listing 5.4: Das Binding an ein Protokoll <binding name= D i s t a n c e C a l c u l a t i o n P o r t B i n d i n g type= t n s : D i s t a n c e C a l c u l a t i o n P o r t T y p e > <s o a p : b i n d i n g s t y l e= rpc t r a n s p o r t= h t t p : // schemas. xmlsoap. org / soap / http /> <o p e r a t i o n name= c a l c u l a t e G r e a t C i r c l e D i s t a n c e > <s o a p : o p e r a t i o n soapaction= c a l c u l a t e G r e a t C i r c l e D i s t a n c e /> <input> <soap: body namespace= h t t p : //wwwiuk. i n f o r m a t i k. uni r o s t o c k. de/ws/ GeoFunctionServices use= l i t e r a l /> </ input> <output> <soap: body namespace= h t t p : //wwwiuk. i n f o r m a t i k. uni r o s t o c k. de/ws/ GeoFunctionServices use= l i t e r a l /> </ output> </ o p e r a t i o n> </ binding> Der nächste Abschnitt definiert, wie die abstrakte Operation an ein spezielles Protokoll gebunden wird. Dieser erste konkrete Teil einer Beschreibung ist in Listing 5.4 zu sehen. In Zeile 3 sieht man, dass dieser Dienst, wie alle anderen 46

60 5.1. DIE FUNKTIONEN ALS WEBSERVICES Abbildung 5.1: SOAP Request für die Berechnung einer Entfernung Dienste auch, an das SOAP-Protokoll gebunden wird, welches wiederum als Transport-Protokoll HTTP verwendet. Mit dem style Attribut wird der Aufbau der Nachricht festgelegt. So bedeutet rpc, dass die Nachricht als Wurzel den Methoden-Namen enthält und die Parameter als dessen Kind-Elemente. Der Rückgabewert wird in einer Nachricht übertragen, die nach Konvention den Methoden-Namen mit der Endung Response als Wurzel besitzt. Die Abbildungen 5.1 und 5.2 zeigen die beiden SOAP-Nachrichten an einem Beispiel. Wie man sieht, wird die Nachricht direkt als Kind-Element des SOAP-Body eingefügt. Weiterhin ist zu sehen, dass in diesem Fall keine Header-Informationen übertragen werden. Listing 5.5: Die Defintion des Dienstes und seiner Operationen <s e r v i c e name= D i s t a n c e C a l c u l a t i o n S e r v i c e > <port binding= t n s : D i s t a n c e C a l c u l a t i o n P o r t B i n d i n g name= D i s t a n c e C a l c u l a t i o n P o r t > <s o a p : a d d r e s s l o c a t i o n= h t t p : // l o c a l h o s t : / a x i s 2 / s e r v i c e s / D i s t a n c e C a l c u l a t i o n S e r v i c e /> </ port> </ s e r v i c e> </ d e f i n i t i o n s> Letztlich zeigt das Listing 5.5 noch die Definition des Dienstes mit seinen Operationen. Dazu bekommt er einen Namen und einen Port, der neben dem Abbildung 5.2: SOAP Response mit der berechneten Entfernung 47

61 5.2. DIE UDDI REGISTRY MIT DEN DIENSTEN verwendeten Binding auch noch die Adresse angibt, unter der der Dienst zu erreichen ist. Beendet wird das WSDL-Dokument durch das Schließen des Wurzel-Element <definitions/>. Das UML-Diagramm in Abbildung C.1 im Anhang C auf Seite 84 zeigt am Beispiel des Dienstes, der Transformationsmethoden bereitstellt, wie die Anwendungslogik für die Webservices aufgebaut ist. Über die Datei service.xml von Axis2 wird dem Dienst eine Implementierungs-Klasse zugewiesen. Diese trägt den Namen des Dienstes mit dem Suffix ServiceSkeleton. Sie beinhaltet die angebotenen Funktionen des Dienstes, deren Parameter und Rückgabewerte vom Typ org.apache.axiom.om.omelement sind, d.h., sie arbeiten nur mit reinen XML-Elementen. Zu jedem Dienst existiert weiterhin eine Schnittstelle, die ebenfalls dessen Methoden definiert, diesmal aber mit Parametern und Rückgabewerten, die der Berechnung der jeweiligen Funktion entsprechen. Im abgebildeten Beispiel hat die Methode calculategeocentrictranlation als Übergabeparameter drei reelle Zahlen (Ordinaten des Translationsvektors) und eine Liste mit Punkten, die transformiert werden sollen. Die Rückgabe ist dann die Liste mit den transformierten Punkten. Die Schnittstelle wird anschließend von Klassen implementiert, die Algorithmen für die entsprechende Funktion bereitstellen. In diesem Beispiel gibt es die Umsetzung mit Hilfe der GeoTools-Bibliothek und eine eigene Implementierung. Somit kann in der entsprechenden ServiceSkeleton Klasse die genutzte Implementierung je nach Bedarf auf flexible Art und Weise verändert werden. 5.2 Die UDDI Registry mit den Diensten Als UDDI Registry wird in dieser Arbeit Apache juddi 6 eingesetzt, welche den UDDIv2 Standard umsetzt. Dabei handelt es sich um eine Java- Implementierung, bestehend aus einer relationalen Datenbank und der vermittelnden Geschäftslogik, die in einem Servlet-Container eingerichtet wird. Die Datenbank wurde mit Hife des Systems von MySQL 7 umgesetzt. Die Veröffentlichung der Dienste erfolgt programmatisch mit Hilfe einer Java

62 5.2. DIE UDDI REGISTRY MIT DEN DIENSTEN Abbildung 5.3: Schematischer Aufbau der Dienste-Veröffentlichung in die UDDI Registry API namens UDDI4J. Diese quelloffene, ursprünglich von IBM entwicklte API stellt Klassen für alle Konzepte aus der UDDI Datastructure Reference [BEH + 02] zur Verfügung. Somit erhält man einen einfachen Zugang beispielsweise zu den TModels und deren Inhalte. Eine weitere wichtige Klasse ist UDDIProxy. Sie implementiert mit ihren Methoden die UDDI-Schnittstelle [BDE + 02], sodass man durch einen einfachen Aufruf u.a. speichern, suchen oder löschen kann. Abbildung 5.3 zeigt den schematischen Aufbau der Implementierung zur Veröffentlichung der Dienste in der UDDI Registry. Die Informationen zu den Diensten werden in einer XML-Datei namens uddientries.xml abgespeichert. Deren Format ist durch das XML-Schema uddidetails.xsd vorgegeben, welches dem Aufbau der UDDI-Datenstruktur ähnelt und diese zum großen Teil umsetzt. An einigen Stellen wurden Veränderungen vorgenommen oder Informationen ergänzt. Die BLibId ist eine solche Ergänzung. Sie dient als Identifikator für die Funktionen in der Bibliothek und ist dabei an die EPSG-Definitionen angelehnt. Daraus folgt, dass die Ids im Bereich der Koordinatenoperationen identisch sind und lediglich für Funktionen, die durch die EPSG nicht abgedeckt werden (z.b. die Entfernungsberechnung), eine neue, unabhängige Nummer ver- 49

63 5.2. DIE UDDI REGISTRY MIT DEN DIENSTEN Abbildung 5.4: Ein Eintrag über ein Binding in der Registry geben wird. Diese BLibId wurde als Kategorie in die UDDI-Registry eingeführt. Um sie technisch nutzen zu können, wird ein tmodel in die Registry eingeführt. Dieses kann dann später von einem Binding, welches eine bestimmte Funktion implementiert, referenziert und mit der dazugehörigen Id versehen werden. Nach den Vorgaben der UDDI-Spezifikation muss zudem ein beschreibendes Dokument in Form einer Hypertext Markup Language (HTML) Seite eingeführt werden, welches durch das neue tmodel für die BLibId referenziert wird. Abbildung 5.4 zeigt einen Ausschnitt aus der eingerichteten Registry. Darin ist das tmodel zur Beschreibung des SOAP-Bindings für die Transformation GeocentricTranslation zu sehen, welche nach EPSG-Definition die Id 9603 hat. Zudem sind noch weitere Kategorisierungen zu sehen, wie z.b. nach dem Namensraum oder die Einordnung als Binding. Die Business Service Einträge enthalten zudem noch eine Kategorisierung nach der geographischen Lage. Die Werte sind durch den ISO 3166 Standard definiert, welcher Kürzel für Länder und Regionen einführt. Ein möglicher Schlüsselwert ist z.b. DE-MV. Die geographische Lage bezieht sich dabei auf den Standort des Servers auf dem der Dienst läuft, sodass die Latenz durch Auswahl des nächsten Endpunktes minimiert werden kann. Listing 5.6: Die Defintion eines Binding-tModels nach dem uddidetails- XMLSchema <t n s : t M o d e l name= G e o c e n t r i c T r a n s l a t i o n P o r t B i n d i n g > <BLibId>9603</ BLibId> <! corresponding i d o f t h e BLibFunction > <t n s : d e s c r i p t i o n t n s : l a n g= en > Performs a G e o c e n t r i c T r a n s l a t i o n. Access v i a SOAP. </ t n s : d e s c r i p t i o n> <tns: overviewdoc> <t n s : d e s c r i p t i o n t n s : l a n g= en >URL o f d e f i n i n g WSDL document</ t n s : d e s c r i p t i o n> <overviewurl> h t t p : //wwwiuk. i n f o r m a t i k. uni r o s t o c k. de:8091 / a x i s 2 / s e r v i c e s / OperationMethodsTransformationService? wsdl 50

64 5.2. DIE UDDI REGISTRY MIT DEN DIENSTEN </ overviewurl> </ tns: overviewdoc> <t n s : c a t e g o r y B a g> <t n s : k e y e d R e f e r e n c e keyname= keyvalue= wsdlspec tns: tmodelref= uuid:c1acf26d D70 39B756E62AB4 /> <! uddi o r g : t y p e s > <t n s : k e y e d R e f e r e n c e keyname= keyvalue= binding tns:tmodelref= u u i d : 6 e a f a 33e5 36eb 81b7 1ca18373f457 /> <! uddi o r g : w s d l : t y p e s > <t n s : k e y e d R e f e r e n c e keyname= keyvalue= r e f : G e o c e n t r i c T r a n s l a t i o n P o r t T y p e tns: tmodelref= uuid: 082b d8 303c b332 f24a6d53e38e /> <! uddi o r g : w s d l : p o r t T y p e R e f e r e n c e > <t n s : k e y e d R e f e r e n c e keyname= keyvalue= h t t p : //wwwiuk. i n f o r m a t i k. uni r o s t o c k. de/ws/ GeoFunctionServices tns: tmodelref= uuid:d01987d1 ab2e be2 2a66eb99d824 /> <! uddi org: xml: namespace > </ t n s : c a t e g o r y B a g> </ t n s : t M o d e l> Die Definition des gezeigten Binding-tModel in der XML-Datei ist im Listing 5.6 zu sehen. Wie bereits erwähnt ist der Aufbau ähnlich dem der UDDI- Spezifikation. In diesem konkreten Fall wurde lediglich in Zeile 2 mit der BLibId ein Projekt-spezifisches Detail hinzugefügt. Der Vorteil der Auslagerungen der eigentlichen Informationen aus dem Quellcode in eine externe Datei, die zudem noch gut von Mensch und Maschine editiert werden kann (XML), liegt in der besseren Erweiterbarkeit. Neue Funktionen der Bibliothek oder auch neue Kategorien können schnell und problemlos in einer UDDI-Registry veröffentlicht werden. Mit einem speziellen Maschinenzugang ist dieser Vorgang sogar aus der Ferne durchführbar. Für die Umsetzung der XML-Eingabe in die UDDI-Ausgabe sind die Klassen aus dem Paket de.unirostock.iuk.ws.common.uddi zuständig. Dessen UML Klassen-Diagramm ist in Abbildung C.2 im Anhang C auf Seite 85 zu sehen. Es existiert eine Trennung zwischen der UDDI4J API und der XML- Beans API. Letztere wird durch die beiden Klassen UDDIRegistryBuilder und UDDIEntriesXMLParser benutzt, um auf die Informationen der XML- Datei zuzugreifen zu können. Wie der Name es andeutet, enthält der UDDIRegistryBuilder die Anwendungslogik zum korrekten Zusammenbau der Registry. Er greift dabei auf die vier Unterklassen des UDDIGeneralHandler zu, um die jeweiligen Entitäten speichern, finden oder auch löschen zu können. Diese kapseln dabei sämtliche UDDI4J API-Calls, sodass auch ein anderes Eingabeformat der Informationen mit der dazugehörigen Steuerklasse möglich wären. 51

65 5.3. DIE ONTOLOGIE IN OWL 5.3 Die Ontologie in OWL Für die Erstellung der Ontologie wurde der Protégé Editor der Stanford Universität benutzt. Dieser unterstützt die graphische Erstellung von Ontologien und die Administration von KBs. Er ermöglicht die Ausgabe vieler Formate, darunter auch OWL und RDF. Des Weiteren ist die Anbindung eines externen Inferenz-Systems möglich, welches gewisse Dienste anbietet. Dies sind u.a.: Überprüfung der Konsistenz der Wissensbasis Überprüfung der Klassenzugehörigkeit von Instanzen Strukturierung der Wissensbasis (Bildung von Hierarchien) Instanzgenerierung (Herleitung) Die Listings 5.7 und 5.8 zeigen zusammen einen Auszug aus der Ontologie, die die Konzepte nach der Definition der EPSG beschreibt. Zur Veranschaulichung sind hier aufeinander aufbauend eine Klasse, eine Eigenschaft und ein Individuum dargestellt. Diese Ontologie ist nicht vollständig, weil einige referenzierte Klassen aus Platzgründen nicht aufgelistet sind. Zu Beginn steht wieder die XML-Deklaration gefolgt von dem Wurzel-Element <rdf:rdf> mit allen benötigten Namensräumen. Das erste Kind-Element ist <owl:ontology>, worin man sämtliche Metadaten über die vorliegende Ontologie unterbringen kann. Listing 5.7: Beginn eines OWL-Dokuments <?xml version= 1. 0?> <rdf:rdf x m l n s : r d f= h t t p : //www. w3. org /1999/02/22 rdf syntax ns# xmlns:xsd= h t t p : //www. w3. org /2001/XMLSchema# x m l n s : r d f s= h t t p : //www. w3. org /2000/01/ rdf schema# xmlns:owl= h t t p : //www. w3. org /2002/07/ owl# xmlns= h t t p : //wwwiuk. i n f o r m a t i k. uni r o s t o c k. de/ws/ GeoFunctions / owl / e p s g D e f i n i t i o n s# > <owl:ontology r d f : a b o u t= > <o w l : v e r s i o n I n f o r d f : d a t a t y p e= h t t p : //www. w3. org /2001/XMLSchema#s t r i n g > v e r s i o n 1. 0 </ o w l : v e r s i o n I n f o> <rdfs:comment r d f : d a t a t y p e= h t t p : //www. w3. org /2001/XMLSchema#s t r i n g > t i t l e Ontology o f c o n c e p t s o f the EPSG d e f i n i t i o n s. c r e a t o r Ralf Grube. d e s c r i p t i o n Ontology o f c o n c e p t s o f the d e f i n i t i o n s o f 52

66 5.3. DIE ONTOLOGIE IN OWL the European Petroleum Survey Group (EPSG). p u b l i s h e r Rostock U n i v e r s i t y. date format t e x t /xml. language E n g l i s h </ rdfs: comment> </ owl: Ontology> Das Listing 5.8 zeigt exemplarisch, wie die Informationen in der Wissenbasis repräsentiert sind. Ein Konzept bzw. eine Klasse wird eingeführt durch <owl:class rdf:id=""/>. In diesem Beispiel wird die Klasse CoordinateOperationMethodConversion definiert und im darauf folgenden Element gleich näher spezifiziert. Dabei wird <owl:class rdf:about=""> genutzt, um eine Klasse zum Zwecke der Erweiterung zu referenzieren. Wie man sieht, wird sie disjunkt zu CoordinateOperationMethodTransformation und als Unterklasse von CoordinateOperationMethod erklärt. Ähnlich läuft es bei den Eigenschaften ab. Zunächst wird sie eingeführt und anschließend näher spezifiziert. In diesem Fall wird der Definitionsbereich (domain) und der Wertebereich (range) mit Hilfe von Referenzen auf die entsprechenden Klassen festgelegt. Hieran erkennt man gut den Eigenschaftzentrierten Ansatz von OWL. Bei has_operationmethod handelt es sich um ein ObjectProperty, d.h., der Wertebereich ist durch eine Klasse festgelegt und nicht durch ein Literal (DatatypeProperty). Letztlich wird noch die Erstellung eines Individuums (Instanz) veranschaulicht. Hier wird eins mit dem Namen GeocentricToGeographic3D der Klasse CoordinateOperationMethodConversion erzeugt. Zudem wird noch die geforderte Eigenschaft has_epsgcode gesetzt. Diese verweist auf eine Instanz der Klasse EPSGId. Dessen Property identify zeigt wiederum zurück auf das anfänglich definierte Individuum. Darum spricht man von der inversen Eigenschaft von has_epsgcode. In der vollständigen Ontologie sind die beiden Eigenschaften sogar als InverseFunctional deklariert, d.h., jede Instanz, die has_epsgcode enthält, kann durch den EPSG-Code eindeutig identifiziert werden. Gleiches gilt andersherum auch für identify. Listing 5.8: Die Defintion des Dienstes und seiner Operationen <o w l : C l a s s r d f : I D= CoordinateOperationMethodConversion /> <o w l : C l a s s r d f : a b o u t= #CoordinateOperationMethodConversion > <o w l : d i s j o i n t W i t h> <o w l : C l a s s r d f : a b o u t= #CoordinateOperationMethodTransformation /> </ o w l : d i s j o i n t W i t h> <r d f s : s u b C l a s s O f> <o w l : C l a s s r d f : a b o u t= #CoordinateOperationMethod /> </ r d f s : s u b C l a s s O f> </ o w l : C l a s s> 53

67 5.4. DIE ONTOLOGIE-ANFRAGEN MIT SPARQL <owl: ObjectProperty r d f : I D= has OperationMethod /> <owl: ObjectProperty r d f : a b o u t= #has OperationMethod > <r d f s : d o m a i n r d f : r e s o u r c e= #CoordinateOperation /> <r d f s : r a n g e r d f : r e s o u r c e= #CoordinateOperationMethod /> </ o w l : O b jectproperty> <CoordinateOperationMethodConversion r d f : I D= GeocentricToGeographic3D > <has EPSGCode> <EPSGId r d f : I D= Code9602 > <i d e n t i f y r d f : r e s o u r c e= #GeocentricToGeographic3D /> </EPSGId> </has EPSGCode> </ CoordinateOperationMethodConversion> </ rdf:rdf> 5.4 Die Ontologie-Anfragen mit SPARQL Der erste Schritt der erweiterten Suche einer Funktion erfolgt über Anfragen an die Ontologie, die als Ergebnis noch keine Funktionsbeschreibung in Form eines WSDL-Dokuments enthält, sondern Klassen bzw. Individuen aus der Wissensbasis. Die Anfragen werden in SPARQL [PS06] formuliert. Programmatisch lässt sich dies mit Hilfe des quelloffenen Jena-Framework 8 realisieren, das aus mehreren APIs zusammengesetzt ist, welche u.a. Zugriff auf Ontologien ermöglichen und auch eine SPARQL Query Engine enthalten. Listing 5.9: Das Ontologie-Modell im Jena-Framework // c r e a t e an empty o n t o l o g y model using P e l l e t spec OntModel model = ModelFactory. createontologymodel ( P e l l e t R e a s o n e r F a c t o r y. THE SPEC ) ; // read t h e f i l e model. read ( http : / / wwwiuk. i n f o r m a t i k. uni r o s t o c k. de/ws/ GeoFunctions / owl / e p s g D e f i n i t i o n s. owl ) ; // v a l i d a t e t h e o n t o l o g y V a l i d i t y R e p o r t r e p o r t = model. v a l i d a t e ( ) ; Als Abstraktion einer Ontologie stellt die API mit der Klasse OntModel ein Modell bereit. Das Listing 5.9 zeigt am Beispiel der Ontologie über die EPSG- Definitionen wie das Laden und das anschließende Validieren mit Hilfe der API umgesetzt wird. Um auch bei den Anfragen, ähnlich zu den UDDI-Informationen, einen flexiblen, leicht erweiterbaren Ansatz bereitstellen zu können, wurden auch hier

68 5.4. DIE ONTOLOGIE-ANFRAGEN MIT SPARQL die Anfragen aus dem Quellcode in eine externe Datei (queries.xml) verlagert. Deren Aufbau wird durch das XML-Schema queries.xsd definiert, welches im Listing A.2 im Anhang A auf Seite 80 zu sehen ist. Listing 5.10: Eine Anfrage im XML-Format <query queryid= 2 > <d e s c r i p t i o n>s e l e c t EPSG ID o f a s p e c i f i c c o o r d i n a t e t r a n s f o r m a t i o n</ d e s c r i p t i o n> <ontologyurl>h t t p : //wwwiuk. i n f o r m a t i k. uni r o s t o c k. de:8091 /ws/ GeoFunctions / owl / e p s g D e f i n i t i o n s. owl</ontologyurl> <p r e f i x><! [CDATA[ g e o : <h t t p : //wwwiuk. i n f o r m a t i k. uni r o s t o c k. de:8091 /ws/ GeoFunctions / owl / e p s g D e f i n i t i o n s#>] ]></ p r e f i x> <v a r i a b l e>epsgid</ v a r i a b l e> <whereexpression>?x r d f : t y p e g e o : C o o r d i n a tetransformation</ whereexpression > <whereexpression>? x geo:has SourceCRS geo:pulkovo1942 CRS 2D gg</ whereexpression> <whereexpression>? x geo:has EPSGCode? y</ whereexpression> <whereexpression>?y g e o : h a s V a l u e?epsgid</ whereexpression> < f i l t e r></ f i l t e r> </ query> Listing 5.11: Die Anfrage als String PREFIX r d f : <h t t p : //www. w3. org /1999/02/22 rdf syntax ns#> PREFIX o w l : <h t t p : //www. w3. org /2002/07/ owl#> PREFIX g e o : <h t t p : //wwwiuk. i n f o r m a t i k. uni r o s t o c k. de:8091 /ws/ GeoFunctions / owl / e p s g D e f i n i t i o n s#> SELECT?EPSGId WHERE {?x r d f : t y p e g e o : C o o r d i n a tetransformation.? x geo:has SourceCRS geo:pulkovo1942 CRS 2D gg.? x geo:has EPSGCode? y.?y g e o : h a s V a l u e?epsgid. } Die Umsetzung der extern gespeicherten Anfragen auf API-Calls des Jena- Framework und deren Ausführung übernehmen zwei Klassen, die sich im Paket de.unirostock.informatik.iuk.ws.owl befinden. BLibSPARQLCreator liest die Informationen aus der XML-Datei und generiert daraus einen String. In Listing 5.10 und 5.11 sieht man die Ein- und Ausgabe dieses Prozesses. In diesem Fall wird die EPSG-Id aller verfügbaren Koordinaten-Transformationen gesucht, die als Source-CRS Pulkovo1942 besitzen. Listing 5.12: Das Erzeugung und Stellen einer Anfrage public S t r i n g executequery ( S t r i n g querystring, OntModel model ) throws Exception { Query query = QueryFactory. c r e a t e ( q u e r y S t r i n g ) ; PelletQueryExecution queryexec = new PelletQueryExecution ( query, model ) ; R e s u l t S e t r e s u l t s = queryexec. e x e c S e l e c t ( ) ; } return ResultSetFormatter. asxmlstring ( r e s u l t s ) ; 55

69 5.5. DIE DIENSTE IN OWL-S Die Klasse BLibSPARQLExecutor führt die Anfragen anschließend aus und gibt einen String im XML-Format als Ergebnis zurück. In Listing 5.12 ist die Methode für die Ausführung zu sehen. Zuerst wird diese aus dem String generiert und danach ein Objekt der Klasse PelletQueryExecution erzeugt. Dabei wird die Anfrage und das zuvor erstellte Modell der Wissensbasis übergeben. Im Listing 5.13 zeigt das Ergebnis der oben definierten Anfrage. Listing 5.13: Das Ergebnis der Anfrage im XML-Format <s p a r q l x m l n s : r d f= h t t p : //www. w3. org /1999/02/22 rdf syntax ns# xmlns:xs= h t t p : //www. w3. org /2001/XMLSchema# xmlns= h t t p : //www. w3. org /2005/ s p a r q l r e s u l t s# > <head> <v a r i a b l e name= EPSGId /> </ head> <r e s u l t s ordered= f a l s e d i s t i n c t= f a l s e > <r e s u l t> <binding name= EPSGId > < l i t e r a l datatype= h t t p : //www. w3. org /2001/XMLSchema#i n t >1679</ l i t e r a l> </ binding> </ r e s u l t> </ r e s u l t s> </ s p a r q l> 5.5 Die Dienste in OWL-S Im vorigen Abschnitt wurde gezeigt, wie der Entwickler eine Anfrage nach einer gesuchten Funktion an die Wissensbasis stellen kann. Die Antworten darauf sind RDF-Klassen oder Individuen. Ein besserer Ansatz ist, als Antwort direkt eine Dienstbeschreibung bzw. einen Verweis auf diese zu bekommen, um die gesuchte Funktion gleich in den Code einbinden zu können. Dazu ist es nötig, Dienste mit Hilfe von Ontologien zu beschreiben. In Abschnitt auf Seite 24 wurde mit OWL-S [MBH + 04] eine Spezifikation vorgestellt, die dieser Aufgabe gewachsen ist. Man erhält die Möglichkeit, Dienste unter verschiedenen Aspekten zu beschreiben. Dazu gehören u.a. ein Profil mit den Ein- und Ausgabeparametern sowie die Vor- und Nachbedingungen eines Dienstes. Konkret wurde mittels einer OWL-S-Erweiterung für den Protégé Editor (s. Abschnitt 5.3) ein Profil für die Dienste erstellt. In Abbildung 5.5 sieht man dies beispielhaft für die Funktion zur Berechnung der sphärischen Entfernung. Für die Nutzung des Profils zur Dienstsuche wurde eine Lösung gewählt, die den UDDI-Standard um OWL-S erweitert. Die Carnegie Mellon University 56

70 5.5. DIE DIENSTE IN OWL-S Abbildung 5.5: Definition eines ServiceProfiles hat mit dem OWL-S/UDDI Matchmaker eine Erweiterung vorgestellt, der die UDDI Registry juddi um die nötigen Komponenten erweitert [SPS04]. Teil der Erweiterung sind tmodels, die die Elemente des Profils abbilden. Zudem wurden die Publish- und Inquiry-API ergänzt, um die erweiterte Registrierung und semantische Anfragen zu ermöglichen. Bei der Veröffentlichung der erzeugten Profile traten Fehler auf, die aufgrund des fehlenden Source-Codes nicht behoben werden konnten. Somit war eine Anwendung der Suche nach OWL-S Profilen nicht möglich. Um dennoch den kompletten Suchprozess (s. Abbildung 4.5 auf Seite 40) durchführen zu können, wird ein alternativer Ansatz verwendet. Abbildung 5.6 zeigt die neue Lösung für den erweiterten Suchprozess. Der Unterschied besteht in der Verbindung zwischen dem Ergebnis der ersten Anfrage und der darauf folgenden UDDI-Suche mittels der Standard Inquiry API. Die Funktion wird mit Hilfe der BLibId (s. Abschnitt 5.2) gefunden. Dazu wird das zur Suche verwendete Category Bag (technischen Fingerabdruck, s. Abschnitt auf Seite 13) um die BLibId-Kategorie erweitert, welche als Wert die erhaltene Id trägt. 57

71 5.6. DIE PROJEKTSTRUKTUR UND DAS DEPLOYMENT Abbildung 5.6: Alternativer Ansatz für den erweiterten Suchprozess 5.6 Die Projektstruktur und das Deployment Wie aus den vorhergehenden Abschnitten erkennbar wurde, umfasste die Bereitstellung der Funktionsbibliothek mit Hilfe von Webservices verschiedene Teilaufgaben. Zunächst mussten die Webservices entwickelt und im Axis2 - Container eingerichtet werden. Des Weiteren wurden die Daten für die UDDI- Registry erstellt und in juddi veröffentlicht. Danach wurden die Anfragen mit SPARQL erstellt. Letztlich wurden noch Test-Clients entwickelt, die die Webservices überprüfen sollten. Alle Teilaufgaben benötigten die von XML- Beans erzeugten Klassen zur Bindung an das vorgesehene XML-Schema. Die Entwicklung erfolgte in der Eclipse IDE. Dabei wurden die verschiedenen Aufgaben in unterschiedlichen Projekten organisiert. Die Abbildung 5.7 gibt einen Überblick über die beteiligten Projekte und deren Zweck. Die Installation der Webservices in dem Container erfolgt über ein Axis-Archiv (aar). Dies ist ein Java-Archive (jar), das die Anwendungslogik der Dienste, deren WSDL-Beschreibungen, eine Konfigurationsdatei (service.xml) sowie alle benötigten Bibliotheken zusammenfassen. Das Erstellen der benötigten Ordner-Struktur und das Zusammenstellen der Dateien aus den verschiedenen Projekten wird durch einen Ant-Build im Projekt ServiceAssembly übernommen. Dieser übernimmt anschließend auch die Erzeugung des Archivs sowie anschließend das Kopieren in den entsprechenden Ordner des Axis2-Containers, sodass das Deployment gestartet wird. Das Setzen der benötigten Ordner auf dem Zielsystem erfolgt über eine Properties-Datei. 58

72 5.6. DIE PROJEKTSTRUKTUR UND DAS DEPLOYMENT Abbildung 5.7: Projektstruktur der Implementierung Die Erzeugung der Binding-Klassen für die verwendeten XML-Schemas wird im Projekt DataTypes durchgeführt. Dort sind die Schemas untergebracht sowie Ant-Builds, die die Klassen mit Hilfe des XmlBeans-Compiler erzeugen und in einem Java-Archiv zur späteren Nutzung in anderen Projekten zusammenfassen. Die Erzeugung des verwendeten GML-Profils geschieht mittels einer XSLT Transformation, die ebenfalls in dem Projekt untergebracht ist. 59

73 Kapitel 6 Evaluierung In diesem Kapitel erfolgt eine Evaluierung der Arbeit. Es wird zunächst die Implementierung gegen das Konzept geprüft. Anschließend folgt eine kritische Betrachtung der Arbeit. Des Weiteren sind verschiedene Testfälle erarbeitet worden, die eine quantitative und auch qualitative Einschätzung der erstellten Bibliothek ermöglichen sollen. Diese werden kurz vorgestellt und anschließend die Ergebnisse gezeigt und erläutert. Im Rahmen der Implementierung wurden Webservices für die Berechnung von Entfernungen und Richtungen, für die Konvertierung von Einheiten und für die Transformation von Koordinaten geschrieben. Desweiteren ist eine UDDI Registry mit den Dienst-Informationen befüllt worden, sodass die grundlegende Suche der Webservices möglich ist. Ebenfalls wurde eine einfache Wissensbasis erstellt, die die Begriffe und deren Beziehungen zueinander im Bereich der Koordinatenoperationen nach dem Vorbild der EPSG- Definitionen erklärt. Aufbauend auf der Wissensbasis wurden Anfragen definiert, mit deren Hilfe Domänen-spezifisches Wissen extrahiert werden kann. Dieses ermöglicht es nun, durch die Verbindung mit einer UDDI-Anfrage direkt einen Verweis auf das Dienst-beschreibende WSDL-Dokument zu bekommen. Die geplante Einbindung von OWL-S Dienstprofilen für diesen Zweck ist aufgrund fehlender Werkzeugunterstützung nicht möglich (s. Abschnitt 5.5 auf Seite 56). Es wurde ein alternativer Ansatz implementiert, der die Verbindung zwischen den Ergebnissen der Wissensbasis und den Anfragen an die UDDI Registry über eine Id herstellt. 60

74 6.1. KRITISCHE BETRACHTUNG Es entstehen dadurch keine Nachteile bzgl. des Auffindens der Dienste, weil der erste Schritt der Suche die Möglichkeiten einer Ontologie und des semantischen Webs nutzen kann. Jedoch ist die Wartung der Bibliothek somit aufwendiger, weil die Bereitstellung und Vergabe der Ids für neue Funktionen administriert werden muss. Da die Id ansonsten keine Informationen über die Domäne transportiert, ist die Einsparung dieses Aufwands erstrebenswert. Darum ist eine vollständige Integration von OWL-S in die Implementierung sinnvoll. Neben dem verbesserten Auffinden ist auch die automatische Komposition und das Ausführen der Dienste ein zentrales Thema dieser Spezifikation. Dadurch ließen sie sich noch besser in eine große SOA im Bereich der LBS integrieren. Diese Vorteile lassen sich momentan nicht nutzen und können erst bei verbesserter Werkzeug-Unterstützung eingebunden und integriert werden. Zusammenfassend kann man sagen, die in Abschnitt 1.1 auf Seite 1 definierten Ziele konnten umgesetzt werden. Um letztlich noch Aussagen bezüglich der Qualität des Konzeptes und dessen aktueller Umsetzung machen zu können, wird die Implementierung anhand der gestellten Anforderungen gemessen. Dabei handelt es sich um solche, die an klassische Funktionsbibliotheken gestellt werden [FKV95], als auch um Anforderungen, die sich aus den neuen möglichen Einsatzszenarien ergeben. Als Übersicht werden hier noch einmal alle aufgelistet: Effizienz - splittet sich auf in Stabilität und Performanz Anwendbarkeit - speziell über heterogene Systemgrenzen hinaus Eine einfache Nutzbarkeit Eine einfache Wartung Genaue Ergebnisse 6.1 Kritische Betrachtung Nach [ACKM03] bringen neue Konzepte in der Welt der verteilten Systeme oftmals Nachteile durch gestiegene Komplexität und verringerte Performanz mit sich. Man erhält dafür aber auch bessere Möglichkeiten im Entwurf und in der Umsetzung solcher Systeme. Es setzen sich naturgemäß die Konzepte durch, deren Vorteile überwiegen. Die gestiegene Komplexität ist auch deutlich im Laufe dieser Arbeit erkennbar gewesen. 61

75 6.2. EINFACHE NUTZBARKEIT Durch die Einführung von Webservices verlängerte sich die Berechnungszeit teilweise sehr deutlich (s. Abschnitt auf Seite 66). Dies ist im Bereich der geographischen Funktionen, bei denen es sich durchweg um grundlegende mathematische Berechnung handelt, durchaus kritisch zu betrachten. Die Erstellung von Anwendungen, die die Ergebnisse fortlaufend in Echtzeit benötigen, ist mit dieser Dienste-orientierten Funktionsbibliothek nicht möglich. Auf der anderen Seite bekommt man durch die Auslagerung der Berechnung auf einen Server die Möglichkeit auch auf Geräten mit geringen Ressourcen die Funktionen zu nutzen. Im Laufe der Arbeit ist nicht immer alles so reibungslos verlaufen wie es sollte. Die Zielstellung, durch den Einsatz der GML die Kompatibilität zu Anwendung aus dem geomatischen Umfeld zu gewährleisten, widerspricht einer Best Practice der Webservice-Programmierung, möglichst einfache Datentypen für die Schnittstellen der Dienste zu verwenden. Die GML besitzt ein komplexes Vokabular, was sich in einem komplexen XML-Schema zur Beschreibung niederschlägt. Darin werden schwierig aufzulösende Erweiterungs- und Restriktions-Konstrukte zwischen den beteiligten Datentypen benutzt. Dies führt dazu, dass viele XML-Binding-Frameworks an ihre Grenzen stoßen und die automatische Generierung von Code nicht mehr möglich ist. Letzteres ist nötig, um eine komfortable Implementierung für die XML-basierten Sprachen bei den Webservices zu erreichen. Ein weiteres Problem ist die fehlende Software zur Verarbeitung von OWL-S. Es gibt zwar den sogenannten Matchmaker der Carnegie Mellon University, der aber in Verbindung mit den Ontologien dieser Arbeit nicht lauffähig ist. Der Source-Code ist ebenfalls nicht verfügbar, sodass keine Fehlerkorrektur möglich ist. Daraus folgt, dass die erstellten semantischen Beschreibungen der Dienste nicht getestet werden können. 6.2 Einfache Nutzbarkeit Es hat sich gezeigt, dass es bei den eingesetzten Frameworks für die automatische Code-Generierung Probleme mit der Erstellung des Bindings für das benutzte XML-Schema gibt. Speziell das sehr umfangreiche GML-Profil als Teil des verwendeten ApplicationSchema erzeugt einige Fehler während des Generierungsprozesses. Bei gsoap 1, einem Webservice-Framework für

76 6.2. EINFACHE NUTZBARKEIT Abbildung 6.1: Fehler nach dem ersten Generierungsschritt mit gsoap die Sprachen C und C++, ist dieser zweistufig. Zuerst wird eine Header- Datei aus dem WSDL-Dokument erstellt, welches anschließend durch einen speziellen Compiler in die benötigten Quell-Dateien umgewandelt wird. In beiden Schritten ergeben sich Fehler, die auf das komplexe Schema zurückzuführen sind. In Abbildung 6.1 sieht man die Ausgabe des Compilers in Schritt zwei, der die Fehler aus dem ersten Generierungsprozess aufzeigt. Nachdem man diese Fehler per Hand behoben hat, ist auch in den folgenden generierten Dateien ein Fehler. In Abbildung 6.2 sieht man, dass das Kompilieren der erzeugten C++ Quelldatei fehlschlägt. Ähnliche Erfahrungen wurden auch mit dem WSDL2Java Tool des Axis2- Framework (Java) gemacht. Selbst mit XmlBeans als Binding-Framework funktioniert das automatische Erstellen eines Clients nicht auf Anhieb, weil das GML-Profil die Unique Particle Attribution Regel verletzt. Immerhin ist es möglich, die Überprüfung dieser Regel beim Generieren auszuschalten, wenn man in einem separaten Schritt mit dem speziellen Compiler von Xml- Beans arbeitet. Dann muss man aber auch den Client selber schreiben und genießt die Vorteile des Codegenerierens nicht. Zusammenfassend lässt sich feststellen, dass die automatische Code-Generie- 63

77 6.3. GENAUIGKEIT, PERFORMANZ UND STABILITÄT Abbildung 6.2: Fehler nach dem zweiten Generierungsschritt mit gsoap rung nur mit erheblichem Aufwand zu nutzen ist. Dies liegt an dem komplexen XML-Schema des GML-Profil, welches nicht von den zur Verfügung stehenden Werkzeuge unterstützt wird. Daraus resultiert viel Handarbeit während der Implementierung, welche auch ein solides Grundwissen über die verwendeten Techniken voraussetzt. Letzteres sollte durch die Werkzeug- Unterstützung eigentlich vermieden werden. Somit ist momentan die geforderte einfache Nutzbarkeit nicht gegeben. 6.3 Genauigkeit, Performanz und Stabilität In diesem Abschnitt sollen Kriterien, die das Laufzeitverhalten beschreiben, überprüft werden. Bis auf die Stabilität wird eine vergleichende Bewertung vorgenommen. Als Vergleich wird die geographische Funktionsbibliothek GeoTools genommen, welche im klassischen Umfeld für Java-Anwendungen verwendet werden kann. Da die Anwendungslogik, die den Diensten zugrunde liegt, zum großen Teil ebenfalls auf dieser Bibliothek aufbaut, sollten die Ergebnisse für jeden Vergleich theoretisch identisch sein. Somit erhält man im Grad der Abweichung ein gutes Maß, wie groß die Auswirkungen der zusätzlichen Abstraktion und Kommunikation sind. Die Testfälle zum Testen der drei Kriterien und deren Ergebnisse werden in den folgenden Abschnitten genauer erläutert Vergleich der Ergebnisse mit GeoTools Zum Vergleich der Ergebnisse wurden drei Funktionen aus unterschiedlichen Kategorien ausgewählt. Dadurch kann man eine Aussage über die gesamte Breite der Bibliothek machen sowie maßgebliche Faktoren näher eingrenzen. Innerhalb der einzelnen Kategorien müssten Abweichungen beim Vergleich der Ergebnisse ähnlich sein, weil diese lediglich aus der De-/Serialisierung 64

78 6.3. GENAUIGKEIT, PERFORMANZ UND STABILITÄT der Ein- und Ausgabeparameter stammen können. Für die statistische Aussagekraft wurden je Vergleich 1000 zufällige Parametermengen generiert und in einer Datei abgespeichert. Anschließend wurden die 1000 Berechnungen nacheinander von beiden Bibliotheken durchgeführt und die Ergebnisse zum Zwecke der Auswertung abermals in eine Datei geschrieben. In einem dritten Schritt erfolgte der Vergleich der Ergebnisse. Dabei wurde die Höhe der Abweichung beider Ergebnisse prozentual zum GeoTools- Ergebnis berechnet. Dieser prozentuale Anteil wurde über alle Durchläufe gemittelt sowie die Standardabweichung bestimmt. Die Gleichungen dafür waren folgende, wobei x ein Ergebnis aus der Menge der Messungen (x X) und n die Kardinalität der Ergebnismenge (n = X ) ist: x = 1 n x i (6.1) n i=1 s x = 1 n (x i x) n 1 2 (6.2) i=1 Tabelle 6.1 zeigt die Ergebnisse dreier Durchläufe mit je 1000 Berechnungen. Darin sieht man, dass keine Abweichung der Ergebnisse zwischen den beiden Bibliotheken existieren. Damit ist gezeigt, dass es keine Werte-Veränderung durch die Serialisierung der Daten bzw. deren Transport gibt. Der Test wurde durchgeführt, weil das so nicht sicher zu erwarten war. Erwartungswert und Standardabweichung bzgl. der Ergebnis-Differenz (%) Funktion Lauf1 Lauf2 Lauf3 EW SA EW SA EW SA GreatCircleDistance Helmert7Parameter Pulkovo1942ToWGS Tabelle 6.1: Durchschnittliche Abweichung (EW) des Webservice-Ergebnis vom Geotools-Ergebnis relativ zum letzteren (in %) und die Standardabweichung (SA) 65

79 6.3. GENAUIGKEIT, PERFORMANZ UND STABILITÄT Vergleich der Rechendauer mit GeoTools Als Rechendauer wird in diesem Test die Zeit zwischen dem Aufruf der Funktion und dem Erhalt des Ergebnisses definiert. Streng genommen müsste man somit von der Bearbeitungsdauer sprechen, da bei der BLib noch die Kommunikationszeit sowie die Zeit für das De-/Serialisieren hinzukommt. Um aber den Vergleich zu der herkömmlichen Bibliothek zu verdeutlichen, bei dem es ausschließlich um das Berechnen von geographischen Funktionen geht, wurde der Term Rechendauer benutzt. Die Auswahl der Funktionen ist äquivalent zum Test in Abschnitt Auch hier werden wieder Parameter-Mengen zufällig generiert und gespeichert, ebenso wie anschließend die Ergebnisse. Im Unterschied zum ersten Test werden die beiden Bibliotheken nicht nur nacheinander 1000 mal aufgerufen, sondern die BLib wird zweimal getestet. Dabei erfolgt ein Aufruf ohne echte Netzwerkschnittstelle, d.h., vom gleichen Rechner auf dem die Bibliothek läuft. Der zweite ist dann entsprechend von einem Remote-System. Dadurch soll die Auswirkung der Latenz des Netzwerkes explizit betrachtet werden können. Die Berechnung des Erwartungswertes und der Standardabweichung erfolgt ebenfalls nach den Gleichungen 6.1 und 6.2. Der Rechner, auf dem der Server läuft, ist ein Athlon XP mit 1GB RAM. Als Remote-System wird eine Notebook mit dem Prozessor Intel Pentium M 725 (1,6 GHz) und 512Mb RAM eingesetzt. Erwartungswert und Standardabweichung bzgl. des Rechenzeit-Verhältnisses Funktion Lauf1 Lauf2 Lauf3 EW SA EW SA EW SA GreatCircleDistance Helmert7Parameter Pulkovo1942ToWGS Tabelle 6.2: Durchschnittliche Rechenzeit (EW) der Webservice-Berechnung relativ zur GeoTools-Berechnung und die Standardabweichung (SA) - Lokaler Webservice-Aufruf In Tabelle 6.2 sieht man die durchschnittliche Verlängerung der Berechnungs- Zeit durch einen lokalen Webservice-Aufruf. Die Verlängerung bei der ersten Funktion um den Faktor 1000 ist lediglich so extrem, da es sich bei der Entfernungs-Berechnung um eine einfache Berechnung handelt. Somit wirkt 66

80 6.3. GENAUIGKEIT, PERFORMANZ UND STABILITÄT Erwartungswert und Standardabweichung bzgl. des Rechenzeit-Verhältnisses Funktion Lauf1 Lauf2 Lauf3 EW SA EW SA EW SA GreatCircleDistance Helmert7Parameter Pulkovo1942ToWGS Tabelle 6.3: Durchschnittliche Rechenzeit (EW) der Webservice-Berechnung relativ zur GeoTools-Berechnung und die Standardabweichung (SA) - Remote Webservice-Aufruf sich der Overhead durch die Webservice-Implementierung bedeutend stärker aus. Vergleicht man dazu Tabelle 6.4, ist zu sehen, dass die Zeit zur Berechnung der Funktion über den Webservice bei allen drei Funktionen ähnlich lang dauert. Daraus kann man schließen, dass ein Großteil des Berechnungsaufwandes für die De-/Serialisierung der Nachrichten aufgewendet wird und die Berechnung der Funktion eher eine untergeordnete Rolle spielt. Einen Einfluss hat sicher auch die Prozessor-Teilung durch die Server- und Client-Anwendung, sodass die angegebenen Berechnungszeiten nicht die untere Grenze sind. In Tabelle 6.3 und 6.5 wird diese Annahme bestätigt. Darin sind die Werte für einen Remote-Aufruf zu sehen. Entgegen den Erwartungen sind die Zeiten und Faktoren kleiner als bei einem lokalen Aufruf. Dabei muss man den Testaufbau berücksichtigen. Die Rechner sind direkt über eine 100MBit-Leitung von 4m Länge verbunden, sodass die Latenz sehr gering ist und kaum Einfluss nehmen kann. Somit wirkt sich eher der Vorteil der 2 Prozessoren zur dedizierten Berechnung für die Serverbzw. Client-Seite aus. Zum Test steht leider kein Server mit WAN-IP zur Verfügung, sodass der konkrete Einfluss der Latenz nicht überprüft werden kann. Die Erwartungen diesbezüglich sind aber, dass die Berechnungszeit um die mittlere Latenz verlängert wird. Aus diesem Grund ist die Kategorisierung nach Standorten (ISO 3166) in der UDDI Registry vorgenommen worden. Somit kann jeder Client den für ihn nächsten Endpunkt zum Aufruf der Funktion wählen, sofern die Dienste auf mehreren Servern laufen. Allgemein kann man festhalten, je komplexer die Berechnung der Funktio- 67

81 6.3. GENAUIGKEIT, PERFORMANZ UND STABILITÄT nen wird, desto geringer ist der Nachteil der Webservice-Implementierung gegenüber der GeoTools-Bibliothek. Dies erkennt man an der dritten Funktion, die lediglich eine Verlängerung der Rechenzeit um den Faktor 9 verursacht. Eine Zeit von durchschnittlich 10 ms plus die auftretende Latenz während der Kommunikation, kann je nach Anwendungsfall noch im Rahmen des Anwendbaren sein. Erwartungswert und Standardabweichung bzgl. der absoluten Rechenzeit der Webservices (ms) Funktion Lauf1 Lauf2 Lauf3 EW SA EW SA EW SA GreatCircleDistance Helmert7Parameter Pulkovo1942ToWGS Tabelle 6.4: Absolute Rechenzeit (EW) der Webservice-Berechnung (in ms) und die Standardabweichung (SA) - Lokaler Webservice-Aufruf Erwartungswert und Standardabweichung bzgl. der absoluten Rechenzeit der Webservices (ms) Funktion Lauf1 Lauf2 Lauf3 EW SA EW SA EW SA GreatCircleDistance Helmert7Parameter Pulkovo1942ToWGS Tabelle 6.5: Absolute Rechenzeit (EW) der Webservice-Berechnung (in ms) und die Standardabweichung (SA) - Remote Webservice-Aufruf Test des Lastverhaltens Bei einer klassischen Shared Library ist die Anzahl der gleichzeitigen Zugriffe durch das eine abgegrenzte System, auf dem sie läuft, und dessen laufende Anwendungen, beschränkt. Im Gegensatz dazu kann eine offen zugängliche Funktionsbibliothek auf Basis von Diensten weitaus öfter aufgerufen werden. Die Anzahl der potenziellen nutzenden Systeme ist zwar auch endlich, aber deutlich höher als 1. Darum ist ein Test zum Lastverhalten, der letztlich auch die Stabilität der Bibliothek widerspiegelt, sinnvoll. 68

82 6.4. EINFACHE WARTUNG Für den Test werden je 100 Threads auf einem Remote-System und auf dem BLib-Server gestartet. Diese führen zufällig Aufrufe beliebiger Dienste der Bibliothek durch. Geprüft werden soll, ob es eine Grenze bei der Anzahl der Aufrufe gibt, wo diese liegt und wodurch sie beeinflusst wird. Das Ergebnis ist erwartungsgemäß, dass der Server nur auf eine begrenzte Anzahl an Anfragen antwortet. Eine quantitativ aussagekräftige Auswertung kann an dieser Stelle nicht vorgenommen werden. Die Client-Threads, die auf der Server-Maschine gestartet werden, beeinflussen die insgesamt zur Verfügung stehenden Ressourcen auf dem System. Dadurch kann die Last- Grenze des Servers nicht genau bestimmt werden. Wird der Test mit 200 Client-Threads ausschließlich vom Remote-System durchgeführt, so bricht dieses vor dem Server ab, da zu wenig Arbeitsspeicher vorhanden ist. Zusammenfassend kann man sagen, dass es eine Lastgrenze gibt für den Server, die aber von den zur Verfügung stehenden Ressourcen abhängt. Da jeder Funktionsaufruf, aufgrund des gewählten Binding, ein HTTP Request an einen Server ist, sind die Standardverfahren der Lastverteilung anwendbar. Zudem können Server mit besserer Rechenleistung benutzt werden, um die Verfügbarkeit der Webservice-Implementierung in ausreichendem Maße zu gewährleisten. Die nötige Stabilität der Bibliothek ist dadurch gegeben. 6.4 Einfache Wartung Unter einfacher Wartung versteht man im Kontext einer Funktionsbibliothek hauptsächlich das Testen und Optimieren der bestehenden und die gute Erweiterbarkeit um neue Funktionen. Die ersten beiden Punkte sind durch den Komponenten-orientierten Charakter der Dienste, bei dem die Anwendungslogik klar von der Schnittstelle getrennt ist, gut umsetzbar. So kann man beliebig die eigentliche Berechnung durch neue optimierte Algorithmen ersetzen und während der separaten Entwicklung testen. Auch ein paralleler Betrieb von unterschiedlichen Algorithmen zur Berechnung des gleichen Ergebnisses, die nach verschiedenen Kriterien optimiert sind (z.b. Genauigkeit vs. Schnelligkeit), ist durch die inhärente lose Koppelung der Dienste-orienterten Architektur möglich. Man richtet lediglich ein weiteres Binding für den abstrakten PortType, der eine gewisse Funktion repräsentiert, ein und veröffentlicht dieses mit der entsprechenden Kategori- 69

83 6.5. ANWENDBARKEIT sierung in der UDDI-Registry. Die gute Erweiterbarkeit um neue Funktionen wird zunächst schon einmal durch die Webservice-Architektur und deren implizite Werkzeug-Unterstützung gefördert. So muss man lediglich im entsprechenden WSDL-Dokument die neue Funktion als PortType, Binding und Port ergänzen und den Algorithmus in die dazugehörigen Klassen der Anwendungslogik integrieren. Zum Aufsetzen eines neuen Dienstes erstellt man dessen WSDL-Dokument neu und lässt sich die nötigen Klassen zur Implementierung des eigentlichen Algorithmus durch entsprechende Werkzeuge generieren. Dieser letzte Schritt des Generierens verläuft zwar zur Zeit noch nicht optimal (s. folgender Abschnitt), wird aber im Zuge verbesserter Werkzeug-Unterstützung zukünftig keine Probleme mehr erzeugen. Eine zweite Voraussetzung für die Einführung neuer Funktionen ist die Erweiterung der UDDI sowie der Ontologie und deren Anfragen. Um den Prozess leichter handhaben zu können, wurden die UDDI-Einträge (s. Abschnitt 5.2 auf Seite 48) und auch die SPARQL-Anfragen (s. Abschnitt 5.4 auf Seite 54) aus dem Code in eine XML-Repräsentation ausgelagert. Dadurch ist eine Neukompilierung der Anwendung nach Änderungen nicht nötig. Auch die Remote-Anpassung der beiden XML-Dateien ist vorstellbar. Zusammenfassend kann man sagen, dass die geforderte gute Erweiterbarkeit gegeben ist. 6.5 Anwendbarkeit Die Webservices sind in Java programmiert und auch der Container, in dem sie eingerichtet sind, basiert auf dieser Sprache. Es wurde für jeden implementierten Dienst ein TestClient erstellt, der dessen Funktionen aufrufen kann. Auch diese Clients sind in Java geschrieben. Somit hat man noch nicht die Überwindung der Heterogenität gezeigt, obwohl die Berechnung der Funktion auch in diesem Fall jenseits der Systemgrenzen des Clients durchgeführt wird. Aus diesem Grund wurde eine Testanwendung in der Sprache C++ geschrieben, die die Anwendbarkeit der Funktionen der Bibliothek zwischen zwei unterschiedlichen Programmiersprachen demonstrieren soll. Es wurde das Webservice-Framework gsoap benutzt, um möglichst viel Code aus der vorhandenen Dienstbeschreibung in Form des WSDL-Dokuments generieren zu 70

84 6.5. ANWENDBARKEIT lassen. Damit konnte zugleich die einfache Nutzbarkeit überprüft werden (s. Abschnitt 6.2). Nachdem die aufgetretenen Probleme während der Genierung beseitigt wurden, war der Aufruf des Dienstes mittels des C++ Clients möglich. Dadurch ist gezeigt, dass sich die Nutzung der Dienste nicht mehr nur auf eine Programmiersprache beschränkt. Somit ist die Bibliothek anwendbar, sofern die beschränkte Performanz (s. Abschnitt 6.3.2) in dem jeweiligen Anwendungsfall toleriert werden kann. 71

85 Kapitel 7 Zusammenfassung und Ausblick In diesem Kapitel folgt zunächst eine Zusammenfassung der Arbeit, worin die Kernelemente noch einmal aufgegriffen werden. Abschließend wird ein kurzer Ausblick gegeben, welche Fragestellungen zukünftig noch bearbeitet werden können. 7.1 Zusammenfassung Im Rahmen einiger vorangegangener Studien- und Diplomarbeiten im Kontext der LBSs war stets die Nutzung grundlegender geographischer Funktionen (z.b. Koordinatentransformationen oder Richtungs- und Entfernungsberechnung) nötig. Damit die Entwicklungen in verschiedenen Programmiersprachen nicht immer die Anwendung einer neuen geographische Funktionsbibliothek erfordern, war die Idee eine einheitliche API zur Nutzung in allen Programmiersprachen zu entwickeln. Gleichzeitig wurde nach einem Weg gesucht, Bibliotheks-Funktionen auch auf Ressourcen-armen Geräten nutzen zu können. Daraus ergab sich die Zielstellung für diese Arbeit. Es sollte eine Diensteorientierte geographischen Funktionsbibliothek entwickelt werden. Dafür wurden Webservices erfolgreich entworfen und erstellt. Für die Beschreibung der geographischen Daten, die als Eingabe benötigt und als Ausgabe erzeugt wurden, kam die GML vom OGC zum Einsatz. Dadurch soll die Einbindung der Dienste in LBSs, die ebenfalls diese Sprache benutzen, um deren Daten zu beschreiben, nahtlos ermöglicht werden. 72

86 7.2. AUSBLICK Neben der Auswahl und Erstellung der Dienste war deren semantische Beschreibung ein wesentliches Ziel der Arbeit, dass auch erreicht wurde. Für dessen Umsetzung wurden zwei Ontologien entworfen sowie eine bestehende eingebunden und miteinander verknüpft, die die Domäne der geographischen Funktionen, auf RDF basierend, beschreiben. Dieses Vokabular wird zum einen in der semantischen Beschreibung der Dienste mittels OWL-S verwendet. Zum anderen bietet es über Anfragen in SPARQL die Möglichkeit das Wesen der Domäne an einen Entwickler eines LBS zu vermitteln. 7.2 Ausblick Da es sich bei dieser Arbeit um ein erstes Konzept und eine prototypische Implementierung handelt, welche nicht alle Aspekte in der nötigen Tiefe berücksichtigen konnte, ist es sinnvoll in weiteren Arbeiten diese zu betrachten. Im folgenden sollen mögliche, zukünftige Problemstellungen aufgezählt werden: 1. Ein großer Bereich, den es zu konkretisieren gilt, ist der über die Wissensrepräsentation und -verarbeitung mit Hilfe der Ontologien. Sowohl die Verfeinerung der Wissenbasis durch neue Konzepte, Beziehungen und Individuen als auch flexiblere Anfragen sind nötig, um das volle Potenzial, der auf semantischen Beschreibungen beruhenden Suche, ausnutzen zu können. Ein Textanalyse-System, welches Anfragen in natürlicher Sprache in die entsprechenden SPARQL-Anfragen umformen kann, gehört ebenso dazu. Zudem muss der Einsatz von OWL-S in einer funktionstüchtigen Umgebung getestet werden. 2. Weiterer Entwicklungsbedarf ist bei den Webservices im Bereich der Performanz. Da sollten Techniken wie der Einsatz von Binary XML für die Verringerung der Übertragungszeiten und der Datenmenge untersucht oder andere Server-Systeme und SOAP-Implementierung auf deren Geschwindigkeiten überprüft werden. 3. Neben den beiden Hauptthemen ist die Betrachtung von Sicherheitsfragen durchzuführen. Diese spielen im Kontext der geographischen Funktionen zwar erstmal eine untergeordnete Rolle, sollten aber für einen Produktiv-Betrieb nicht außer Acht gelassen werden. 4. Die stetige Erweiterung um neue geographische Funktionen ist unerlässlich, damit der Einsatz der Bibliothek sinnvoll ist. 73

87 7.2. AUSBLICK Nach der Untersuchung der genannten Aspekte und einer Umsetzung von einigen dieser, ist ein Feldtest für die letzte Evaluierung nötig. Darin wird sich zeigen, ob der breite Einsatz der neuen Funktionsbibliothek möglich ist. Zugleich werden dadurch potenzielle Anwendungsszenarien, die die zusätzliche Flexibilität trotz der verringerten Berechnungsgeschwindigkeit nutzen können, aufgezeigt. 74

88 Literaturverzeichnis [ACKM03] Gustavo Alonso, Fabio Casati, Harumi Kuno, and Vijay Machiraju. Web Services. Springer, 1 edition, October [AFM + 05] [AvH04] [BDE + 02] Rama Akkiraju, Joel Farrell, John Miller, Meenakshi Nagarajan, Marc-Thomas Schmidt, Amit Sheth, and Kunal Verma. Web service semantics - WSDL-S. Technical Note 1, IBM and University of Georgia, V1.html, April Grigoris Antoniou and Frank van Harmelen. A Semantic Web Primer. B&T, July Douglas Bryan, Vadim Draluk, Dave Ehnebuske, Tom Glover, Andrew Hately, Yin Leng Husband, et al. UDDI version 2.04 API specification. UDDI committee specification, OA- SIS, htm, July [BEH + 02] Tom Bellwood, David Ehnebuske, Yin Leng Husband, Alan Karp, Keisuke Kibakura, et al. UDDI version 2.03 data structure reference. Specification, OA- SIS, htm, July [BEK + 00] [BG04] Don Box, David Ehnebuske, Gopal Kakivaya, Andrew Layman, Noah Mendelsohn, Henrik Frystyk Nielsen, Satish Thatte, and Dave Winer. Simple object access protocol (SOAP) 1.1. W3C note, W3C, /, May Dan Brickley and Ramanathan V. Guha. RDF vocabulary description language 1.0: RDF schema. W3C recommendation, W3C, February

89 LITERATURVERZEICHNIS [BWN + 05] Tom Bychowski, Jonathan Williams, Harry Niedzwiadek, Yaser Bishr, Jean-Francois Gaillet, et al. OpenGIS location services (OpenLS): Core services. Implementation specification, Open Geospatial Consortium Inc., May [CCMW01] Erik Christensen, Francisco Curbera, Greg Meredith, and Sanjiva Weerawarana. Web services description language (WSDL) 1.1. W3C note, W3C, March [CDL + 04] [Dau85] Simon Cox, Paul Daisey, Ron Lake, Clemens Portele, and Arliss White. Geography markup language (GML) Open- GIS recommendation paper, Open Geospatial Consortium Inc., February Manfred Dausmann. Informationsstrukturen und Verfahren fuer die getrennte Uebersetzung von Programmteilen. R. Oldenbourg, Muenchen, GMD-Bericht Nr [DJM05] Wolfgang Dostal, Mario Jeckle, and Ingo Melzer. Serviceorientierte Architekturen mit Web Services. Konzepte - Standards - Praxis. Spektrum Akademischer Verlag, 1 edition, September [dl05] Norbert de Lange. Geoinformatik in Theorie und Praxis: In Theorie Und Praxis. Springer, Berlin, 2., aktualis. u. erw. aufl. edition, September [dlb + 06] Jeff de la Beaujardiere et al. OpenGIS web map server implementation specification OGC implementation specification, Open Geospatial Consortium Inc., March [Erl05] [FKV95] Thomas Erl. Service-Oriented Architecture. Concepts, Technology, and Design. Prentice Hall International, September Glenn S. Fowler, David G. Korn, and Kiem-Phong Vo. Principles for writing reusable libraries. In SSR 95: Proceedings of the 1995 Symposium on Software reusability, pages , New York, NY, USA, ACM Press. 76

90 LITERATURVERZEICHNIS [HLMR] [HMG + 03] Richard Harrah, Sam Lee, Joel Munter, and Claus Von Riegen. UDDI version 3 features list. Feature list, OASIS, v3 features.htm. Marc Hadley, Noah Mendelsohn, Martin Gudgin, Henrik Frystyk Nielsen, and Jean-Jacques Moreau. SOAP version 1.2 part 1: Messaging framework. W3C recommendation, W3C, June [KC04] Graham Klyne and Jeremy J. Carroll. Resource description framework (RDF): Concepts and abstract syntax. W3C recommendation, W3C, February [KF04] [Kie06] [MBH + 04] [POSV04] Wolfgang Kresse and Kian Fadaie. ISO Standards for Geographic Information. Springer, Berlin, 1 edition, January Christian Kiehle. Geodaten standardisiert integrieren. ix Magazin für professionelle Informationstechnik, 12(1):50 55, December David Martin, Mark Burstein, Jerry Hobbs, Ora Lassila, Drew McDermott, et al. OWL-S: Semantic markup for web services. White paper, DARPA, November Abhijit A. Patil, Swapna A. Oundhakar, Amit P. Sheth, and Kunal Verma. Meteor-s web service annotation framework. In WWW 04: Proceedings of the 13th international conference on World Wide Web, pages , New York, NY, USA, ACM Press. [PS06] Eric Prud hommeaux and Andy Seaborne. SPARQL query language for RDF. W3C working draft, W3C, October [RCWM06] Arthur Ryman, Roberto Chinnici, Sanjiva Weerawarana, and Jean-Jacques Moreau. Web services description language (WSDL) version 2.0 part 1: Core language. Candidate recommendation, W3C, March

91 LITERATURVERZEICHNIS [SD04] Guus Schreiber and Mike Dean. OWL web ontology language reference. W3C recommendation, W3C, February [SMSV 5] [SPS04] Kaarthik Sivashanmugam, John Miller, Amit Sheth, and Kunal Verma. Framework for semantic web process composition. International Journal of Electronic Commerce, 9(2):71 106, Winter Naveen Srinivasan, Massimo Paolucci, and Katia P. Sycara. An efficient algorithm for OWL-S based semantic search in UDDI. In Jorge Cardoso and Amit P. Sheth, editors, SWSWPC, volume 3387 of Lecture Notes in Computer Science, pages Springer, [V + 05] Panagiotis A. Vretanos et al. Web feature service implementation specification OGC implementation specification, Open Geospatial Consortium Inc., May [VSS + 05] [WCL05] Kunal Verma, Kaarthik Sivashanmugam, Amit Sheth, Abhijit Patil, Swapna Oundhakar, and John Miller. Meteor-s wsdi: A scalable infrastructure of registries for semantic publication and discovery of web services. Journal of Information Technology and Management, 6(1):17 39, Kluwer Academic Publishers. Sanjiva Weerawarana, Francisco Curbera, and Frank Leymann. Web Services Platform Architecture: Soap, WSDL, WS-Policy, WS-Addressing, WS-Bpel, WS-Reliable Messaging and More. Prentice Hall International, April

92 Anhang A Ausgewählte XML-Schemas Listing A.1: Das GML Application Schema mit eigenem Namespace <?xml version= 1. 0 encoding= UTF 8?> <schema targetnamespace= h t t p : //wwwiuk. i n f o r m a t i k. uni r o s t o c k. de/ws/ GeoFunctionServices x m l n s : x l i n k= h t t p : //www. w3. org /1999/ x l i n k xmlns:gml= h t t p : //www. o p e n g i s. net /gml xmlns:iuk= h t t p : //wwwiuk. i n f o r m a t i k. uni r o s t o c k. de/ws/ GeoFunctionServices xmlns= h t t p : //www. w3. org /2001/XMLSchema elementformdefault= q u a l i f i e d version= > <import namespace= h t t p : //www. o p e n g i s. net /gml schemalocation= gmlsubset. xsd /> <! =========================================================== r e s u l t element with a d o u b l e v a l u e =========================================================== > <element name= doubleresult type= double /> <! =========================================================== r e s u l t element o f t y p e gml:anglechoicetype =========================================================== > <element name= anglechoice type= gml:anglechoicetype /> <! =========================================================== f a u l t d e t a i l element o f type i u k : F a u l t D e t a i l T y p e =========================================================== > <element name= f a u l t D e t a i l type= i u k : F a u l t D e t a i l T y p e /> <! =========================================================== f a u l t d e t a i l type, used to submit f a u l t d e t a i l s =========================================================== > <complextype name= FaultDetailType > <annotation> <documentation>a f a u l t d e t a i l c o n t a i n s an e r r o r code and a message.</ documentation> </ annotation> <sequence> <element name= code type= n o n N e g a t i v e I n t e g e r /> <element name= message type= s t r i n g /> </ sequence> </ complextype> </ schema> 79

93 A. AUSGEWÄHLTE XML-SCHEMAS Listing A.2: Das Schema zur Beschreibung von SPARQL-Queries <?xml version= 1. 0 encoding= UTF 8?> <schema targetnamespace= h t t p : //wwwiuk. i n f o r m a t i k. uni r o s t o c k. de/ws/ GeoFunctionServices / s p a r q l x m l n s : t n s= h t t p : //wwwiuk. i n f o r m a t i k. uni r o s t o c k. de/ws/ GeoFunctionServices / s p a r q l xmlns= h t t p : //www. w3. org /2001/XMLSchema elementformdefault= u n q u a l i f i e d version= 1. 0 > <element name= q u e r i e s type= t n s : q u e r i e s T y p e /> <complextype name= queriestype > <sequence> <element name= query minoccurs= 0 maxoccurs= unbounded > <complextype> <annotation> <documentation>the query element that c o n t a i n s a l l n e s s e c a r y i n f o r m a t i o n.</ documentation> </ annotation> <sequence> <element name= d e s c r i p t i o n type= s t r i n g minoccurs= 1 /> <element name= ontologyurl type= s t r i n g minoccurs= 1 /> <element name= p r e f i x type= s t r i n g minoccurs= 1 /> <element name= v a r i a b l e type= s t r i n g minoccurs= 1 maxoccurs= unbounded /> <element name= whereexpression type= s t r i n g minoccurs= 1 maxoccurs= unbounded /> <element name= f i l t e r type= s t r i n g minoccurs= 0 /> </ sequence> <a t t r i b u t e name= queryid type= i n t e g e r /> </ complextype> </ element> </ sequence> </ complextype> </ schema> 80

94 Anhang B Abbildungen von ausgewählten Ontologien Abbildung B.1: Auszug aus der GML Ontologie 81

95 B. ABBILDUNGEN VON AUSGEWÄHLTEN ONTOLOGIEN Abbildung B.2: Taxonomie nach EPSG Definition 82