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.

07.03.1997 - 

Neu: Datenbankzugriff und Komponentenmodell

Sun öffnet Java 1.1 für Geschäftsanwendungen

Java weist Vorzüge auf, die die Programmiersprache schnell für mehr empfehlen als den Aufputz von Web-Seiten. Wesentlich in diesem Zusammenhang ist die Plattformunabhängigkeit des interpretierten Byte-Codes.

Freilich mangelte es Java in der ersten Ausführung an Funktionen, die für die Entwicklung von Geschäftsanwendungen unabkömmlich sind. Dazu gehören die Fähigkeit zu Datenbankzugriffen oder die Möglichkeit, Java-Module über ein Komponentenmodell zu größeren Anwendungen zu kombinieren. Hinderlich waren bis dato auch die Beschränkungen des Abstract Window Toolkit (AWT), das die Klassen zur Programmierung der Benutzer-Schnittstelle enthält.

Diese Beschränkungen bekam eine Vielzahl von Unternehmen zu spüren, die frühzeitig in die Java-Programmierung eingestiegen waren. Sie warteten nun ungeduldig mit halbfertigen Produkten auf die Fertigstellung des JDK 1.1. Dazu gehören beispielsweise Borland mit "Jbuilder" (Codename "Latte"), Corel mit "Office for Java" oder auch Lotus mit seinen zahlreichen Java-Projekten. Für den Erfolg von Java spricht, daß die Stimmung in der Software-Industrie durchaus mit jener vergleichbar war, wie sie vor dem Erscheinen von Windows 95 zuletzt beobachtet werden konnte. Mit der Freigabe des JDK 1.1 erwarten Marktbeobachter für 1997 eine Flut neuer Java-Anwendungen.

Das Java Development Kit (JDK) 1.1 räumt nicht nur mit vorhandenen Defiziten auf, sondern bringt darüber hinaus eine Reihe von Neuerungen, die es als Entwicklungswerkzeug für plattformunabhängige, internationale Anwendungen aufwerten soll (siehe Kasten).Mit "Java Database Connectivity" (JDBC) bietet Sun Java-Programmierern nun eine Schnittstelle an, über die sie auf Unternehmensdaten zugreifen können. Der Hersteller bezeichnet JDBC als ein Low-Level-API, mit dem SQL-Befehle aufgerufen werden können. Diese müssen als Argumente an Java-Methoden übergeben werden. Das direkte Einbetten von SQL-Statements in Java-Quellcode sieht das JDK 1.1 aber nicht vor. Implementierungen für Embedded SQL überläßt Sun Drittherstellern. Beispielsweise will Oracle im zweiten Quartal 1997 einen entsprechenden Precompiler für sein J/SQL anbieten.

Die Ankündigung von JDBC im letzten Jahr rief die Kritik von Microsoft hervor. Die Gates-Company reklamierte, daß mit ODBC bereits eine Standard-Schnittstelle für den Datenbankzugriff existiere. Sun verweist allerdings darauf, daß JDBC spezifische Vorteile für Java-Programmierer anbiete. ODBC besitzt nämlich nur eine Schnittstelle für die Sprache C, Java-Entwickler müßten deshalb auf plattformabhängigen C-Code zurückgreifen. Mit JDBC besteht hingegen die Möglichkeit, SQL-Befehle direkt aus Java abzusetzen. Im übrigen erfordert ODBC im Gegensatz zu JDBC die Installation eines ebenfalls plattformabhängigen Treiber-Managers auf jedem Client.

Sun verzichtet freilich nicht auf die Vorteile des großen Treibersortiments, das für ODBC existiert. Die Architektur von JDBC sieht vor, daß über eine Bridge ODBC-Treiber angesprochen werden können.

Diesen Ansatz will nun Microsoft aufgreifen. Vielversprechend für dreistufige Anwendungen scheinen sogenannte "JDBC Net pure Java driver": Treiber dieses Middleware-Modells übersetzen JDBC-Aufrufe in datenbankunabhängige Protokolle, die anschließend auf einem Server in datenbankspezifische Befehle umgewandelt werden.

Sehr viel einfacher wird mit JDBC der Datenbankzugriff für zweistufige Web-Anwendungen. Nachdem der Browser ein Java-Applet über eine HTML-Seite heruntergeladen hat, kann dieses vorbei am Web-Server direkt mit der Datenbank kommunizieren.

Für Java-Applets, die in eine Web-Seite eingebettet sind, stellte Sun bis dato keine Technik zur Verfügung, mit deren Hilfe diese untereinander kommunizieren können. Microsoft war in diesem Punkt mit Active X vorgeprescht und bot durch sein Entwicklungswerkzeug "Visual J++" die Möglichkeit, Java-Applets über das hauseigene Component Object Model (COM) zu verknüpfen. Auch Netscape entwickelte für den "Navigator" ein Komponentenmodell namens "Live Connect", das es erlaubt, Java-Applets mit Hilfe von Javascript zu steuern.

Mit den "Javabeans" legt Sun nun ein offizielles Komponentenmodell für Java vor. Wie bei JDBC war die Designvorgabe für die Sun-Entwickler, eine möglichst einfache und völlig in Java gehaltene Lösung anzubieten. Java-Programmierer benötigen kein zusätzliches Tool, um die Funktionen einer Javabean von außen zugänglich zu machen. In den meisten Fällen reicht dafür das Einhalten einer Namenskonvention für Methoden und Eigenschaften. Im Gegensatz dazu müssen für Active-X-Controls sogenannte Type-Libraries erstellt werden, um die in den Komponenten enthaltene Funktionalität zu veröffentlichen. Diese Informationen werden beim Installationsprozeß in der Registrierdatenbank abgespeichert. Jeder Javabean-Container ist hingegen in der Lage, entweder über Introspection oder die neu hinzugekommene Reflection-API Informationen über veröffentlichte Methoden und Eigenschaften direkt aus einer digitalen Kaffeebohne zu lesen. Eine Systemregistrierung oder ein separates Repository sind daher nicht nötig.

Dieser Sachverhalt kommt den Anbietern von Entwicklungswerkzeugen zugute. Tools können Programmierern sofort Auskunft über eine Javabean geben, wenn diese über Drag-and-drop auf ein Formular gezogen wird. Über visuelle Verfahren lassen sich dann einfach gewünschte Anpassungen an zugekauften Objekten vornehmen.

Die Javabeans-Architektur ist so konzipiert, daß jede Javabeans-Komponente über Bridges der Java Virtual Machine mit Modulen anderer Komponentenmodelle wie Active X, Opendoc oder Live Connect kommunizieren können. Sun wirbt damit, daß Entwickler deshalb auf Basis von Javabeans den größtmöglichen Markt für Komponenten und obendrein alle von Java unterstützten Plattformen erreichen können.

Im Gegensatz zu OLE (mittlerweile Active X), das Microsoft entwickelte, um monolithische Anwendungen auf kleinere Einheiten herunterbrechen zu können, geht es bei Javabeans um die Kombination von Applets zu größeren Anwendungen. Dieser Zusammenschluß von Applets funktioniert mit Javabeans allerdings nur innerhalb einer virtuellen Maschine. Sollen Java-Anwendungen in verteilten Umgebungen kommunizieren, dann müssen Entwickler auf die "Remote Method Invocation" (RMI) oder auf Corba zurückgreifen. RMI, ebenfalls eine Neuerung des JDK 1.1, ist auf die Interaktion von Anwendungen beschränkt, die mit Java entwickelt wurden. Corba hingegen verbindet Objekte unabhängig von der Programmiersprache, in der sie geschrieben wurden.

Im Vergleich zu ausgewachsenen GUIs etablierter Betriebssysteme fanden Entwickler bisher die Java-Möglichkeiten für das Design von Benutzer-Schnittstellen dürftig. Die im Paket "Abstract Window Toolkit" (AWT) zusammengefaßten Klassen machten sich ausgerechnet auf der Massenplattform Windows durch schlechte Performance und wenig ansprechende Optik bemerkbar. Das AWT für das Microsoft-System wurde deshalb beim JDK 1.1 von Grund auf neu geschrieben. Der Funktionsumfang erweiterte sich insgesamt erheblich. Neben der Unterstützung einer Zwischenablage, von Popup-Menüs, von Drag-and-drop, besserer Bedienung mit der Tastatur und der Integration eines reicheren Font-Angebots können auf dem JDK 1.1 basierende Anwendungen nun erstmals drucken.

Damit Anwender bei Applets, die auf lokale Ressourcen zugreifen, mehr Sicherheit gegen Hacker-Angriffe haben, sieht Sun nun auch Verfahren zur Codesignierung vor. Damit läßt sich die Herkunft eines Applets belegen. Das JDK 1.1 enthält ein Tool, mit dem sich die ebenfalls neu hinzugekommenen Java-Archive (JAR) signieren lassen. Eine solche JAR-Datei erlaubt Entwicklern, zusammengehörige Klassen komprimiert in einem Archiv zusammenzupacken und so die Download-Zeiten zu verkürzen. Auch hier begegnete Sun einem Vorstoß der Microsoft Corp., die über Visual J++ das hauseigene CAB-Format für diesen Zweck etablieren wollte.

Suns hochgesteckter Anspruch "Write once - run everywhere" kann sich nicht mit Plattformunabhängigkeit und Integration mit diversen Komponentenmodellen zufriedengeben. Durch die globale Reichweite des Internet sind Entwickler oft gezwungen, ihre Java-Anwendungen in mehreren länderspezifischen Versionen anzubieten. Schon von Anfang an unterstützte Java den Unicode-Zeichensatz. Im JDK 1.1 kamen in Zusammenarbeit mit IBM eine Reihe von Klassen hinzu, die die Lokalisierung von Anwendungen erleichtern sollen. Big Blue schöpfte dafür aus dem Vorrat des Taligent-Projekts.

Kasten

JDK 1.1: Neuerungen im Überblick

Unterstützung für internationale Anwendungen

Erlaubt die Darstellung von Unicode-Zeichen, unterstützt Zeichensatzkonvertierung und lokalisierte Ausgabe von Nachrichten, Behandlung von Zeit- und Währungsformaten.

Sicherheit

Das Java-Security-API umfaßt Schnittstellen für digitale Signaturen. Zusätzlich beinhaltet das JDK 1.1 abstrakte Schnittstellen für das Management von Schlüsseln, Zertifikaten und Zugriffskontrollen. Weitere APIs unterstützen Zertifikate nach X.509, Version 3. Zum Lieferumfang gehört zudem ein Tool, mit dem sich Java-Archive signieren lassen.

Erweiterungen des Abstract Window Toolkit

Sun war beim AWT vor allem um Verbesserung der Ablaufgeschwindigkeit bemüht. Zusätzliche Funktionalität umfaßt APIs für das Drucken, eine Zwischenablage für den Datenaustausch, eigene Cursor für jede Komponente, Drag and Drop und Pop-up-Menüs.

Java-Archive

Das plattformunabhängige JAR-Dateiformat kann mehrere Klassendateien, Grafiken und Sound in komprimierter Form zusammenfassen. Dadurch verkürzen sich die Ladezeiten für Applets.

Javabeans

Es handelt sich dabei um ein Komponentenmodell für Java, das die Zusammenstellung komplexer Anwendungen auf Basis von Java-Modulen erlaubt.

Reflection

Erlaubt Java-Anwendungen, Informationen über Methoden und Konstruktoren von geladenen Klassen zu erhalten.

Remote Method Invocation

RMI läßt die Programmierung von verteilten Java-Anwendungen zu. Methoden von entfernten Java-Objekten können damit von anderen virtuellen Maschinen aus aufgerufen werden.

Object Serialization

Diese Technologie erweitert die Java-Standardklassen für die Ein- und Ausgabe. Sie sorgt für die Persistenz von Objekten (das dauerhafte Speichern des Status von Objekten). Kommunikation über Sockets und RMI benutzen Object Serialization.

Java Database Connetivity

JDBC bietet als Standard-SQL-Schnittstelle einen einheitlichen Ansatz für den Zugriff auf Datenbanken verschiedener Hersteller. JDBC enthält eine Bridge zu ODBC.

Erweiterungen für Networking

Das java.net-Paket unterstützt nun Sockets im BSD-Stil. Hinzu kommen Performance-Verbesserungen und Fehlerkorrekturen.

Zusatzfunktionen für Ein- und Ausgabe

Das I/O-Paket unterstützt neben Byte-Streams nun auch Character-Streams. Diese können 16-Bit-Unicode-Zeichen enthalten.

Math-Paket

Umfaßt zusätzliche mathematische Funktionen wie das Generieren von Primzahlen oder für monetäre Berechnungen.