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.

Web-Services in .NET und J2EE

In den beiden heute im Umfeld betrieblicher Steuerungs- und Informationssysteme relevanten Plattformen Java und .NET gibt es mehrere Umsetzungen der vom Standardisierungsgremium W3C genormten Webservice-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.

In .NET Framework 2.0 und vor allem in 3.0 sind Web-Services ebenfalls ein zentrales Merkmal. Die Implementierung der Standards durch die IT-Hersteller sind jedoch nicht vollständig miteinander kompatibel. An einer vollständigen Interoperabilität der unterschiedlichen Ausprägungen arbeitet vor allem die Web Services Interoperability Organisation (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 realisieren. Die Technik eignet sich aber auch für andere Aufgaben, die beispielhaft erläutert werden:

1. Unternehmensinterne Kopplung heterogener Systeme.

2. Lose Integration interner Software mit einem externen Web-Service.

3. Web-Service als Zugriffsmechanismus auf Server-Funktionen.

1. Unternehmensinterne Kopplung heterogener Systeme

Das erste Projektbeispiel ist ein Integrationsprojekt, in dem neue und vorhandene Anwendungen über Web-Services mit anderen Legacy-Anwendungen gekoppelt werden. Web-Services agieren hier als Middleware zur unternehmensweiten, 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 "Unternehmensinterne Kopplung" zeigt, wurde einem neuen Buchhaltungsystem 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 positiv, weil im Vorfeld die Kompatibilität der Web-Service-Implementierungen sowie die Unterstützung durch Werkzeuge im Vorfeld gründlich analysiert wurden. Die verwendeten Tools funktionierten gut, und die realisierte Lösung lässt sich komfortabel weiterentwickeln. Auch die Performance-Werte waren akzeptabel.

2. Lose Kopplung interner Systeme mit einem externen Dienst

Im zweiten Projektbeispiel ging es darum, Web-Services für den Zugang zu klassischen Diensten von Service-Anbietern zu nutzen. Im konkreten Fall handelte es sich um Dienste zur Prüfung von Adress- und Bankinformationen. Hier war die Zielsetzung, 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 einer 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 Vielzahl an geplanten 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 Webservice-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.

Neben einem Online-Verfahren realisierten die Softwareentwickler auch einen Zugriff auf die Web-Services aus Batch-Programmen heraus. 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.

Der Aufwand für dieses Projekt, vor allem das 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.

3. 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 für beliebige Clients"). 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.

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 Kodierungsstil bei der Serialisierung. Apache Axis nutzte standardmäßig einen RPC-Stil, Microsoft .NET dagegen einen Dokumentenstil (siehe auch Kasten "Nachrichtenformate …"). Vor allem traten bei komplexeren Datentypen, die als Parameter in Web-Service-Operationen dienten, anfänglich Schwierigkeiten auf. Erst durch Inkaufnahme gewisser Einschränkungen 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 Dialog-betrieb vertretbar. Auch hier kann es in Batch-orientierten Systemen zu Engpässen kommen.

Lessons Learned

Die drei Projekte repräsentieren unterschiedliche Web-Services-Szenarien. Die ersten beiden beschriebenen Umgebungen 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 Kodierungsstile brachte die gewünschten Ergebnisse. Es empfiehlt sich, WSDL-Dateien Server-seitig zu erzeugen und bei den Client-Anwendungen zur Code-Erzeugung 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 lassen sich einfach für neutrale, zustandslose Dienste in heterogenen Umgebungen verwenden. In allen drei Projekten wurde daher ein robustes Transaktionskonzept eingesetzt, 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 Tran-saktionen 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 = Overhead

Da die Kommunikation via Web-Services aufwändig ist, müssen Anwender die Performance immer im Auge behalten. Zumindest in diesen 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. Dies tritt insbesondere bei steigender Parameteranzahl auf. Oft treten die Flaschenhälse jedoch bei den Datenbankzugriffen auf.

Auch wenn Web-Services die Anwendungskopplung vereinfachen, sind viele unterschiedliche Komponenten daran beteiligt, vor allem wenn man mit einer direkten Generierung des Web-Service-Codes aus einem Applikations-Server heraus arbeitet. Zwar fangen Entwicklungswerkzeuge die Komplexität ab, trotzdem muss die Arbeitsweise der Umgebung beherrscht werden, wenn es zu Fehlersituationen kommt.

Fazit

• Trotz einiger Schwierigkeiten ist die Nutzung von Web-Services für diese Anwendungsfälle insgesamt positiv zu bewerten.

• Bei heterogenen Technologieumgebungen (.NET, Java) muss man sich noch mit Kompatibilitätsproblemen befassen, die aber lösbar sind.

• Echte Performance-Probleme traten trotz deutlicher Einbußen bei der Übertragung und beim Parsen der Nachrichten in den Projekten nicht auf.

• Nicht Web-Services, sondern der Zugriffe auf Datenbanken stellen oft den Flaschenhals dar. Bei der Nutzung von Web-Services in der Batch-Verarbeitung sind frühzeitige Benchmarks aber unbedingt notwendig.

• Der Einsatz von Web-Services kann insbesondere bei einfacher Transaktionsverarbeitung sehr nützlich sein, sollte aber – wie alle anderen Lösungsvarianten auch - nicht als Allheilmittel für sämtliche Architekturprobleme angesehen werden.

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, mit objektorientierten Mitteln realisiert werden. Services sind dann nur die Dienste, die Komponenten für ihre Nutzer so anbieten, dass die "Innereien" nach außen 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.