Nachdem zuerst vor allem Microsoft und IBM die Web-Services als neue Infrastruktur für Internet-Anwendungen propagierten, lässt ihnen nun auch Sun Aufmerksamkeit zukommen. Die Unix-Company stellte auf der diesjährigen Entwicklerkonferenz Javaone zahlreiche neue Programmier-Schnittstellen und Erweiterungen vor, die Java zur ersten Wahl für die Entwicklung dieser neuen Web-Dienste machen soll.

Das ehrgeizige Ziel freilich harmoniert nicht ohne weiteres mit dem von Sun festgelegten Java-Fahrplan. Das liegt zum einen daran, dass für die Web-Services sowohl neue Basisfunktionen als auch zusätzliche Server-Dienste vorgesehen sind. Erstere werden typischerweise in der "Java 2 Standard Edition" (J2SE) umgesetzt, Letztere erfordern entsprechende Erweiterungen der Java 2 Enterprise Edition (J2EE). Die beiden Java-Editionen folgen aber keinem einheitlichen Update-Zyklus, so dass die gesamten in Arbeit befindlichen Spezifikationen nicht gleichzeitig freigegeben werden. Zudem will Sun fast alle XML-APIs getrennt von der J2SE-Kerndistribution verfügbar machen; erst in der Version 1.5 sollen sie zum Java-Kern gehören.

Die Web-Service-Unterstützung lässt sich mit dem Java-Fahrplan auch deshalb schwer abstimmen, weil einzelne Technologien selbst noch einem Wandel unterliegen: Beispielsweise soll Soap in einer W3C-Empfehlung namens XMLP aufgehen. Nicht zuletzt steht Sun hinter der Initiative ebXML, deren Framework für den elektronischen Handel sich in vielen Bereichen mit den Web-Services überschneidet (siehe dazu CW 23/01, Seite 18). Die Unix-Company legt deshalb Wert darauf, dass die entsprechenden Java-APIs beide Initiativen berücksichtigen. Allerdings wurde die erste Version von ebXML erst Anfang Mai verabschiedet und bremste so Suns Ambitionen.

Betrachtet man die Funktionsweise der Web-Services, dann lassen sich ihre künftigen Anforderungen an die Java-Plattform absehen. Etwas salopp könnte man diese als simplifizierte Variante von Corba beziehungsweise DCOM beschreiben.

Lose gekoppelte Internet-AnwendungenDie Universal Description, Discovery und Integration (UDDI) dient dem Registrieren und Auffinden von Diensten, beides erfolgt über Soap-Nachrichten. Eine Abfrage gibt einen Zeiger auf die Website des Anbieters zurück, wo sich die genaue Beschreibung der zugänglichen Funktionen befindet. Die Publizierung von Methoden und der verlangten Parameter leistet dort die Web Services Description Language (WSDL), eine Art Interface Definition Language (IDL) im XML-Format. Für den synchronen Aufruf entfernter Prozeduren oder die asynchrone Zustellung von Nachrichten dient wiederum Soap, seinerseits ein XML-basierendes Protokoll über HTTP. Insgesamt ist bei den Web-Services von einer Infrastruktur für verteilte, aber lose gekoppelte Internet-Anwendungen die Rede.

Aufgrund der XML-Lastigkeit der Web-Services bietet Sun in Java Schnittstellen zur Verarbeitung derart strukturierter Daten an. Die Java APIs for XML Processing (Jaxp) unterstützten bereits in der Version 1.0 den W3C-Standard Document Object Model (DOM) und das Simple API for XML (SAX). Das eben erschienene Update 1.1 unterstützt Level 2 der beiden XML-APIs und definiert zudem eine Schnittstelle namens Transformation API for XML (Trax) zu XSLT-Prozessoren. Jaxp 1.1 wird Bestandteil von J2SE 1.4 sein.

XML-APIs in Jax-Pack zusammengefasstAls Folge der beschriebenen Konflikte zwischen dem Java-Fahrplan und den kurzfristigen Anforderungen durch die Web-Services bleiben aber die Jaxp die einzigen XML-APIs, die den Weg in die J2SE-Kerndistribution finden. Zu den optionalen Packages zählen die Java APIs for XML Messaging (Jaxm), die für das Verpacken, Transportieren und Weiterleiten von XML- und Nicht-XML-Daten zuständig sind. Sie unterstützen sowohl Soap 1.1 with Attachments als auch das Messaging-Verfahren von ebXML. Ebenfalls auf Soap setzt Jax-RPC auf, nutzt dieses aber nicht für asynchrones Messaging, sondern für den Aufruf von entfernten Methoden via Remote Procedure Call (RPC). Dem Eintragen in und der Abfrage von UDDI und ebXML-Registrierungen dienen die Java APIs for XML Registries (Jaxr). Eine weitere XML-Schnittstelle namens Java Architecture for XML Binding (Jaxb) dient nicht direkt der Implementierung von Web-Services, könnte aber durch die Abbildung von XML-Daten auf Java-Objekte unter Verwendung eines Schema-Compilers die Verarbeitung solcher Business-Informationen beschleunigen. Nachdem DOM-Parser beim Eintreffen einer großen Zahl von Soap-Nachrichten möglicherweise bald an ihre Leistungsgrenzen stoßen, könnte sich Jaxr in diesem Zusammenhang als interessante Alternative erweisen.

Sun wird alle XML-APIs in einem Paket unter der Bezeichnung Jax-Pack zur Verfügung stellen. Sie eignen sich zur Nutzung sowohl auf dem Client als auch auf dem Server, wobei diese Unterscheidung im Fall der Web-Services nicht ohne weiteres getroffen werden kann: Ein Versender von Soap-Nachrichten, also ein Client, läuft in der Praxis meist auf einem Server, da diese Art des Messaging häufig ohne Benutzerintervention vonstatten gehen soll. Dieses Jax-Pack soll seinerseits wieder Bestandteil des Web-Service-Pack sein, das zusätzlich die Servlet- und JSP-Engine "Tomcat" der Apache Group sowie "Java Server Faces" enthalten soll. Letzteres beschreibt Sun als Framework von GUI-Komponenten für die Erzeugung von Web-Frontends. Unter anderem soll es in der Lage sein, Elemente einer HTML-Seite mit bestimmten Java-Klassen auf dem Server zu assoziieren. Treten bestimmte Benutzerereignisse auf, beispielsweise das Anklicken einer Checkbox oder das Herausbewegen des Cursors aus einem Textfeld, dann sollen die zugeordneten Methoden auf dem JSP-Server aktiviert werden. Auf diese Weise könnten beispielsweise Benutzereingaben validiert werden. Laut Hersteller können Tools, die diese Spezifikation umsetzen, Entwickler von den Eigenheiten bestimmter Browser abschirmen und die Verbindung zwischen Client und Server mittels visueller Programmierung erlauben. Derzeit durchläuft Java Server Faces noch den Java Community Process und ist als Java Specification Request (JSR) 127 registriert (http://jcp.org/jsr/detail/127.jsp).

Während ein solches Server-basierendes GUI nicht unmittelbar mit Web-Services zu tun zu haben scheint, zielen andere Neuerungen in J2EE stärker auf die Unterstützung dieser Infrastruktur ab. So müssen Hersteller, die Produkte auf Basis des kommenden J2EE 1.3 anbieten wollen, das Java Message Service API (JMS) implementieren. Es handelt sich dabei um Schnittstellen für den Zugriff auf Message Oriented Middleware (MOM) wie IBMs "MQ Series" oder "Sonic MQ" von Progress. Diese Entscheidung mag zwar auch dadurch motiviert sein, dass Microsoft sein "MS MQ" seit dem Erscheinen von Windows 2000 mit COM+ als Teil des Betriebssystems ausliefert. Im Zusammenhang mit lose gekoppelten Internet-Anwendungen kommt aber der asynchronen Kommunikation erhebliche Bedeutung zu: Der Aufruf von entfernten Prozeduren mittels RPC über das Internet blockiert den Aufrufer und führt bei schlechter Verbindungsqualität schlimmstenfalls zu Zeitüberschreitungen. Hingegen gewährleisten MOMs üblicherweise die Zustellung von Nachrichten selbst nach Absturz und Neustart des Rechners.

Neben der Verpflichtung für Hersteller von J2EE-kompatiblen Produkten, JMS zu implementieren, soll auch die Einführung von Message Driven Beans (MDB) die Unterstützung für asynchrone Kommunikation verbessern. Es handelt sich dabei um eine Erweiterung des Komponentenmodells Enterprise Javabeans (EJB), die mit der Version 2.0 eingeführt wird. Bisher erforderte die Integration von EJBs mit Message-Queuing-Middleware einigen Programmieraufwand. MDBs sollen diesen verringern, weil sie Zugriff auf JMS haben und bei Eintreffen einer Nachricht automatisch aktiviert werden können.

Die Publizierung von EJB-Funktionen mittels WSDL dürfte bei der Java-Unterstützung für Web-Services die geringsten Probleme bereiten. Da alle modernen Komponentenmodelle Funktionen über definierte Interfaces nach außen sichbar machen, geht es dabei in erster Linie um die Übersetzung dieser Information in XML-Syntax. Einzelne Hersteller wie Bea oder IBM beherrschen dies mit ihren Applikations-Servern bereits. Für Sun geht es jetzt noch darum, dieses Mapping zu standardisieren.

Ebenfalls zum Pflichtprogramm für Hersteller von J2EE-konformen Applikations-Servern wird mit der Version 1.3 die noch in Entwicklung begriffene Java Connection Architecture (JCA). Sie dient der Anbindung von Standardsoftware, etwa von ERP- oder CRM-Systemen. JCA kann im Gegensatz etwa zu JDBC keine einheitliche Schnittstelle zu diesen Anwendungen bieten, da sich diese in puncto Funktionsumfang und APIs zu stark voneinander unterscheiden. Sie legt aber einen Plugin-Mechanismus fest, über den sich Adapter für Standardsoftware in alle mit J2EE 1.3 kompatiblen Applikations-Server einbinden lassen. Nach Vorstellung von Sun-Verantwortlichen könnte JCA deshalb einen eigenen Markt für derartige Integrationsmodule schaffen.

Für Anwender ergeben sich daraus gleich mehrere Vorteile: Sie erlangen mehr Unabhängigkeit von einzelnen Applikations-Servern, können wegen des größeren Angebots an Adaptern wahrscheinlich auch weniger verbreitete ERP-Systeme einbinden und außerdem diese Systeme mittels des Java-Anwendungs-Servers für die neuen Web-Dienste zugänglich machen. Dabei sind Applikations-Server in der Lage, Verbindungen zum ERP-System für mehrere User gleichzeitig zu nutzen ("Connection Pooling") und verteilte Transaktionen auszuführen, die auch andere Programme oder Datenbanken mit einbeziehen. Mit SAP hat bereits ein Schwergewicht der Branche Unterstützung für diese Architektur angekündigt: Die Walldorfer wollen ihren "SAP Java Connector" für die JCA anpassen.

Im Vergleich zur Einführung von JCA nimmt sich eine weitere Neuerung in J2EE zwar weniger spektakulär aus, kann sich aber in Zusammenhang mit Web-Services als nützlich erweisen. Die Version 2.3 der Servlet-Spezifikation sieht vor, dass sich derartige Web-Server-Erweiterungen als Filter nutzen lassen. Entwickler können dann Routinen (Callbacks) schreiben, die bei Start oder Beendigung eines Servlets ausgeführt werden. Beispielsweise ließe sich so die Nutzlast einer Soap-Nachricht, die häufig im XML-Format vorliegt, vor ihrer Verarbeitung einem XSLT-Prozessor zur Transformation auf ein anderes Schema übergeben.

Neu in J2SE 1.4Die Version 1.4 bringt unter anderem folgende Veränderungen:

-Geschwindigkeitsverbesserungen für Java-GUIs durch eine neue 2D-Rendering-Engine

-"Headless GUI" erlaubt auch Server-Programmen Zugriff auf einen Teil der GUI-Funktionen, beispielsweise zur dynamischen Erzeugung von Grafiken

-Bessere Unterstützung für Truetype-Schriften und X-Window-Systeme. Bei Letzteren wird die Bildschirmausgabe nicht mehr in Form von Bitmaps an das X-Terminals geschickt, sondern als X-Kommandos

-Java-Programme können Mouse Wheel ansprechen

-Volle Drag-and-Drop-Unterstützung

-Neue GUI-Elemente: Fortschrittsanzeige und Drehmenü ("Spinner")

-Persistenz für Javabeans durch Archivierungsfeature, so dass dafür nicht mehr die Serialisierungsfunktionen genutzt werden müssen

-Unterstützung für IPv6, wenn im darunter liegenden Betriebssystem vorhanden

-Neue URI-Klasse mit vollständiger Kompatibilität mit W3C-URLs

-Die bisher optionalen Packages Java Secure Socket Extension (JSSE), Java Authentication and Authorization Service (JAAS) und die Java Cryptography Extension (JCE) sind künftig Bestandteil der Kerndistribution. Neu hinzu kommt eine Kerberos-Implementierung, die auch die Anmeldung an Microsofts "Active Directory" erlaubt

-Fliegender Austausch von Klassen während des Debugging, so dass wie bei Scriptsprachen nach Behebung eines Fehlers der Programmablauf ohne Neustart fortgesetzt werden kann

-Einführung des Sprachkonstrukts "assertion", das die Fehlersuche vereinfachen soll

-Asynchrones I/O, so dass nicht für jede Ein- und Ausgabe ein eigener Thread gestartet werden muss

-Unterstützung für reguläre Ausdrücke nach dem Vorbild von Perl 5

-Preference API mit Funktionen zur Speicherung von Benutzereinstellungen

-Logging API, von dem das JDK selbst sowie Anwendungen Gebrauch machen können

-Volle Unterstützung für Unicode 3.0

-Verkettung von Ausnahmeereignissen ("Exception Chaining") macht bei mehreren aufeinander folgenden Fehlerbedingungen nicht nur die zuletzt, sondern auch alle zuvor aufgetretenen für den Programmierer sichtbar

-Unterstützung von Heap-Speicher in GB-Größe

Java-GeschmacksrichtungenNachdem Sun bereits mit Java 1.1 begann, abgespeckte Varianten ("Embedded Java" und "Personal Java") seiner Plattform anzubieten, teilte die Unix-Company rund ein Jahr später Java in drei Ausführungen auf: die Standard-, Enterprise- und Micro-Edition. Während für die ersten beiden ein genauer Funktionsumfang feststeht, den Lizenznehmer bei jedem Update vollständig umsetzen müssen, bietet J2ME den Herstellern von Kleingeräten größere Freiheiten. Die jeweilige Java-Implementierung ist dort das Ergebnis von Konfigurationen und Profilen. Konfigurationen treffen je nach Zielplattform eine grundsätzliche Unterscheidung hinsichtlich der Leistungsfähigkeit der Virtual Machine (VM) und der Low-Level-Funktionsbibliotheken. So eignet sich die Connected Device Configuration (CDC) für Geräte mit 32-Bit-Prozessoren und mindestens 2 MB Arbeitsspeicher; hingegen ist die Connected Limited Device Configuration (CLDC) für Hardware gedacht, die nicht mehr als 160 bis 512 KB an Memory aufweist. Für beide Konfigurationen sieht Sun unterschiedliche VMs vor, für CDC die "C Virtual Machine" und für DLDC die KVM. Auf Basis dieser Grundausstattung legen dann Profile fest, welche APIs zusätzlich unterstützt werden sollen. Beispielsweise bestimmt das Mobile Information Device Profile (MIDP), welche Programmier-Schnittstellen auf DLDC-Geräten wie Mobiltelefonen oder Pager vorhanden sind. Das unter Java 1.1 eingeführte "Personal Java" wird auf Basis des CDC und eines "Personal"-Profils neu definiert. Neben der Nutzung von Konfigurationen und Profilen steht es Hardwareherstellern frei, weitere APIs, also Optional Packages, auf ihren Geräten zu unterstützen.

Da J2ME-Profile bei der Auswahl von APIs auf die Bibliotheken der J2SE zurückgreifen, gilt bei der Weiterentwicklung von Java die Standard-Edition als Schrittmacher. Diese Abhängigkeit trifft auch auf J2EE zu, die mit Servlets, Java Server Pages oder Enterprise Javabeans auf J2SE aufsetzt. Beide Ausgaben bestehen jeweils aus der Spezifikation, einer Referenzimplementierung, Kompatibilitätstests und Blueprints, die Empfehlungen für die Umsetzung der Spezifikation umfassen.

Grundlegende Unterschiede existieren zwischen J2SE und J2EE hinsichtlich der Referenzimplementierung: Während jene der Enterprise-Ausführung nur zeigen soll, dass sich die Spezifikation prinzipiell realisieren lässt ("Proof of Concept"), ist die der Standard-Edition für die Nutzung in Produktionsumgebungen ausgelegt. Sun bietet eine solche auf Geschwindigkeit und Stabilität getrimmte Implementierung über das SDK und als Java Runtime Environment (JRE) für Solaris, Windows und Linux an. Für andere Plattformen steht es deren Herstellern oder Drittanbietern frei, die Spezifikation selbst umzusetzen. Letztere bleibt ohne Rücksicht auf die Anforderungen der Zielplattform immer gleich, die jeweiligen Implementierungen sollen aber für den geplanten Einsatz angepasst werden. So bietet Sun für jedes der drei unterstützten Betriebssysteme zwei funktionsgleiche VMs an, die aber jeweils für die Nutzung auf dem Client beziehungsweise auf dem Server optimiert wurden (für Windows muss die Server-Ausführung separat heruntergeladen werden).