Galileo Computing < openbook > Galileo Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Geleitwort zu diesem Buch
Inhalt des Buchs
1 Warum eine neue Server-Version?
2 Editionen und Lizenzen
3 Hardware und Dimensionierung
4 Protokolle
5 Was überhaupt ist .NET?
6 Installation
7 Core-Installationsoption
8 Active Directory-Domänendienste
9 Netzwerkdienste im AD-Umfeld
10 Active Directory Lightweight Directory Services (AD LDS)
11 Active Directory-Verbunddienste (Federation Services)
12 Active Directory-Zertifikatdienste
13 Active Directory-Rechteverwaltungsdienste (AD RMS)
14 »Innere Sicherheit«
15 Dateisystem und Dateidienste
16 Drucken
17 Webserver (IIS)
18 SharePoint (Windows SharePoint Services, WSS)
19 Remotedesktopdienste (Terminaldienste)
20 Hochverfügbarkeit
21 Datensicherung
22 Servervirtualisierung mit Hyper-V
23 Windows PowerShell
24 Windows 7 und Windows Server 2008 R2
Stichwort
Ihre Meinung?

Spacer
<< zurück
Windows Server 2008 R2 von Ulrich B. Boddenberg
Das umfassende Handbuch
Buch: Windows Server 2008 R2

Windows Server 2008 R2
geb., 1.410 S., 59,90 Euro
Rheinwerk Computing
ISBN 978-3-8362-1528-2
Pfeil 17 Webserver (IIS)
Pfeil 17.1 Begriffsdefinitionen
Pfeil 17.1.1 Webapplikation vs. Webservice
Pfeil 17.1.2 Website vs. Webseite
Pfeil 17.2 ASP.NET
Pfeil 17.2.1 Die Entwicklungsumgebung
Pfeil 17.2.2 Clientseitig: JavaScript
Pfeil 17.2.3 Die web.config-Datei
Pfeil 17.2.4 Kompilierung und Vorkompilierung
Pfeil 17.2.5 Sicherheit und ASP.NET
Pfeil 17.3 Installation
Pfeil 17.4 Kurzer Überblick über die Architektur des Webservers
Pfeil 17.4.1 Architektur
Pfeil 17.4.2 Anforderungsverarbeitung
Pfeil 17.4.3 Anforderungsverarbeitung im Anwendungspool
Pfeil 17.4.4 Die »Modulbauweise«
Pfeil 17.5 Webserver, Websites, Anwendungen, virtuelle Verzeichnisse und Anwendungspools
Pfeil 17.5.1 Die Zusammenhänge
Pfeil 17.5.2 Webserver
Pfeil 17.5.3 Anwendungspool
Pfeil 17.5.4 Website
Pfeil 17.5.5 Anwendung
Pfeil 17.5.6 Virtuelles Verzeichnis
Pfeil 17.6 Authentifizierung
Pfeil 17.6.1 Anonyme Authentifizierung
Pfeil 17.6.2 Standardauthentifizierung
Pfeil 17.6.3 Digestauthentifizierung
Pfeil 17.6.4 Windows-Authentifizierung
Pfeil 17.6.5 Authentifizierungsdelegierung
Pfeil 17.6.6 Webanwendungen und Kerberos
Pfeil 17.6.7 Delegierung, eingeschränke Delegierung und Protokollübergang
Pfeil 17.6.8 Formularauthentifizierung
Pfeil 17.7 Autorisierung
Pfeil 17.7.1 NTFS-Berechtigungen
Pfeil 17.7.2 URL-Autorisierung
Pfeil 17.8 Sonstiges zum Thema »Sicherheit«
Pfeil 17.8.1 SSL-Verschlüsselung
Pfeil 17.8.2 .NET-Vertrauensebenen
Pfeil 17.8.3 IP- und Domäneneinschränkungen
Pfeil 17.9 Sitzungszustand
Pfeil 17.10 Load Balancing und Redundanz
Pfeil 17.10.1 Verwendung von Microsoft NLB
Pfeil 17.10.2 Remoteanforderungen
Pfeil 17.10.3 Freigegebene Konfiguration
Pfeil 17.10.4 Sitzungsstatus
Pfeil 17.10.5 Datenbankserver
Pfeil 17.11 Administration
Pfeil 17.11.1 Remote-Administration
Pfeil 17.11.2 Remote-Administration für Nicht-Server-Administratoren und IIS-Benutzer
Pfeil 17.11.3 Delegierung von Features
Pfeil 17.11.4 Protokollierung
Pfeil 17.12 Der Best Practice Analyzer (BPA)
Pfeil 17.13 IIS-Schlussbemerkung


Galileo Computing - Zum Seitenanfang

17.4 Kurzer Überblick über die Architektur des Webservers Zur nächsten ÜberschriftZur vorigen Überschrift

Über die Architektur von komplexen Serversystemen kann man natürlich seitenlang schreiben. Das möchte ich hier bewusst nicht tun, es gibt aber einige Fakten, die Sie einfach über den IIS wissen sollten. Weiterhin gibt es auch für diejenigen, die sich bereits mehr oder weniger intensiv mit dem Vorgänger-IIS beschäftigt haben, das ein oder andere Neue zu entdecken: Oder wissen Sie aus dem Stand, was der Windows-Prozessaktivierungsdienst tut?


Galileo Computing - Zum Seitenanfang

17.4.1 Architektur Zur nächsten ÜberschriftZur vorigen Überschrift

In Abbildung 17.17 ist die Architektur des Internet Information Servers zu sehen:

  • http.sys ist der im Kernelmodus ausgeführte Protokolllistener. Sämtliche HTTP-Anforderungen gehen hier ein. Dies gilt übrigens auch für HTTPS-Anforderungen.
  • Der WWW-Publishing-Dienst (W3SVC) verwaltet bzw. steuert die http.sys und ist für die Leistungsüberwachung zuständig.
  • Der Windows-Prozessaktivierungsdienst (WAS) verwaltet die Arbeitsprozesse. Er startet und beendet die Anwendungspools.
  • Im Konfigurationsspeicher werden die Einstellungen sowohl für den IIS als auch für ASP.NET gespeichert. Im Gegensatz zum IIS6 und dessen Metabase gibt es nicht eine zentrale Konfigurationsdatenbank, sondern es existiert eine Hierarchie aus verteilten XML-Dateien.
  • Arbeitsprozess (w3wp.exe): Dieser Prozess verarbeitet die Anforderungen und generiert Antworten. Es können mehrere Arbeitsprozesse pro Anwendungspool existieren.

Abbildung 17.17 Architektur des IIS7-Webservers


Galileo Computing - Zum Seitenanfang

17.4.2 Anforderungsverarbeitung Zur nächsten ÜberschriftZur vorigen Überschrift

Die Funktion der einzelnen Bausteine ist natürlich nur sehr grob umrissen worden, etwas »mehr Leben« lässt sich dem Ganzen einhauchen, wenn man das Zusammenspiel anschaut oder etwas wissenschaftlicher gesprochen »die Anforderungsverarbeitung analysiert«. In Abbildung 17.18 sind die einzelnen Schritte eingetragen:

  • Schritt 1: Die vom Client eingehende HTTP-Anforderung wird von http.sys entgegengenommen.
  • Im Schritt 2 gibt es nun zwei Varianten:
    • Falls http.sys über die Konfigurationsinformationen für die Webanwendung verfügt, an die die Anforderung gerichtet ist, wird die Anforderung an den entsprechenden Arbeitsprozess weitergeleitet – und gelangt somit direkt zu Schritt 7.
    • Verfügt http.sys nicht über die Konfigurationsinformationen, wird der WWW-Publishing-Dienst kontaktiert, der wiederum den Windows-Prozessaktivierungsdienst (WAS) bemüht.
  • Schritt 3: Der WAS ruft die Konfiguration aus dem Konfigurationsspeicher ab (application-host.config).
  • Schritt 4: Der WAS prüft, ob innerhalb des für die Webanwendung zuständigen Anwendungspools bereits ein Arbeitsprozess läuft. Ist dieser nicht vorhanden, wird er gestartet.
  • Schritt 5: Der WAS übergibt die Konfiguration (Anwendungspool- und Anwendungskonfiguration) an den WWW-Publishing-Dienst.
  • Schritt 6: Der WWW-Publishing-Dienst passt, aufgrund der vom WAS übergebenen Konfigurationsinformationen, die Konfiguration von http.sys an.
  • Schritt 7: http.sys leitet die Anforderung an den Arbeitsprozess weiter.
  • Schritt 8: Die Anforderungsverarbeitungspipeline wird von http.sys initiiert. Das Ergebnis ist eine Antwort auf die Webanforderung.
  • Schritt 9: http.sys sendet das Ergebnis an den Client.

Abbildung 17.18 Die HTTP-Anforderungsverarbeitung

Man kann dem IIS übrigens recht komfortabel unter die Haube schauen, zumindest ein bisschen. Im Internetinformationsdienste-Manager steht ein Dialog zur Anzeige der aktiven Arbeitsprozesse zur Verfügung (Abbildung 17.19). Es gibt sogar noch eine detaillierte Anzeigemöglichkeit: Im Kontextmenü des jeweiligen Arbeitsprozesses existiert der Menüpunkt Aktuelle Anforderungen anzeigen. Sie werden beim »Selbst-Testen« erkennen, dass für jeden Anwendungspool, in dem eine Webanwendung gestartet wurde, ein oder mehrere Arbeitsprozesse gestartet worden sind. Wenn Sie die schematische Darstellung der HTTP-Anforderungsverarbeitung in Abbildung 17.18 konsultieren, ist das auch sofort verständlich.

Abbildung 17.19 Laufende Arbeitsprozesse können im Internetinformationsdienste-Manager angezeigt werden.


Galileo Computing - Zum Seitenanfang

17.4.3 Anforderungsverarbeitung im Anwendungspool Zur nächsten ÜberschriftZur vorigen Überschrift

Wenn Sie den IIS6 einigermaßen gut kennen, wird Ihnen in den Grundeinstellungen der Anwendungspools aufgefallen sein, dass Sie einen Verwalteten Pipelinemodus auswählen können (Abbildung 17.20). Richtig, hier geht es um die Verarbeitung von ASP.NET-Anfragen, die naturgemäß im IIS-Umfeld eine besonders wichtige Rolle spielen.

Abbildung 17.20 Für die ASP.NET-Anforderungsverarbeitung in einem Anwendungspool können Sie zwischen zwei Pipelinemodi wählen.

Um es gleich vorwegzunehmen: Wenn es nicht irgendwelche mehr oder weniger mysteriösen Kompatibilitätsprobleme im integrierten Modus gibt, sollten Sie diesen auswählen. Trotzdem kann es sicherlich nicht schaden, die beiden Modi ein wenig genauer anzuschauen.

Der klassische Modus

Die Vorteile des integrierten Modus lassen sich besonders einfach vermitteln, wenn man mit der Abarbeitung im klassischen Modus beginnt. Der klassische Modus ist aus Gründen der Abwärtskompatibilität vorhanden, denn es könnte durchaus ASP.NET-Anwendungen geben, die in dem modernen integrierten Modus nicht lauffähig sind.

In Abbildung 17.21 sehen Sie die (etwas verkürzte) Darstellung der Anforderungsverarbeitung im klassischen Modus. Die wesentlichen Aspekte:

  • Im Arbeitsprozess wird eine Authentifizierung durchgeführt.
  • Bei der Handlerausführung wird bestimmt, ob die Anforderung durch ASP.NET verarbeitet werden muss. Dies ist beispielsweise bei dem Aufruf von *.aspx oder *.asmx der Fall.
  • Es wird dann die ASP.NET-ISAPI-Erweiterung aufgerufen, die sich unter anderem wieder um die Authentifizierung kümmern muss.
  • Nach Abschluss der ASP.NET-Verarbeitung in der ISAPI-Erweiterung wird die Weiterverarbeitung wieder an den Arbeitsprozess zurückgereicht.

Abbildung 17.21 Die Anforderungsverarbeitung im klassischen Modus

Es ergeben sich folgende Einschränkungen bzw. Nachteile:

  • Von ASP.NET-Modulen bereitgestellte Funktionen sind für Nicht-ASP.NET-Anforderungen nicht verfügbar. Ein klassisches Beispiel ist die formularbasierte Authentifizierung.
  • Es werden Verarbeitungsschritte doppelt ausgeführt. Wie Sie in Abbildung 17.21 sehen, trifft dies beispielsweise für die Authentifizierung zu.
  • Die ASP.NET-Anwendungen können keinen Einfluss auf die sonstige IIS-Anforderungsverarbeitung nehmen. Das ist bei Betrachtung der Abbildung ebenfalls völlig einleuchtend, denn die ASP.NET-Verarbeitung erfolgt außerhalb der Verarbeitung im Arbeitsprozess.
  • Etliche Einstellungen müssen sowohl für den Arbeitsprozess als auch für die ASP.NET-ISAPI-Erweiterung gespeichert werden, beispielsweise die Authentifizierung.

Der integrierte Modus

Wenn Sie jetzt, mit dem soeben erworbenen Wissen über den klassischen Modus im Hinterkopf, raten müssten, was der Unterschied zwischen dem klassischen und dem integrierten Modus ist, würden Sie ohne Schwierigkeiten einen Treffer landen: Die ASP.NET-Verarbeitung ist nun nicht mehr in einer ISAPI-Erweiterung »ausgelagert«, sondern findet im Arbeitsprozess statt. Dies ist in Abbildung 17.22 zu erkennen. Die Skizze zeigt aber noch einen weiteren Aspekt:

  • Bei der klassischen Anforderungsverarbeitung stehen im Arbeitsprozess bei der Authentifizierung lediglich die Standard-, die Windows- und die anonyme Authentifizierung zur Verfügung. Die in ASP.NET enthaltene Formular-Authentifizierung ist nicht vorhanden bzw. kann erst bei der ASP.NET-Verarbeitung in der ISAPI-Erweiterung angewendet werden.
  • Die integrierte Anforderungsverarbeitung ermöglicht hingegen, dass die Formular-Authentifizierung im Rahmen der IIS-Anforderungsverarbeitung genutzt werden kann. Sie wird sozusagen gleichberechtigt mit den nativen IIS-Modulen eingesetzt. Anmerkung: Damit die ASP.NET-Module ausgeführt werden können, muss zwingend das Modul Managed Engine auf dem IIS installiert sein. Dieses Modul ist Bestandteil des Rollendiensts .NET-Erweiterbarkeit, der zwingend bei der Installation von ASP.NET mitinstalliert wird.

Um nochmals auf die Vorteile des integrierten Modus zu sprechen zu kommen: Man kann sagen, dass die im vorherigen Abschnitt aufgeführten Nachteile des klassischen Modus allesamt behoben sind:

  • Alle Anfordungen – egal ob ASP.NET, statische Dateien, ASP oder CGI – können alle Features des IIS und der ASP.NET-Welt (»verwaltet«) nutzen.
  • Es gibt keine doppelt vorhandenen Features.
  • Die Verwaltung erfolgt an einem Ort.
  • Entwickler können den IIS mit ASP.NET-Modulen erweitern und mit diesen auch recht weitgehend in die Anforderungsverarbeitung eingreifen.

Abbildung 17.22 Die Verarbeitungspipeline bei der integrierten Verarbeitung

Reihenfolge der Verarbeitung

In den vorherigen Skizzen zur Anforderungsverarbeitung haben Sie gesehen, dass der Arbeitsprozess diverse Module in einer bestimmten Reihenfolge abarbeitet. Die Reihenfolge ist natürlich ganz entscheidend, denn es hätte beispielsweise wenig Sinn, zuerst die Module zur Autorisierung aufzurufen und erst danach die Authentifizierung durchzuführen: Was soll man autorisieren, wenn man gar nicht weiß, wer vor dem Browser sitzt?

Die Abarbeitungsreihenfolge können Sie einsehen, wenn Sie auf der Ebene des Servers den Konfigurationsdialog Module aufrufen und auf der Aktionen-Leiste (rechts) den Menüpunkt Sortierte Liste anzeigen wählen. Sie sehen dann die systemeigenen und verwalteten (d. h. ASP.NET-)Module in der Reihenfolge der Verarbeitung (Abbildung 17.23).

Es ist durchaus möglich, die Reihenfolge der Verarbeitung zu ändern – dabei sollten Sie aber ganz genau wissen, was Sie tun. Die Modifikation der Verarbeitungsreihenfolge ist insbesondere dann relevant, wenn eigene individuelle Module hinzugefügt werden.

Abbildung 17.23 In dieser Reihenfolge werden die Module in der Verarbeitungspipeline abgearbeitet. Bei Bedarf kann die Reihenfolge angepasst werden. Wenn Sie aber nicht ganz genau wissen, was Sie tun, ist das keine gute Idee!


Galileo Computing - Zum Seitenanfang

17.4.4 Die »Modulbauweise« topZur vorigen Überschrift

Wenn Sie sich einige Minuten mit dem IIS7 beschäftigt haben, wird eines sofort klar: Es handelt sich um ein modulares System, bei dem die einzelnen Module genau den Anforderungen entsprechend hinzugefügt oder auch entfernt werden können.

Daraus ergeben sich drei Hauptvorteile, die jeder für sich und alle gemeinsam absolut signifikant sind:

  • Sicherheit: Dies ist einer der wesentlichen Aspekte, wenn nicht sogar der wesentlichste Aspekt.
    • Durch die Modulbauweise wird die Angriffsfläche signifikant verringert, denn was nicht installiert ist, kann auch nicht angegriffen werden.
    • Der Pflege- und der Wartungsaufwand werden reduziert. Dies ist auch eindeutig ein Sicherheitsthema, denn es hat sich in der Vergangenheit gezeigt, dass die angegriffenen Lücken häufig dadurch entstanden sind, dass Systeme schlecht gepflegt waren oder den Administratoren gar nicht klar war, wo es überall Pflegebedarf gibt.
    • Das vereinheitlichte Sicherheitsmodell von IIS und ASP.NET trägt ebenfalls zur Verbesserung der Situation bei.
  • Verbesserte Leistung: Je weniger Module geladen sind, desto weniger Schritte sind bei der Anforderungsverarbeitung zu durchlaufen (siehe Abbildung 17.21 und Abbildung 17.22). Weiterhin benötigen nicht geladene Module natürlich auch keinen Speicher etc.
  • Erweiterbarkeit: Verständlichweise trägt eine konsequente Modulbauweise dazu bei, dass IIS sehr weitgehend erweitert werden kann. Dies ist sowohl mit nativen, also in C++ geschriebenen Modulen als auch mit verwalteten (d. h. .NET-)Modulen möglich.

Die Konfiguration bzw. Aktivierung der Module ist nun zwar nicht unbedingt ein Thema, das man acht Semester lang studiert haben müsste, aber ein paar Hintergründe, sollte man schon parat haben. Die grundlegende Konfiguration erfolgt in der applicationHost.config-Datei, also der »Zentralkonfiguration« des IIS (Pfad: C:\Windows\System32\inetsrv\config).

  • Alle nativen (d. h. nicht auf .NET-Technologie basierenden) Module müssen im Abschnitt <globalModules> registiert werden. Dieser Abschnitt ist in Abbildung 17.24 gezeigt.
  • Weiterhin müssen auf Serverebene und/oder Anwendungsebene die nativen Module aktiviert werden. Dies geschieht dadurch, dass diese zusätzlich im Abschnitt <modules> aufgeführt werden, allerdings ohne Pfadangaben. Verwaltete Module (d. h. .NET-Code) können direkt im Abschnitt <modules> eingetragen werden. Abbildung 17.25 (untere Hälfte) zeigt den entsprechenden Auszug aus der applicationHost.config-Datei.
  • Zu beachten ist noch der Abschnitt <handlers>, der sowohl in der applicationHost.config als auch auf Anwendungs- und URL-Ebene existieren kann. Dort wird festgelegt, welche Handler bei welchen Dateiextensionen und Verben (z. B. POST, GET) verwendet werden sollen.

Abbildung 17.24 Der Abschnitt <globalModules> der »applicationHost.config«-Datei

Abbildung 17.25 Die Abschnitte <modules> und <handlers>

Ein Beispiel, was auf Anwendungsebene, also in der web.config, so alles gemacht werden kann, ist auf Abbildung 17.26 gezeigt. Diese web.config wurde so ohne mein Zutun von Visual Studio 2008 erstellt.

  • Das Modul ScriptModule wird entfernt und wieder hinzugefügt.
  • Vier Handler werden entfernt und wieder hinzugefügt.

Wenn Sie sich fragen, was das soll und ob Visual Studio irgendwie unter Drogen steht, hier die Antwort: Die Zielplattform des Projekts ist .NET Framework 3.5 gewesen. Durch das Entfernen und Wiederhinzufügen der »entscheidenden« Module und Handler wird sichergestellt, dass für diese Anwendung wirklich mit den Komponenten mit Versionsstand 3.5 gearbeitet wird. Es ist zwar auf der Abbildung nicht zu sehen, aber sowohl beim Modul als auch bei den Handlern wird genau diese Version referenziert.

Die WebServiceHandlerFactory-Integrated wird nicht hinzugefügt, da sie in dem Projekt nicht erforderlich ist.

Abbildung 17.26 Eine von Visual Studio erzeugte »web.config«-Datei nimmt Modifikationen im Bereich der Module und Handler vor.

Geschockt durch zu viel XML?

Kein Problem, Sie können alles auch in der grafischen Oberfläche einstellen:

  • Abbildung 17.27 zeigt die systemeigenen und verwalteten Module in der Ansicht. Im Kontextmenü des Moduls gibt es jeweils minimale Konfigurationsmöglichkeiten, insbesondere beim Dateipfad (bei systemeigenen Modulen) und bei den Typen (bei verwalteten Modulen) – also nichts, an dem man etwas einstellen müsste. Der auf der Abbildung gezeigte Bildschirm entspricht übrigens dem Abschnitt <globalModules> der applicationHost.config-Datei (siehe Abbildung 17.24).
  • Der Dialog in Abbildung 17.28 zeigt die definierten Handlerzuordnungen auf Serverebene. Auch die hier gezeigten Einträge finden sich natürlich in der applicationHost.config-Datei. Der entsprechende Abschnitt heißt wenig überraschend <handlers>; in Abbildung 17.25 (oben) ist er in der Originalform zu sehen.

Abbildung 17.27 Diese systemeigenen und verwalteten Module sind auf der Maschine installiert – das kann aber bei Ihnen durchaus anders aussehen.

Abbildung 17.28 Die definierten Handlerzuordnungen

Die Abschnitte <handlers> und <modules> können, wie zuvor bereits erwähnt, sowohl auf Server- als auch auf Anwendungsebene definiert werden. Ein wenig weiter vorn in Abbildung 17.26 haben Sie gesehen, dass eine Anwendung mit »ihrer« web.config Module und Handlerzuordnungen entfernen und hinzufügen kann. Schaut man den Dialog Module dieser Anwendung an, wird man feststellen, dass bei dem explizit hinzugefügten Modul (ScriptModule) als Eintragstyp Lokal angegeben ist, während bei den von der Serverkonfiguration übernommenen Modulen Geerbt eingetragen ist (Abbildung 17.29). Im Konfigurationsdialog Handlerzuordnungen zeigt sich eine ähnliche Situation: Schließlich werden in der web.config auch an dieser Rubrik Anpassungen vorgenommen (ohne separate Abbildung).

Abbildung 17.29 Zu beachten ist hier, dass auf Anwendungsebene die meisten Module »geerbt« sind; eines ist allerdings »lokal« definiert.



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen. >> Zum Feedback-Formular
<< zurück
 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Windows Server 2012 R2






 Windows Server
 2012 R2


Zum Katalog: Office 365






 Office 365


Zum Katalog: Microsoft Hyper-V






 Microsoft Hyper-V


Zum Katalog: Linux-Server






 Linux-Server


Zum Katalog: Vmware vSphere 5






 Vmware vSphere 5


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Rheinwerk Verlag GmbH 2010
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.


[Rheinwerk Computing]

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de