17Webserver (IIS)

Aller Achaier umher! und nenntest du selbst Agamemnon,
Der nun mächtig zu sein vor allem Volke sich rühmet!
Jetzo begann er getrost, und sprach, der untadliche Seher:
Nicht versäumte Gelübd’ erzürnten ihn, noch Hekatomben;
Sondern er zürnt um den Priester, den also entehrt’ Agamemnon
Um Microsofts Webserver, den Internet Information Server (IIS), einigermaßen umfassend abzuhandeln, müsste man eigentlich ein eigenes Buch mit circa 1.000 Seiten schreiben. Da sich das vorliegende Buch schwerpunktmäßig an Architekten und Administratoren wendet, kann man aber mit einer etwas reduzierten Darstellung die wichtigsten Aspekte abdecken – und genau das soll dieses Kapitel leisten.
Abbildung 17.1 zeigt den Internetinformationsdienste-Manager, der auch mit vielen hübschen Symbolen nicht darüber hinwegtäuschen kann, dass es jede Menge Aspekte zu verstehen und zu konfigurieren gibt.
In den Anfangszeiten des »Webs« zeigten die Webserver mehr oder weniger statische Inhalte an. Das hatte mit den heutigen modernen Internet-, Extranet- und Intranet-Applikationen nicht viel zu tun. Heute ist »der Webserver« in vielen Unternehmen eine wichtige Drehscheibe für den Austausch und die Bereitstellung komplexer Informationen sowie für die Darstellung von Geschäftsprozessen – kurz gesagt: Er ist eine Applikationsplattform.
Die Probleme – oder besser gesagt die Herausforderungen – bestehen meiner Erfahrung nach auch nicht darin, den IIS dazu zu bringen, dass er einige statische HTML-Seiten anzeigt, sondern darin, das Gesamtkonstrukt mit Authentifizierung, Autorisierung, Zertifikaten und dergleichen mehr zu beherrschen.
In der Microsoft-Welt ist ASP.NET eine der Schlüsseltechnologien, die von vielen Applikationsentwicklern verwendet wird. Der IIS kann auch durchaus mit anderen Webtechnologien zusammenarbeiten. Meiner Erfahrung nach kommt aber niemand, der den IIS installiert und administriert, um einigermaßen profunde ASP.NET-Kenntnisse herum, weshalb das Thema in diesem Kapitel ebenfalls angesprochen wird.
Abbildung 17.1 Eine beeindruckende Menge von zu konfigurierenden Aspekten – der Internetinformationsdienste-Manager
ASP und PHP
Neben ASP.NET-Anwendungen unterstützt der IIS den Betrieb von ASP- (ohne .NET) und PHP-Anwendungen.
Hier ein kurzer Überblick über die IIS-Versionsnummern in den neueren Serverbetriebssystemen:
- Server 2008: 7.0
- Server 2008 R2: 7.5
- Server 2012: 8.0
- Server 2012 R2: 8.5
Abbildung 17.2 Die aktuellste Version des IIS ist 8.5
17.1
Begriffsdefinitionen

Wenn ich mit Kunden spreche, stelle ich immer wieder fest, dass es im »erweiterten Internet-Umfeld« Begriffe gibt, die zwar alle benutzen, mit denen aber teilweise etwas Unterschiedliches gemeint wird. Es folgen daher zwei Begriffsbestimmungen.
17.1.1
Webapplikation vs. Webservice


In der heutigen Welt muss sehr sorgfältig zwischen einer Webapplikation und einem Webservice unterschieden werden. Dieser Abschnitt ist allen gewidmet, die sich unter Webservices (noch) nichts vorstellen können.
Ein Blick in die Wikipedia (http://de.wikipedia.org) liefert folgende Definition:
»Ein Web Service ist eine Software-Anwendung, die mit einem Uniform Ressource Identifier (URI) eindeutig identifizierbar ist und deren Schnittstellen als XML-Artefakte definiert, beschrieben und gefunden werden können. Ein Web Service unterstützt die direkte Interaktion mit anderen Software-Agenten unter Verwendung XML-basierter Nachrichten durch den Austausch über internetbasierte Protokolle.«
Verwechseln Sie also einen Webservice nicht mit einer Webapplikation:
- Auf eine Webapplikation greift ein Mensch mit seinem Browser zu.
- Auf einen Webservice greift eine Maschine bzw. ein Softwareprogramm zu.
Am einfachsten ist der Unterschied zwischen Webapplikation und Webservice an einem Beispiel zu erklären (Abbildung 17.3). Die Ausgangslage: Ein Kurierdienst bietet seinen Kunden die Möglichkeit, im Internet den Status der Sendungen abzufragen. Nach Eingabe der Sendungsnummer kann der Datenbankserver mit den Sendungsverfolgungsdaten ermitteln, wo die Sendung das letzte Mal erfasst worden ist. Nun gibt es zwei Zugriffsszenarien:
- Wenn ein menschlicher Benutzer gezielt den Status einer Sendung abfragen möchte, kann er die Webapplikation des Kurierdiensts aufrufen und dort seine Sendungsnummer eingeben, woraufhin die Webapplikation die Daten beim Datenbankserver abfragt und anzeigt.
- Wenn das Unternehmen auf die Idee kommt, dass die Status aller Sendungen regelmäßig
in die Warenwirtschaft eingepflegt werden sollen, wäre das eine ziemlich heftige Arbeitsbeschaffungsmaßnahme,
wenn ein Mitarbeiter alle Sendungsnummern zunächst manuell in die Webapplikation und
das Ergebnis dann in die Warenwirtschaft eintippen müsste.
Über Webservices kann eine Softwarekomponente des Warenwirtschaftssystems ohne »menschliche Hilfe« die Daten abfragen – vorausgesetzt, der Kurierdienst bietet einen Webservice an.
Abbildung 17.3 Ein menschlicher Benutzer arbeitet mit der Webapplikation; eine Maschine konsumiert einen Webservice.
Bei einem Webservice werden XML-Daten über das SOAP-Protokoll ausgetauscht. Der Transport der Daten an sich erfolgt per HTTP/HTTPS. Die Definition eines Webservice ist in Abbildung 17.4 gezeigt:
- Im oberen Bereich der Definition sehen Sie die Definition der Anfrage, die vom Client zum Webservice gesendet wird. Innerhalb des SOAP-Envelope ist zwischen den Tags <soap:Body> und </soap:Body> der eigentliche Funktionsaufruf zu erkennen. Als Parameter werden drei Strings, nämlich Startdatum, Enddatum und Emailaddr, übergeben.
- Im unteren Teil ist zu erkennen, was der Webservice an den Client zurücksendet. Zwischen den Tags <CheckFBResponse> und </ CheckFBResponse> sehen Sie, dass schlicht und ergreifend XML-Code (darin ist ein String enthalten) zurückgesendet wird.
Auf den ersten Blick sieht das nach recht komplizierter Programmierarbeit aus, um den Webservice nutzen zu können. Visual Studio unterstützt das Erstellen von Webservices und Webservice-Client-Applikationen sehr nachhaltig, sodass zumindest die Protokollabwicklung recht unproblematisch ist.
Die Vorteile von Webservices sind:
- Sie sind plattform- und applikationsunabhängig. Über Webservices kann auch eine Unix-Applikation problemlos auf Exchange zugreifen.
- Sie funktionieren über das Internet.
- Sie sind (zumindest mit Visual Studio) vergleichsweise einfach zu erstellen und zu konsumieren. Zumindest Visual Studio-Entwicklern wird mehr oder weniger die komplette Handhabung der »Webservice-Technik« abgenommen, sodass sie sich mit ihrer eigentlichen Arbeit beschäftigen können, nämlich mit der Implementation der Business-Logik.
Abbildung 17.4 Die Definition eines Webservice. Im oberen Bereich sehen Sie die Anfrage, im unteren Bereich die Antwort.
Auf den ersten Blick sind Webservices zwar eher ein Entwickler- als ein IT-Professional-Thema, allerdings ist grundlegendes Wissen über das Funktionieren von Webservices auch für IT-Pros elementar wichtig – schließlich müssen sie die Webservices einspielen und betreiben.
17.1.2
Website vs. Webseite

Website vs. Webseite: Das klingt irgendwie trivial, oder? Das habe ich auch gedacht, bis ich letztens u. a. in einer Fachpublikation eine Vermischung dieser Begriffe gefunden habe. Vielleicht führt auch die phonetische Ähnlichkeit im Deutschen zum Begriffschaos?
Sollten wir diese Begriffe doch noch einmal »sortieren«? Vielleicht ja, habe ich mir gedacht und ein kleines Bild erstellt, das ich Ihnen nicht vorenthalten möchte (Abbildung 17.5):
- Eine Webseite (englisch web page) ist eine einzelne Seite, die man ausgedruckt auf ein Blatt Papier bringen könnte. (Wie groß das Blatt Papier sein müsste, lassen wir einmal offen; das spielt ja auch keine Rolle.)
- Eine Website (englisch web site) besteht aus beliebig vielen Webseiten. Für den Begriff Website gibt es diverse Synonyme wie Webauftritt, Webpräsenz oder Webangebot.
- Eine spezielle Webseite ist die Homepage. Dies ist die »oberste Seite« der Website.
Abbildung 17.5 Bitte nicht verwechseln: Website und Webseite
Ihre Meinung
Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.