Galileo Computing < openbook >
Galileo Computing - Professionelle Buecher. Auch fuer Einsteiger.
Galileo Computing - Professionelle Buecher. Auch fuer Einsteiger.


Kompendium der Informationstechnik
 von Sascha Kersken
EDV-Grundlagen, Programmierung, Mediengestaltung
Buch: Kompendium der Informationstechnik
gp Kapitel 14 Netzwerkanwendungen
  gp 14.1 Netzwerkkonfiguration unter verschiedenen Betriebssystemen
    gp 14.1.1 Linux
    gp 14.1.2 Mac  OS
    gp 14.1.3 Windows
    gp 14.1.4 TCP/IP-Dienstprogramme
  gp 14.2 Server konfigurieren
    gp 14.2.1 Mac  OS
    gp 14.2.2 Windows
    gp 14.2.3 UNIX/Linux
    gp 14.2.4 Der Webserver Apache
  gp 14.3 Einführung in die Netzwerkprogrammierung
    gp 14.3.1 Die Berkeley Socket API
    gp 14.3.2 Ein einfaches Beispiel
  gp 14.4 Verteilte Anwendungen
    gp 14.4.1 J2EE
    gp 14.4.2 Microsoft .NET
    gp 14.4.3 Web Services
  gp 14.5 Zusammenfassung

gp

Prüfungsfragen zu diesem Kapitel (extern)


Galileo Computing

14.4 Verteilte Anwendungen  downtop

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 so genannten Framework. Die beiden wichtigsten Frameworks für verteilte Anwendungen, die zurzeit verbreitet sind, sind die Java 2 Enterprise Edition (J2EE) und das Microsoft .NET-Framework. Eine weitere Form verteilter Anwendungen sind Web Services – es handelt sich dabei um Dienste, die über das Web, also über HTTP zusammenwirken, um gemeinsam bestimmte Aufgaben zu erledigen. Web Services lassen sich übrigens mit Mitteln von J2EE, von .NET oder auch über andere Sprachen und APIs programmieren.

Bestandteile von Enterprise-Frameworks

Ein Framework für verteilte Anwendungen besteht aus vielen verschiedenen Komponenten, vor allem aus den folgenden:

gp  Zugriff auf Datenbanken
gp  Möglichkeiten der Kommunikation zwischen einzelnen Anwendungen auf verschiedenen Rechnern
gp  Eine Schnittstelle für Webanwendungen
gp  Eine Möglichkeit zur Verarbeitung von XML-Dateien
gp  Zugriff auf Namens- und Verzeichnisdienste

Tabelle 14.1 zeigt eine Übersicht über die Komponenten von J2EE und .NET, mit denen diese Anforderungen verwirklicht werden.


Tabelle 14.1   Verwirklichung der wichtigsten Bestandteile von Enterprise-Anwendungen in J2EE und .NET

Fähigkeit J2EE-Komponente .NET-Komponente
Datenbankschnittstelle JDBC (siehe Kapitel 7) ADO.NET (ActiveX Data Objects für .NET)
Direkte Kommunikation zwischen Anwendungen Enterprise JavaBeans (EJB) Java Message Service (JMS) .NET Message Queuing
Web-Schnittstelle Java Servlets JavaServer Pages (JSP) Active Server Pages für .NET (ASP.NET)
XML-Tools SAX, DOM und andere (siehe Kapitel 15) ADO.NET
Namens- und Verzeichnisdienste Java Naming and Directory Interface (JNDI) Zugriff auf Active Directory


Galileo Computing

14.4.1 J2EE  downtop

Die Java2 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 J2EE-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 teueren 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 7, Datenbanken, finden Sie eine kurze Einführung in die Arbeit mit der Datenbankschnittstelle JDBC; im nächsten Kapitel, XML, werden die XML-Programmierschnittstellen SAX und DOM vorgestellt. Als weitere wichtige Bestandteile der J2EE lernen Sie in den folgenden Unterabschnitten EJB und Servlets kennen.

Enterprise Java Beans (EJB)

Enterprise Java Beans (EJB) sind 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 Einzelkomponenten 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) oder CORBA (Common Object Request Broker Architecture).

EJB-Vorteile

Verteilte Komponentenmodelle wie EJB haben noch einen zusätzlichen Nutzen: Es handelt sich um eine Client-Server-Architektur, bei der ein Client EJB-Komponenten nutzen 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 nicht nur einzelne Methoden, sondern komplexe Anwendungen und Geschäftsprozesse an entfernte Rechner zur Verfügung stellen.

Man unterscheidet drei verschiedene Arten von EJB:

gp  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.
gp  Entity-Beans sind persistent, das bedeutet, dass sie zwischen zwei Verbindungen ihren Zustand beibehalten. Sie sind darüber hinaus an irgendein Entity gebunden, das heißt an ein unabhängiges Objekt aus einer Datenquelle wie zum Beispiel einer Datenbank.
gp  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.

EJBs implementieren

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 J2EE-konformen Application-Servers.

Eine Enterprise Java Bean besteht aus drei Klassen beziehungsweise Interfaces:

gp  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.
gp  Das Client-Interface definiert die Methoden der Bean, auf die ein Client zugreifen kann. Es kann ebenfalls lokal oder entfernt sein.
gp  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 Interfaces 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, wenn Guthaben vorhanden ist. Listing 14.3 zeigt zunächst den Code der Bean-Implementierung.

Listing 14.3   Implementierung einer Konto-EJB

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;
   }
}

Interfaces zur EJB-Veröffentlichung

Als Nächstes benötigen Sie noch die beiden weiter oben 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 zu guter Letzt 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;
}

EJB-Deployment

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 noch ein Verzeichnis META-INF, in dem sich eine spezielle Bean-Beschreibungsdatei befindet, der so genannte Deployment-Deskriptor. Es handelt sich um eine XML-Datei namens ejb-jar.xml, die beispielsweise so aussieht (die eigentliche Struktur von XML-Dokumenten wird im nächsten Kapitel 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>

EJB-Clients

Das kleine Beispielprogramm in Listing 14.4 zeigt schließlich einen Client, der die Konto-Bean auf einem entfernten Computer nutzt.

Listing 14.4   Ein Client, der die Konto-EJB verwendet

import javax.naming.Context;
import javax.naming.InitialContext;
import javax.rmi.PortableRemoteObject;
 
public class HelloWorldClient
{
   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();
      }
   }
}

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 CGI-Scripting, das in Kapitel 18, Serverseitig dynamische Websites, beschrieben wird. Wenn Sie sich mit dem Thema überhaupt noch nicht auskennen, sollten Sie dieses Kapitel durcharbeiten und erst danach den vorliegenden Unterabschnitt lesen.

Gegenüber CGI besitzen Java Servlets zwei wichtige Vorteile:

gp  Die Servlet-Engine bleibt im Hintergrund aktiv und kann Servlets auf diese Weise sofort ausführen. Bei klassischen CGI-Skripten muss dagegen für jede einzelne Ausführung ein neuer Prozess gestartet werden, was viel unnötigen Aufwand erzeugt. Darüber hinaus sind Servlets kompilierte Java-Klassen, die ohnehin schneller ausgeführt werden als interpretierte CGI-Skripte.
gp  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.

In Listing 14.5 sehen Sie ein kleines Beispiel für ein Java-Servlet. Es gibt die Quadrate der Zahlen 1 bis 15 als HTML-Seite aus.

Listing 14.5   Beispiel für ein Java-Servlet

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 bitte der Dokumentation Ihrer Servlet-Engine beziehungsweise Ihres Application-Servers.

JSP

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.


Galileo Computing

14.4.2 Microsoft .NET  downtop

Das Microsoft .NET-Framework ist eine Windows-basierte Umgebung für verteilte Anwendungen. Ähnlich wie bei Java werden Programme nicht als Binärdateien für Prozessor oder Betriebssystem kompiliert, sondern es gibt eine übergeordnete Schicht für die Programmausführung, für die spezieller Bytecode erzeugt wird. Diese Schicht wird bei .NET als Common Language Runtime (CLR) bezeichnet. Da Microsoft die CLR-Spezifikation der Öffentlichkeit zugänglich gemacht hat, besteht die Möglichkeit, alternative CLR-Implementierungen zu schreiben – ein Beispiel ist die freie Implementierung Mono, die die Ausführung von .NET-Code unter freien Betriebssystemen wie Linux ermöglicht.

.NET-Sprachen

Der Name Common Language Runtime wurde gewählt, weil sich .NET-Programme in verschiedenen Programmiersprachen entwickeln lassen. Dazu gehören zurzeit die folgenden von Microsoft selbst entwickelten Sprachen (es gibt auch noch eine Reihe von Sprachen von Drittanbietern, die .NET unterstützen):

gp  Visual C++. Die Programmiersprache C++ wurde natürlich nicht von Microsoft entwickelt, sondern ist eine objektorientierte Erweiterung von C. Visual C++ ist die Windows-optimierte Variante der Sprache, für die ein Compiler, eine Entwicklungsumgebung und spezielle Klassenbibliotheken von Microsoft verfügbar sind. Der klassische Kern der Visual C++-Klassenbibliothek sind die Microsoft Foundation Classes (MFC), die Entwicklern sämtliche Komponenten der Windows-GUI zur Verfügung stellen. Im Zusammenhang mit .NET werden sie allerdings durch die .NET Windows Forms ersetzt beziehungsweise ergänzt.
gp  Visual Basic. Diese Sprache ist eine moderne, objektorientierte Weiterentwicklung von BASIC und wurde von Microsoft für die einfache Programmierung von Windows-Anwendungen entwickelt.
gp  C#. Die neueste, von Anfang an speziell für .NET entworfene Sprache C# (gesprochen »C Sharp«) erinnert stark an Java: Auch hier wurden sämtliche nicht objektorientierten Erbstücke von C entfernt; außerdem verwendet die Sprache Klassen, Interfaces sowie einfache und objektorientierte Datentypen.

Das praktischste Werkzeug zur Entwicklung von .NET-Anwendungen ist das Paket Visual Studio .NET. Es handelt sich um eine integrierte Entwicklungsumgebung, in der Sie GUI-Komponenten grafisch aus einem Baukasten erstellen können. Das Entwicklungspaket unterstützt alle oben genannten Sprachen.

Eine kostenlose Alternative ist das .NET Framework SDK, das bei Microsoft zum Download bereitsteht. Enthalten sind Kommandozeilen-Compiler für die drei oben erwähnten Sprachen sowie das .NET-Framework (die Klassenbibliothek) selbst. Wenn Sie .NET-Anwendungen auf Ihrem Rechner lediglich ausführen, aber nicht schreiben möchten, benötigen Sie das .NET-Framework, das die CLR enthält. Sie können es auf Microsofts Website herunterladen. Sämtliche .NET-bezogenen Themen und Downloads finden Sie unter www.microsoft.com/net.

Eine Windows Forms-Beispielanwendung

Das Beispiel in Listing 14.6 zeigt ein kleines C#-Programm, das über Windows Forms einen Dialog mit einer Textbox und einem Button erzeugt. Jedes Mal, wenn Sie auf den Button klicken, wird die Ausgabe in der Textbox aktualisiert. Sie zeigt an, wie oft der Button bereits gedrückt wurde. Wie Ihnen auffallen dürfte, ähnelt dieser Code sehr stark den JFC- beziehungsweise AWT-Anwendungen, die in Kapitel 6, Konzepte der Programmierung, vorgestellt wurden.

Listing 14.6   Eine kleine grafische C#-Beispielanwendung

using System;
using System.Windows.Forms;
using System.Drawing;
 
public class MyForm : Form
{
 
   private TextBox tbox;
   private Button btn;
   private int d;
 
   void btn_onclick (object sender, EventArgs e)
   {
      d++;
      tbox.Text = "Bereits " + d + "-mal geklickt.";
   }
 
   public MyForm()
   {
      tbox = new TextBox();
      tbox.Text = "Noch nicht geklickt.";
      tbox.Location = new Point (10, 20);
      tbox.Size = new Size (120, 30);
      btn = new Button();
      btn.Text = "Hier klicken.";
      btn.Location = new Point (10, 70);
      this.Controls.Add (tbox);
      this.Controls.Add (btn);
      btn.Click += new EventHandler (btn_onclick);
      Text = "Klick-Zähler";
   }
 
   public static void Main()
   {
      Application.Run (new MyForm());
   }
}

Mit Hilfe der using-Klausel werden Teile der Klassenbibliothek eingebunden, ähnlich wie mit der import-Anweisung in Java. MyForm ist der vorgegebene Name für eine Klasse, die von der Windows Forms-Klasse Form abgeleitet ist; die Vererbung erfolgt wie in C++ durch einen Doppelpunkt. Im Konstruktor werden die einzelnen Komponenten erzeugt und platziert. Der überschriebene Operator += ordnet der Komponente btn (einem Button) seinen Event-Handler zu. Die von Form geerbte Eigenschaft Text dient der Zuweisung des Fenstertitels.

C# kompilieren

Wenn Sie Visual Studio .NET verwenden, können Sie das Programm einfach auf Knopfdruck kompilieren. Mit dem .NET Framework SDK müssen Sie dagegen den folgenden Kommandozeilenbefehl eingeben (falls die Quelldatei ClickCount.cs heißt):

> csc ClickCount.cs

Es entsteht eine Programmdatei namens ClickCount.exe, die Sie per Doppelklick ausführen können. Anders als beim Java AWT sind grundlegende Verhaltensweisen des Fensters bereits automatisch eingebaut – beispielsweise beendet das Schließen des Fensters das Programm.

ASP.NET

Eine wichtige Komponente des .NET-Frameworks ist ASP.NET, Microsofts Lösung für dynamisches Web-Publishing. Die Grundidee basiert auf den Active Server Pages (ASP). Es handelt sich um eine Technologie, die seit einigen Jahren in Microsofts Webserver, den Internet Information Server, eingebaut ist. Während die ursprüngliche ASP-Technologie aber nur eine einzige Sprache unterstützte, deren Syntax auf Visual Basic basierte, können Sie die neueren ASP.NET-Seiten in jeder beliebigen .NET-Sprache schreiben und haben zudem Zugriff auf das gesamte .NET-Framework.

Web Forms

Ein weiterer sehr interessanter Ansatz von ASP.NET sind Web Forms. Es handelt sich um eine einfache Möglichkeit, HTML-Formulare auf Webseiten mit serverseitig ausführbarem Code zu hinterlegen – alle Schwierigkeiten, die normalerweise mit der Übergabe und Verarbeitung von Formulardaten verbunden sind, werden durch intelligente Automatisierung aufgehoben.

Damit Sie einen direkten Vergleich zur oben beschriebenen Java-Webtechnologie haben, sehen Sie in Listing 14.7 eine ASP.NET-Datei, die ebenfalls die Quadrate der Zahlen 1 bis 15 ausgibt.

Listing 14.7   Beispiel für ein ASP.NET-Dokument

<%@ Page Language="C#"%>
 
<html>
  <head>
    <title>Quadratzahlen</title>
  </head>
  <body>
    <h1>Quadratzahlen von 1<sup>2</sup>     bis 15<sup>2</sup></h1>
    <% for (int i = 1; i <= 15; i++) { %>
      <%=i%><sup>2</sup> = <%=i * i%><br />
    <% } %>
  </body>
</html>

Sie werden solche Code-Konstrukte besser verstehen, wenn Sie Kapitel 18, Serverseitig dynamische Websites, lesen. Dort wird Ähnliches am Beispiel der Sprache PHP genau erläutert.


Galileo Computing

14.4.3 Web Services  toptop

Eine besondere Form der verteilten Anwendungen sind Web Services. 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 Web Service automatisch im Hintergrund beim Reiseveranstalter nachfragen, ob noch Plätze zur Verfügung stehen, was sie kosten, und später vollautomatisch die Buchung vornehmen. Der Veranstalter könnte wiederum Web Services einsetzen, um alles Erforderliche mit der Fluggesellschaft und dem Hotel zu klären.

Vorteile von Web Services

Der große Vorteil der Web Services ist ihre absolute Plattformneutralität: Das Angebot bestimmter Web Services 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:

gp  Das Simple Object Access Protocol (SOAP) ermöglicht die Kommunikation zwischen Web Services. Allerdings gibt es noch andere Protokolle, die alternativ für diese Kommunikation eingesetzt werden können.
gp  Die Web Services Description Language (WSDL) stellt eine Möglichkeit zur Beschreibung der Methoden und Datenstrukturen von Web Services bereit.
gp  Die Universal Description, Discovery and Integration (UDDI) dient gewissermaßen als globaler Katalog der Web Services und der von ihnen angebotenen Dienstleistungen. Sie können dort sowohl nach Web Services suchen als auch Ihre eigenen registrieren, wenn Sie sie der Öffentlichkeit anbieten möchten. Unter www.uddi.org erfahren Sie Näheres.

Die eigentliche Funktionalität eines Web Services kann in fast jeder Programmiersprache geschrieben werden – beliebte Varianten sind Java, die .NET-Sprachen oder Perl. In diesem Abschnitt wird als Beispiel die Implementierung in Java gezeigt.

Ein SOAP-Beispiel in Java

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 ausführlicher Online-Dokumentation ist Apache SOAP, verfügbar unter ws.apache.org/soap. Die enthaltene SOAP-Server-Komponente benötigt eine Java Servlet Engine; als Open-Source-Lösung ist Apache Tomcat zu empfehlen. Beachten Sie die Hinweise zur Installation eines aktuellen XML-Parsers in der dortigen Dokumentation.

Der erste Bestandteil des Web Services ist die Java-Klasse DateTimeService in Listing 14.8. 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 Web Service handelt. In der Tat ist das auch gar nicht der Fall – um einen echten Web Service daraus zu machen, ist zusätzlich eine spezielle Form des Deployments erforderlich.

Listing 14.8   Eine Java-Klasse, die als Web Service eingesetzt werden soll

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));
   }
}

SOAP-Deployment

Als Nächstes benötigen Sie einen Deployment-Deskriptor für die Klasse, damit Ihr SOAP-Server sie veröffentlichen kann. Hier sehen Sie ein Beispiel für den DateTimeService:

<isd:service xmlns:isd="http://xml.apache.org/xml-soap/deployment" 
id="urn:datetime">
  <isd:provider type="java"
                scope="Request"
                methods="getDateTime">
     <isd:java class="DateTimeService" static="false"/>
  </isd:provider>
</isd:service>

Angenommen, der Deployment-Deskriptor heißt DateTime.xml. Dann können Sie Apache SOAP mit Hilfe der folgenden Kommandozeilenanweisung dazu bringen, den Web Service anzubieten:

$ java org.apache.soap.server.ServiceManagerClient 
http://localhost/soap/servlet/rpcrouter deploy DateTime.xml

SOAP-Clients

Um den Web Service 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. Listing 14.9 zeigt einen Java-Client, der ebenfalls mit Apache SOAP arbeitet und auf den DateTimeService zugreift, der auf dem lokalen Rechner läuft. Das Programm wird hier nicht zeilenweise erläutert, enthält aber einige erklärende Kommentare.

Listing 14.9   Ein SOAP-Client

import org.apache.soap.*;
import org.apache.soap.rpc.*;
import java.net.URL;
 
public class DateTimeClient
{
   public void printDateTime throws SOAPException ()
   {
      // Den SOAP-Aufruf erzeugen
      Call call = new Call();
      call.setTargetObjectURI ("urn:datetime");
      call.setMethodName ("getDateTime");
      call.setEncodingStyleURI            (Constants.NS_URI_SOAP_ENC);
      // Die URL erzeugen
      URL url = new URL            ("http://localhost/soap/servlet/rpcrouter");
      // Den Aufruf abschicken
      Response res;
      res = call.invoke (url, "");
      // Die Antwort entnehmen, falls kein Fehler
      if (!response.generatedFault())
      {
         Parameter val = res.getReturnValue();
         String dt = (String)val.getValue();
         System.out.println ("Server liefert: " + dt);
      } else {
         // Fehler
         Fault f = res.getFault();
         System.out.println ("Fehler: " +               f.getFaultString());
      }
   }
 
   public static void main (String args[])
   {
      try {
         DateTimeClient dtc = new DateTimeClient();
         dtc.printDateTime();
      } catch (Exception e) {
         System.out.println               ("Ein Fehler ist aufgetreten.");
         e.printStackTrace();
      }
   }
  

Einstieg in PHP 5

Einstieg in Java

C von A bis Z

Einstieg in C++

Einstieg in Linux

Einstieg in XML

Apache 2




Copyright © Galileo Press GmbH 2004
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


[Galileo Computing]

Galileo Press GmbH, Gartenstraße 24, 53229 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de