Web-Services sind plattformunabhängige Software-Komponenten zur Realisierung verteilter Anwendungen. Web-Services beschreiben hierbei die von Teilsystemen implementierten Funktionalitäten und machen diese über Standard-Internetprotokolle verfügbar. Teilsysteme sind nur lose über Nachrichten-Austausch zu Anwendungen gekoppelt.
Web-Service
(WSDL) und die Interaktion mit Web-Services über SOAP-Nachrichten die Kernelemente bei der Charakterisierung von Web-Services [Haas, Brown 2004]. WSDL und SOAP sowie die Mehrheit weiterführender Web-Service-Technologien (WST) basieren auf XML-Standards.
Ein Web-Service selbst ist lediglich ein Stellvertreter oder Vermittler implementierter Funktionalität, die in WSDL beschrieben und auf die über SOAP-Nachrichten von anderen Systemen zugegriffen werden kann (Web-Services sind für die Kommunikation zwischen Rechnern und nicht zwischen Mensch und Rechner konzipiert). Damit ist ein Web-Service abstrakt und Bedarf einer konkreten Soft- oder Hardwareimplementierung. Die eigentliche Implementierung ist, bei konstanter Web-Service-Schnittstelle, austauschbar; auch können bereits vorhandenen Softwarekomponenten (Legacy Systeme) Web-Service-Schnittstellen vorgeschaltet werden um diese über WST zu integrieren. Anstelle von Einzelprojekten zur Integration bestimmter Komponenten erreicht man damit einen einheitlichen, plattformunabhängigen Ansatz. Im Folgenden werden SOAP und WSDL vorgestellt.
Web-Service-Basistechnologien WSDL und SOAP
SOAP [Mitra, Lafon 2007] ist eine Spezifikation des W3C für das Layout von Nachrichten an und von Web-Services. Damit bildet SOAP die Kommunikationsgrundlage der Web-Services, da es die Grundstruktur sowie die Verarbeitungsvorschriften der Nachrichten vorgibt. SOAP ist, wie alle im folgenden aufgeführten Spezifikationen des W3C, plattformunabhängig. SOAP stand bis zur Version 1.2 im Jahr 2001 als Akronym für Simple Object Access Protocol. Da sich der Name als ungeeignet erwies, da man nicht mehr nur auf Objekte zugreifen kann sondern auf prinzipiell beliebige XML-strukturierte Inhalte, ist SOAP mittlerweile kein Akronym mehr.
SOAP-Nachrichten können über HTTP oder andere Internetprotokolle auf der Anwendungsschicht übertragen werden. Jede SOAP-Nachricht ist ein XML-Dokument mit Envelope als Wurzelelement, und hat optional einen oder mehrere Header. Ein Header enthält Meta- oder Kontrollinformation wie z.B. eine Nachrichtennummer oder Authentifizierungsdaten des Aufrufenden. Eine Nachricht hat genau einen Body, der die eigentlichen Nutzdaten enthält. In der Regel bestehen Nutzdaten aus dem XML-codierten Aufruf einer Web-Service-Operation inklusive den benötigten Parametern, wobei auch nicht XML-konforme Daten (z.B. binäre Daten) über SOAP versendet werden können. Optional kann der Body auch Fehlermeldungen enthalten. Neben dem klassischen Anforderung/Antwort-Interaktionsmuster können auch einzelne Nachrichten ohne Antwort verschickt oder beliebige andere Kommunikationsmuster realisiert werden. SOAP definiert, neben dem Aufbau einer Nachricht, auch ein Verarbeitungsmodell. Nach diesem Modell gibt es neben dem Absender und Empfänger einer Nachricht noch sogenannte Intermediaries, welche die Nachricht auf dem Weg vom Absender zum Empfänger bearbeiten und im Anschluss weiterleiten. Diese Intermediaries führen ihre Aktionen (z.B. Protokollierung, Abrechnung) typischerweise anhand der Information im Nachrichten-Header aus.
WSDL (Web Service Description Language ) [Chinnici, Moreau, Ryman 2007] dient dem Zweck, die Schnittstellen eines Web-Services zu beschreiben. Diese Informationen werden für einen Zugriff auf einen Web-Service benötigt. Beispielsweise muss dem Aufrufer die URI des Web-Services sowie der Name der aufzurufenden Web-Service-Operation (Funktionalität) und das zu übergebende Parameterset bekannt sein. Ein WSDL-Dokument deklariert, welche eingehenden Nachrichten der Web-Service erwartet, welche ausgehenden Nachrichten (Antwort oder Fehlermeldung) der Web-Service erzeugt und welche Operationen der Web-Service anbietet. Ein sogenannter Port Type bündelt eine Menge von Operationen, die mit denselben Mechanismen (i.e., Binding) aufgerufen werden können, d.h. ein Port Type definiert eine Schnittstelle eines Web-Services. Weiter wird definiert, welche Übertragungsprotokolle (HTTP, SMTP, FTP etc) zum Nachrichtenaustausch verwendet werden, wie die Nachrichten kodiert werden und letztlich unter welcher URI, also unter welcher Internet-Adresse, man Nachrichten an den Web-Service schicken kann.
Weitere Web-Service-Technologien
Aufbauend auf WSDL und SOAP existieren zahlreiche weitere Technologien, die sich jeweils spezifischen Problemstellungen bei der Umsetzung von Web-Service-Architekturen annehmen.
Web-Service-Verzeichnisdienste ermöglichen die Publikation von Dienstbeschreibungen über standardisierte Schnittstellen und erlauben potenziellen Dienstnutzern eine strukturierte Suche nach geeigneten Diensten entsprechend unterschiedlicher Suchkriterien wie Firmenname, Diensttyp, etc. Über automatisiertes Suchen und Finden von Diensten und dynamisches Einbinden in Anwendungen kann unter Verwendung von Verzeichnisdiensten über WST eine Service-Orientierte Architektur (SOA) realisiert werden. Für Verzeichnisdienste existieren mehrere Spezifikationen. Bekannte Vertreter hiervon sind Web-Services Inspection Language (WS-Inspection) [Ballinger et al. 2007] sowie Universal Description, Discovery and Integration (UDDI) [OASIS 2004]. WS-Inspection ist eine gemeinsame Spezifikation von IBM und Microsoft und bietet im Vergleich zu UDDI ein einfaches Konzept zum Finden von Web-Services. Angebotene Web-Services werden hierbei über ein WS-Inspection-Dokument veröffentlicht, welches Verweise auf Web-Service-Beschreibungen wie WSDL-Dokumente oder auch auf UDDI-Einträge enthält, in denen die Dienstbeschreibungen vorliegen. Auch können UDDI-Einträge auf WS-Inspection-Einträge verweisen. Während WS-Inspection das Konzept verfolgt, viele dezentrale, kleine Verzeichnisse anzubieten in denen wenige Anbieter ihre Dienste veröffentlichen, ist UDDI auf wenige, zentralisierte Verzeichnisse mit vielen Anbietern und Diensten ausgelegt. UDDI wird daher oftmals mit den weißen und gelben Seiten eines Telefonbuches verglichen. UDDI wurde von Ariba, Microsoft und IBM ins Leben gerufen. Seit 2005 wird die Standardisierung und Weiterentwicklung von UDDI von der Organization for the Advancement of Structured Information Standards (OASIS) übernommen. UDDI bietet Schnittstellen, über die Web-Services nach verschiedenen Kriterien gesucht werden können. UDDI enthält hierfür zahlreiche Möglichkeiten der Beschreibung und Kategorisierung von Diensten auf fachlicher und technischer Ebene sowie Informationen über die Organisation, die Dienste bereitstellen.
Semantic Web-Services (SWS) sind Web-Services, deren Beschreibungen über rein syntaktische Schnittstellenbeschreibung hinaus mit semantischen Inhalten angereichert werden. Ziel ist es, ihr Auffinden, Auswählen, Ausführen und die Komposition mit anderen Web-Services zu vereinfachen. Zum Einsatz kommen hierfür Techniken aus dem Bereich des Semantic Web. Diese Techniken sollen es ermöglichen, Informationen nicht nur für Menschen sondern auch für Computer interpretier- und weiterverarbeitbar zu machen. Grundlegend hierfür sind semantische Annotationen (zusätzliche Informationen) in den Dienstbeschreibungen, die über Ontologien miteinander logisch in Beziehung gesetzt werden. Diese Beziehungen beruhen damit auf Eigenschaften, die den Web-Services spezifisch zugewiesen oder logisch geschlossen werden können. Im Jahr 2008 beschäftigen sich mehrere Gruppen des W3C mit der Erarbeitung von Empfehlungen für Semantic Web-Services. Zum Zeitpunkt der Erstellung dieses Artikels wurde noch keiner der eingereichten Vorschläge wie Web Service Semantics (WSDL-S) [Akkiraju et al. 2005], oder Web Ontology Language for Services (OWLs) [Martin et al. 2004] als Empfehlung verabschiedet.
Sicherheit spielt in verteilten Umgebungen wie Web-Service-Architekturen eine wichtige Rolle, insbesondere wenn Nachrichten über das Internet mit Partnerfirmen ausgetauscht werden. Für den Nachrichtenaustausch zwischen zwei Endpunkten beispielsweise über HTTP kann auf etablierte Sicherheitsverfahren wie IP-Sec und TLS zurückgegriffen werden, über die der Anrufer authentifiziert, die Nachricht signiert und der Inhalt der Nachricht verschlüsselt werden kann. Für komplexere Web-Service-Architekturen reichen diese Sicherheitsmechanismen nicht aus, da SOAP-Nachrichten mehrere Intermediaries passieren und hierbei über Pfade gesendet werden. Auch können andere Anwendungsprotokolle als HTTP für den SOAP-Nachrichtentransport verwendet werden. Technologien wie TLS oder IP-Sec berücksichtigen nicht die End-to-End-Sicherheit, die hier erforderlich ist.
Die Web-Service Security-Spezifikation (WS-Security) [OASIS 2006a] beschreibt einen Ansatz, einen sicheren Kontext in einem Nachrichtenpfad mit mehreren Punkten herzustellen. WS-Security bietet hierfür eine Vielzahl von Sicherheitslösungen. OASIS hat die WS-Security-Spezifikation 2004 als Empfehlung unter dem Namen OASIS Web Services Security (WSS) bestätigt. WS-Security baut weitgehend auf etablierte Standards auf. So werden Kerberos und X.509 für die Authentifizierung eingesetzt; für die Signierung und Verschlüsselung von SOAP- Nachrichten sowie die Übertragung von Sicherheitstokens setzt WS-Security die Standards XML-Signature und XML-Encryption des W3Cs ein.
Web-Services Resource Framework(WSRF) [OASIS 2006b] ist in Bündel von Spezifikationen zur Standardisierung der Verwaltung von Zustandsinformationen von Web-Services. Web-Services sind zunächst zustandslos, speichern also keine kunden- oder sitzungsbezogenen Informationen beispielsweise vorangegangener Aufrufe. Zur Realisierung komplexerer Anwendungen sind jedoch typischerweise Authentifizierung, Transaktionen oder andere zustandsbezogene Operationen notwendig. Bis 2007 gab es keinen Standard für Web-Services zur Zustandsverwaltung, was zur Entwicklung proprietärer Lösungen führte. Daraus resultierte eine erhöhte Komplexität beim Austausch und der Integration von Web-Services, da hierfür Kenntnisse über deren Implementierungen der Zustandsverwaltung notwendig waren. Ziel des WSRF ist die Umgehung dieses Integrationsproblems. Das hauptsächlich von der Globus Alliance and IBM für das Grid-Computing entwickelte WSRF wurde 2004 veröffentlicht und ermöglicht die Ausführung von Grid-Services als zustandsbehaftete Web-Services. Damit stellt es eine Symbiose des Grid- und des Web-Services-Computing dar. Im Jahr 2006 wurde WSRF von OASIS als Empfehlung freigegeben. Kern des WSRF ist die Trennung zwischen Zustandsinformationen und dem Web-Service selbst. Die Zustandsinformationen werden in einer XML-Datenstruktur, einer sogenannten
Ressource, gespeichert, deren eindeutiger Name bei jeder Anfrage an den Web-Service mit übertragen wird. Daneben standardisiert das WSRF auch die Verwaltung des Lebenszyklus einer Ressource.
Komposition von Web-Services ermöglicht die Realisierung von Geschäftsprozessen mit Hilfe von Web-Services. Komposition bezeichnet das Zusammenfügen mehrerer Services zu einer Geschäftsanwendung bzw. einem Geschäftsprozess. Ansätze zur Komposition sind Orchestrierung und Choreographie von Web-Services.
Literatur
Haas, Hugo; Brown, Allen: W3C Web Services Glossary (2004). http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211 (Abruf 3.8.2008).
Chinnici, Roberto ; Moreau, Jean-Jaques ; Ryman, Arthur ; Weerawarana, Sanjiva: Web Services Description Language (WSDL) Version 2.0: Part 1 Core Language – W3C Recommendation (2007). http://www.w3.org/TR/wsdl20 (Abruf 4.8.2008).
Mitra, Nilo ; Lafon, Yves : SOAP Version 1.2 Part 0: Primer Specification – W3C Recommendation (2007). http://www.w3.org/TR/2007/REC-soap12-part0-20070427/ (Abruf 4.8.2008).
Ballinger, Keith; Brittenham, Peter; Malhotra, Ashok; Nagy, William A.; Pharies, Stefan: WS-Inspection : Web Services Inspection Language (2007). http://www.ibm.com/developerworks/library/specification/ws-wsilspec/ (Abruf 5.8.2008).
OASIS UDDI Spec. TC: UDDI Specification Version 3.0.2 (2004).http://www.oasis-open.org/specs/#uddiv3.0.2 (Abruf 3.8.2008).
Martin, David ; Burstein, Mark ; Hobbs, Jerry ; Lassila, Ora ; McDermott, Drew ; McIlraith, Sheila ; Narayanan, Srini; Paolucci, Massimo; Parsia, Bijan; Payne, Terry; Sirin, Evren; Srinivasan, Naveen; Sycara, Katia: OWL-S (Web Ontology Language for Services) – W3C Member Submission (2004). www.w3.org/Submission/OWL-S/ (Abruf 1.8.2008).
Akkiraju, Rama, Farrell, Joel; Miller, John; Nagarajan, Meenakshi; Schmidt, Marc-Thomas; Sheth, Amit; Verma, Kunal: WSDL-S Web Services Semantics – W3C Submission (2005). http://www.w3.org/Submission/WSDL-S/ (Abruf 7.8.2008).
OASIS Web Services Security TC: OASIS Web Services Security (WSS) Specification(2006a). http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss (Abruf 6.8.2008).
OASIS WSRF TC: WSRF Specifications (2006b). http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrf (Abruf 1.8.2008).
