Web Services – mehr Speed in der Applikationsentwicklung

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) schon im vergangenen Jahr heraus, dass 83 Prozent der insgesamt 170 befragten Entscheidungsträger deutscher Unternehmen auf diese Technologie setzen oder zumindest auf Teile davon. Die Analysten von Gartner präsentierten in einer Studie vom Frühjahr 2003 sogar ein noch stärkeres Interesse: Demnach testeten 92 Prozent der Teilnehmer einer Studie in den USA mittlerweile die Web Services-Technologie meist in Pilotprojekten.

Die Gründe für diesen Erfolg liegen vor allem in der Plattformunabhängigkeit der Web Services und durch die Verwendung von XML als Datenaustauschformat. Die dadurch erreichte Freiheit bezieht sich sowohl auf den Einsatz von Programmiersprachen und Verbindungsprotokollen sowie auf Hardware und Betriebssysteme. Auf Basis von XML sind auch die Eckpfeiler für Web Services entstanden: SOAP für Nachrichtenaustausch, WSDL für die Schnittstellenbeschreibung sowie UDDI als Verzeichnisdienst. Der Nutzen dieser recht simplen Technologie zeigt sich dann beispielsweise bei der kostengünstigen Integration von Legacy-Systemen mit neuen Anwendungen. Ein weiterer 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 automatisch zur Verfügung. Zudem bieten Web Services die Möglichkeit, Brücken zwischen den Plattformen J2EE und .NET zu schlagen.

J2EE an .NET: „bitte kommen“

Für die Kompatibilität etwa zwischen J2EE und .NET sind Stand heute die Standards noch nicht vollständig ausdefiniert. So sind von einem Tool erzeugte WSDL-Beschreibungen nicht immer kompatibel zu den SOAP-Nachrichten des Clients, der mit dem Tool eines anderen Anbieters erzeugt wurde. Hier helfen Communities oder Foren im Internet etwa „SOAPBuilders“ (siehe Links) 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. Ebenso wird im Rahmen von Web Services Interoparability (WS-I), einer Organisation, in der die wichtigsten Softwarefirmen vertreten sind, an der Beseitigung dieser Probleme gearbeitet.

Im Unterschied zu Microsofts XML-Web Services, die auf der Technologie (.NET) und dem Microsoft Betriebssystem basieren und lediglich auf Intel-Plattformen laufen, stellen Web Services unter J2EE eine Spezifikation von XML-basierten 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 aufbauende 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).

Großansicht: Klick auf Bild

Grundsätzlich unterscheidet man bei Web Services zwischen RPC-Style (Remote Pro-cedure Call) und dem Document-Style – der vor allem in der Microsoft-Welt wichtig ist. Beim RPC-Style beinhaltet die SOAP-Nachricht eine Funktionsaufruf-Syntax, das heißt es wird ein entfernter Prozeduraufruf durchgeführt. Datentypen werden dabei nach der SOAP-Spezifikationen codiert. Beim Document-Style werden dagegen XML-Dokumente ausgetauscht. Die Datentypen sind dabei komplett über XML-Schema definiert.