Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

31.10.2003 - 

Web-Services/Web-Services sind keine Spielwiese mehr

Der Startschuss ist längst gefallen

Nahezu alle Hersteller haben sich die Unterstützung von WebServices in ihren Produkten auf die Fahnen geschrieben. Trotz der zum Teil noch unterschiedlichen Implementierungen sowie der Lücken mancher Spezifikationen: Der Durchbruch dieser Technik ist nur noch eine Frage der Zeit.Von Manfred Hein und Henner Zeller*

Web-Services sind das Ergebnis der konsequenten Umsetzung des Gedankens "Der Computer ist das Netz". Einträchtig kommunizieren hier Java-Applikationen mit .NET-Anwendungen, Windows-Programme mit Unix-Servern. Web-Services basieren auf der Extensible Markup Language (XML) zur Datenpräsentation, einem Format, das auf der Trennung von Struktur und Repräsentation beruht. Aus diesem Grund ist es im Gegensatz etwa zu HTML sehr gut zum Datenaustausch geeignet, weshalb sich verschiedene Ansätze von einfachen Web-Services im Netz entwickelt haben. Im einfachsten Fall werden lediglich XML-Dokumente über HTTP ausgetauscht.

Ein leichter Ansatz für den Funktionsaufruf über XML ist XML-RPC (RPC = Remote Procedure Call). Es beschreibt einen Basismechanismus, wobei sich die komplette Spezifikation für XML-RPC leicht auf einer DIN-A4-Seite unterbringen lässt. Daran ist schnell erkennbar, dass hier noch einige Wünsche offen sind. So gibt es weder standardisierte Methoden, einen solchen Dienst im Netz zu finden, noch die Aufrufkonventionen zu ermitteln.

Die aktuellste Technologie auf dem Gebiet des XML-basierenden Datenaustauschs ist das Simple Object Access Protocol (Soap), das einen Schritt weiter als XML-RPC geht und nicht nur Signaturen und Strukturen in XML abbildet, sondern als komplette Zugriffs-Schnittstelle auf Objekte fungiert. Der Nachteil von Soap ist die aufwändige Implementierung, denn fasst man alle Spezifikationen zusammen, die dafür existieren, kommt man leicht auf einige hundert Seiten.

Standardkomponenten sind der Schlüssel

Die Entwicklung der Soap-Spezifikation fand unter Beteiligung von IBM und Microsoft statt. Dies war 1999 ein Novum, da frühere Protokolle zumeist isoliert entwickelt wurden und nicht kompatibel zueinander waren. Ein Schlüssel für die Interoperabilität ist, dass Soap in flexibler Form bereits standardisierte Komponenten verwendet und diese leicht kombinierbar macht. So ist es beispielsweise für eine Soap-Implementierung egal, ob als unterliegendes Transportprotokoll HTTP, SMTP oder FTP verwendet wird.

Trotz der gemeinsamen Spezifikation fielen die Soap-Implementierungen der einzelnen Hersteller im Detail durchaus unterschiedlich aus. Dies hatte in der praktischen Anwendung zur Folge, dass die Interoperabilität zumindest in Teilen dann doch nicht gewährleistet war.

Neben der Präsentation, dem Zugriff und der Versendung von Daten existieren weitere Technologien, um Web-Service-Dienste zu beschreiben beziehungsweise zu publizieren und aufzufinden. Hierzu dienen die Web Service Definition Language (WSDL) sowie die Spezifikation Universal Description, Discovery and Integration (UDDI). Es besteht die Möglichkeit, dass Web-Services in zentralen UDDI-Katalogdiensten abgelegt werden und über ein standardisiertes Format (WSDL) Auskunft über ihre Schnittstellen geben können. Client-Applikationen werden so in die Lage versetzt, automatisch nach den für sie passenden Diensten zu suchen und diese anzusprechen.

UDDI wird allerdings im Kontext von Web-Services bislang kaum verwendet. Dies liegt unter anderem daran, dass die Funktionen für ein dynamisches Finden und Einbinden von Diensten die Anwender bisher wenig interessierten, da Web-Services derzeit meist noch firmenintern oder zwischen festen Kommunikationspartnern eingesetzt werden und die entsprechend anzubindenden Systeme in diesem Fall oft übersichtlich und bekannt sind.

Probleme bei Programmiersprache behoben

Was die Entwicklungswerkzeuge betrifft, gibt es für viele Programmiersprachen inzwischen Implementierungen, die es erlauben, über XML mit Web-Services zu kommunizieren. Neben C++ und einigen Skriptsprachen sind dies vor allem die J2EE-Plattform und Microsofts .NET-Framework. Bezüglich Java ist "Axis" die wichtigste Framework-Implementierung, die durch das Apache-Projekt bereitgestellt wird. Die Entwicklungsgruppe ist bekannt für den marktführenden Web-Server gleichen Namens und eine große Zahl hochlastfähiger Java-Server-Komponenten. Zwischen den Implementierungen gab es in der Vergangenheit Probleme aufgrund der unterschiedlichen Darstellung von komplexen Datentypen innerhalb des Soap-/.NET-Frameworks auf der einen und des Axis-Toolkits auf der anderen Seite. Inzwischen funktioniert die Unterhaltung der beiden Welten.

Viele Microsoft-Applikationen können schon jetzt über Visual Basic Scripting externe Web-Services ansprechen - für die .NET-basierenden Produkte ist dies ein integraler Bestandteil. Sehr erfolgreich werden zum Beispiel Web-Services eingesetzt, um Excel-Tabellen mit Buchhaltungsdaten aus anderen Systemen zu füllen oder Word-Texte mit dynamischen Informationen anzureichern. Ein Java-Web-Service auf einem Rechner, der das Buchhaltungssystem hostet, kann dabei die Daten liefern.

Die Basisfunktionen von Soap-basierenden Techniken unter Nutzung entsprechender Frameworks sind sehr weit ausgereift und arbeiten zwischen den Plattformen einwandfrei. So ist es beispielsweise möglich, mittels einiger Mausklicks beziehungsweise einiger Zeilen Code eine komplette Web-Service-Schnittstelle zu implementieren. Hier wird in der Regel so vorgegangen, dass bestehende Programmier-Schnittstellen (APIs) als Ausgangspunkt für die Web-Service-Definition dienen und ein Framework daraus vollautomatisch eine plattformunabhängige Zugriffs-Schnittstelle und eine WSDL-Spezifikation erstellt.

Die Verschlüsselung und Signatur von Daten innerhalb einer Web-Service-Interaktion ist bisher dagegen nur zum Teil gelöst. Zwar gibt es bereits einige spezifizierte Ansätze, jedoch ist davon noch keiner als Standard wirklich in allen Implementierungen aufgegangen. Findet die Übertragung der Informationen jedoch über ein verschlüsseltes Transportprotokoll wie HTTPS (HTTP mit SSL) statt, kann diese Methode zur sicheren Übertragung angewendet werden. Derzeit nutzen die meisten Web-Service-Projekte diese Technik, allerdings mit dem Nachteil, dass die Verwendung anderer Übertragungsprotokolle entfällt.

Für große Binärdatenmengen ungeeignet

Web-Services sind als XML-basierende Technik nicht unbedingt für den direkten Austausch von großen Binärdatenmengen geeignet. In der Regel bilden die reinen Nutzdaten einer Web-Service-Kommunikation den kleinsten Teil der Daten. Große Volumina fallen allerdings beim Austausch von Bildern, Filmen oder anderen Binärinformationen an. Das Unterbringen von Binärdaten innerhalb von Soap-XML-Dokumenten erfordert eine Umwandlung in Text, der ohne Sonderzeichen in XML transportiert werden kann. Bei Datenmengen, die einige Megabyte überschreiten, gibt es aber wenig Sinn, diese im XML-Dokument selbst unterzubringen. Das liegt daran, dass die momentan in den meisten Web-Services-Frameworks verwendeten Parser nicht in der Lage sind, solche großen Binärdatensegmente innerhalb eines XML-Dokuments einzulesen.

Eine bekannte Technik hilft aus diesem Dilemma: So wie zunächst reine Text-E-Mails vor etwa 20 Jahren um Anhänge (Attachments) erweitert worden sind, lassen sich auch Soap-Messages so verpacken, dass binäre Daten angehängt werden können. Dabei wird das XML-Dokument zur Kommunikation im ersten Teil übertragen, die binären Daten kommen in Anhängen hinterher.

Ein weiterer wichtiger Punkt ist die Transaktionsfähigkeit von Web-Services. Im Hinblick auf eine verteilte Umgebung, in der es darauf ankommt, kritische Prozesse abzubilden, muss es möglich sein, transaktionsorientiert zu arbeiten. Dies dient der Gewährleistung der atomaren (unteilbaren) Funktionsausführung in den über Web-Services verbundenen Systemen. Das bedeutet, dass eine Reihe voneinander abhängiger Operationen entweder komplett oder gar nicht ausgeführt werden. Zurzeit gibt es für dieses Problem immer noch keine allgemein verwendbare Lösung. Zwar existieren bereits einige Spezifikationen zu diesem Thema, jedoch sind die aktuellen Implementierungen eher als Prototypen zu betrachten.

Transaktionssicherheit selten benötigt

Allerdings bleibt auch hier, ähnlich wie bei UDDI, festzuhalten, dass Transaktionsaktionssicherheit für Web-Services in der Praxis momentan so gut wie nicht gebraucht wird, da nur ein extrem kleiner Bruchteil der verteilten Anwendungen auf atomare Aktionen angewiesen ist. Für die meisten Anwendungen ist die einfache Kombination von XML-RPC und SSL (Übertragung über HTTPS) völlig ausreichend, da die Verwendung von XML-RPC unkompliziert ist und man den Verschlüsselungsgedanken berücksichtigt. Wird im Vergleich dazu eine höhere Flexibilität bezüglich der Transportprotokolle und des Datenzugriffs benötigt, empfiehlt sich Soap, wobei jedoch die Implementierung aufwändiger ist. Signaturen und XML-basierende Verschlüsselung sind in beiden Modellen möglich.

Eine hohe Bedeutung kommt der Wahl des Kommunikationsprotokolls auch deshalb zu, weil es wesentlich die Richtung der Kommunikation bestimmt. Soap ist so definiert, dass es prinzipiell mit jedem Kommunikationsprotokoll zusammenarbeiten kann. In der üblichen Verwendung von Web-Services ist die Kommunikation ein Frage-Antwort-Spiel, weshalb sich HTTP gut eignet. Auch eine einseitige Kommunikation ist möglich, bei der lediglich eine Nachricht an einen Empfänger geschickt, aber keine Antwort erwartet wird. Das lässt sich einfach über E-Mail abwickeln. Was aber, wenn mehrere aktive Partner beteiligt sind? Da HTTP asymmetrisch (unidirektional) ist und Anfragen immer nur in eine Richtung gestellt werden können, müssten in diesem Fall zwei Kommunikationskanäle geöffnet werden. Auch hier ist eine Lösung möglich: Das seit Mitte 2002 entwickelte Block Extensible Exchange Protocol (BEEP) erlaubt eine gleichberechtigte Kommunikation zweier Seiten auf nur einer geöffneten Netzverbindung über verschiedene virtuelle Kanäle (bidirektional).

Ausgereifte Lösungen hierfür sind im Laufe des nächsten Jahres zu erwarten. Innerhalb von Apache Axis ist Soap-Encryption und -Signierung bereits implementiert. Microsoft hat seinerseits im Juli eine Preview-Version seiner "Web Service Enhancements 2.0" (WSE) bereitgestellt, die genau diese Themen adressiert.

Die noch fehlenden Funktionen für Web-Services werden kommen. Anders als vor einem Jahr ist es inzwischen keine Frage mehr, ob sich Web-Services durchsetzen, sondern lediglich wann die Technik so weit spezifiziert und implementiert ist, dass sie alle benötigten Möglichkeiten für umfassende Dienste bereitstellt. So hat erst kürzlich Sun Microsystems zusammen mit einer Reihe von Partnerunternehmen Anträge zur Standardisierung einer Spezifikation unter dem Namen "Web Services Composite Application Framework" (WS-CAF) gestellt. Diese umfasst unter anderem vereinheitlichte Kontextinformationen und Transaktionssicherung.

Der Trend geht also klar in Richtung einer Vervollständigung der Web-Service-Implementierung mit Funktionen, wie sie aus Applikations-Server-Umgebungen bekannt sind. Wenn diese Entwicklung nicht durch andere Techniken eingeholt oder abgelöst wird, wird man in zwei bis drei Jahren in der Lage sein, verteilte Applikationen über das Internet so transparent zu benutzen, wie dies heute innerhalb eingeschränkter Systemgrenzen mit Applikations-Server-Architekturen möglich ist.

Grundsätzlich bleibt festzuhalten, dass Web-Services gegenwärtig für die Versendung nicht vertraulicher Informationen innerhalb öffentlicher Netze oder vertraulicher Daten innerhalb geschlossener beziehungsweise verschlüsselter Netze bestens geeignet sind. Die Technik hierfür ist ausgereift und funktioniert auch zwischen den Plattformen und Implementierungen einwandfrei. Dies lässt sich bereits daran ablesen, dass es zunehmend produktive Anwendungen auf Basis von Web-Services gibt. Hierzu gehören EAI-Projekte und typische Data-Provider-Anbindungen. Ein Anwendungsbeispiel dafür ist die traditionell sehr stark von Schnittstellen geprägte Reisebranche: Produktdaten werden von einem Dienstleister zentral gehalten, durch verschiedene Vertriebspartner abgefragt und dem Endkunden zum Beispiel über eine Web-Oberfläche zur Verfügung gestellt. Diese Arten der Anbindung sind weder zwingend transaktionsabhängig noch werden hier Signaturen oder XML-interne Verschlüsselungen benötigt. Die Entwicklung von Web-Services zur Übertragung sensibler Informationen, für die eine XML-interne Verschlüsselung beziehungsweise Signatur oder Transaktionssicherheit notwendig wäre, ist dagegen zur Zeit noch nicht empfehlenswert. (ue)

*Manfred Hein und Henner Zeller sind Senior Program Manager bei der Hamburger Firma Freiheit.com Technologies GmbH.

Angeklickt

Für die Versendung nicht vertraulicher Informationen innerhalb öffentlicher Netze oder vertraulicher Daten in geschlossenen beziehungsweise verschlüsselten Netzen ist die Technik der Web-Services ausgereift. Sie funktioniert in diesen Fällen auch zwischen den Plattformen und Implementierungen. Defizite gibt es dagegen noch, wenn sensible Informationen XML-intern verschlüsselt, signiert und transaktionssicher in verteilten Umgebungen interagieren sollen.

Buchtipp

Mit dem Buch "Java Web Services - Entwicklung plattformübergreifender Dienste mit J2EE, XML und Soap" führen Manfred Hein und Henner Zeller in die Grundlagen der Web-Services-Techniken und -Standards ein. Hierzu gehören die Kommunikation im Web, das Parsen von XML-Dateien und die grundlegende Architektur von Web-Services. Ein weiterer Bereich widmet sich der Implementierung von Web-Services mit Java und deren Interaktion mit .NET über die dafür vorhandenen Toolkits.

ISBN: 3-8273-2071-2, 356 Seiten - 1 CD, Addison-Wesley, München, Mai 2003, 39,95 Euro.

Abb: Suchen, finden, verbinden

Prinzip einer Service-Broker-Architektur. Quelle: Freiheit.com