10.5 Verteilte Anwendungen mit Java Enterprise Edition
In diesem Abschnitt werden Systeme vorgestellt, die weit über einfache Client-Server-Konfigurationen hinausgehen. Verteilte Anwendungen, auch Enterprise-Anwendungen genannt, bestehen aus zahlreichen Komponenten, die auf einem komplexen Gefüge aus Clients, Servern und Vermittlerdiensten aufsetzen, einem sogenannten Framework. Die beiden wichtigsten Frameworks für verteilte Anwendungen, die zurzeit verbreitet sind, sind die Java Enterprise Edition (Java EE) und das Microsoft .NET Framework. Eine weitere Form verteilter Anwendungen sind Webservices. Es handelt sich dabei um Dienste, die über das Web, also über HTTP zusammenwirken, um gemeinsam bestimmte Aufgaben zu erledigen. Webservices lassen sich übrigens mit Mitteln von Java EE, von .NET oder auch über andere Sprachen und APIs programmieren.
Ein Framework für verteilte Anwendungen besteht aus vielen verschiedenen Komponenten, vor allem aus den folgenden:
- Zugriff auf Datenbanken
- Möglichkeiten der Kommunikation zwischen einzelnen Anwendungen auf verschiedenen Rechnern
- eine Schnittstelle für Webanwendungen
- eine Möglichkeit zur Verarbeitung von XML-Dateien
- Zugriff auf Namens- und Verzeichnisdienste
Tabelle 10.1 zeigt eine Übersicht über die Komponenten von J2EE und .NET, mit denen diese Anforderungen verwirklicht werden.
Die Java Enterprise Edition ist im Wesentlichen eine Spezifikation, die durch die Hersteller von Application-Servern implementiert werden kann. Zwar erhalten Sie eine Referenzimplementierung sämtlicher wichtigen Klassen und Komponenten, wenn Sie die Java-EE-Distribution von Sun herunterladen. In der Praxis werden Sie aber eher einen voll ausgestatteten Server eines anderen Herstellers verwenden. Diese Systeme reichen von der Open-Source-Implementierung JBoss bis hin zu teuren kommerziellen Systemen wie BEA WebLogic oder IBM WebSphere. Daneben existieren separate Implementierungen einzelner Bestandteile wie die Servlet-Engine Apache Tomcat.
Einige Bestandteile der Java Enterprise-Plattform werden in anderen Kapiteln dieses Buches vorgestellt: In Kapitel 12, »Datenbanken«, finden Sie eine kurze Einführung in die Arbeit mit der Datenbankschnittstelle JDBC; in Kapitel 15, »XML«, werden die XML-Programmierschnittstellen SAX und DOM vorgestellt (diese gehören zwar nicht exklusiv zur Enterprise Edition, aber die Verarbeitung von XML ist für Enterprise-Anwendungen sehr wichtig). Als weitere wichtige Bestandteile der Java EE lernen Sie in den folgenden Abschnitten EJB und Servlets kennen.
10.5.1 Enterprise Java Beans (EJB)
Enterprise Java Beans (EJB) ist eine moderne, verteilte Komponentenarchitektur. Das komponentenbasierte Programmieren geht bezüglich der Universalität und der Wiederverwendbarkeit von Code im Grunde noch einen Schritt weiter als die Objektorientierung: Komponenten sind fertig kompilierte Programme oder Programmteile, die über bestimmte Schnittstellen mit anderen Programmen kommunizieren können. Gegenüber der klassischen OOP besitzt die Verwendung von Komponenten zwei Vorteile: Erstens können die verschiedenen Komponenten in unterschiedlichen Programmiersprachen geschrieben sein, und zweitens können Sie für einen bestimmten Zweck eine vorgefertigte Komponente einsetzen, deren Funktionieren garantiert ist. Gängige Komponentenmodelle sind Microsoft COM (Component Object Model) und CORBA (Common Object Request Broker Architecture).
Verteilte Komponentenmodelle wie EJB haben noch einen zusätzlichen Nutzen: Es handelt sich um eine Client-Server-Architektur, bei der ein Client EJB-Komponenten verwenden kann, die auf beliebigen anderen Rechnern in einem Netzwerk laufen. Die herkömmliche Java-Lösung für die Kommunikation zwischen Programmen auf verschiedenen Rechnern ist die RMI (Remote Method Invocation). Wie der Name schon sagt, handelt es sich um eine Möglichkeit, Methoden aufzurufen, die sich nicht auf dem lokalen Rechner, sondern irgendwo im Netz befinden. Enterprise Java Beans können noch mehr als RMI, weil sie entfernten Rechnern nicht nur einzelne Methoden, sondern komplexe Anwendungen und Geschäftsprozesse zur Verfügung stellen.
Man unterscheidet drei Arten von EJB:
- Session-Beans existieren nur für die Dauer einer einzelnen Verbindung, das heißt vom Beginn der Verbindung zwischen den beteiligten Rechnern bis zum Ende.
- Entity-Beans sind persistent, das bedeutet, dass sie zwischen zwei Verbindungen ihren Zustand beibehalten. Sie sind darüber hinaus an irgendein Entity gebunden, also an ein unabhängiges Objekt aus einer Datenquelle wie zum Beispiel einer Datenbank.
- Message Driven Beans erfüllen die zusätzliche Aufgabe der asynchronen Kommunikation: Die beiden anderen Arten von Beans kommunizieren jeweils synchron mit dem Client, das heißt, sie müssen Ein- und Ausgabe zu bestimmten Zeitpunkten durchführen und aufeinander abstimmen. Message Driven Beans kommunizieren dagegen über den Java Message Service und können Nachrichten auf diese Weise genau dann verarbeiten, wenn sie dazu bereit sind.
Die eigentliche EJB-Implementierung befindet sich auf der Serverseite. Es handelt sich um eine Klasse, die eines der Interfaces javax.ejb.SessionBean, EntityBean oder MessageDrivenBean implementiert. Auf dem Server muss ein EJB-Container vorhanden sein, der die Kommunikationsschnittstellen zur Verfügung stellt. Ein EJB-Container ist ein wichtiger Bestandteil eines Java-EE-konformen Application-Servers.
Eine Enterprise Java Bean besteht aus drei Klassen beziehungsweise Interfaces:
- Das Home-Interface gibt Clients die Möglichkeit, EJB-Objekte zu erzeugen. Es gibt zwei Varianten von Home-Interfaces: Ein entferntes Home-Interface ermöglicht entfernten Rechnern im Netz die Nutzung der EJB, während ein lokales Home-Interface ihre Verwendung auch auf dem implementierenden Rechner selbst erlaubt.
- Das Client-Interface definiert die Methoden der Bean, auf die ein Client zugreifen kann. Es kann ebenfalls lokal oder entfernt sein.
- Die Bean-Implementierung enthält die konkreten Implementierungen aller Methoden, die über das Client-Interface exportiert werden.
An dieser Stelle finden Sie ein einfaches Beispiel für eine Session-Bean. Zunächst müssen Sie eine Reihe von Methoden des Interface SessionBean implementieren, anschließend werden die Geschäftsmethoden geschrieben, die die eigentliche Funktionalität der Bean zur Verfügung stellen. Das Beispiel stellt ein rudimentäres Konto zur Verfügung: Es enthält die drei Geschäftsmethoden abheben (double betrag), einzahlen (double betrag) und getKontostand(). Es handelt sich um ein reines Guthabenkonto – es kann nur abgehoben werden, sofern Guthaben vorhanden ist. Hier zunächst der Code der Bean-Implementierung:
import javax.ejb.*;
public class KontoBean implements SessionBean {
// Globale Variablen
private SessionContext context = null;
private double kontostand;
// SessionBean-Implementierung
/* Die Methoden müssen implementiert werden,
aber die meisten enthalten in diesem einfachen
Beispiel keine Funktionalität.
Deshalb nur Ausgabe zu Kontrollzwecken. */
public void ejbCreate() {
// Hier wird der Anfangskontostand (0) gesetzt.
kontostand = 0;
}
public void ejbRemove() {
System.out.println ("Bean entfernt.");
}
public void getSessionContext (SessionContext c) {
// Session-Kontext vom Container entgegennehmen
// und speichern
context = c;
}
public void ejbActivate() {
System.out.println ("Bean aktiviert.");
}
public void ejbPassivate() {
System.out.println ("Bean passiviert.");
}
// Geschäftsmethoden
public double abheben (double betrag) {
if (kontostand < betrag)
return 0;
kontostand -= betrag;
return betrag;
}
public void einzahlen (double betrag) {
kontostand += betrag;
}
public double getKontostand() {
return kontostand;
}
}
Als Nächstes benötigen Sie noch die beiden eingangs beschriebenen Interfaces. Das (entfernte, nicht lokale) Home-Interface sieht folgendermaßen aus:
import javax.ejb.*;
import java.rmi.RemoteException;
public interface KontoHome extends EJBHome {
public Konto create()
throws CreateException, RemoteException;
}
Die create()-Methode muss mit denselben Argumenten deklariert werden wie die Methode ejbCreate() der Bean-Implementierung – hier also ohne Argumente. Bei der Erzeugung können verschiedene Ausnahmen ausgelöst werden: Eine RemoteException ist ein RMI-Kommunikationsfehler (RMI wird als Kommunikationsbasis verwendet); eine CreateException wird dagegen ausgelöst, wenn aus irgendeinem Grund keine Bean erzeugt werden kann.
Das (ebenfalls entfernte) Client-Interface sieht so aus:
import javax.ejb.*;
import java.rmi.RemoteException;
public interface Konto extends EJBObject {
public double abheben (int betrag)
throws RemoteException;
public void einzahlen (int betrag)
throws RemoteException;
public double getKontostand()
throws RemoteException;
}
Um die Bean tatsächlich verwenden zu können, ist zunächst ihre Veröffentlichung erforderlich, die auch als Deployment bezeichnet wird. Im Wesentlichen geht es darum, die soeben entwickelten Bestandteile der Bean zu kompilieren und in eine .jar-Datei (ein Java-Archiv, ähnlich einer ZIP-Datei) zu verpacken, die im vorliegenden Fall Konto.jar heißt. Außer den kompilierten Klassen und Interfaces enthält sie ein Verzeichnis namens META-INF, in dem sich eine spezielle Bean-Beschreibungsdatei befindet, der sogenannte Deployment-Deskriptor. Es handelt sich um eine XML-Datei namens ejb-jar.xml, die beispielsweise wie folgt aussieht (die eigentliche Struktur von XML-Dokumenten wird in Kapitel 15, »XML«, ausführlich beschrieben):
<?xml version="1.0"?>
<!DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 1.1//EN"
"http://java.sun.com/j2ee/dtds/ejb-jar_1_1.dtd">
<ejb-jar>
<display-name>Konto</display-name>
<enterprise-beans>
<session>
<description>Ein einfaches
Guthabenkonto</description>
<ejb-name>KontoBean</ejb-name>
<home>KontoHome</home>
<remote>Konto</remote>
<ejb-class>KontoBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
</enterprise-beans>
</ejb-jar>
Hier sehen Sie abschließend einen Client, der die Konto-Bean auf einem entfernten Computer nutzt:
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.rmi.PortableRemoteObject;
public class KontoClient {
public static void main(String[] args) {
try {
// Die EJB Über JNDI ermitteln
Context initial = new InitialContext();
Object ref = initial.lookup("Konto");
// Home-Interface referenzieren
KontoHome home = (KontoHome)
PortableRemoteObject.narrow
(ref, KontoHome.class);
// Konto-Bean referenzieren
Konto konto = home.create();
// Konto-Methoden nutzen
System.out.println ("Startguthaben: "
+ konto.getKontostand());
konto.einzahlen (1000);
System.out.println ("Neues Guthaben: "
+ konto.getKontostand());
double betrag = konto.abheben (500);
System.out.println ("Abgehoben: " + betrag
+ "; neues Guthaben: "
+ konto.getKontostand());
}
catch(Exception e) {
System.out.println
("Ein Fehler ist aufgetreten!");
e.printStackTrace();
}
}
}
10.5.2 Java Servlets
Die Java-Servlet-API arbeitet mit einem Webserver zusammen, um die Ausgabe von Java-Klassen als dynamisch generierte Webseiten an Clients auszuliefern. Das Prinzip ähnelt dem klassischen CGI.
Falls Sie sich mit dem Thema Webanwendungen überhaupt noch nicht auskennen, sollten Sie zuerst Kapitel 18, »Webserveranwendungen«, durcharbeiten und erst danach den vorliegenden Abschnitt lesen.
Wenn Sie ein Servlet schreiben, steht Ihnen der vollständige Funktionsumfang der Java-Klassenbibliothek oder sogar der J2EE zur Verfügung: Sie können mit Datenbanken, Enterprise Java Beans, XML-Datenbeständen und vielen anderen Elementen arbeiten und den Zugriff darauf über das Web ermöglichen.
Hier sehen Sie ein kleines Beispiel für ein Java-Servlet. Es gibt die Quadrate der Zahlen von 1 bis 15 als HTML-Seite aus:
import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;
public class QuadratServlet extends HttpServlet {
public void doGet (HttpServletRequest req,
HttpServletResponse resp)
throws ServletException, IOException {
resp.setContentType ("text/html");
PrintWriter out = resp.getWriter();
out.println ("<html>");
out.println ("<head>");
out.println ("<title>Quadratzahlen</title>");
out.println ("</head>");
out.println ("<body>");
out.println ("<h1>Quadratzahlen 1<sup>2</sup>
bis 15<sup>2</sup></h1>");
for (int i = 1; i <= 15; i++) {
out.println (i + "<sup>2</sup> = " + i * i
+ "<br />");
}
out.println ("</body>");
out.println ("</html>");
}
}
Die Methode doGet() implementiert die Antwort, die das Servlet auf eine HTTP-GET-Anfrage geben soll. Das HttpServletRequest-Objekt enthält die Einzelheiten dieser Anfrage, während die HttpServletResponse der Antwort entspricht, die über den Webserver an den Client übermittelt werden soll. Die Einzelheiten der Veröffentlichung des Servlets und der Zusammenarbeit mit dem Webserver entnehmen Sie der Dokumentation Ihrer Servlet-Engine beziehungsweise Ihres Application-Servers.
Da die Ausgabe einzelner HTML-Zeilen über println()-Befehle recht umständlich und unübersichtlich ist, gibt es als alternative Lösung die Java Server Pages (JSP). Sie entsprechen eher dem Ansatz von PHP oder Microsofts ASP: An bestimmten Stellen innerhalb einer normalen HTML-Datei können Java-Anweisungen durch <% ... %> eingeschlossen werden.
10.5.3 Webservices
Eine besondere Form der verteilten Anwendungen sind Webservices. Es handelt sich um ein Framework für die Kooperation zwischen Komponenten. Die Besonderheit ist, dass diese Komponenten über HTTP-Verbindungen kommunizieren können. Auf diese Weise lassen sich sehr kundenfreundliche E-Commerce-Modelle einrichten: Angenommen, Sie möchten online eine Reise buchen. Sie besuchen die Website eines Reisebüros, um sich über Angebote zu informieren. Das Reisebüro könnte über einen Webservice automatisch im Hintergrund beim Reiseveranstalter nachfragen, ob noch Plätze zur Verfügung stehen und was diese kosten, und später vollautomatisch die Buchung vornehmen. Der Veranstalter könnte wiederum Webservices einsetzen, um alles Erforderliche mit der Fluggesellschaft und dem Hotel zu klären.
Viele wichtige Web-Dienstleister stellen öffentlich zugängliche Webservices zur Verfügung. Auf diese Weise können Sie Informationen und Dienste dieser Anbieter nahtlos in Ihre eigenen Webanwendungen integrieren. Besonders bekannt und beliebt sind verständlicherweise die Webservices von Websites wie Amazon, eBay oder Google.
Der große Vorteil der Webservices ist ihre absolute Plattformneutralität: Das Angebot bestimmter Webservices und die Kommunikation zwischen ihnen und ihren Clients funktionieren über allgemein zugängliche, frei verfügbare Dokumentenstandards. Diese Beschreibungs- und Kommunikationsdokumente werden in XML geschrieben. Die wichtigsten Bestandteile sind folgende:
- Das Simple Object Access Protocol (SOAP) ermöglicht die Kommunikation zwischen Webservices. Allerdings gibt es noch andere Protokolle, die alternativ für diese Kommunikation eingesetzt werden können.
- Die Web Services Description Language (WSDL) stellt eine Möglichkeit zur Beschreibung der Methoden und Datenstrukturen von Webservices bereit.
- Die Universal Description, Discovery and Integration (UDDI) dient gewissermaßen als globaler Katalog der Webservices und der von ihnen angebotenen Dienstleistungen. Sie können dort sowohl nach Webservices suchen als auch Ihre eigenen registrieren, wenn Sie diese der Öffentlichkeit anbieten möchten. Unter www.uddi.org erfahren Sie Näheres hierzu.
Die eigentliche Funktionalität eines Webservice kann in fast jeder Programmiersprache geschrieben werden – beliebte Varianten sind Java, die .NET-Sprachen, PHP oder Perl. In diesem Abschnitt wird als Beispiel die Implementierung in Java gezeigt.
Als Beispiel wird hier eine Java-Klasse entwickelt, die das aktuelle Datum und die Uhrzeit über SOAP veröffentlicht. Um sie auszuprobieren, benötigen Sie eine SOAP-Implementierung, die mit Java zusammenarbeitet. Ein gutes Open-Source-Beispiel mit einer ausführlichen Onlinedokumentation ist Apache Axis, verfügbar unter ws.apache.org/axis. Die Java-Version benötigt einen J2EE-Application-Server oder Servlet-Container; die erste Wahl ist hier Jakarta Tomcat.
Der erste Bestandteil des Webservice ist die Java-Klasse DateTimeService:
import java.util.*;
public class DateTimeService {
public String getDateTime() {
Date d = new Date();
DateFormat f = new SimpleDateFormat
("dd.MM.yyyy, HH:mm:ss");
return (f (d));
}
}
Wie Sie sehen, handelt es sich um eine gewöhnliche Klassendefinition ohne jegliche Besonderheiten, die darauf schließen ließen, dass es sich um einen Webservice handelt. In der Tat ist das auch gar nicht der Fall – die Klasse wird nur durch die Bereitstellung auf dem SOAP-Server zum Webservice. Auf diese Weise können in beliebigen Sprachen geschriebene Clients über das Web die Methode getDateTime() aufrufen und ihren Rückgabewert entgegennehmen.
Speichern Sie den zuvor gezeigten Quellcode unter dem Dateinamen DateTimeService.jws im axis-Verzeichnis Ihres Servlet-Containers. Beim ersten Zugriff wird er automatisch kompiliert. In komplexeren Fällen benötigen Sie einen Deployment-Deskriptor für die Klasse, aber das führt hier zu weit.
Um den Webservice zu nutzen, muss ein Client über HTTP eine SOAP-Anfrage an den Server schicken. Es handelt sich um eine HTTP-POST-Anfrage, deren Nutzdaten aus einem speziellen XML-Dokument bestehen, dem SOAP-Envelope. Normalerweise werden solche Anfragen nicht manuell erzeugt, sondern durch ein spezielles Programm, den SOAP-Client. Hier sehen Sie einen Java-Client, der ebenfalls mit Apache Axis arbeitet und auf den DateTimeService zugreift, der auf dem lokalen Rechner läuft:
import org.apache.axis.client.*;
public class DateTimeClient {
public static void main(String [] args) {
try {
// URL des Webservice
String endpoint =
"http://localhost/axis/services/datetime";
//Service- und Aufruf-Objekt erzeugen
Service service = new Service();
Call call = (Call) service.createCall();
// Adresse und Methode des Aufrufs
call.setTargetEndpointAddress (
new java.net.URL (endpoint));
call.setOperationName ("getDateTime"));
// Aufruf absenden und Rückgabewert speichern
String ret = (String) call.invoke();
// Ausgabe
System.out.println ("Heute ist " + ret);
} catch (Exception e) {
// Fehlerbehandlung
System.err.println(e.toString());
}
}
}
Nach dem Kompilieren gibt jeder Aufruf von java DataTimeClient das Datum und die aktuelle Uhrzeit aus, die vom Webservice geliefert werden.
Webservices der neuesten Generation verwenden häufiger eine Architektur namens REST (Representional State Transfer) statt SOAP. Hier kommen für die verschiedenen Befehle an den entfernten Server wie »Datei speichern« oder »Datei löschen« lang vernachlässigte HTTP-Methoden wie PUT beziehungsweise DELETE zum Einsatz, was die Anfragen kürzer und leichter interpretierbar macht.
Ihr Kommentar
Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.
