Semantik, Odem einer Service-orientierten Architektur

Wolfgang Dostal und Mario Jeckle
Erschienen in der Ausgabe Feb./März (1/2004), Seiten 53-56, der Zeitschrift Java Spektrum

Derzeit steigt die Anzahl von Vorschlägen, Empfehlungen und Standards im Umfeld der Web Services stetig. Es werden nahezu alle Aspekte die eine Technologie für eine Service-orientierte Architektur auszeichnen abgedeckt. Das Hauptaugenmerk der Diskussion und Standardisierung liegt momentan noch auf den Themen Sicherheit und Workflow. Zweifelsohne sind dies wichtige Schlüsselthemen, deren erfolgreiche Umsetzung, entscheidend für den Erfolg von Web Services sind. Für die vollständige Umstellung der Vision der Service-orientierten Architektur muss jedoch auch das Thema Semantik betrachtet werden. Bislang haftet diesem Thema noch ein Hauch von Esoterik und akademischer Abgehobenheit an. Aus Sicht der Gartner Group wird dies jedoch nicht mehr lange der Fall sein. [GAR]

back to top   Agenda

 

Unser Ziel mit dieser Artikelserie ist es, zu zeigen, dass Semantik nicht nur was für „Gurus“ ist, sondern eine Notwendigkeit ist. Wir werden zeigen, dass Semantik bedeutend ist(1), von uns allen bereits genutzt wird und das Web Services als ein Träger von Semantik geeignet ist. Dazu haben wir die Diskussion in vier Artikel aufgeteilt:

Der vorliegende Artikel diskutiert die Aussage: Semantik, Odem einer Service-orientierten Architektur. Um diese Aussage zu „beweisen“, werden in dieser Artikelserie konkret Web Services, als derzeitig populäres Technologiekonzept einer Service-orientierten Architekturen (SOA), betrachte.

back to top   Service-orientierte Architekturen

 

Die Idee einer Service-orientierten Architektur ist keine Erfindung die mit der Erfindung von Web Services entstanden ist. Das SOA-Konzept ist bereits in den 90er Jahren beschrieben worden. Seitdem wurde dieses Konzept weiter ausgearbeitet und verfeinert.
Kernelement einer Service-orientierten Architektur ist der Service (Dienstleistung). Dieser Begriff ist kein ursprünglicher IT-Begriff, und jeder wird schon einmal über die Bedeutung des Begriffs Service nachgedacht haben. Ob bei der Nutzung von öffentlichen Verkehrsmitteln, beim Friseur oder abgeben der Steuererklärung, jeder nimmt täglich Services in Anspruch. Es handelt sich um eine Leistung die ein Dritter für uns erbringt von der wir vor der Inanspruchname wissen was sie leistet, kostet und in welchem Zeitraum sie erbracht wird. Wie gut oder schlecht diese Leistung letztendlich durchgeführt wird und welche Konsequenzen daraus entstehen ist ein Thema für sich, was mehr als Technik beinhaltet.
In Abbildung 1 sind die Elemente einer Service-orientierten Architektur, dem SOA-Tempel, widergegeben. Basis der gesamten Architektur sind die drei Stufen unterhalb der Säulen:

Alle diese Eigenschaften erscheinen so selbstverständlich, dass sie gerne als gegeben angesehen werden.

Abbildung 1Der Tempel der Service-orientierten Architektur
Der Tempel der Service-orientierten Architektur
(click on image to enlarge!)

Auf diesem Fundament ruhen die vier Säulen (Merkmale), die zusammen das Dach der Service-orientierten Architektur stützen.

Bleibt abschließend noch zu klären, wer die Nutzer (Akteure) einer Service-orientierten Architektur sind. Im Unterschied zu einer Browser-Anwendung, steht im SOA-Konzept die automatisierte Kommunikation zwischen Anwendungen im Mittelpunkt der technologischen Überlegungen. Letztendlich ist zwar der Mensch der Nutznießer, im SOA-Konzept allerdings „nur“ mittelbar.

back to top   Web Services

 

In Abbildung 2 ist das wohlbekannte Beziehungsdreieck mit den Akteuren Requestor, Provider und Broker einer Service-orientierten Architektur dargestellt. Üblicherweise wird dies Darstellung in einem Atemzug mit den Web Services spezifischen Komponenten SOAP, WSDL und UDDI dargestellt, was mitunter suggeriert, dass Service-orientierte Architektur und Web Services lediglich Synonyme sind. Um das volle Potenzial einer SOA entfalten zu können, ist es jedoch wichtig, Web Services als eine Implementierungsmöglichkeit einer Service-orientierten Architektur zu erkennen. Andere Ansätze Service-orientierte Architekturen umzusetzen sind CORBA, DCOM und RMI.
Ein Vorteil von Web Services ist es, dass sie auf XML basieren Standards -- Standards -- damit ist die Grundlage für eine breite Akzeptanz -- Akzeptanz -- gelegt. Da in den ersten Tagen dieser Technologie das Web aus Web Services häufig mit HTTP gleichgesetzt wurde, konnte zumindest eine einfache Absicherung des Datenaustausches erreicht werden -- Sicherheit. Durch die Nutzung von HTTP sind Web Services per se geeignet zur Entwicklung von verteilten Anwendungen -- Verteilung. Die anfängliche Fokussierung auf den RPC-Stil(3) machte es möglich schnell und unkompliziert mit Hilfe von Codegeneratoren die entsprechenden Kommunikationsklassen aufzubauen - Einfachheit. Den anderen Aspekt der Einfachheit können Web Services erfüllen, da im Rahmen einer Web-Services-Kommunikation „lediglich“ Daten kopiert werden. Im Gegensatz zu anderen Technologie -- z. B. CORBA -- werden Service-Nutzer und Anbieter damit nicht über eine gemeinsame Objektnetzstruktur miteinander gekoppelt.

Abbildung 2Das Beziehungsdreieck einer Service-orientierten Architektur aus Sicht der Web-Services-Technologie
Das Beziehungsdreieck einer Service-orientierten Architektur aus Sicht der Web-Services-Technologie
(click on image to enlarge!)

Die aktuelle, große Herausforderung für die Web Services ist die Erfüllung der Anforderung der Prozessorientierung. Diese Anforderung stellt bisher üblichen Annahmen über einige Aspekte von Web Services in Frage. Zur Verdeutlichung wird dies am Beispiel von SOAP kurz erläutert.

Wichtig ist anzumerken, dass diese üblichen Annahmen nicht durch die entsprechenden Spezifikationen erzwungen werden.

back to top   Automatisierte Dienstnutzung

 

Der einfache Teil der oben beschriebenen Rückkopplungen der Prozessorientierung ist, dass in den Bereichen Kommunikation, Transport und Sicherheit „lediglich“ eine Überarbeitung bestehender Konzepte benötigt wird. Komplizierter gestaltet sich der Sachverhalt bei der Automatisierung der Dienstnutzung. Woher weiß eine Anwendung, welche Services sie nutzen soll, um ein gesetztes Ziel zu erreichen? Bei genauer Analyse dieser Frage rückt der Aspekt der Bedeutung (Semantik) eines Services in den Mittelpunkt.

Betrachtet man die bisherige Entwicklung der Internet-Technologien, so fällt auf, dass bisherige Spezifikation hauptsächlich einen syntaktische Rahmen definieren. Bei der Beschreibung eines Services mittels WSDL verbleibt die Bedeutung des Services im Kopf des Anbieters und wird nicht in das WSDL-Dokument übertragen. Diese fehlende explizite Beschreibung der Semantik wird zunehmend als Hindernis für eine „vollständige“ Automatisierung eingestuft [DB].

Abbildung 3Der Weg zu Semantic Web Services
Der Weg zu Semantic Web Services
(click on image to enlarge!)

Die Ursachen dafür, dass Web Services hauptsächlich auf syntaktischen Spezifikationen basieren, ist aus deren Historie zu sehen. In Abbildung 3 ist dargestellt, dass Web Services ihren Ursprung im Internet (WWW) haben. Das WWW mit Browsern als clientseitiges Endgerät ist auf direkte Interaktion eines vernunftbegabten Akteurs mit einer Anwendung ausgerichtet. Die Bedeutung einer Web-Seite entsteht im Kopf des Akteurs. Die Seitenbeschreibungssprache -- HTML -- muss lediglich Informationen übermitteln, auf welche Art eine übermittelte Information dargestellt werden soll. Dazu muss der Browser nicht „wissen“ bzw. ableiten können, was die dargestellte Information bedeutet. Syntaktische Information, wie dies ist eine Überschrift auf dem Level 1 (>H1>) reichen aus.

Web Services stellen einen wichtigen Schritt in Richtung Automatisierung des Datenaustauschs dar. Dies Technologie gibt den syntaktischen Rahmen vor wie Services beschrieben (WSDL), gefunden (UDDI) und Daten ausgetauscht werden (SOAP). Bis auf die Auswahl des geeigneten Services kann somit ein großer Teil der Kommunikation weitegehend automatisch ablaufen.

Der Bedarf nach Semantik zeichnete sich jedoch bereits in den Anfängen der Web Services ab. Interessanter Weise manifestierte sich dies am deutlichsten in der Komponente UDDI, die aktuell etwas in das Kreuzfeuer der Kritik geraten ist. Momentan ist unklar, wie diese Komponente sinnvoll genutzt werden kann. Bereits jetzt können Service-Anbieter mit Hilfe von Klassifizierungssystemen (Taxonomien) wie DUNAS(5) eindeutig eingeordnet werden. D. h. der Eintrag in der UDDI ist mit einer bestimmten Bedeutung verbunden.

Das Auffinden eines bestimmten Services ist allerdings lediglich über eine bloße Schlüsselwortsuche realisiert. Für das automatische Auffinden ist dies oft nicht ausreichend, da die Begriffe des Alltags nicht immer eindeutig bzw. Kontextabhängig sind. Deshalb bieten neuere UDDI-Implementierungen die Möglichkeit auch einen Service mit Bedeutung zu versehen.

Für die Verknüpfung eines Services -- bzw. eines beliebigen Elements einer Web-Services-Kommunikation -- mit einer eindeutigen Bedeutung, muss eine weitere Beschreibungssprache in das Web-Services-Konzept eingeführt werden. Dabei vefolgt die Web-Services-Community den bisher erfolgreichen Weg, bereits existierende Standards, die eine gewünschte Funktionalität erfüllen, zu integrieren. Im Fall von Semantik ist dies das Semantic Web.

back to top   Semantic Web

 

Im Grunde faßt das Schlagwort Semantic Web seit 2001 alle zuvor isoliert vorangetriebenen Bestrebungen das Web in seiner gegenwärtig von HTML-Inhalten dominierten Form um „Bedeutung“ anzureichern zusammen. Ausgangspunkt dieser Begriffsbildung ist ein gemeinsam von Tim Berners-Lee, James Hendler und Ora Lassila verfaßter Artikel [BLH+01] in der renommierten Zeitschrift Scientific American. Darin stellen die Autoren ihre Vision einer maschinengestützten Interaktion zwischen Menschen vor, die deutlich über die gegenwärtig anzutreffenden technischen Unterstützungsformen wie E-Mail, Web-Seiten und mobiler Telephonie hinausreicht. Im Kern entwirft der Artikel das Bild einer Welt in der Menschen ihre alltäglichen Aufgaben (die Autoren diskutieren eine verteilte Terminabstimmung zwischen Familienmitgliedern) unter Nutzung von Technik leichter und effizienter abwickeln können. Die hierzu verwendete Technik unterscheidet sich von den aktuell gängigen „elektronischen Helferlein“ dadurch, daß die zur Aufgabenerfüllung heranzuziehenden Daten (wie bereits vereinbarte Termine, freie Zeit und persönliche Planungspräferenzen) in ihrer Bedeutung der Maschine bekannt sind. Die notwendige Bedeutungszuschreibung erfolgt hierbei durch den maschinenbedienenden Menschen, weshalb ein Kalender auch zukünftig nichts über eingetragene Geburtstage „wissen“ muß, sondern lediglich anhand des Eintragstyps und seinen festgelegten Charakteristika erkennt, daß es sich um einen nur schwerlich verschiebbaren Termin handelt.

Diese weiterhin bestehende tragende Rolle des Menschen ist daher gleich in zweifacher Hinsicht hervorzuheben. Das Semantische Web trachtet nicht danach die Aufgaben von Menschen zu übernehmen oder diesen zu ersetzen, den beteiligten Maschinen wird nicht einmal die Intelligenz zugebilligt selbst automatisiert Schlüsse aus den durch sie verwalteten Daten zu ziehen. All diese Vision, die an den altbekannten HAL aus 2001 oder den etwas vorlauten C3-PO erinnern, werden weiterhin ins Reich der künstlichen Intelligenz (KI) verbannt, deren Verschmelzung mit dem Web ausdrücklich nicht Zielsetzung des Semantic Webs ist. Vielmehr versteht sich diese Vision als Komplementierung des bestehenden Webs um Aspekte der Maschine-Maschine-Kommunikation; wenngleich auch einige Termini und Basistechniken dieses Forschungszweiges Eingang in die Aktivitäten gefunden haben.

Vor diesem Hintergrund wird auch offenbar, daß das diese Erweiterung des heutigen Webs keines Semantic Web Browsers als Präsentationskomponente bedarf, da die erzeugten, augetauschten und verarbeiteten Daten ausschließlich der Konsumption durch maschinelle Agenten vorbehalten sind. Als Agent wird hierbei jede Softwarekomponente aufgefaßt, die im Namen einer natürlichen oder juristischen Person oder eines Prozesses agiert. Diese pragmatische Definition grenzt absichtsvoll weitergehende Ansätze (wie autonome Auftragserfüllung oder dynamsiche Zustandsmigration) der KI aus und gewährleistet gleichzeitig die begriffliche Kompatibilität zum klassischen WWW, welches durch Web Agenten (d.h. Browser) bedient wird.

Gleichzeitig wird das Semantische Web als Erweiterung der beiden Basiselemente Hypertext-Seite und Link des sichtbaren HTML-basierten verstanden. Während die herkömmlichen Hyperlinks des Ankerelements es bereits gestatten innerhalb einer HTML-Seite auf Inhalte beliebigen Typs -- etwas andere Web-Seiten, Dokumente oder Binärdaten - zu verweisen faßt das Semantische Web die Beziehungsquellen und -ziele einheitlich als Ressourcen auf. Zwischen den, anhand der Linkstruktur zugänglichen, Ressourcen werden jedoch nicht mehr ausschließlich gleichartige Beziehungen etabliert, sondern die gebildeten Verknüpfungen anhand ihrer Bedeutung unterschieden. So kann eine Ressource durch eine Beziehung des Typs erstellt durch auf eine andere Ressource verweisen, die Daten über den Autor bereithält, während diese wiederum durch einen Link des Typs E-Mailadresse auf eine Ressource verweist, welche die Mailadresse des Autors enthält.

Bereits dieses Beispiel läßt deutlich werden, daß die denkbaren Beziehungstypen so zahlreich sind, daß keine zentrale Instanz diese vorhersehen oder vorgeben kann. Auch mit dieser Erkenntnis stützt sich das Semantische Web auf den Grundideen des WWW ab. Seinem Ansatz verteilter Datenablage liegt die Überzeugung zu Grunde durch Dezentralisierung der Verantwortung ein größeres System stärker funktionsfähig zu halten (relativ zur Gesamtgröße gesehen sind Fehler der Nummer 404 vergleichsweise selten, wenngleich selten ärgerlich), als es eine Umsetzung mit genau einer Koordinierungsinstanz erlauben würde. Daher steht es dem Autor im Semantischen Web offen, die von ihm benötigten Beziehungstypen selbst geeignet zu definieren.

Um die Funktionsfähigkeit des Gesamtsystems zu erhalten muß sich jedoch jeder Autor derselben Sprache zur Formulierung seiner Inhalte bedienen. Zu diesem Zweck bietet das W3C mit RDF einen gleichermaßen einfachen wie mächtigen Ansatz zur Beschreibung von Ressourcen und ihren Abhängigkeiten an, der wie XML keine inhaltliche Übereinstimmung herbeizuführen sucht, sondern sich wie dieses auf die Festschreibung struktureller Übereinkünfte beschränkt.

So sinnvoll die Ablage von Bedeutung für Web-Seiten sein mag -- eröffnet sie doch gänzliche neue Möglichkeiten beispielsweise für Suchmaschinen -- so unabdingbar ist die Offenlegung von semantischen Informationen zu einem Web Service. Da sich diese ausschließlich an maschinelle Agenten wenden, ist eine manuelle Interpretation von beschreibenden Daten (etwas eines Handbuches oder einer textuellen Beschreibung der Nutzungsbedingungen) unmöglich. Mit WSDL ist bereits ein erster Schritt zur maschinenlesbaren Explizierung von Semantik unternommen worden. Allerdings beschränkt sich die Ausdruckskraft dieses Formates ausschließlich auf die Beschreibung von Daten über die zur Verfügung gestellte technische Schnittstelle sowie die einzuhaltenden Aufrufkonventionen.

Eine vollständig automatisierte Nutzung von Web Services wird erst dann möglich sein, wenn alle zur verläßlichen Nutzung notwendigen Informationen in einer maschinelesbaren Form abgelegt und zugreifbar sein werden.

back to top   Zusammenfassung

 

Ziel dieses Artikels war es den Bedarf von Semantik innerhalb einer Service-orientierten Architektur herauszuarbeiten, da ohne diese die Dreiecksbeziehung der Web Services zum „Bermudadreick“ degenerieren würde, in dem sich Unglücke während des Dienstaufrufs unerklärlich häufen würden. Zur Beleuchtung der Hintergründe wurden zuvorderst die Anforderungen an eine SOA beschrieben. Anschließend wurde am Beispiel von Web Services -- der aktuell populärsten SOA-Inkarnation -- dargestellt, das insbesondere die Anforderung der Prozessorientierung mit der automatisierten Service-Auswahl nur mit Semantik erfüllt werden kann.
Eine Service-orientierte Architektur kann demzufolge nur entstehen, wenn Syntax (Web Services) und Semantik (Semantic Web) ein gemeinsames Ganzes bilden. Dies kommt unserer Ansicht nach sehr gut im Ying-Yang-Bild zum Ausdruck.
Wie in der Abbildung dargestellt ist die Kerntechnik des Semantic Webs das RDF-Format. Diese werden wir im nächsten Artikel beschreiben und vorstellen, wie mit RDF ein XML-Dokument mit Semantik angereichert werden kann.

Abbildung 4Syntax (Web Services) und Semantik (Semantic Web) zusammen bilden die SOA
Syntax (Web Services) und Semantik (Semantic Web) zusammen bilden die SOA
(click on image to enlarge!)

back to top   Referenzen

 

back to top   Abbildungsnachweis

 

back to top   Anmerkungen

 

(1) Eine schöne Tautologie ;-)

(2) Allerdings ist Einfachheit in diesem Zusammenhang ein sehr relativer Begriff, der sehr stark vom Eindruck des jeweiligen Nutzers abhängt.

(3) Damit ist nicht notwendigerweise, die in der SOAP-Spezifikation beschriebene Syntax gemeint bzw. notwendig.

(4) Siehe dazu vorangegangene Fußnote.

(5) Mit Hilfe dieser neunstelligen Nummer kann ein Unternehmen eindeutig identifiziert werden. Die Nummern werden zentral von einem Unternehmen verwaltet.




separator line
Service provided by Mario Jeckle
Generated: 2004-06-11T07:11:39+01:00
Feedback Feedback       SiteMap SiteMap
This page's original location This page's original location: http://www.jeckle.de/semanticWebServices/intro.html
RDF metadata describing this page RDF description for this page