Mit Web-Services lassen sich Basismechanismen für Service-orientierte Architekturen erzeugen, wobei das Internet als Kommunikationsplattform dient. Über diese Services sollen beliebige Anwendungen ohne Rücksicht auf die Programmiersprache und die Ablaufumgebung miteinander kommunizieren können.
Hier lesen Sie ...
für welche Integrationsaufgaben sich Web-Services eignen;
wie Web-Services Schnittstellen zu heterogenen Applikationen, einem externen Netzdienst sowie Server-Diensten gestalten;
dass bei Batch-orientierten Systemen Web-Services mit Vorsicht zu genießen sind;
dass die versprochene Kompatibilität zwischen unter-schiedlichen Web-Services-Implementierungen der Her-steller in der Praxis oft nicht hält, was sie verspricht.
Glossar
Axis: Von Apache verwaltete Soap-Implementierung, auch als Soap-Engine bezeichnet.
Encoding-Style: Codierungsstil, legt die Art der Codierung fest. Der Begriff bezeichnet hier einen Satz von Regeln für Web-Services, die exakt festlegen, wie Datentypen in einer allgemein verbindlichen XML-Syntax für die Übertragung zu codieren sind. Der Codierungsstil wird bei der Web-Service-Definition an entsprechenden Stellen in WSDL-Dokumenten festgelegt. Man unterscheidet "Soap-Encoding" und "Literal". Ersterer nutzt spezielle Codierungsregeln aus der Soap-Spezifikation. Für Letzteren gibt es in WSDL ein standardisiertes XML-Schema. WS-I unterstützt den Soap-Encoding-Style nicht mehr.
JAX-RPC und JAX-WS: Java-API-Spezifikationen für die Nutzung von Web-Services.
Oasis: Organization for the Advancement of Structured Information Standards, befasst sich mit der Weiterentwicklung von Standards im Web-Service-Umfeld. Unterstützt drei Vorschläge zur Transaktions-verarbeitung mit Web-Services WS-Coordination (WS-C), WS-Atomic Transactions (WS-AT) und WS-Business Activity (WS-BA).
RPC: Remote Procedure Call. Aufruf einer Funktion eines entfernten Systems.
SOA: Service-orientierte Architektur.
Soap: Simple Object Access Protocol, Kommunikationsprotokoll der Anwendungsschicht zum Aufruf von Web-Services.
WS-I: Web Services Interoperability Organization, Herstellervereinigung, die den Zweck verfolgt, die Portabilität von Web-Service-Implementierungen zu verbessern.
UDDI: Universal Description, Discovery and Integration, Standard für Verzeichnisdienste von Web-Service-Architekturen, dient zum Auffinden von Web-Services im Netz.
WSDL: Web Services Description Language, plattform- und auch programmiersprachenunabhängige Interface-Beschreibungsspache für Web-Services auf Basis von XML.
Nachrichtenformate und Codierung
Der Zusammenhang zwischen Kommunikationsmodell und Codierungsstil ist sehr verwirrend. Daher sollen die Zusammenhänge nochmals kurz zusammengefasst werden. Das Kommunikationsmodell, also die Art und Weise, wie die Kommunikationspartner miteinander kommunizieren, ist unabhängig vom Nachrichtenformat. Prinzipiell sind Soap-Nachrichten so konzipiert, dass sie jeden beliebigen wohlgeformten XML-Code aufnehmen können.
Beim Nachrichtenformat gibt es zwei Varianten, die mit "RPC" und "Document" bezeichnet werden (siehe Binding-Element, Style-Attribut):
Im Nachrichtenformat "Dokument" enthält der Soap-Body ein oder mehrere Kindelemente, die als Parts bezeichnet werden. Es werden keine Soap-Codierungsregeln für den Body angewendet. Der Aufbau der Soap-Nachricht muss zwischen den Kommunikationspartnern abgestimmt werden und wird in XML formuliert.
Im Nachrichtenformat "RPC" steht im Soap-Body genau ein Element, das auch noch den Namen der Operation enthält, die aufgerufen werden soll. Für jeden Parameter wird in diesem Element ein weiteres Element (Subelement) übertragen.
Der Wert "wrapped" im Style-Attribut gibt an, dass alle Parameter einer Operation in ein Root-Schema-Element mit dem gleichen Namen wie die Operation eingebettet sind.
Die Bedeutung des Style-Attributs lässt sich aus der Namensgebung nicht exakt ableiten, denn man kann - wie bereits angedeutet - auch mit dem Dokumentenstil einen Request-/Response-Ansatz realisieren und umgekehrt mit dem RPC-Stil (asynchrone) Nachrichten versenden.
Codierungsstile (Der Begriff "Codierungsstil" bezeichnet hier einen Satz von Regeln, die exakt festlegen, wie Datentypen in einer allgemein verbindlichen XML-Syntax zu codieren sind) legen bei Web-Services die Art der Codierung fest. Die Problematik ist aus RPC, RMI und sonstigen Techniken verteilter Kommunikation bekannt. Hier ist also festgelegt, in welcher Form eine Codierung der Soap-Nachrichteninhalte stattfinden soll. WSDL kennt zwei Möglichkeiten:
"Soap-Encoding" wird im Attribut encodingStyle für beliebige Blöcke im Soap-Body oder im Use-Attribut (siehe Binding) angegeben. In diesem Fall werden spezielle Serialisierungsregeln aus der Soap-Spezifikation verwendet. Sie wird auch Section-5-Encoding genannt, da die Regeln in der Section 5 der Soap-Spezifikation festgelegt sind.
"Literal" wird im Use-Attribut (siehe Binding) angegeben. Bei dieser Art der Codierung werden die Daten im Soap-Body gemäß der Festlegung in der XML-Schema-Spezifikation codiert.
Die Kombination aus Nachrichtenformat und Codierungsstil ergibt wiederum mehrere Möglichkeiten (Nachrichtenformat = Style-Attribut, Codierungsstil = Use-Attribut) ergeben:
Style=Document/Use=Literal: Der Soap-Message-Body enthält hier ausschließlich Dokumente nach XML-Schema, dass heißt, die ganze Nachricht lässt sich vollständig validieren. Dieser Stil wird Innerhalb der Web-Service-Community als favorisierte Lösung propagiert.
Style=RPC/Use=Literal: Hier werden die Soap-Nachrichten als RPC-Aufrufe mit Parametern und Returncodes realisiert. Jede Nachricht hat einen eigenen Schematyp. Die Datentypen der Parameter werden in der Nachricht nicht explizit angegeben, sondern sie ergeben sich aus der konkreten Schema-Beschreibung.
Auch die Kombination Style=RPC/Use=Encoded ist möglich. Diese Kombination wird aufgrund der mangelnden Interoperabilität nicht mehr von allen Standards und Herstellern unterstützt. Er wurde eingeführt, als es noch kein WS-I-Basic-Profile (siehe unten) gab. Heute verfügbare Web-Service-Implementierungen nutzen diesen Codierungsstil aber noch sehr häufig.
Anmerkung: Man sollte sich bei der Entwicklung von Web-Services auf die Kombination Style=Document/Use=Literal oder Style=RPC/Use=Literal beschränken. Hier gibt es Unterschiede im Nachrichtenaufbau, aber alle Web-Service-Plattformen dürften diese beiden Kombinationen kennen. Will man ganz sicher gehen, dass Web-Services auch in heterogener Umgebung funktionieren, so ist die Kombination Style=Document/Use=Literal am besten, da diese auch von .NET verwendet wird. Soap-Encoding sollte nicht mehr verwendet werden.
Fazit
n Trotz Schwierigkeiten haben sich Web-Services in den beschriebenen Fällen bewährt.
n Bei heterogenen Technologie-umgebungen (.NET, Java) muss man sich noch mit Kompatibilitätsproblemen befassen, die aber lösbar sind.
n Echte Performance-Probleme traten trotz deutlicher Geschwindigkeitseinbußen bei der Übertragung und beim Parsen der Nachrichten in den Projekten nicht auf.
n Nicht Web-Services, son-dern Zugriffe auf Datenbanken stellen oft den Flaschenhals dar. Bei Web-Services in der Batch-Verarbeitung sind frühzeitige Benchmarks aber notwendig.
n Web-Services können insbesondere bei einfacher Transaktionsverarbeitung sehr nützlich sein, sollten aber wie alle anderen Lösungsvarianten auch nicht als Allheilmittel für sämtliche Architekturprobleme angesehen werden.
In den beiden heute im Umfeld betrieblicher Steuerungs- und Informationssysteme relevanten Plattformen Java und .NET gibt es mehrere Umsetzungen der vom Standardisierungsgremium W3C genormten Web-Service-Standards Soap (Simple Object Access Protocol), WSDL (Web Services Description Language) und UDDI (Universal Description, Discovery and Integration). Aus der Java-Welt sind die Spezifikationen JAX-RPC und JAX-WS bekannt. Implementierungen hiervon sind beispielsweise in der Soap-Engine Apache Axis und in J2EE-Applikations-Servern wie Jboss umgesetzt.
Vom Service zur SOA
In .NET Framework 2.0 und vor allem in 3.0 sind Web-Services ebenfalls ein zentrales Merkmal. Die durch die IT-Hersteller implementierten Standards sind jedoch nicht vollständig miteinander kompatibel. An einer kompletten Interoperabilität der unterschiedlichen Ausprägungen arbeitet vor allem die Web Services Interoperability Organization (WS-I). Unter Beteiligung vieler namhafter IT-Hersteller entstehen dort plattformunabhängige Web-Service-Profile (WS-I Basic Profiles).
Unternehmen verwenden Web-Services unter anderem, um Anwendungen zu integrieren und Service-orientierte Architekturen zu schaffen. Die Technik eignet sich aber auch für andere Aufgaben, die im Folgenden anhand von drei Beispielen aus der Praxis erläutert werden
Unternehmensinterne Kopplung heterogener Systeme
Das erste Beispiel ist ein Integrationsprojekt, in dem neue und alte Anwendungen über Web-Services mit anderen Legacy-Anwendungen gekoppelt werden. Web-Services fungieren hier als Middleware zur unternehmensübergreifenden, aber auch unternehmensinternen Integration von Anwendungssystemen. Wichtiges Argument für Web-Services war, dass die Funktionen unterschiedlicher Legacy-Anwendungen (implementiert in der 4GL-Sprache Natural der Software AG und auf Basis von Oracle PL/SQL Stored Procedures) in Java-Anwendungen bereitgestellt werden mussten. Wie die Abbildung "Unternehmensinterne Kopplung" zeigt, wurde einem neuen Buchhaltungssystem sowie einer Lösung für die Auslandsfaktura der Zugang auf die bestehenden Applikationen über einfache und auch über höherwertige (komponierte) Web-Services ermöglicht.
In diesem Projekt wurden anwendungsspezifische Dienstschnittstellen aus dem bestehenden Programmcode der Legacy-Anwendungen heraus generiert. Basis dafür waren Werkzeuge im Umfeld von Oracle PL/SQL sowie von Natural. Allerdings publizierten die Entwickler die generierten Programme nicht direkt als Web-Service, sondern versahen sie nochmals durch eigene, schlanke Wrapper mit elementaren Zusatzfunktionen wie Logging oder Exception-Handling, was sich auch als sehr sinnvoll erwiesen hat.
Das Projekt verlief nicht zuletzt deshalb erfolgreich, weil im Vorfeld die Kompatibilität der Web-Service-Implementierungen sowie die Unterstützung durch Werkzeuge gründlich analysiert wurden. Die verwendeten Tools funk-tionierten gut, und die Lösung lässt sich komfortabel weiterentwickeln. Auch die Performance-Werte waren akzeptabel.
Kopplung interner Systeme mit externen Dienst
Im zweiten Projektbeispiel ging es darum, Web-Services für den Zugang zu klassischen Diensten von Serviceanbietern zu nutzen. Im konkreten Fall handelte es sich um Dienste zur Prüfung von Adress- und Bankinformationen. Ziel war, eine für das Unternehmen universelle Funktion nur einmal zu realisieren, um sie dann von unterschiedlichen Anwendungen aus nutzen zu können. Die Implementierung erfolgte in Java, da der Prüfdienst eine Java-Schnittstelle anbot. Typischerweise sind solche Prüffunktionen zustandslos und verfügen über eine klar umrissene Service-orientierte Schnittstelle. Somit ließ sich die Anbindung problemlos realisieren. Wie die Abbildung "Lose Anbindung externer Dienste" zeigt, wurden Anwendungen zur Mitgliederverwaltung, ein Buchhaltungssystem und eine Außendienst-Anwendung über Web-Services mit den Diensten des Adress- und Bankauskunfts-Providers verbunden.
Als Applikations-Server fungiert "Oracle Containers for Java EE" mit einer Soap-Engine. Gleichwohl ist die Umsetzung kompatibel zu Konfigurationen mit Applikations-Servern wie Jboss und Axis. Wegen der zu erwartenden vielen Anfragen gab es anfänglich Bedenken hinsichtlich der Leistungsfähigkeit. Im Online-Betrieb zeigte sich aber, dass der durch das Einschalen der externen Dienste mit Web-Service-Code erforderliche Overhead im Vergleich zum Aufwand für den Basisdienst kaum ins Gewicht fiel. Der zusätzliche Kommunikationsaufwand und auch das Parsen der XML-Nachrichten wirkten sich damit nicht negativ auf die Leistungsfähigkeit aus.
Batch-Konflikte
Neben einem Online-Verfahren richteten die Softwareentwickler auch einen Zugriff auf die Web-Services aus Batch-Programmen heraus ein. Die Batch-Jobs sollten einen umfangreichen Adressbestand überprüfen. Obwohl auch hier Tests gezeigt haben, dass die Performance gerade noch akzeptabel ist, entschloss man sich, für diese Aufgabe einen neuen Service zu bauen. Dabei werden Abfragen für jeweils eine große Zahl an Adressdaten in einem Web-Service erzeugt. Diese Variante hat sich letztlich bewährt, allerdings erfordern solche Sonderformen Eingriffe in die Systeme. Beispielsweise musste der Container des Applikations-Servers neu konfiguriert werden, damit er die sehr lange Laufzeit dieses neuen Service nicht als Timeout interpretierte.
Den Aufwand für dieses Projekt, vor allem das Ausrollen der Software (Deployment), hatten die Projektleiter stark unterschätzt. Das Entwicklungsteam hatte einige Zeit mit unterschiedlichen Zeichensätzen der verschiedenen Systeme zu kämpfen, die sich erst durch die richtige Konfiguration der Unix-Umgebung lösen ließen. Dieses Problem wirkte sich direkt auf die Funktion der Web-Services aus, trat jedoch während der Entwicklung nie auf. Dennoch hat es sich gelohnt, auf Web-Services zu setzen: Das Unternehmen hat nach Inbetriebnahme der Web-Services ohne technische Eingriffe inzwischen weitere Anwendungssysteme angebunden.
Web-Services als zentraler Zugang zu Server-Funktionen
In einem dritten Projekt wurde ein Controlling-System auf Basis einer Client-Server-Architektur realisiert. Web-Services fungierten hier als Ersatz für einen klassischen RPC-Mechanismus (siehe Abbildung "Web-Service öffnet Server-Funktionen"). Die Clients der Anwendung greifen ausschließlich über Services auf die Server-Dienste zu. Die geplante Lösung sollte offen sein für beliebige Client-Techniken. Zunächst schrieb das Projektteam einen .NET-Client in der Programmiersprache C#. Die Server-Seite stützte sich auf J2EE/EJB 2.1 auf Basis des "Jboss Application Server". Die Web-Services wurden durch Apache Axis (JAX-RPC) ergänzt. Derzeit stellt das Anwenderunternehmen den Server auf EJB 3.0 und JAX-WS um.
Kompatibilitätsprobleme
Für die Server-Schnittstelle realisierten die Programmierer mehr als 100 Operationen in mehreren Web-Services. Probleme ergaben sich zunächst aufgrund von Inkompatibilitäten vor allem im Codierungsstil bei der Serialisierung. Apache Axis nutzte standardmäßig einen RPC-Stil, Micro-soft .NET dagegen einen Dokumentenstil. Vor allem traten bei komplexeren Datentypen, die als Parameter in Web-Service-Operationen dienten, anfänglich Schwierigkeiten auf. Erst durch Inkaufnahme gewisser Einschrän-kungen ließen sich die Probleme lösen: Man verzichtete beispielsweise auf Arrays aus komplexen Typen.
Wie die Praxis zeigt, erkauft man sich die Unabhängigkeit der Client-Technik von der Server-seitigen Implementierung mit einer etwas schlechteren Performance. Allerdings ist die Leistung für den Dialogbetrieb vertretbar. Auch hier kann es in Batch-orientierten Systemen zu Engpässen kommen.
Erfahrungswerte
Die drei Projekte repräsentieren unterschiedliche Web-Services-Szenarien. Die ersten beiden beschriebenen Lösungen sind bereits im produktiven Einsatz. Probleme traten vor allem bei heterogenen Umgebungen auf. Mit dem aus den WSDL-Dateien generierten Code war meist nicht sofort eine Kommunikation zwischen Partnerinstanzen möglich. Erst der Abgleich der Codierungsstile brachte die gewünschten Ergebnisse. Es empfiehlt sich, WSDL-Dateien Server-seitig zu erzeugen und bei den Client-Anwendungen zur Codeerzeugung zu nutzen. Auch wenn die Software offizielle Standards unterstützt, scheinen die angebotenen Werkzeuge zur Generierung von Code nach wie vor unterschiedliche Schwerpunkte zu setzen, so dass in der Praxis immer noch Kompatibilitätsprobleme auftreten. Diese lassen sich zwar lösen, kosten aber Zeit und Aufwand.
Web-Services eignen sich gut für neutrale, zustandslose Dienste in heterogenen Umgebungen. In allen drei Projekten wurde daher ein robustes Transaktionskonzept umgesetzt, in dem eine Web-Service-Operation eine Transaktion repräsentiert. Die Client-Anwendung nutzt in diesem Fall nur die Operation und muss sich nicht mit Transaktionslogik befassen. Dienstübergreifende Transak-tionen implementierten die Projektbeteiligten nicht: Transaktionskonzepte, wie sie das Standardisierungsgremium Oasis definiert (WS-C, WS-AT und WS-BA), eignen sich offenbar noch nicht für den praktischen Einsatz.
Web-Services bringen Overhead
Da die Kommunikation via Web-Services aufwändig ist, müssen Anwender die Performance immer im Auge behalten. Zumindest in den beschriebenen Projekten spielte die Leistungsfähigkeit mit Ausnahme der Batch-Verarbeitung nur eine untergeordnete Rolle. Problematisch sind Job-Systeme deshalb, weil Messungen und Vergleiche mit klassischen Kommunikationsprotokollen einen beträchtlichen Overhead bei der Übertragung und beim Parsen von Nachrichten ergeben haben. Weitaus öfter treten Flaschenhälse jedoch bei Datenbankzugriffen auf.
Auch wenn Web-Services die Anwendungskopplung vereinfachen, sind viele unterschiedliche Komponenten daran beteiligt, vor allem wenn man den Web-Service-Code direkt aus einem Applikations-Server heraus generiert. Zwar fangen Entwicklungswerkzeuge die Komplexität ab, trotzdem muss die Arbeitsweise der Umgebung beherrscht werden, wenn es zu Fehlern kommt.
SOA macht nicht alles neu
Eine Service-orientierte Architektur löst weder die Objektorientierung noch die komponentenorientierte Softwareentwicklung ab, sondern nutzt, ganz im Gegenteil, deren Konzepte. Man kann auch vereinfacht sagen, dass die Objektorientierung der Programmierung im Kleinen dient. Komponenten sind etwas grobkörnigere Softwarebausteine, die meistens, aber nicht zwangsläufig, objektorientiert realisiert werden. Services sind dann nur die Dienste, die Komponenten für ihre Nutzer so anbieten, dass die "Innereien" verborgen bleiben. Services basieren also auf Komponenten und stellen Schnittstellen für den Zugriff auf deren Methoden bereit. SOA ist damit nichts grundsätzlich Neues. Neu ist nur der offene Zugang über das Internet. (fn)