Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

31.10.2003 - 

Web-Services/Programmieren von Web-Services mit J2EE

Applikationsentwicklung verliert an Komplexität

Führende Hersteller aus dem Java-Lager unterstützen mit ihren Produkten bereits seit längerem die Entwicklung von Web-Services. Im jüngsten Release 1.4 des J2EE-Standards wird diese Technik nun erstmals offiziell berücksichtigt. Von Evgenia Rosa*

Dass Web-Services bereits eine feste Größe in IT-Abteilungen sind, zeigen Befragungen von Anwenderunternehmen. So fanden die Berater von Cap Gemini Ernst & Young (CGEY) im vergangenen Jahr heraus, dass 83 Prozent der insgesamt 170 befragten Entscheidungsträger deutscher Unternehmen zumindest auf Teile dieser Technologie setzen. Die Analysten von Gartner dokumentierten in einer Studie vom Frühjahr 2003 sogar ein noch stärkeres Interesse: Demnach testeten 92 Prozent der Teilnehmer einer US-amerikanischen Umfrage Web-Services-Verfahren meist in Pilotprojekten.

Ein Pluspunkt ist, dass sich Web-Services mit jeder Programmiersprache implementieren lassen. Eine solche Abbildung der einzelnen Programmiersprachen stellen Entwicklungsumgebungen wie "Jdeveloper" von Oracle, "Jbuilder" von Borland oder "Visual Studio .NET" von Microsoft mehr oder weniger per Mausklick zur Verfügung. Zudem bieten Web-Services die Möglichkeit, Brücken zwischen den Plattformen J2EE und .NET zu schlagen.

Gemischte Anwendungen testen

Für die Kompatibilität etwa zwischen J2EE und .NET sind derzeit allerdings die Standards noch nicht vollständig definiert. So sind die von einem Tool erzeugten WSDL-Beschreibungen nicht immer kompatibel zu den Soap-Nachrichten des Clients, der mit dem Werkzeug eines anderen Anbieters generiert wurde. Hier helfen Communities oder Foren (im Internet etwa "Soap Builders") Entwicklern dabei, die Verträglichkeit gemischter Anwendungen zu testen und festzustellen, ob beispielsweise eine .NET-Anwendung von einem Java-Client angesprochen werden kann und umgekehrt.

Im Unterschied zu Microsofts XML-Web-Services, die auf der .NET-Technik und dem Microsoft-Betriebssystem basieren und lediglich auf Intel-Plattformen laufen, stellen Web-Services unter J2EE eine Spezifikation von XML-basierenden Frameworks dar, die von verschiedenen Herstellern implementiert werden. Dabei wird eine Reihe von standardisierten APIs definiert, die es erlauben, eine vorhandene Geschäftslogik - implementiert etwa als Java-Klassen oder Enterprise Javabeans (EJBs) - als Web-Services zur Verfügung zu stellen. Zu den maßgeblichen APIs gehören: das Java-API für XML-Parsing (JAXP) und darauf aufbauend das Java-API für XML-basierende RPCs (JAX-RPC), das Interface für XML-Registries (JAXR) sowie die Java-Architektur für XML-Binding (JAXB).

Grundsätzlich unterscheidet man bei Web-Services zwischen RPC-Style (RPC = Remote Procedure Call) und dem Document-Style - der vor allem in der Microsoft-Welt wichtig ist. Beim RPC-Style beinhaltet die Soap-Nachricht eine Funktionsaufruf-Syntax, es erfolgt also ein entfernter Prozeduraufruf. Datentypen werden dabei nach der Soap-Spezifikation codiert. Beim Document-Style werden dagegen XML-Dokumente ausgetauscht. Die Datentypen sind dabei komplett über XML-Schema definiert.

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 Apaches "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ügen die Application Server beispielsweise über ein zeilenorientiertes Werkzeug, mit dessen Hilfe sich Programme als Web-Services verpacken lassen.

Komfortable Arbeitsumgebung

Sehr viel komfortabler geht es zu, wenn die Entwicklungsumgebungen die Arbeit des Programmierers mit grafischen Werkzeugen unterstützen, so durch Wizards, die grafische Modellierung auf Basis der Unified Modelling Language (UML) mit Klassen- und Aktivitätsdiagrammen sowie durch eine automatische 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.

Bei der Entwicklung von Web-Services lassen sich sowohl bestehende Programme entsprechend aufbereiten als auch neue Anwendungen schreiben. Für eine neue Anwendung programmiert der Entwickler wie gewohnt seine Geschäftslogik zum Beispiel in Form von Java-Klassen. Hierbei werden Applikationen in "stateless" oder "statefull" unterschieden, wobei sich Anwendungen ersteren Typs einen Status nicht merken. 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 jedoch nicht gezwungen, selbst Hand anzulegen, sondern der Application Server benutzt in diesem Fall automatisch den Cookie-Mechanismus. Dieser Weg ist allerdings nicht standardisiert, beim Wechsel auf eine andere Ablaufumgebung kann also ein Änderungsaufwand entstehen. Weitere Implementierungen von Logik können unter anderem stateless Enterprise Javabeans (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. Die meisten Entwicklungs-Tools unterstützen das. Dabei wird ein WSDL-Interface, das beschreibt, wie man den Service aufrufen kann, automatisch erzeugt. Gleichzeitig erfolgt die Generierung aller technischen Klassen: ein Client-Stub oder auch Proxy sorgt dafür, dass Java-Aufrufe auf der Client-Seite in Soap-Nachrichten übersetzt werden, und ein Server-Skeleton überträgt Server-seitig die Soap-Aufrufe in die Sprache der Dienstimplementierung etwa in Java.

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ötig mit Soap-Implementierung befassen müssen.

Der nächste Schritt ist die Verteilung (Deployment) des Archivs auf den Application Server. Diesen Schritt unterstützen die meisten Entwicklungssuiten für mehrere Application Server mit einem einzigen Mausklick. Dabei wird das J2EE Web Service Archive entpackt und entsprechend den J2EE-Vorschriften so im Application Server verteilt, dass der Web-Service sofort lauffähig ist. Um vorab die Funktionsfähigkeit des Web-Service zu testen, erzeugen die meisten Ablaufumgebungen automatisch einen Test-Client in Form einer Java Server Page.

Datenbank: Provider oder Consumer

Als letzte Aufgabe muss die Client-Anwendung geschrieben werden. Hier profitiert der Java-Entwickler vom generierten Client-Stub. Es muss lediglich dafür gesorgt sein, dass im Client-Programm die gewünschten Web-Service-Aufrufe als lokale Java-Methodenaufrufe auf dem Stub programmiert sind.

Nicht nur Java-Applikationen lassen sich als Web-Services bereitstellen, sondern auch vorhandene Datenbankanwendungen können sehr komfortabel entsprechend "umgewandelt" werden. Dabei unterscheidet man grundsätzlich zwei Mechanismen: die Datenbank als Provider oder als Consumer. Im ersten Fall steckt die Implementierung, also die Programmlogik, in der Datenbank und soll als Web-Service von außen zugänglich sein. Dadurch lässt sich ein Zugriff auf relationale und multimediale Daten, XML-Dokumente und weitere Datenbankobjekte für andere, etwa Browser-basierende Anwendungen umsetzen. Der Vorteil: Auf diese Weise sind früher getätigte Investitionen in datenbankgestützte SQL-Anwendungen geschützt. Mit einem entsprechenden Tool werden die SQL-Prozeduren in eine Java-Hülle gepackt und eine Beschreibung mit WSDL angelegt. Per Soap können dann andere Programme darauf zugreifen.

Vorhandene Logik nutzen

Fungiert eine Datenbank als Consumer, holt sich die SQL- oder Java-Stored-Procedure-Anwendung Daten aus einem anderen System via Web-Service. Dazu müssen Soap-Bibliotheken sowie der Java-Client-Proxy in die Datenbank geladen werden, um den entfernten Service aufzurufen. Dies ist ein einfaches Mittel, um Logik, die in der Datenbank vorhanden ist, effizient zu nutzen. So lassen sich je nach Bedarf Daten, die sich permanent ändern (zum Beispiel Aktien- und Währungskurse, Zinssätze oder Wetterinformationen) aus einer Datenbankanwendung abfragen. Ein Beispiel: Unterschreitet der Lagerbestand, der durch eine Datenbanktabelle repräsentiert ist, einen bestimmten Mindestwert, wird automatisch die Nachbestellung der Ware im Lieferantensystem durch eine Soap-Nachricht ausgelöst.

In modernen betriebswirtschaftlichen Lösungen werden solche Ereignisse heute in der Applikation abgearbeitet. Bei vielen bestehenden Datenbankanwendungen jedoch bietet sich durch Web-Services die Möglichkeit, etwa Alarm- oder Meldefunktionen sehr schnell aus der Datenbank heraus umzusetzen, ohne dass Anwendungen neu geschrieben werden müssen. Denn Schnelligkeit ist der Hauptbeweggrund für den Einsatz von Web-Services, wie die eingangs genannten CGEY-Berater herausfanden. Während weniger als 38 Prozent der befragten User Kostenaspekte als Gründe für den Einsatz von Web-Services ins Feld führten, standen Kriterien wie Flexibilität und schnelle Anpassung an Marktveränderungen mit 66 Prozent an der oberster Stelle. (ue)

*Evgenia Rosa ist Senior Systemberaterin bei Oracle Deutschland.

Angeklickt

Die bekannten grafischen Entwicklungsumgebungen bieten Programmierern inzwischen komfortable Werkzeuge, um Java-basierende Web-Services-Komponenten zu erstellen. Sei es das Schreiben von Geschäftslogik etwa in Form von Java-Klassen, das Anlegen von J2EE Enterprise Archive, das Erzeugen von WSDL-Interfaces und Soap-Nachrichten oder die Verteilung des Archivs auf den Applikations-Server.