Windows NT für Programmierer

Kapitel 1: Hardware- und Netzwerkschichtenmodell

Überblick

Letzte Änderung: 22.6.98 von B. Tritsch

Zurück zum Inhalt


Entwicklungsgeschichte

In den 80er Jahren wurde die Windows-Umgebung entwickelt, um auf dem Betriebssystem MS-DOS zu laufen. Die erste Vorstellung dieser graphischen Benutzeroberfläche erfolgte im November 1985. Nach der gemeinsam mit IBM gestarteten OS/2-Initiative zur Entwicklung eines Nachfolgers für MS-DOS, entschied sich Microsoft zur Arbeit an einem fortschrittlicheren Betriebssystem. Es sollte neben Intel Prozessoren auch andere CPU’s unterstützen. Die Idee war, daß das neue Betriebssystem in einer höheren Programmiersprachen (wie "C") geschrieben werden sollte, um es einfach portieren zu können. Microsoft stellte für diese Aufgabe David Cutler ein, den Chef-Entwickler von Digitals VMS, um das Projekt New Technology Operating System zu leiten. Dieses Projekt sollte am vorläufigen Ende die ungeheure Summe von mehr als einer Milliarde US$ verschlungen haben!

Anfang der 90er Jahre gab Microsoft auch die Version 3.0 von Windows frei. MS-Windows 3.0 schaffte sich eine große Benutzerbasis und spielte daher auch eine zentrale Rolle in der Entwicklungsgeschichte des neuen Systems Windows NT.

Die erste Version von Windows NT wurde im Mai 1993 auf den Markt gebracht und hatte in Anlehnung an das kleinere (aber erfolgreiche) Geschwistersystem Windows die Versionsnummer 3.1. Windows und Windows NT hatten die selbe graphische Oberfäche, NT basierte jedoch von Anfang an nicht auf MS-DOS, sondern einem völlig neuen 32-Bit-Betriebssystem. Windows NT hatte gleich in seiner ersten Fassung die zusätzliche Fähigkeit neben textbasierten OS/2- auch die meisten der älteren DOS- und Windows-Applikationen ausführen zu können.

Im Laufe der Jahre entwickelten sich die beiden Windows-Versionen konsequent weiter. Hierbei wurde Windows NT von Anfang an als das stabilere System speziell für den professionellen Bereich gesehen. Seit nun die Personal Computer auch in vielen Unternehmen Einzug gehalten haben, setzt sich Windows NT dank seiner Stabilität und trotz erhöhter Anforderungen an die Hardware auf breiter Front am Markt durch.

Schichtenmodelle

Die meisten Computersysteme stellen sich heute als ein Gerät mit verschiedenen Eingabekomponenten sowie einem Monitor mit darauf ablaufendem graphischen und fensterorientierten Interaktionsprogramm dar. Ein solches System ist in ein Schichtenmodell gegliedert.

Abbildung 1.1: Schichtenmodell

Die Reihenfolge der verschiedenen Schichten von unten nach oben ist hierbei wie folgt:

Die Kombination aus den letzten vier Levels wird oft als GUI (Graphische Benutzerschnittstelle) bezeichnet. Imaging Model, Windowing Model und User Model definieren das Application Programming Interface (API). Die folgende Abbildung zeigt das Hardware/Software-Schichtenmodell für verschiedene Plattformen. Unter Windows NT wird hierbei DOS durch das NT-Betriebssystem ersetzt.

Abbildung 1.2: Einordnung verschiedener Betriebssysteme in das Schichtenmodell

Um das Thema Netzwerke besser zu strukturieren und damit leichter auf die erhöhten Anforderungen des Marktes reagieren zu können, entwickelte die International Standardization Organization (ISO) 1977 ein sogenanntes Referenzmodell für Open Systems Interconnection, das ISO-OSI-Referenzmodell. Hierbei handelt es sich um ein Schichtenmodell, wobei die transportorientierten Funktionen in vier und die datenverarbeitungsorientierten Funktionen in drei Schichten unterteilt sind.

Abbildung 1.3: Das OSI-Schichtenmodell

Die grundlegende Idee hinter einem Schichtenmodell ist, daß jede beteiligte Schicht einer darüberliegenden Schicht bestimmte Dienste anbietet. Damit schirmt sie die höheren Schichten von Details ab, wie die betreffenden Dienste realisiert sind. Dadurch ist es möglich, daß eine Schicht n des einen Computers mit der selben Schicht n eines anderen Computers kommuniziert. Die Regeln und Konventionen dieser Kommunikation werden als das Protokoll der Schicht n genannt.

In der Realität kommunizieren die Schichten n nicht miteinander. Jede Schicht reicht seine Daten und zusätzliche Kontrollinformationen an die direkt darunterliegende Schicht weiter bis die tiefste Schicht erreicht ist. Unter dieser Schicht liegt das physikalische Medium, durch das die echte Kommunikation stattfindet.

Zwischen einem Paar übereinanderliegender Schichten besteht eine definierte Schnittstelle (Interface). Das Interface bestimmt die Operationen und Dienste die die untere der oberen Schicht anbietet. Ein Satz von Schichten und Schnittstellen wird dann die Netzwerkarchitektur genannt. Eine Liste von Protokollen, die von einem bestimmten System genutzt werden - ein Protokoll pro Schicht - wird Protocol Stack genannt.

Windows NT unterstützt mehrere Protokolle parallel, wobei jedoch nicht alle installiert sein müssen. Dennoch ist es wichtig zu wissen, welche Protokolle existieren und für welchen Zweck sie eingesetzt werden können. Weiterhin setzt Windows NT für die Interprozeß-Kommuniation (IPC) eine Reihe verschiedener Mechanismen ein, die für die Realisierung verteilter Anwendungen benötigt werden.

In einer verteilten Umgebung müssen die Daten zwischen Client- und Server-Anwendungen bi-direktional ausgetauscht werden. Hierfür gibt es unter Windows NT sieben Möglichkeiten: Named Pipes, Mailslots, NetBIOS, Windows Sockets, RPCs, NetDDE, SMBs und DCOM.

Named Pipes und Mailslots wurden ursprünglich als Treiber für Dateisysteme entwickelt und stammen noch aus der OS/2-Welt. Eine Pipe verbindet zwei Prozesse miteinander, so daß die Ausgabe des einen als Eingabe des zweiten dienen kann. Named Pipes sind verbindungsorientiert und basieren auf OS/2-API-Aufrufen. Mailslots sind Bestandteil der OS/2-LAN-Manager-Implementierung und erlauben die verbindungslose Übertragungen von Rundsendungen (Broadcasts). Named Pipes und Mailslots können sowohl von lokalen Prozessen als auch über den Redirector für entfernte Kommunikation eingesetzt werden.

Die NetBIOS-Schnittstelle wird schon seit Anfang der achtziger Jahre zur Entwicklung von verteilten Anwendungen verwendet. Die Kommunikation von NetBIOS-Applikationen kann über verschiedene Protokolle erfolgen:

Viele Anwendungen und Dienste, die für den Betrieb einer Windows NT-Umgebung benötigt werden, basieren auf der NetBIOS-Schnittstelle.

Die Windows Socket-Schnittstelle erlaubt die Kommunikation über Protokolle mit unterschiedlichen Adressierungssystemen. Momentan werden TCP/IP sowie NWLink (IPX/SPX) von den Windows Sockets unterstützt. Ursprünglich wurden sie von den Berkeley Sockets abgeleitet, einer Standardschnittstelle zur Entwicklung von Client/Server-Anwendungen unter UNIX und vieler anderer Plattformen.

Das Konzept der Remote Procedure Calls (RPCs) wurde von Sun Microsystems entwickelt, um Prozesse so auf einem entfernten Rechner aufzurufen, als würden sie lokal ausgeführt werden. Die Entwickler sollten sich nicht um Details für die Netzwerkkommunikation kümmern müssen, so wie dies z.B. bei den Windows Sockets notwendig ist. RPCs setzen daher Methoden wie Named Pipes, NetBIOS oder Windows Sockets als Basis ein und kapseln die eigentliche Kommunikation.

Bei Network Dynamic Data Exchange (NetDDE) handelt es sich um eine Erweiterung des DDE-Mechanismus‘ zum Austausch von Daten zwischen Windows-Anwendungen. Um NetDDE verwenden zu können, muß ein NetBIOS-kompotibles Netzwerk eingesetzt werden.

Zur Weiterleitung von bestimmten Informationen zwischen Computern werden Server Message Blocks (SMBs) eingesetzt. Für die Verteilung von SMBs auf entfernte Geräte und den lokalen Rechner spielt der Redirector eine zentrale Rolle. Er sorgt für die reibungslose Interaktion zwischen den verschiedenen Versionen der Netzwerkprodukte von Microsoft und anderer Hersteller. Die Funktionalitäten der SMBs umfassen insbesondere Sitzungssteuerung, Dateizugriffe, Druckerkontrolle und Nachrichtenmeldungen.

Die Konzepte des Distributed Common Object Model (DCOM) spielen eine wachsende Bedeutung unter Windows NT und einer Reihe von weiteren Plattformen. Sie dienen zur objektorientierten Ankopplung von Software-Komponenten über eine Middleware.

Client/Server-Architektur

Grundsätzlich wird im Netzbereich zwischen zwei Architekturen unterschieden: Peer-to-Peer- und Client/Server-Netze. Ersteres realisiert eine Punkt-zu-Punkt-Verbindung zwischen einzelnen Plattformen. Parallel zu seiner normalen Arbeit kann jeder Rechner seine Ressourcen den anderen Rechnern im Netz verfügbar machen sowie verfügbar gemachte Ressourcen von anderen Rechnern in Anspruch nehmen. Dies gilt für Ressourcen wie Dateien, ganze Verzeichnisse oder Dateisystemzweige, Drucker, Festplatten, CD-Laufwerke, etc.

In einer Client/Server-Architektur bleiben bestimmte ressourcenintensive Aufgaben wie Datenverwaltung, Drucken, E-mail-Verwaltung oder Systemadministration auf den Server (Auftragnehmer) beschränkt. Die Clients (Auftraggeber) haben nur direkte Verbindung zum Server und dienen durch Anforderungen an seine Dienste als Interaktionseinheit. Der Netzverkehr ist dadurch im Gegensatz zu anderen Architekturen vergleichsweise gering. Der Server erfordert jedoch ein hohes Maß an Prozessorleistung, Festplattenkapazität, Hauptspeicherkapazität und Datendurchsatz. In der Regel kann der Server durch die hohen Anforderungen an seine Reaktionszeit auf Diensteanforderungen für keine anderen Aufgaben benutzt werden. Daher wird ein solches Netz erst ab mehr als zehn Benutzer sinnvoll.

Die folgende Abbildung zeigt den typischen Aufbau verschiedener Netze:

  1. Peer-to-Peer-Netz, wobei zwei Arbeitsstationen spezifische Resourcen (Drucker, ISDN-Ankopplung) zur Verfügung stellen.
  2. Client/Server-Netz mit Servern für die Kommunikation, die Datenhaltung und das Ausdrucken.

Abbildung 1.4: Verschiedene Netzwerktypen

Es existieren verschieden abgestufte Client/Server-Optionen, die in der untenstehenden Abbildung aufgezeigt werden. Sie differieren hauptsächlich durch die unterschiedliche Behandlung der verteilten Anwendung und der Datenhaltung. Sie implizieren verschiedene Leistungsfähigkeiten auf Seiten des Servers oder des Clients.

Abbildung 1.5: Unterschiedliche Client/Server-Konzepte

Zum nächsten Kapitel