|
Web
Services - die nächste Revolution des Internets? Im Grunde folgen Web-Services einem sehr einfachen Konzept: Funktionen auf Systemen werden durch das Senden von Anforderungen und Daten zwischen Computern unter Verwendung von XML und HTTP ausgeführt. Jeder, der XML oder HTTP sendet, wendet im Prinzip bereits Web-Services an – wenn auch sehr rudimentär. Das Konzept wird jedoch deutlicher, wenn man einige weitere Standards betrachtet. Um Anforderungen und Antworten zu verkapseln, verwenden Web-Services einen als SOAP (Simple Object Access Protocol) bezeichneten Standard - man könnte dies mit der Telefontechnik vergleichen. WSDL (Web-Services Definition Language), ein weiterer Standard, beschreibt den Kommunikationspartnern, was die Funktionen leisten und welche Daten benötigt werden - dies entspräche beispielsweise einer ausführlichen Visitenkarte oder einem detaillierten Eintrag in einem Telefonbuch. Mit UDDI (Universal Description Discovery Integration) lassen sich Funktionen in einer Registrierung speichern, damit Dritte wissen, welche Services wo verfügbar sind - dies entspräche dem Telefonbuch als Ganzes. Die Verarbeitung verteilter Dienste ist nichts neues. Standards wie Corba, COM und RMI bieten diese Möglichkeit schon seit einigen Jahren. Doch in der Praxis scheiterten diese Ansätze an der Plattformgebundenheit und an ihrer Komplexität. Standards wie SOAP, WSDL und UDDI sind dagegen von der zugrunde liegenden Sprache, dem Betriebssystem oder den Transport-Protokollen unabhängig. Technisch gesehen, müssen Web-Service-Anforderungen nicht einmal über HTTP vorgenommen werden. Sie können per SMTP (E-Mail) oder einen anderen Kommunikationsstandard erfolgen. HTTP ist lediglich der verbreitetste und am einfachsten zu interpretierende Standard. Im Wesentlichen sieht der Ablauf wie folgt aus: Durch die Verknüpfung mit einem SOAP-Server können Unternehmen im Rahmen einer Collaborative-Business-Strategie eine bestimmte Funktion zu einem Web-Service machen. Wenn eine Anforderung an dieser URL eintrifft, nimmt das System das eingehende XML an und ruft die entsprechende Funktion auf. Zum Auffinden dieses Services stellen Entwickler ein WSDL-Eintrag zur Verfügung . Dritte - seien es Partner, Zulieferer oder eine andere Niederlassung - die diese Funktion verwenden möchten, können das WSDL erhalten und Tools ihrer Wahl verwenden, um einfach SOAP-Aufrufe an den Server machen zu können. Und wenn ein Unternehmen möchte, dass die Verfügbarkeit ihrer Funktion öffentlich oder halb-öffentlich bekannt gemacht wird, kann es eine Beschreibung des Web-Services in einem UDDI-Verzeichnis publizieren. Web-Services erleichtern es Unternehmen, intern und extern miteinander zu kommunizieren und Funktionen auszutauschen - und das zu geringeren Kosten. Ein weiterer Pluspunkt ist, dass sie nicht nur die Integration mit externen Geschäftspartnern fördern, sondern auch die Verknüpfung von Systemen innerhalb des eigenen Unternehmens. Sobald eine Funktion als Web-Service zur Verfügung steht, kann grundsätzlich jeder, der dazu befugt ist - Intranet-, Extranet- oder auch Internet-User - unter Verwendung von XML und HTTP auf die Funktion zugreifen. Dabei spielt es keine Rolle, ob das eigene System auf J2EE basiert und das andere System ein Visual-Basic-System ist. Wenn ein Unternehmen und dessen Geschäftspartner Web-Services verwenden, lassen sich Aufrufe in die Geschäftsprozesse einbinden. Die Integration von Systemen kann also exponentiell vervielfältigt werden, was sich darauf auswirken wird, wie wir Geschäfte führen. Überzeugend und zukunftssicher ist die Rolle von herstellerunabhängigen Standards. Derzeit kann eine Abteilung Microsoft-Tools zur Erzeugung von COM-basierten Systemen verwenden, während eine andere Abteilung J2EE für die Systemerzeugung nutzt. Häufig ist es aber nicht möglich, die in den verschiedenen Abteilungen erzeugten Funktionen gemeinsam zu nutzen. Für eine gemeinsame Nutzung ist dann der Einsatz einer COM-zu-CORBA-Brücke oder das Schreiben eines umfangreichen Codes zur Umleitung von Daten über XML und HTTP erforderlich. Im Web ist keine Brücke erforderlich, da Tools für Web-Services zur Verfügung stehen, die beliebige Java- oder Microsoft-Komponenten unterstützen. Somit ist nur eine geringfügige zusätzliche Programmierung erforderlich, um Anforderungen zwischen diesen Systemen umzuleiten. Neuer Ansatz in der Applikationsentwicklung Eine der Zielsetzungen von Systemarchitekten und Entwicklern besteht darin, lose verknüpfte Systeme zu erzeugen - das heißt, es sollten modulare, in einzelne Komponenten unterteilte Systeme erstellt werden, die die Wiederverwendung von einzelnen Komponenten erlauben. Web-Services sorgen für eine konsequente Trennung von Geschäftsinhalten und technologischer Implementierung. Grund hierfür ist, dass es keine Rolle spielt, mit welcher Technologie (J2EE oder .NET) ein Service implementiert wird - solange er Web-Services unterstützt, können ihn andere einfach nutzen. Zudem können Entwickler sich bei der Entwicklung auf die Funktionalität selbst konzentrieren und müssen nicht berücksichtigen, wer diese in welcher Form nutzen soll. Bisher wurden Systeme für eine bestimmte Zielgruppe erzeugt. Mit Web-Services sind Zielgruppe und Funktionalität voneinander unabhängig. Als Benutzer eines Services kommen etwa eine JSP-Seite, eine Visual-Basic-Anwendung oder ein anderes System in Frage. Dies bedeutet eine klare Trennung zwischen den Erzeugern von Services und den Benutzern oder "Verbrauchern" von Services. Sowohl aus finanzieller als auch aus pragmatischer Sicht ist ein großer Vorteil von Web-Services, dass die bestehenden Systeme lediglich angezapft werden müssen, um sie in ihrer Funktionalität zu erweitern. Der Entwicklungsaufwand ist dabei äußerst gering. Im Rahmen von Collaborative Commerce gilt es, neue Funktionalitäten für eine neue Zielgruppe bereitzustellen. Dies erfordert das Umschreiben von bestehenden Systemen oder das Erstellen einer XML-Schnittstellenebene für bestehende Systeme. Dies ist gewöhnlich kostengünstiger und weniger riskant. Mit speziellen Lösungen können Entwickler Web-Services als Java-Code speichern oder bestehende Systeme als Web-Services einem neuen Zweck zuführen. So können Unternehmen beispielsweise CICS-Transaktionen, 3270/5250-Terminalsessions, MQSeries-Warteschlangen, Telnet-Sitzungen, SQL-Datenbanken oder EDI-Transaktionen eine neue Verwendung zuordnen. In Zukunft könnten auch Service-orientierte Architekturen für flexible Geschäftsprozesse enstehen, die bis dato in der Regel "hart codiert" (festgelegt) werden. Der Code für einen Geschäftsprozess umfasst jeweils einen Code zur Bestimmung von ablaufenden Prozessen, ein Programm für Aufrufe an Objekte zur Ausführung von Funktionalität, ein weiteres zum Transformieren der Ausgabe einer Funktion in eine Eingabe für eine andere Funktion und schließlich einen Code zur Bestimmung des nächsten Teils eines Prozesses. Die Verarbeitung dieser Codes findet im Herzstück einer Web-Service-Lösung der Engine statt. Diese ermöglicht die Integration von Geschäftsprozessen und stellt eine Entwicklungsumgebung zur Verfügung. Entwickler können Web-Services, EJBs, Servlets und Java-Komponenten zu einem komplexen flexiblen Workflow zusammenbauen. Die Engine für Geschäftsprozesse ist kompatibel mit der Web-Services Flow Language (WSFL) und vollständig in eine leistungsfähige Engine für Geschäftsregeln integriert. Allerdings sind Web-Services nicht zu empfehlen, wenn sehr performante Systeme oder zeit- und speicherempfindliche Prozessen gestaltet werden sollen. Für diese stehen die bewährten Java-, J2EE-, EAI- oder CORBA-Lösungen zur Verfügung. Auch der Einsatz von UDDI wird weniger spektakulär verlaufen, als viele Web-Service-Protagonisten heute glauben. Sie träumen von öffentlichen und globalen UDDI Registries, doch sind die unmittelbaren Auswirkungen zunächst innerhalb von Unternehmen interessant: Jede Entwicklungsgruppe, die Web-Services erstellt, veröffentlicht auf einem oder mehreren internen UDDI-Servern. Die Registrierung interagiert dann mit einem zentralen Objektverzeichnis, damit verschiedene Entwicklungsgruppen unternehmensspezifisch Aufrufe zwischen den Systemen machen können.
|