Web Services – mehr Speed in der Applikationsentwicklung

Die Basis für den Einsatz von Web Services sind in der Regel Application Server etwa von Bea, Sun, Oracle, IBM oder auch Lösungen aus dem Open-Source-Lager (wie zum Beispiel Apache „Axis“). Sie stellen die Ablaufumgebung bereit, sorgen für die Kommunikation zwischen dem Web-Service und dem Client-Programm und erlauben die Verteilung von Komponenten. Daneben bieten Sie Überwachungs-, Sicherheits- und Transaktionsdienste. Für die Erstellung und Verteilung von Web Services verfügt der Oracle Application Server wie auch andere Plattformen beispielsweise über ein zeilenorientiertes Werkzeug, mit dessen Hilfe sich Programme als Web Services verpacken lassen.

Doch auf diese kryptische Entwicklungsmöglichkeit sind Entwickler nicht angewiesen: Development-Suiten wie Oracles JDeveloper oder JBuilder von Borland unterstützen den Programmierer sehr viel komfortabler bei seiner Arbeit etwa durch Wizzards, eine grafische Modellierung auf Basis der Unified Modelling Language (UML) mit den Klassen- und Aktivitätsdiagrammen sowie einer automatischen Generierung von Java-Klassen und XML-Dateien. Daneben gehören Features wie Tuning, Debugging sowie Monitoring von Web Services zum Leistungsumfang der meisten Programmier-Tools.

Web Services in vier Schritten

Bei der Entwicklung von Web Services lassen sich sowohl bestehende Programme als Web-Service aufbereiten als auch neue Anwendungen schreiben. Bei einer neuen Anwendung programmiert der Entwickler wie gewohnt seine Geschäftslogik zum Beispiel in Form von Java Klassen. Hierbei wird in „stateless“ oder „statefull“ Applikation unterschieden, wobei sich bei ersterem die Anwendung einen Status nicht merkt. Wer für die Erstellung von Web Services Anwendungen benutzen möchte, die sich den Status merken, muss sich derzeit mit Cookies behelfen. Hier ist der Programmierer im Oracle-Umfeld jedoch nicht gezwungen, selbst Hand anzulegen, sondern der Application Server benutzt in diesem Fall automatisch den Coockie-Mechanismus. Dieser Weg ist allerdings nicht standardisiert, also beim Wechsel auf eine andere Ablaufumgebung kann hier ein Änderungsaufwand entstehen. Weitere Implementierungen von Logik können unter anderem „stateless“ Enterprise Java Beans (EJBs), JMS Destination oder auch Datenbankanwendungen, wie SQL-Prozeduren und Java-Stored-Procedures sein.

Im zweiten Schritt legt der Entwickler nun ein J2EE Enterprise Archive (EAR) an. Dies wird von den meisten Entwicklungs-Tools unterstützt. Dabei wird WSDL-Interface, das beschreibt, wie man den Service aufrufen kann, automatisch erzeugt. Gleichzeitig erfolgt die Generierung aller technischen Klassen: ein sogenannter Client-Stub oder auch Proxy, der dafür sorgt, dass Java-Aufrufe auf der Client-Seite in SOAP-Nachrichten übersetzt werden und ein Server-Skeleton, der Serverseitig für die Übersetzung der SOAP-Aufrufe in die Sprache der Dienstimplementierung etwa Java sorgt. Für den Client-Entwickler stehen Java-APIs zur Verfügung, so dass er SOAP-Nachrichten nicht per Hand erzeugen muss. Der Grund: Entwickler kennen sich mit Java aus und sollen sich nicht unnötigerweise mit SOAP-Implementierung befassen müssen.

Der nächste Schritt ist die Verteilung (Deployment) des Archivs in den Application Server. Diesen Schritt unterstützen die meisten Entwicklungs-Suiten für mehrere Application Server mit einem einzigen Maus-Click. Dabei wird das J2EE Web Service Archive ausgepackt und entsprechend den J2EE-Vorschriften so in den Application Server verteilt, dass der Web-Service sofort lauffähig ist. Um vorab die Funktionsfähigkeit des Web Services zu testen, erzeugen die meisten Umgebungen, wie zum Beispiel Oracle Application Server, automatisch einen Test-Client in Form einer Java Server Page.

Als letzte Aufgabe muss die Client-Anwendung geschrieben werden. Hier profitiert der Java-Entwickler vom generierten Client-Stub. Der Programmierer muss lediglich dafür sorge tragen, in seinem Client-Programm die gewünschten Web-Service-Aufrufe als lokale Java-Methodenaufrufe auf dem Stub zu programmieren.