|  |
Wie Web-Services Anwendungen koppeln
Softwaredienste können Applikationsfunktionen kapseln und so Systemgrenzen überwinden. Trotz Standards gibt es allerdings Inkompatibilitäten zwischen .NET und Java.
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. 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-StandardsSoap (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.
1. 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 funktionierten gut, und die Lösung lässt sich komfortabel weiterentwickeln. Auch die Performance-Werte waren akzeptabel.
2. Kopplung interner Systeme mit externem 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.
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"). 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 .NETClient 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, Microsoft .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ä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 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 Transaktionen 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.
Der Artikel wurde in der Computerwoche veröffentlicht und ist weiterhin im Archiv zu lesen unter:
www.computerwoche.de
Dr. Peter Mandl
Dr. Peter Mandl ist Professor für Wirtschaftsinformatik an der FH München und Geschäftsführer der iSYS Software GmbH.
|
Dr. Nikolai Bauer
Nikolai Bauer ist Informatiker und Vorstand der XT AG in München.
|
04/2008
Kommentare zu diesem Beitrag | | |
Weitere Beiträge zu diesem Thema | | |
|  | | Aktuelle Studien zeichnen ein deutliches Bild: Lediglich 2% der amerikanischen Online-Shopper lesen gar keine Produktbewertungen... | |  | | Behavioural Targeting ist als essentielles Tool für die Verbesserung des Online-Marketings auf dem deutschen Markt angekommen... | |  | | Im Wertpapierhandel enden alle Gewissheiten. Aber gerade im sorgfältigen Umgang mit Risiken liegen Chancen. Dessen ist sich jedes Institut bewusst, das margenstarke Aktienzertifikate und Garantiefonds anbietet... | |  | | In dieser Ausgabe befassen wir uns mit den wichtigsten Teilen eines Shops: den Formularen. Sie sind deshalb am wichtigsten, weil sie über den Erfolg oder Misserfolg entscheiden. Mit einem Formular wird die Bestellung aufgegeben – oder eben nicht... | |  | | Einen einfachen Webshop einzurichten ist technisch mittlerweile kein Problem mehr. Es gibt kostengünstige Kauf-Lösungen, die mit wenig Aufwand auf dem eigenen Server installiert sind... | |
Beiträge aus anderen Themenbereichen | | |
|  | | F-Secure präsentiert Sicherheits-Reiseapotheke für Internet, Laptop & Co: Der neue Badeanzug ist gekauft, die Impfung aufgefrischt und der Reisepass verlängert. Doch wie sieht es mit einer elektronischen Reiseapotheke für die sichere Online-Buchung ... | |  | | Datenschutz, Sicherheit beim Mobile Computig, Compliance. Das sind nur einige der Schlagworte, die um das Thema IT-Sicherheit kreisen. Die Debatte hat in den letzten Jahren an Brisanz zugelegt. Dazu tragen auch Berichte über den Steuerskandal ... | |  | | Die Virtualisierung von IT-Architekturen erfordert neue Sicherheitsstrategien... | |
| | | |
