Semantic Web: Services finden

20.12.2006
Von Michael Stollberg
Eine Möglichkeit, eine SOA technisch umzusetzen, sind Web-Services. Doch wie sollen diese Mosaksteine gefunden werden, um eine spezifische Anforderung damit zu beältigen? "Semantic Web Services" bieten Lösungen dafür an.
Erweiterte Beschreibung von Web Services sagen etwas für die Nutzbarkeit aus.
Erweiterte Beschreibung von Web Services sagen etwas für die Nutzbarkeit aus.
Der im Jahr 2005 revidierte "Semantic Web Layer Cake": Die Basis bilden die existenten Web-Technologien (URI, Unicode, XML, Namespaces); darauf folgt die Ontologie-Ebene (RDF, OWL, Rules, und SparQL).
Der im Jahr 2005 revidierte "Semantic Web Layer Cake": Die Basis bilden die existenten Web-Technologien (URI, Unicode, XML, Namespaces); darauf folgt die Ontologie-Ebene (RDF, OWL, Rules, und SparQL).

Die Idee von SOA besteht darin, eine Anwendung aus vielen kleinen Services zusammenzusetzen - möglichst automatisch. Dazu müssen aus einer Vielzahl von Web-Services jene dynamisch gefunden, kombiniert und ausgeführt werden, die zur Lösung einer spezifischen Nutzeranfrage erforderlich sind. Basierend auf semantischen Beschreibungen können Web-Services automatisch gefunden, kombiniert und ausgeführt werden. Die Grundlage stellen Ontologien dar - Wissensmodelle, die bedeutungserhaltende Informationsverarbeitung ermöglichen.

Kein SOA ohne Semantik: Zwei führende Tools dafür

Zwei Frameworks für Semantic Web Services wird große Beachtung geschenkt: Beide wurden als Vorschläge zur Standardisierung beim W3C eingereicht.

OWL-S - Chronologisch der erste Ansatz wurde innerhalb des Programms DARPA Agent Markup Language (DAML) in den USA entwickelt. Unter Verwendung der Web Ontology Language OWL (W3C Recommendation) wird ein Meta-Modell zur semantischen Annotation von Web-Services definiert. Dieses besteht aus drei Teilen:

Das Service Profile beinhaltet die funktionale Beschreibung des Web-Services sowie nicht-funktionale Aspekte und dient zum Auffinden und Selektieren.

À Das Service Model beschreibt die Realisierung des Web-Services als einen Prozess. Dies beinhaltet sowohl das Interface zur Konsumierung durch einen Nutzer als auch den Aufruf aggregrierter Web-Services als Teilprozesse.

à Das Service Grounding beschreibt die technischen Details zum Aufrufen des Web-Services (Endpoint, Protokolle etc.); dies wird durch ein "Grounding" der semantischen Beschreibung zu einer syntaktischen WSDL-Beschreibung definiert.

Web Service Modeling Ontology (WSMO) - Die Web Service Modeling Ontology (WSMO) ist der europäische Ansatz zu Semantic Web Services, entwickelt unter der Federführung des Digital Enterprise Research Instituts (DERI) an der Universität Innsbruck (www.deri.at). Im Gegensatz zu OWL-S definiert WSMO nicht nur ein Modell zur semantischen Beschreibung von Web-Services, sondern die semantische Beschreibung für vier Elemente: Ontologien als das Datenmodell, ein Beschreibungsmodell für Web-Services ähnlich jenem von OWL-S, Goals als formal beschriebene Nutzeranfragen und Mediators zum Auflösen und Behandeln von Heterogenitäten.

Diese werden als die Kernelemente von SOA-Systemen verstanden. Dabei sollen Endnutzer lediglich das zu lösende Problem definieren, während das System automatisch die zu benutzenden Web-Services auf Grundlage der semantischen Beschreibungen findet, kombiniert und ausführt. Damit geht WSMO einen Schritt weiter hin zu Semantic SOA, also der Realisierung der kompletten SOA-Vision auf Grundlage semantischer Technologien.

Das Konzept von Web-Services selbst wurde Ende der 90er-Jahre auf Initiative führender Softwarekonzerne entwickelt.

Mit diesen Technologien kann man also prinzipiell Web-Services bereitstellen, finden, und ausführen. Allerdings ist dies noch sehr weit entfernt von der Realisierung der SOA- Vision. Der einzige automatisierte Prozess ist die konkrete Ausführung eines Web-Services durch den Austausch von SOAP-Messages. Die gesamte vorhergehende Nutzbarkeitsanalyse - das Wesentliche zur wirklichen Nutzung von Web-Services im Sinne von SOA - erfordert menschliche Intervention. Das ist nicht trivial.

Insbesondere treten dabei folgende Schwierigkeiten auf:

Auffinden des richtigen Web-Services

Zunächst muss man den richtigen Web-Service finden. Dabei ist zum einen eine sehr große Menge von Web-Services zu erwarten - mehrere Millionen, wenn man als grobe Größenordnung zu Grunde legt, dass jede derzeit registrierte .com-domain mindestens einen Web-Service anbietet. Zum anderen treten die funktionalen Unterschiede gleichartiger Web-Services zumeist im Detail auf - zum Beispiel die unterschiedlichen Lieferkonditionen von Transport- und Logistikanbietern.

À Feststellen der Nutzbarkeit

Nachdem der richtige Web-Service gefunden ist, muss der Nutzer die richtigen Informationen in der richtigen Reihenfolge bereitstellen können, um den Web-Service aufzurufen. Die relevanten Anforderungen stehen in der WSDL-Beschreibung - allerdings sind darin lediglich die möglichen Messages auf syntaktischer Ebene beschrieben. Daher muss der Nutzer diese manuell analysieren und dann ein kompatibles Gegenstück bereitstellen, um den Web-Service zur Lösung der spezifischen Anfrage nutzen zu können.

à Behandlung von Heterogenitäten

Gemeinhin bekannt als das Integrationsproblem, können Heterogenitäten auf verschiedenen Ebenen die erfolgreiche Nutzung eines Web-Services verhindern. Dies können unterschiedliche Datenformate oder -modelle sein sowie Unverträglichkeiten zwischen den öffentlichen Geschäftsprozessen des Anbieters und des Konsumenten.

Kurzum: Man braucht ausdrucksstärkere Beschreibungen von Web-Services sowie geeignete Mechanismen, um die Nutzbarkeitsanalyse von Web-Services besser zu unterstützen und zu automatisieren. Nur damit lässt sich die SOA-Vision wirklich realisieren. Der Ansatz von Semantic Web Services setzt sich genau das zum Ziel. Es werden detaillierte Beschreibungen der angebotenen Funktionalität sowie des Interfaces zur Nutzung eines Web-Service definiert. Diese Beschreibungen basieren auf Ontologien, also in logischen Sprachen spezifizierte Wissensmodelle. Auf Grundlage dieser semantischen Beschreibungen dienen inferenz-basierte Mechanismen zum Auffinden, Kombinieren und Ausführen von geeigneten Web-Services. Damit soll zum einen eine weitgehende Mechanisierung der Nutzenanalyse von Web-Services erreicht werden. Zum anderen soll das Integrationsproblem durch entsprechende Ontologie-Techniken behandelt werden.

Ontologien - Semantic Web

Die zentrale Basis für das Semantic Web sind Ontologien. In Anlehnung an die gleichnamige philosophische Disziplin ist dies eine Wissensmodellierungstechnik in der Künstlichen Intelligenz (KI). Darin ist eine Ontologie als "explizite Formalisierung eines geteilten konzeptionellen Modells" definiert, also ein konzeptionelles Modell einer Wissensdomäne, die von allen Beteiligten akzeptiert wird und so die Basis eines gemeinschaftlichen Verständnisses zum bedeutungserhaltenden Informationsaustausch bildet. Dabei soll implizites Wissen so weit wie möglich externalisiert werden, sodass widersprüchliche Interpretationen vermieden werden. Dieses Modell wird in einer geeigneten logischen, maschinenlesbaren Sprache formalisiert.

Sinn der erweiterten Beschreibung von Web-Services ist es, die Funktionalität, das Interface sowie weitere Aspekte eines Web-Services derart hinreichend zu beschreiben, dass die Nutzbarkeitsanalyse automatisiert werden kann. Ontologien sowie andere formale Sprachen dienen als Basis, sodass wir von einer semantischen Annotation eines Web-Services sprechen. Dabei müssen die syntaktischen Beschreibungen von Web-Services hin zu semantischen erweitert werden. Die wesentlichen Aspekte dabei sind:

Ontologien als Datenmodell: Sowohl jedes Beschreibungselement als auch alle Daten, die zwischen einem Web-Service und dessen Nutzer ausgetauscht werden, sind einer Ontologie zugeordnet. Damit werden die Vorteile von Ontologien zur semantischen Informationsverarbeitung genutzt und die Integration mit dem Semantic Web gesichert.

À Formale, explizite Funktionalitätsbeschreibung: Als neuer Aspekt wird die von einem Web-Service angebotene Funktionalität explizit beschrieben. Formal wird dies durch Preconditions (Bedingungen vor dem Aufrufen des Web-Services) und Effects (Bedingungen nach erfolgreicher Ausführung) definiert. Diese Beschreibung ist vor allem für das Auffinden der richtigen Web-Services relevant.

à Formale Interface-Beschreibung: Zur Automatisierung der Nutzbarkeitsfeststellung wird das Web-Service-Interface reicher beschrieben. In Ergänzung zu den Informationen in der WSDL-Beschreibung werden vor allem die möglichen Abfolgen des Informationsaustauschs in formalen Prozesssprachen definiert. Außerdem beschreibt ein weiteres Interface das Verhalten eines Web-Services zur Interaktion mit anderen Web-Services, sodass komplexere Web-Services als Kompositionen definiert werden können.

Õ Nicht-funktionale Aspekte: Diese umfassen Informationen über den Anbieter sowie Quality-of-Service-Aspekte (Sicherheit, Erreichbarkeit und Stabilität, örtliche Bezogenheiten etc.)

Service automatisch finden

Auf der Grundlage derartig annotierter Web-Services sowie von Ontologien können intelligente, inferenzbasierte Mechanismen zur Automatisierung der kompletten Nutzbarkeitsanalyse und Ausführung von Web-Services definiert werden.

Wie in der SOA-Vision angedacht, werden für eine konkrete Anfrage die nutzbaren Web-Services automatisch gefunden und ausführt. Zuerst werden die potenziell nutzbaren Web-Services gesucht; dies geschieht durch semantisches Matchmaking hinsichtlich der funktionalen Beschreibungen (Discovery). Sollte kein direkt nutzbarer Web-Service gefunden werden, wird eine Kombination mehrerer Web Services erstellt (Composition). Als Nächstes werden die gefundenen Web-Services und Kompositionen im Hinblick auf die nicht-funktionalen Aspekte gewichtet und selektiert (Selection). Als letzter Schritt der Nutzbarkeitsanalyse wird die Aufrufbarkeit im Hinblick auf das Interface geprüft, also ob der Konsument den vom Web-Service angebotenen Kommunikationsprozess unterstützen kann (Behavioral Conformance). Wenn dies erfolgreich beendet ist, wird der Informationsaustausch zwischen Web-Service und Anfrager durchgeführt (Execution).

Mediatoren erleichtern Integration

Im Hinblick auf das Integrationsproblem werden zusätzlich sogenannte Mediatoren genutzt. Diese stellen Mechanismen zur Verfügung, die möglicherweise auftretende Heterogenitäten auflösen und behandeln können. Dabei werden die Heterogenitäten auf semantischer Ebene analysiert, also auf struktureller Grundlage der formalen Beschreibung und nicht fallspezifisch für eine konkrete Anfrage. Für Web-Services sind dabei zwei Arten von Mediationstechniken von zentraler Bedeutung:

l Data-Level-Mediation: Dies bezieht sich auf Heterogenitäten, die auf Grund der Benutzung unterschiedlicher Datenformate und -modelle durch Web-Services-Anbietern und -Nutzer entstehen. Erstere werden durch Adapater gelöst, die zwischen Datenformaten konvertieren. Wichtiger und komplizierter handzuhaben sind konzeptionelle Unterschiede, die durch die Verwendung unterschiedlicher Ontologien entstehen. Zu deren Behandlung werden semantische Integrationstechniken verwandt - einer der wesentlichen Vorteile von Ontologien als Wissensrepräsentationstechnik. Das Herzstück dabei sind Ontology Mappings, die eine semantische Brücke zwischen heterogenen Ontologien definieren - zum Bespiel, dass alle "Erwachsenen" aus der Ontologie A identisch sind mit "alle Personen über 18 Jahre" aus der Ontologie B. Damit kann eine bedeutungserhaltende Interaktion gewährleistet werden.

l Process-Level-Mediation: Dies bezieht sich auf Heterogenitäten zwischen den öffentlichen Geschäftsprozessen von Web-Services-Anbietern und -Nutzern. Diese manifestieren sich in Inkompatibilitäten der Interfaces von Web-Services, die interagieren sollen. Zu deren Lösung werden sogenannte Process Mediation Patterns definiert, wie zum Beispiel die Umkehrung zweier Messages. Dadurch kann die Kompatibilität von Web-Service-Interfaces hergestellt werden, wenn dies a priori nicht gegeben ist.

Michael Stollberg ist Mitarbeiter am DERI - Digital Enterprise Research Institute Institute for Computer Science University of Innsbruck (E-Mail: michael.stollberg@deri.org).