Leise Revolution

Von: Jürgen Fey

Java läßt Kenner der Szene an die ersten Mainframe-Modelle zurückdenken: Die Parallelen sind frappierend. Nachdem die Programmiersprache den Client mit beweglichen Texten "erobert" hatte, erkannten die Entwickler, daß der Server das Zentrum der Aktivitäten ist. Dort ist eine Applikation einfacher zu verwalten, und auch die Integration in andere "Legacy"-Systeme fällt an dieser Stelle leichter.

Zwischen dem starren Mainframe-Konzept der "Gründerzeit" und dem "Distributed Processing" der Neuzeit liegen mehr als nur ein paar Jahre. Java eröffnet Systementwicklern mit Konzepten wie den Servlets (Java Applets auf dem WWW-Server), Remote Method Invocation (RMI) und Java Naming and Directory Interface (JNDI) neue Möglichkeiten bei der Entwicklung verteilter und skalierbarer Applikationen. Java Beans erlauben den mehrfachen Gebrauch einmal erstellter Objekte. Ein neuer Markt kündigt sich an, der den Vertrieb von Java Beans zum Ziel hat.

Alternative zu Java Beans

Parallel hierzu entstand mit den "Enterprise Java Beans" (EJB) das passende Objektmodell für Server-basierende Java-Applikationen. Gerade als IBM dabei war, eine eigene Programmierumgebung für C++ zu entwickeln, tauchte Java auf. Innerhalb kürzester Zeit stellte der Konzern die bereits begonnene Arbeit auf das Java-Gleis um. Ein Jahr nach dem Umstieg war das erste Release von EJB fertiggestellt.

EJB ist bereits früh zu einem offenen Standard geworden, den auch Sun und andere Firmen unterstützen. Das Java-Beans-Konzept von Sun existierte zum Projektbeginn noch nicht. Im Gegensatz zu diesem objektorientierten Konzept, bietet EJB einen eigenständigen Lösungsweg, der sich mit den "herkömmlichen" Beans verknüpfen läßt. In Zukunft sollen Migrationstools die EJB-Welt langsam an Java heranführen und schließlich damit verbinden.

IBM bezeichnet EJB als zentrale "Cross-Plattform"-Entwicklungsumgebung, die eine Schnittstelle zwischen der Business-Logik und den Datenbanken bildet. Das Interface, das mit bisherigen Techniken etwa ein bis zwei Drittel der gesamten Programmierzeit verschlungen hat, läßt sich mit den EJB einfacher und schneller bewältigen. Damit kann sich der Programmierer wieder mehr der Entwicklung von Applikationen widmen. Weitere Teile im EJB-Umfeld, wie der von IBMs MQ-Serie abgeleitete Java Messaging Service (JMS) oder das zusammen mit Novell entwickelte JNDI, erweitern die Funktionen.

Die neue Umgebung bietet für IBM-Kunden den Vorteil, daß auch betagte Umgebungen wie DB2 oder CICS nun über eine Java-Schnittstelle verfügen. Schrittweise stellt IBM das gesamte Software-Portfolio auf EJB um. Das Java-Fieber hat den Hersteller wahrlich gepackt, denn die Entscheidung viel auf höchster Ebene im Unternehmen. Heute arbeiten über 1000 Entwickler am EJB-Projekt und an der Umsetzung in eigene Produkte.

Mehr Produktivität mit Java

Nun bietet ein Web-orientierter Server im Zentrum die Funktionen von EJB, HTTP-Dienste sowie CORBA für C-Anwendungen an. Alle Dienste lassen sich miteinander verbinden. Die Server arbeiten in Clustern und erlauben Session-Tracking. Etwa 500 Business-Komponenten stehen den Programmierern zur Wahl.

Praktiker, die bereits mit den EJB-Implementationen unterschiedlicher Anbieter arbeiten, berichten von einer eklatanten Steigerung der Produktivität bei der Erstellung unternehmensweiter Lösungen. Hierbei spielt auch eine Rolle, daß die einzelnen EJB-Komponenten darauf ausgelegt sind, die Daten mit anderen EJB-Objekten auszutauschen. Zudem greifen die Sicherheitsmechanismen von Java uneingeschränkt und die Komponenten sind so konzipiert, daß ein Multiuser-Zugriff möglich ist. Schrittweise entstehen in den Unternehmen Applikationen, die untereinander vernetzt sind und damit weitere, bis dato undenkbare Anwendungen möglich machen. Prinzipiell läßt sich die Benutzeroberfläche auf der Seite des Clients vollkommen frei auswählen. So eignet sich das in den Unternehmen erst schrittweise kommende Visual Basic, dessen neueste Version massive Erweiterungen für Datenbank-basierende Applikationen im Unternehmen bietet, genauso als Client-Tool wie ein HTML-Frontend oder ein Java-Applet. Der wichtige Teil der Applikation, der die Business-Logik enthält, residiert auf dem zentralen und skalierbaren Server und ist als Java Bean auf etwaige Serverwechsel bestens vorbereitet.

Die Steigerung der Programmierer-Effizienz kommt von einer besseren Integration der Middleware-Layer in Programmiertools. Typisch für Middleware: die EJB verbergen die sonst so kraß als Pogrammierbremse wirkenden Unterschiede der zugrundeliegenden Techniken, sei es ActiveX über einen Wrapper, CORBA oder die Bridge zu einem alten Mainframe-System.

Die einzelnen EJB-Komponenten kommunizieren untereinander über das RMI-Protokoll und einen Internet Input Output Processor (IIOP). Hierbei übermittelt im Falle des Falles der IIOP die RMI-Requests. Das EJB-Konzept entstand wie bereits gesagt vollkommen unabhängig zu den Java Beans. Zwar können EJB-Komponenten aus Java Beans bestehen, doch arbeiten beide Konzepte vollkommen unterschiedlich.

Wenn lange Schlangen informationshungriger Besucher bei der diesjährigen Javaone ein Gradmesser für Erfolg sind, braucht Weblogic, Anbieter des EJB-basierenden Applikationsservers "Tengah" die Zukunft nicht fürchten. Seit kurzem steht die Betaversion 3.1 des Programms online zur Verfügung. Weblogic ist stolz darauf, als erster Anbieter die gesamte Spezifikation der EJB 1.0 mit den "Entity Beans" und den "Session Beans" einschließlich aller optionalen Erweiterungen (verteilte Transaktionen, automatische Persistenz) zu erfüllen.

Applikationsserver auf neuen Wegen

Bereits 1996 begann die Entwicklung von Tengah, der jetzt schon die dritte Release hinter sich hat.

Mit der RMI-Implementation von Tengah ist es möglich, einzelne Client-Server-Verbindungen von einer Vielzahl von verteilten Objekten aus gleichzeitig zu nutzen. Hierbei baut das System auf dem JNDI-Naming Service auf, um auch in einer heterogenen Umgebung transparent auf die Objekte zugreifen zu können. Auf der anderen Seite kann Tengah die Objekte auf mehrere Server verteilen und in einem heterogenen System zentral verwalten. Tengah läuft derzeit auf den wichtigsten Unix-Plattformen, auf Windows NT, Windows 95/98, Novell NetWare und NSK von Tandem.

Das Tengah-Gesamtsystem ist eine umfangreiche Sammlung von Java-Paketen. Neben den EJB lassen sich Java-Servlets auf einem HTTP-Server einbinden oder Microsoft-COM-Objekte unter Java nutzen. Zudem stehen alle EJB-Komponenten als ActiveX-Controls zur Verfügung. Damit haben Java-Clients wie Unix-Maschinen oder Palmtops auf die OLE-Objekte von Outlook oder Winword Zugriff, so als liefen diese Applikationen lokal und nicht auf dem Server. Objekte lassen sich entweder mit Hilfe von Java Native Interface (JNI) oder durch "Jdirect" von Microsoft mit einem Java-Wrapper versehen und in der neuen Umgebung weiter nutzen.

Zur Performance-Steigerung bietet Weblogic eigene JDBC-Treiber für Oracle, SQL Server, Sybase und Informix an, kann aber auch mit Fremdtreibern zusammenarbeiten. Bei den Datenbankzugriffen verwaltet Tengah die Query-Daten in einem Cache auf dem Server und aktualisiert diesen automatisch, sobald sich die Daten in der Datenbank ändern. Authorisierte Objekte greifen direkt auf den Cache-Inhalt zu, ohne daß sie die Datenbank verwenden.

Tengah verteilt die Systemlast auf die verfügbaren replizierten Services und ermöglicht damit einen dynamischen Lastenausgleich, der zugleich eine fehlertolerante Arbeitsweise einschließt. Optional lassen sich alle Services und Übertragungen mit SSL verschlüsseln und mit einer X.509-Authorisierung anmelden.

Hinter dem "Zero Administration Client" (ZAC), auch im Lieferumfang von Tengah enthalten, verbirgt sich ein automatisierter Mechanismus zur Verteilung von Applikationen über das Netzwerk. Hierzu lädt der Server eine gewünschte Java-Applikation mit Hilfe des "Directory Replication Protocol" (DRP) beziehungsweise der "Open Software Description" (OSD) direkt auf das Client-System. Updates lassen sich danach automatisiert durchführen.

Wenn die Stereoanlage mit der Heizung spricht

Eine kürzlich unter dem Namen "Jini" angekündigte Technik wurde in den Labors des Sun-Mitbegründers Bill Joy in Aspen entwickelt. Sie kombiniert einige der auf der Straße liegenden Ideen mit den Grundkonzepten von Java, MIDI, NIS und dem Prinzip "The Network ist the Computer". Das Gebräu hat beste Chancen die Diskussionen um das Thema vernetzter Devices in einer verteilten Umgebung neu zu entfachen.

Jini basiert auf einem leicht aufgebohrten RMI und erlaubt es, den unterschiedlichsten Devices, sei es im Büro, zu Hause oder unterwegs, miteinander in Kontakt zu treten, um im Sinne des Anwenders Dienstleistungen zu erfüllen. Jini verbindet die Komponenten der heimischen Audioanlage, die über ein Netzwerk verschaltet sind, und ermöglicht Reisenden über die Infrastruktur des Hotels ihr Office-System zu verwenden oder zu Hause die Heizung anzuschalten.

Das Jini-RMI unterstützt Multicast-Messages, um mit mehreren Objekten in Kontakt treten zu können und kann Objekte ferngesteuert aktivieren. Im Gegensatz zu einem üblichen serverzentrischen Ansatz, bei dem der Server die Services zentral über dessen Ports oder Sockets anbietet, kann in einem Jini-System jedes Device Server oder Client, oder beides zugleich sein. Im gesamten Netzwerk spielt lediglich der Service eine Rolle. Ob dieser durch Hard- oder Software zur Verfügung gestellt wird, ist dabei unerheblich und für alle Teilnehmer transparent.

Dabei unterstützt das System eigenständige Devices mit lokalen CPUs sowie CPU-lose und damit spottbillige Endgeräte, deren Intelligenz in einer zentralen Set-Top-Box zusammengefaßt ist, die als Proxy fungiert. Alle Komponenten basieren auf Java, beziehungsweise liegen als Programm im Java-Bytecode vor.

Komposition eines Gesamtsystems

Da die Komponenten zum Teil mit eigenständigen Java-Interpretern ablaufen, handelt es sich um eine echte verteilte Umgebung. Durch die erst im Bedarfsfalle zusammengestellte Summe der einzelnen Services komponiert der Anwender die Wirkungsweise seines Systems immer wieder neu.

Die atomare Handlung eines Gerätes, also die zur Verfügung gestellte Funktion, heißt in der Jini-Umgebung "Service". Den Service stellt das Device dem gesamten Netzwerk zur Verfügung, indem es ihn nach einem generellen "Presence Announcement" bei dem zentralen "Lookup-Service" mit Hilfe der "Discovery"- und der "Join"-Funktion anmeldet. Hierzu verfügt jeder Service über ein "Add-in"- und ein "Substract-out"-Protokoll. Damit erkennt das Netzwerk das neu integrierte Device. Auch das Device erfährt durch das Protokoll, in welcher Umgebung es sich befindet (Bild 3).

Services und Leasing-Regeln

Möchte ein anderes Device diesen Service nützen, fragt der Client, der gleichzeitig Server für einen anderen Client sein kann, beim Lookup-Service nach verfügbaren Angeboten. Das Angebot definiert sich aus dem "Programmatic Interface", einer Sammlung unterschiedlicher Methodentypen.

"Der Proxy Code" ist ein Programm, das Services zur Integration neuer Services benötigen. Im Zuge der Anmeldung (Join) wird der Proxy Code von einem Service dem Lookup-Server übergeben. In einem zweiten Schritt gelangt der Code vom Lookup Service zum Client (Bild 4). Der Proxy Code ist also nichts anderes als das zum Betrieb des entsprechenden Service notwendige Application Programming Interface (API). Es kommt der für die Bedienung notwendige Code zur Benutzeroberfläche (CD-Player, Spielekonsole) hinzu. Jetzt sind Client und der Service-Provider in der Lage, direkt miteinander zu kommunizieren (Bild 5).

Ein Palmtop könnte auf diese Weise den Zugang zum Server der Adreß-Datenbank erlangen. Ein CD-Spieler kann seinen Service im gesamten Hause über ein Haus- oder Funk-Netzwerk anbieten.

Beim Zugang zum Service gelten die sogenannten Leasing-Regeln, die schon das Java-Spaces-System nutzt. Je nach Konfiguration, darf ein Client den gewünschten Service unbegrenzt oder nur für einen gewissen Zeitraum nutzen. Da ein Service den angebotenen Service im Betrieb immer wieder anmelden muß, erkennt das Gesamtsystem wenn ein Device ausgeschaltet wird. In diesem Fall verlängert der Service das Leasing nicht. Der Lookup-Service kann dann an die Garbage Collection gehen.

Schaltet man ein Gerät aus, verschwindet der entsprechende Eintrag im Lookup-Service. Dieses Verfahren vereinfacht die Vernetzung und reduziert die Betriebskosten (Cost of Ownership), indem es marktwirtschaftliche Regeln zur Anwendung bringt.

Dabei kann ein Teil der Service-Funktionen in Form eines "Smart Proxy" vom Client übernommen werden, während andere Teile über RMI-Referenzen auf dem Service-Provider ablaufen. Die Benutzeroberfläche eines Service behandelt Jini immer als eigenständiges Applet, welches parallel zum Proxy Code" auf dem Lookup-Service zur Abholung bereit liegt.

Offene Standards

Der "Peer-Lookup-Service" vereinfacht die Anmeldung. Der Client verkündet sein Interesse an einem Service im gesamten lokalen Netzwerk. Alle angesprochenen Service Provider können dann überprüfen, ob der gewünschte Service gerade bereitgestellt werden kann. Sie melden sich anschließend beim Client, der aus den eingehenden Anmeldungen einen privaten Lookup-Service aufbaut. Aus den Angeboten kann der Client den optimalen Provider auswählen und durch den bereits übertragenen Proxy Code direkt ansprechen.

Um die Verbreitung zu erleichtern, will Sun Jini offen lizensieren. Firmen wie Canon, Computer Associates, Datek, Epson, Ericsson, Mitsubishi, Novell, Oki, Quantum, Seagate oder Toshiba werden mit von der Partie sein. Die ersten Produkte sind noch vor der Jahrtausendwende zu erwarten.

Datenbanken in einer

Java-Umgebung

Sun möchte das Tool-Business anderen Herstellern nicht komplett überlassen, Java soll als Datenbank-Applikationssprache hoffähig werden. Mit "Java Blend" kündigten die Entwickler ein Tool zur Datenbank-Anbindung an, welches die Unterschiede der Datenbank-Engines vor dem Programmierer verbergen soll.

Java Blend bildet auf der Basis von JDBC die Datenbankstruktur mit Hilfe der "Object-Relational-Mapping"-Technik auf ein Java-Objekt ab und umgekehrt. Das Tool überführt die SQL-Queries direkt in Java-Prädikate von Java-Kollektionen, so daß man in der objektorientierten Umgebung nicht mehr mit SQL in Berührung kommt. Diese Technik erlaubt, daß Programme bestehende DBMS-Systeme und deren Strukturen und Anwendungen in Form objektorientierter Klassen nützen.

Damit erfolgt der Zugriff auf die Unternehmensdaten vollständig in Java und ohne Verwendung von SQL-Statements. Ziel ist es, die Business-Logik mit Java-Klassen zu programmieren, wobei die veränderlichen Datenbereiche als Java-Felder realisiert sind. Der Zugriff auf die Daten erfolgt über die automatisch erzeugten Java-Klassen. Die Java-Umgebung gestattet verteilte Anwendungen durch RMI, EJB, Java Spaces und verknüpft Objekte mit Hilfe von IDL.

Business-Logik und Datenbanken getrennt

Die Entwicklung einer Datenbank-Applikation kann entweder direkt in der Java-Ebene oder wie bisher mit der Erstellung einer Datenbankstruktur beginnen. Hierbei kann der Entwickler das Mapping der Datenbank von Java aus für die jeweilige Anwendung optimieren. Beginnt er auf der Datenbank-Seite, kann er die Form der Datenbank besser definieren. Das Tool erzeugt ein Default-Mapping, welches der Programmierer optimieren kann. Es unterstützt alle typischen Relationen wie "one-to-one", "one-to-many" und "many-to-many".

Neben Objective Database Connectivity (ODBC) unterstützt Java Blend die Vorschläge der Object Database Management Group (ODMG) zum Abbilden von Objekt-Datenbanken und für das Objekt-Relational-Mapping. Bei der klassischen Client-Server-Aufteilung kann eine Java-Blend-Applikation sowohl auf dem Server als auch auf dem Client ablaufen. Alternativ läßt sich das Tool auch auf einem Middleware-Server einsetzen, der einen Thin-Client mit dem Server verbindet. Darüberhinaus ist auf dem Server die Business-Logik von dem Datenbank-Zugriff getrennt, wodurch eine logische Drei-Wege-Architektur entsteht. Java Blend (http:// java.sun.com/products/javablend) soll 3000 US Dollar kosten und unterstützt alle gängigen integrierten Entwicklungsumgebungen.(kpl)