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.

29.08.2003 - 

Java versus .NET/Bordmittel nur für Basisdienste geeignet

Web-Services verbinden Java und .NET

Web-Services gelten als das bevorzugte Mittel zur Kommunikation von Java- und .NET-Anwendungen. Der Soap-Standard reicht allerdings nicht aus, um komplexe Datentypen plattformübergreifend zu verschicken. Abhilfe kann hier ein Soap-Gateway schaffen, das Nachrichten verständlich aufbereitet.Von Arno Klein*

Der Wunsch nach Interoperabilität zwischen verschiedenen Betriebssystemen und Programmierparadigmen hatte in der Vergangenheit stets zur Folge, dass proprietäre Gateway-Systeme gekauft werden mussten. Der Siegeszug von Soap führt nun erstmals zu einer allgemein einsetzbaren Kommunikationsschicht zur Entwicklung von verteilten Applikationen mit .NET- und J2EE-Komponenten. Insbesondere Microsoft hat mit der Einführung von .NET die Vorteile betont, die mit der Öffnung seiner Programmierwelt durch Web-Services einhergehen.

Warum gemischte Anwendungen?

Zunächst stellt sich die Frage nach der Sinnhaftigkeit einer Integration von .NET- und J2EE-Komponenten, da ja jede der beiden Programmier-Frameworks ihre eigenen, effizienten Mechanismen für die Realisierung der rechnerübergreifenden Kommunikation zur Verfügung stellt. Auf J2EE-Seite stehen mit RMI und Corba gleich zwei Möglichkeiten zur Auswahl, die im Falle von Corba auch Persistenz-, Transaktions- und Event-Dienste spezifizieren. Bei .NET ist ein flexibel konfigurierbares und effizientes Remoting-Framework verfügbar. Diese Kommunikationsmittel sind an das jeweilige Programmierparadigma angepasst und auf Performance und Stabilität optimiert. Warum also gemischte Applikationen entwickeln, die den jeweiligen Welten fremde Kommunikationsmechanismen verwenden?

Mögliche Einsatzgebiete für solche kombinierten Lösungen stellen Systeme dar, die aufgrund des De-facto-Monopols von Microsoft am Desktop visuell ansprechende und funktional komplexe Rich-Client-Anwendungen benötigen. Häufig müssen Anwendungen aber auch wegen ihrer Integration mit Office-Komponenten auf die Windows-Plattform zugeschnitten sein und dabei gleichzeitig Dienste für Web-Applikationen anbieten. Für Letztere existieren auf Basis von J2EE-Applikations-Servern sowie verschiedener Frameworks (beispielsweise "Struts", "Turbine", "IBM Portal Server", "SAP Enterprise Portal") eine Vielzahl von Entwicklungs- und Deployment-Umgebungen. Sie erfüllen durchweg die höchsten Ansprüche an Verfügbarkeit, Performance und Wartbarkeit. Zusätzlich sind die Bedenken hinsichtlich der Sicherheit des "Internet Information Server" nach wie vor ein Argument für die Entwicklung von Web-Applikationen mit J2EE.

Web-Services in der Praxis

Mit den neuesten Versionen der jeweiligen Soap-Bibliotheken und -Tools ist eine weitgehende Interoperabilität der mit Werkzeugen und Assistenten erstellten Web-Services gewährleistet. Bei .NET ist die Entwurfsunterstützung für Web-Services komplett in die Microsoft Entwicklungsumgebung Visual Studio .NET integriert. Auf der Java-Seite bietet die Open-Source-Bibliothek "Apache Axis 1.2" Entwicklungs- und Deployment-Tools sowie den Runtime Stack. Allerdings beschränkt sich die Interoperabilität auf die Verwendung von Web-Services mit primitiven Datentypen. Als komplexe Datentypen sind standardmäßig gerade Arrays zwischen .NET und Java-Diensten austauschbar. Sobald benutzerdefinierte, zusammengesetzte Datentypen verwendet werden sollen, muss der Entwickler Serialisierer und Deserialisierer für diese Objektinstanzen selbst programmieren.

Ein weiteres Problem besteht in der korrekten Verwendung des für das Erzeugen von Soap-Nachrichten zuständigen XML-Writers sowie der Konfiguration eines geeigneten XML-Parsers zur Analyse der empfangenen Nachrichten. So versieht der "XmlTextWriter" des .NET-Frameworks UTF-8 und UTF-16-codierte XML-Daten standardmäßig mit einer BOM (Byte Order Mark), die nur von den wenigsten Java-XML-Parsern verstanden wird. Dies gilt auch für den im Java Development KitS(JDK) 1.4 enthaltenen "Crimson". Die in der Vergangenheit vorhandenen Probleme bei der Interpretation der Typinformation von Rückgabewerten sind inzwischen jedoch behoben.

Trotz der weitreichenden Interoperabilität bieten beide Systeme jedoch noch keine Unterstützung bei der Realisierung praxisnaher Applikationen. Hier fehlt eine auf Soap aufbauende Architektur von Unterstützungsdiensten, wie sie etwa die Common Object Services im Rahmen der Corba-Spezifikation bieten. Der aktuelle Soap-Standard lässt sich hinsichtlich seiner Funktionalität mit TCP vergleichen. Dieses Protokoll ist zwar essentiell für die Kommunikation über Rechnergrenzen hinweg, jedoch programmieren Entwickler heute kaum noch auf dieser Ebene. Stattdessen verwenden sie komplexere Komponenten auf Basis von TCP-Nachrichten, die schließlich zu E-Mail-Programmen, HTTP-Diensten und Sicherheitssystemen integriert werden.

Für eine effiziente Verwendung von Web-Services fehlen in der Praxis vor allem die Unterstützung für Session-Management, Transaktionsdienste zur Einbindung von Web-Service-basierenden Komponenten in Enterprise-Anwendungen sowie eine standardisierte Möglichkeit zur Verwendung von Objektreferenzen über Soap-Kommunikationskanäle. Die beiden Plattformen bieten zwar die Mittel, um entsprechende höherwertige Dienste zu realisieren, jedoch muss sichergestellt werden, dass solche Funktionen nicht zu Lasten der Interoperabilität gehen. So lässt sich das Problem des Session-Managements relativ einfach über die Server-seitige Erzeugung und Verwaltung von Cookies in den Griff bekommen, allerdings würde man mit einer entsprechenden Implementierung .NET-basierende Konsumenten ausschließen, die Client-seitig keine Cookies verwalten können.

Trotz der genannten Einschränkungen sind Web-Services auch heute schon eine gute Möglichkeit, Brücken zwischen den zwei unterschiedlichen Welten zu schlagen. Damit die Interaktion jedoch zuverlässig und effizient funktioniert, ist es von Vorteil, eine Zwischenschicht für die Komponentenkommunikation vorzusehen. Diese sollte benötigte Basisdienste, wie etwa Session- und Transaktions-Management in applikationsspezifischer Weise zur Verfügung stellen. Auf diese Weise erlaubt sie die Integration von Soap-basierenden Komponenten in beliebige Enterprise-Anwendungen. Weiterhin bietet die Entkopplung der direkten Kommunikation die Möglichkeit zur Einführung einer Caching-Schicht, die den Datendurchsatz beim Lesezugriff entscheidend verbessern kann.

Entkoppelte Kommunikation

Ein solches Soap-Applikations-Gateway erlaubt die Nutzung von .NET-basierenden Server-Diensten sowohl durch Rich-Client-Anwendungen als auch durch J2EE-gestützte Web-Applikationen. Dabei vermitteln ein oder mehrere Soap-Interop-Web-Services zwischen den Anwendungskomponenten. Sie werden durch die zentrale UDDI-Registrierung netzwerkweit bekannt gemacht und verfügen mindestens über eine gemeinsame Session-, Security- und eventuell Failover-Verwaltung. Auf J2EE-Seite steht eine auf lesenden Zugriff spezialisierte Cache-Komponente zur Verfügung, die benötigte Daten durch Bulk-Operationen von einem Interop-Dienst holt und den Web-Applikationen zur Verfügung stellt.

Was noch fehlt

Die im Moment vorliegenden Web-Service-Spezifikationen bieten Basismechanismen zur Realisierung gemischter Anwendungen. Interoperabilität zwischen Java- und .NET ist mit den neuesten Versionen der entsprechenden Bibliotheken und Tools kein Problem mehr. Es fehlen jedoch die Definition und Realisierung eines Frameworks zum Aufbau komplexerer, Soap-basierender Enterprise-Applikationen. Entsprechende Konzepte befinden sich bereits in Vorbereitung, beispielsweise: bei IBM mit dem Projekt BPELWS (Business Process Execution Language for Web-Services1). Dabei geht es um die Integration und Weiterleitung von Business-Transaktionen mit Web-Services. Einen unternehmensübergreifenden Zusammenschluss zur Verbesserung der Web-Services-Spezifikation stellt die Web-Services Interoperability Organization dar (siehe Kasten). (ws)

*Arno Klein ist Gruppenleiter Entwicklung bei der Schema GmbH in Nürnberg.

Angeklickt

Wenn Java- und .NET-Anwendungen miteinander kommunizieren müssen, dann gelten Web-Services als die bevorzugte Technik. Die dazu zählenden Basisstandards wie Soap machen aber zu wenige Vorgaben, um etwa den reibungslosen Austausch komplexer Datentypen über Plattformgrenzen hinweg zu gewährleisten. Die Initiative WS-I definiert mit dem kürzlich verabschiedeten Basic Profile nur den kleinsten gemeinsamen Nenner. Als Lösung für derartige Interoperabilitätsprobleme kommen eigene Frameworks in Frage.

Die Aufgaben der WS-I Organziation

Die WS-I Organization (http://www.ws-i.org) ist ein Zusammenschluss der wichtigsten Web-Service-Anbieter. Ziel ist die Beseitigung der wichtigsten Probleme bei der praktischen Anwendung von Web-Services.

Das Web-Services Basic Profile 1.0 (WS-Basic) spezifiziert die grundlegenden Interoperabilitätsanforderungen für Web-Services, Use Cases und Szenarien sowie Testmaterialien und Beispielsanwendungen. Auf dieser Grundlage können Programme als WS-I-konform zertifiziert werden.

WS-Basic stellt einen wichtigen Schritt für die Interoperabilität dar, weil die Spezifikation die meisten Stolpersteine und Ungenauigkeiten in der Soap-Spezifikation beseitigt.(siehe auch Seite 15)

Abb: Unterschiedliche Anwendungen kommunizieren über ein Framework

Ein Soap-Interop-Framework unterstützt die Kommunikation unterschiedlicher Anwendungen. Dazu zählen .NET-basierende Server-Dienste ebenso wie Rich-Client- und J2EE-gestützte Web-Applikationen. Quelle: Schema GmbH