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:
- Hardware: Diese Schicht betrifft den Computer als solches inklusive seiner
Komponenten wie Prozessor, Graphikausgabe, Peripheriegeräte, Multimediaerweiterungen,
Schnittstellen sowie Netzanbindung.
- Operating System: Das Betriebssystem erweckt den Rechner zum Leben. Es ist die
unterste Softwareschicht, die sich um den Fluß der Datenströme von und zu dem Prozessor
sowie die Ansteuerung der Peripheriegeräte kümmert.
- Imaging Model: Das Imaging Model oder Graphiksystem entscheidet wie Graphik,
Fonts und andere Abbilder auf dem Bildschirm dargestellt werden.
- Windowing Model: Das Windowing Model besteht aus den Spezifikationen für das
Öffnen, Verändern und Bewegen von Fenstern sowie für die Kontrollmechanismen beim
Bewegen und Wiedersichtbarmachen von Fensterinhalten.
- User Model: Das User Model bestimmt die Führung des Benutzers durch das
Fenstersystem.
- Desktop Manager: Der Desktop Manager übernimmt die Anordnung der einzelnen
Anwendungsprogramme auf der Bildschirmoberfläche (dem Desktop).
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.
- TCP/IP: Auf der OSI Network-Schicht kann man das Internet als eine
Sammlung von Subnetzen oder autonomen Systemen betrachten, die miteinander verbunden sind.
Der Klebstoff, der alles zusammenhält ist IP, das Internet Protocol. Bewegt man
sich nun in das Transport Layer, so besitzt das Internet zwei Hauptprotokolle , wobei das
eine verbindungsorientiert (TCP) und das andere verbindungslos (UDP) ist. Die
TCP/IP-Protokoll-Suite wird inzwischen jedoch auch im Bereich der Intranets genutzt und
ist damit das momentan verbreitetste Protokoll.
- NetBEUI: Das historische von Microsoft und IBM in ihren
Netzwerkbetriebssystemen eingesetzte Standardprotokoll ist NetBEUI (NetBIOS
Enhanced User Interface). Es wird bis heute von Windows NT, Windows 95 und auch von
OS/2 unterstützt, ist jedoch nicht routing-fähig. Andererseits ist es sehr einfach zu
installieren und zu verwalten. Ausgangspunkt für die Entwicklung von NetBEUI war die
NetBIOS-Schnittstelle. (Network Basic Input/Output System). Sie wurde schon zu Urzeiten
der MS-DOS-Netzwerke von Microsoft entwickelt und besteht aus weniger als 20 einfachen
Befehlen, die für den Datenaustausch sorgen.
- NWLink und IPX/SPX: Ab Windows NT 3.5x wurde zusätzlich zum
NetBEUI-Protokoll das NWLink-Protokoll eingeführt, ein NetWare-kompatibles
Protokoll. Es ist kompatibel zu Novells SPX/IPX und kann in einem Netzwerk genauso wie
NetBEUI oder TCP/IP den Transport der Daten übernehmen. Mit dem NWLink-Protokoll kann man
sich mit einem Windows NT-Rechner direkt als Client an einem Novell-Netzwerk
anmelden. Ressourcen dieses Netzwerks (Dateien, Peripherie-Geräte) kann man jedoch erst
dann verwenden, wenn man den NetWare-Gateway-Service eingerichtet hat.
- DLC: Das DLC-Protokoll (Data Link Control) lehnt sich an einen
Industriestandard (IEEE 802.2) an und wurde nicht spezielle für die Netzwerkverbindung
von PCs entwickelt. Es ist jedoch möglich über DLC direkt auf die zweite OSI-Schicht
(Data Link Layer) zuzugreifen. Der Redirector von Windows NT unterstützt DLC dagegen
nicht, weshalb es für die Client/Server-Kommunikation zwischen NT-Rechnern nicht
eingesetzt werden kann. DLC dient daher primär zur Verständigung zwischen zwischen
Windows NT und Mainframe-Rechnern sowie besonderen Komponenten wie JetDirect-Karten
von HP oder MarkVision-Karten von Lexmark.
- AppleTalk: Das AppleTalk-Protokoll wird auf Macintosh-Computern
zur Kommunikation verwendet. Ein spezieller Dienst erlaubt die Konfiguration von
Windows NT Servern in einer Weise, daß mit Macintosh-Computern Ressourcen wie
Festplatten oder Drucker geteilt werden können. Für Macintosh-Clients stellt sich die
Situation dar, als würden sie Verbindung zu einem AppleShare-Server aufnehmen.
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:
- NetBEUI Frame Protocol – NBF
- NWLink NetBIOS – NWNBLink
- NetBIOS over TCP/IP – NetBT
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:
- Peer-to-Peer-Netz, wobei zwei Arbeitsstationen spezifische Resourcen (Drucker,
ISDN-Ankopplung) zur Verfügung stellen.
- 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
