Netzwerkdienste

Kommunikation in Netzen Netzwerke Kommunikation in Netzen Dateisysteme im Netz Arbeitsmodelle im Netz Dienste im Netz Netzwerkdienste

Netzwerk-Nutzen electronic mail Kommunikation: Terminabsprachen, Projektkoordination, Mitteilungen, ... file sharing keine multiplen Kopien: Dateikonsistenz, Speichererparnis device sharing bessere Druckerauslastung, lohnende Anschaffung von Spezialhardware (Farblaserdrucker, high-speed-scanner,...) processor sharing Zeitersparnis durch bessere Prozessorauslastung bei Lastverteilung und /oder Kostenersparnis durch geringere Investitionen Netzwerkdienste

Verteilte Betriebssysteme Verteiltes System: Aufteilung von Funktionen in einem Rechnernetz, wobei BS auf jedem Rechner ex. Verteiltes Betriebssystem: Jede BS-Funktion ex. nur einmal im Netz Netzwerkdienste

MACH- Betriebssystemkern Mach-Kern Benutzer- File Speicher Terminal programm Manager Manager I/O user mode kernel mode Scheduler, Nachrichtenübermittlung, Basic I/O, Speicherobjekte Hardware Mikrokern Vorteile: minimaler Kern, alle Funktionen modularisiert austauschbar Nachteile: Kommunikationsdauer zwischen Managern Netzwerkdienste

Verteilte Betriebssysteme Vorteile Flexibilität inkrementelle Erweiterbarkeit um neue Dienste Transparenz durch ortsunabhängige Dienste Leistungssteigerung bei Lastverteilung Fehlertoleranz bei multiplen, gleichen Diensten Nachteile Leistungseinbuße durch Kommunikationsverzögerung Keine Fehlertoleranz wenn Funktion nur einmal vorhanden Fazit Alle BS sind Mischsysteme aus netzbasierten & lokalen BS-Funktionen; es ex. kein „reines“ System Netzwerkdienste

Netzwerke- Grundbegriffe Subnetz mit zum Internet Stern - Netzarchitektur Router Router Hub Backbone Switch Router Router Repeater Das Ziel, alle Rechner eines Netzes miteinander zu verbinden, kann man sowohl durch einen Kabelstrang erreichen, der an den Enden miteinander verbunden sein kann (Ringarchitektur), als auch dadurch, dass jeder Rechner mit einem Kabel zu einem zentralen Punkt verbunden ist (Sternarchitektur). In der Abb. ist ein solche Architektur gezeigt, in der die Rechner als Kreise und die Vermittlungseinheiten als Vierecke gezeichnet sind. Werden die Kabelstücke durch den Apparat des zentralen Punkts zu einem einzigen, elektrisch zusammenhängenden Netzwerk geschaltet, so wird dieser als Hub bezeichnet. Ein solches Netz hat zwar physisch eine Sternstruktur, logisch entspricht dies aber einer einzigen, langen Leitung. Solch eine Struktur wird gern verwendet, da sie die zentrale Kontrolle jeden Anschlusses erlaubt: fehlerhaften Rechnern im Netz kann jederzeit „der Stecker gezogen“ werden, ohne die anderen Rechner im Netz zu blockieren.. Der Übergang der Signalinhalte von einem Netz in ein angeschlossenes anderes wird durch ein spezielles Gerät, eine Brücke (Bridge) oder ein Gateway, ermöglicht. Grundsätzlich betrachtet eine solche Bridge alle Signale und leitet diejenigen ins Nachbarnetz um, die als solche kenntlich gemacht wurden. Schnelle Brücken, die auch noch weitere Funktionen zur Vermittlung beherrschen, werden als Switch bezeichnet. Wird die Brücke gezielt angesprochen und beauftragt, die Signale aus dem lokalen Netz, wo sie erzeugt wurden, zum Zielrechner in ein anderes Netz geeignet weiterzuleiten, so spricht man von einem Router. Sowohl ein Hub als auch ein Switch kann zu einem Router ausgebaut werden. Man kann mehrere Netze über Router oder Gateways zusammenkoppeln. In Firmennetzen („Intranet“) bildet die Kopplung über ein spezielles Netz, das keine Drucker oder andere gemeinsam genutzte Geräte (Ressourcen) enthält und nur zur zuverlässigen Verbindung der Subnetze zuständig ist, eine wichtige Geschäftsgrundlage. Es wird deshalb als Backbone-Netz bezeichnet im Unterschied zu Netzen, die nichts weiterleiten können, den Stub-Netzen. Router, die zu diesem zentralen Daten-Umschlagplatz vermitteln, sind die Backbone-Router. “Backbone- Router” Subnetz Netzwerkdienste

Netzwerkschichten OSI-ISO Schichten virtueller Maschinen End-to-End Verbindung: portable Software Rechner B Rechner A virtuelle P2P - Verbindungen B 7 Anwendung 7 Anwendung 6 Präsentation 6 Präsentation 5 Sitzung 5 Sitzung Transport 4 Transport 4 Transport 3 Netzwerk 3 Netzwerk 2 Datenverbindung 2 Datenverbindung 1 Phys. Verbi n dung 1 Phys. Verbi n dung Netzkabel Vorteil Systematische, portable Einteilung Nachteil zu starr und damit zu langsam Lösung Zusammenfassung von Schichten Netzwerkdienste

Netzwerkschichten OSI-ISO Layer 7 : Anwendungsschicht High-level Programme: FTP, Grafik, electronic mail, ... Layer 6 : Präsentationsebene Datenformatierung, Kodierung, Gruppierung (Records, Verschlüsselung, ) Layer 5 : Sitzungsebene open/close-Semantik: Sender, Empfänger, high-level-Fehlerbehandlung, logon-passwords, Daten/Kontrollunterscheidung,... Layer 4 : Transportschicht Umwandlung in Datenpakete, Reihenfolge der Pakete, usw. Bei TCP (Transmission Control Protocol): Fehlertoleranzgrad TP0-4 festlegen Layer 3 : Netzwerkschicht Fragen der Netztopologie: Übertragungsweg, Umleitung (routing), Netzstatus, Grenzen, Auslastung, usw. Typisch: Internet Protocol IP Layer 2 : Datenverbindung Datenpakete  Unterteilung in log. Signalframes, Wiederholung bei NO-ACK. Aber: Frame-Reihenfolge ist unkontrolliert. Z.B.: Ethernet Layer 1 : physikalische Signale BitsImpulse, Freq. z.B.10BaseT Netzwerkdienste

Netzwerkschichten Kapselung der Datenpakete Daten Schicht 6 Daten Header Schicht6 Daten Schicht 6 Header Schicht 5 Daten Header Schicht 4 Daten Header Schicht 3 Daten ACHTUNG: das gleiche gilt auf für das Ende (Tail)! Header Schicht 2 Schicht 3 Daten Signal - Datenpaket Netzwerkdienste

Kommunikationsschichten: Unix Stream-System für Protokollschichten Schicht = Treiber, leicht austauschbar 7 Anwendung named pipes, rlogin, … 6 Präsentation XDS BS-Schnittstelle: so c kets 5 Sitzung ports , IP Adresse 4 Transport TCP/IP 3 Netzwerk 2 Datenverbindung Network Access Layer 1 Phys. Verbi n dung Netzwerkdienste

Kommunikationsschichten: Windows NT Kompatibilität zu bestehenden Protokollen SMB (server message block) NetBIOS (network basic input output system) 7 Anwendung files, named pipes, mail slots 6 Präsentation Subsysteme 5 Sitzung Redirector 4 Transport NetBIOS NBT Windows - Sockets Net IPX/ TCP/IP 3 Netzwerk BEUI SPX 2 Datenverbindung NDIS Protokoll NDIS - Treiber Network Access Layer 1 Phys. Verbi n dung Netzwerkdienste

Virtual Private Networks VPN Probleme Geheimhaltung von Daten (Sprache, Dokumente, email) Unterschiedl. Grösse der Datenpakete in gekoppelten Netzen Unterschiedl. Art von Transportprotokollen Lösung Verschlüsselung der Kommunikation der Anwenderebene Netzwerkdienste

Virtual Private Networks VPN End-to-End-Protokoll: VPN durch Verschlüsselung Netzwerkdienste

Technik VoIP, Video IP Anforderung: Viele Sprach/Bildsamples Lösung: Neues Paketmanagement im Schichtenmodell 7 Anwendung 6 Präsentation 5 Sitzung 4 Transport 3 Netzwerk 2 Datenverbindung 1 Phys. Verbi n dung Network Access Layer TCP IP RTP UDP H.323 Codec , Sicherheit Service: Konferenz, Gebühren,.. For example, if the voice samples in one packet represent a duration of 20 milliseconds, then 50 (1000ms/20ms) of these samples would be required each second (the selection of this payload duration is a compromise between bandwidth requirements and quality). Each sample carries an IP/UDP/RTP header overhead of 320 bits, meaning that 16,000 (50 X 320) header bits are sent each second. It can therefore generally be assumed that header information will add 16kbps to the bandwidth requirement for voiceover IP. For example, if an 8kbps algorithm such as G.729 is used, the total bandwidth required to transmit each voice channel will be 24kbps (8+16). Overhead 40Byte/Paket: Header IPv4:20 Byte, UDP:12 Byte, RTP: 8 Byte Zusammenfassung mehrerer samples zu einem Paket! Netzwerkdienste

Kommunikation in Netzen Netzwerke Kommunikation in Netzen Dateisysteme im Netz Arbeitsmodelle im Netz Dienste im Netz Netzwerkdienste

IP-Adresse Namensgebung im Internet Eindeutige IP-Adresse: z.B. 141.2.15.25, IPv4: 32 Bits, notiert in 4 Dezimalzahlen je 0..254 (1Byte), IPv6:128Bit Name: kronos.rbi.uni-frankfurt.de server.LocalNet.domain.country Zuordnung IP-NummerName wird auf speziellen Rechner gehalten (domain name service DNS) Vergabe und Zuordnung der IP-Adresse durch zentrale Instanzen byte 0 byte 1 byte 2 byte 3 reserviert 1 Rechner Id Netz Id Multicast A B C D E 32 Bit sind nur wenige Adressen. Um jeden Mobilrechner (Handy!) oder Haushaltsgerät einheitlich eindeutig adressieren zu können, sind mehr Bits nötig. Dazu wurde mit 128 Bit die Version 6 geschaffen. Das Internet wurde mit dem TCP/IP Protokoll von der Defense Advanced Research Projects Agency (DARPA) geschaffen. Die Verwaltung der IP-Nummern und Namen wurde zuerst von der Defense Communication Agency (DCA) (jetzt Defense Information Systems Agency (DISA)) ausgeübt, die ein Network Information Center (NIC) betrieb. Die Registrierungsrechte wurden 1998 der internationalen, non-profit Organisation ICANN (Internet Corporation for Assigned Names and Numbers) übergeben. Für Deutschland ist das DENIC zuständig. Netzwerkdienste

IP-Adresse Internetnamen: Subnetze Problem: hoher zentraler Verwaltungsaufwand bei zu vielen Netzen Lösung: Unterteilung der Rechneradresse in (Subnetz,Rechner), dezentrale Verwaltung Beispiel: Klasse B-Netz: 2 Byte Rechner ID = (1Byte Subnetz, 1Byte Rechner) besser: dynamische Aufteilung durch Bitmaske (Subnetzmaske) Adressierung (Routingentscheidung) der Subnetze durch die Maske: (Adresse AND Maske) =? Subnetznummer JA : Zielrechner ist lokal im Subnetz NEIN : Routing-Rechner ansprechen Beispiel Rechner 160 129.206.218.160 1000 0001.1100 1110.1101 1010.1010 0000 im Subnetz 129.206.218.0 1000 0001.1100 1110.1101 1010.0000 0000 Maske 255.255.255.0 1111 1111.1111 1111.1111 1111.0000 0000 Also: Festlegung eines Subnetzes durch Angabe (Subnetznummer,Maske) Frage: Ist die RechnerId immer größer als die Id des Subnetzes, in der er ist? Netzwerkdienste

Netznamen Namen im regionalen Netz wide area network WAN Probleme Integration von Diensten mehrerer Domänen Konsistente, zeitveränderliche Ressourcentabelle Lösung CCITT X.500 (1988) DAP Directory Access Protocol Dateizugriff DSP Directory Service Protocol Server-Server Kommunikation DISP Directory Information Shadowing Protocol LDAP Lightweight DAP vereinf. DAP-Version auf TCP/IP Beispiel Windows NT ADS Active Directory Service nutzt LDAP Ressourcen sind Blätter im Pfadbaum <DomänenId>://<Pfad> „Aktive Objekte“: Jede Änderung im Verzeichnis wird dem Knoten darüber mitgeteilt (z.B. Druckerstatus) Nur die letzte Änderung an einem Objekt bleibt erhalten Netzwerkdienste

Netznamen Namen im lokalen Netz local area network LAN Zusammenschluß mehrer Rechner gemeinsame Wurzel // ¼ Hera Kronos Zentrale EDV Abteilung 7 Einzelverbindung / Zentrale EDV AndereAbteilungen ¼ Abteilung 7 Homogene Sicht: Beispiel Andrew File System mit DFS Inhomogene Sicht: Beispiel NFS-System unter Unix Netzwerkdienste

Dateinamen: Windows NT Namensraum Wiederholung: Symbolic link parsing-Methode Beispiel Lese Datei A:\Texte\bs_files.doc \ Device DosDevices Floppy0 HardDisk0 A: B: C: Email Partition0 Objekt Manager Namensraum Dateimanager Namensraum bs_mem.doc bs_files.doc Texte Datei Löschen: 2 Zähler, einen für user (->Löschen im Namensraum) und einen für kernel (Speicher erst freigeben, wenn alle SysCalls beendet) Symbolic link parsing-Methode: Angenommen, das Verzeichnis von Floppy A: soll gelesen werden. „A:“ wird ersetzt durch den symbolic link „\Device\Floppy0“ und dem Objektmanager übergeben. Dann wird stattdessen der Pfad „\Device\Floppy0“ abgearbeitet, bis wieder auf einen symbolic link gestoßen wird. In unserem Fall wird die „Durchsuchen“-Methode von Floppy0 ausgeführt, die im Floppy-Treiber enthalten ist und das FAT Dateisystem auslesen kann. Dies ermöglicht, auch sehr unterschiedliche Dateisysteme homogen einzubinden wie MS-FAT, HPFS von OS/2 oder CD-ROM Dateisysteme. Objekt manager: A:\Texte\bs_files.doc  \Device\Floppy0\Texte\bs_files.doc Datei manager: Lese Texte\bs_files.doc Netzwerkdienste

Netzkommunikation Beispiel Windows NT Namensraum im lokalen Netz Symbolic link parse-Methode der Treiber (MS Redirector, Novell NetWare File System) führt zum Netzverbindungsaufbau. Beispiel: Neuer „Laufwerks“buchstabe V:für Netzverbindung + Dateiname führt zu Umleitung „V:\public\text.doc“ \ Device\NetWareFileSystem\public\text .doc \ Device DosDevices Floppy0 NetWareFileSystem A: .. V: UNC : MUP Beide Mechanismen garantieren nur eine lokale Sicht des Systems durch spezielle Punkt-zu-Punkt-Verbindungen. V:\public\text.doc Redirector Universal Naming Convention UNC Beispiel \\ textserv\public\text.doc  UNC: \textserv\public\text.doc  \Device\MUP \textserv\public\text.doc  \Device\NetWareFileSystem \textserv\public\text.doc Netzwerkdienste

Netzkommunikation: Ports Konzept Punkt-zu-Punkt Kommunikation („Kommunikationspunkte“) Beispiel TCP/IP: well known port numbers Dienst Portnummer Protokoll HTTP 80 TCP FTP 21 SMTP 25 rlogin 513 rsh 514 portmap 111 rwhod UDP Unix: /etc/services Windows NT: \system32\drivers \etc\services Netzwerkdienste

Netzkommunikation: Ports Nachrichtenbasierte Punkt-zu-Punkt Kommunikation ( Protokoll, RechnerAdresse von A, ProzeßId von A, RechnerAdresse von B, ProzeßId von B ) Beispiel UNIX Transport Layer Interface TLI X/Open: Extended Transport Interface XTI Transportendpunkte (Synchron/Asynchron) Prozeß A Prozeß B Transportendpunkt Transportschicht Problem: Zwischenschicht transparent, ohne Beeinflussung Netzwerkdienste

Netzkommunikation: Sockets Verbindungsorientierte Punkt-zu-Punkt Kommunikation Client Server Kommunikation socket() socket() bind ( „Kunde“ ) Kunde ServerDienst bind ( „ ServerDienst“ ) connect() listen() accept() 1. Verbindung deklarieren und einrichten 2. Name des aufrufenden Prozesses registrieren lassen send() recv() recv() send() close() close() Netzwerkdienste

Netzkommunikation : Named Pipes Globales Konzept: Named pipe („Netzwerk/Pfadname“) => LAN-Interprozeß-Kommunikation Unix Named pipe = special device  nur IPC auf selbem Rechner, nicht NFS Named pipe = SystemV: STREAM socket pair() / bind() Windows NT CreateNamedPipe() : Objekt im globalen Namensraum, auch NetzPfad IPC = ReadFile() / WriteFile() UNC-Name = „\\ComputerName\PIPE\PipeName“ Lokale pipe: „\\ .\PIPE\PipeName“ Kommunikation zu Unix möglich, wenn LAN-Manager für Unix LM/U installiert. Netzwerkdienste

Netzkommunikation: Mailbox Konzept: Briefkasten ex. für Sender und Empfänger Multicast & Broadcast möglich Probleme: keine garantierte Reihenfolge, kein garantierter Empfang Netzwerkdienste

Netzkommunikation: Mailbox Beispiel Windows NT mail slots Briefkasten = mail slot, erzeugt mit CreateMailslot(MailBoxName) Senden: CreateFile(MailSlotName)-WriteFile()-CloseFile() mit MailSlotName = „\\ComputerName\mailslot\MailBoxName“ (UNC) bei ComputerName= „.“  lokale IPC bei ComputerName= „*“  Broadcast an alle angeschlossenen Rechner bei ComputerName= „DomainName“  Broadcast an alle Rechner der Domäne Empfänger sind jeweils alle Briefkästen mit dem angegebenen Namen, falls ex. Einschränkungen: Nachrichtenlänge bei NetBEUI: 64kB bei Punkt-zu-Punkt, 400Byte bei broadcast Höheres Protokoll erforderlich für Reihenfolge&Empfang etc., da UDP. Netzwerkdienste Netzwerkdienste

Netzkommunikation: RPC Konzept: Prozedur-Fernaufruf Remote Procedure Calls RPC Remote Method Invocation RMI Java! Remote Function Call RFC Form: wie normaler Prozedur/Methodenaufruf, Ausführung durch Netzwerk-dienst & Transport bleiben verborgen (Client-Server Standardmechanismus!) Client Server Anwender- RPC - Pr o zeß prozeß RPC -Prozeduren RPC-Prozeduren Prozeduraufruf Transport Transport Original- Prozeduren Syntaxformen Wetter=7 Stub-Procedure: ComputeWetter(heute)  RPC(7, „heute“) StdProc+Arg. RPC(7,“heute“) Netzwerkdienste

Netzkommunikation: RPC RPC-Ablauf Client Stub Netzwerk Stub Server Prozeduraufruf Argumente packen wartet .. RPC Argumente entpa c ken warten … Prozeduraufruf Original- Rückkehr ablauf Ergebnisse packen RPC return Ergebnisse auspacken RETURN Netzwerkdienste

Netzkommunikation: RPC Transport der Daten Problem: Hardwareformat von Zahlen RPC-Argumente sollten maschinenunabhängig sein! Big endian Motorola 680X0, IBM 370 höherwertig niederwertig Byte0 Byte1 Byte2 Byte3 Little endian Intel 80X86, VAX, NS32000 höherwertig niederwertig Byte3 Byte2 Byte1 Byte0 Transport: Umkehrung der Byte-Reihenfolge Lösung: data marshaling, z.B. mit XML, Java Serialisierung, ... auch für compiler data alignment (Adreßgrenzen bei records, Wortadressierung,...) Netzwerkdienste

Netzkommunikation: RPC Beispiel Unix Spezielle C-Bibliotheken /lib/libc.a; SystemV: /usr/lib/librpc.a RPC über NFS Schichtenmodell RPC/XDR external data representation RPC-library Client: anmelden mit registerrpc() Client: callrpc() Server: svr_run() clnt_. ../ svc_... Parameter des Transportprotokoll TCP/IP setzen/lesen Berechtigungen setzen/lesen Pmap_.., ath_.., xdr_.. Details des Protokolls: Vorsicht! RPC bei DCE: Compiler für spezielle Interface Definition Languge IDL. RPC durch stub-Aufrufe und Laufzeitbibliothek für Transport Netzwerkdienste

Netzkommunikation: RPC Beispiel Windows NT Verbindungslose RPC: anonymer Service (asynchron) Verbindungsorientierte RPC: bestimmte Prozeduren vom Server (synchr.) Network Data Representation (NDR)-Format Programmierung durch Microsoft IDL-Compiler MIDL Protokoll-Wahl durch Namensnotation: z.B. „ncacn_ip_tcp: MyServer[2004]“ = TCP/IP-Protokoll zu MyServer,port 2004 MIDL= Microsoft IDL-Compiler Netzwerkdienste

Kommunikation in Netzen Netzwerke Kommunikation in Netzen Dateisysteme im Netz Arbeitsmodelle im Netz Dienste im Netz Netzwerkdienste

? Dateisysteme im Netz Synchronisationsprobleme z.B. inkrement. Backup Datei, Ordner neu gelöscht überschrieben umbenannt gegenüber früherem Synchronisationspunkt Angenommen, die Ordner-Baumstruktur hat sich geändert. Woher wissen wir, was der Grund dafür ist? Ist eine Datei neu oder nur umbenannt? Wie kann ein „intelligentes Backup“ gestaltet werden? ? Netzwerkdienste

Synchronisationsstrategien Situation: Datei in A gegenüber Datei in B Weil …. existiert in A, aber nicht in B neuer umbenannt B  A umbenennen älter umbenannt A  B umbenennen neu erstellt A  B kopieren später gelöscht auch in A löschen Konfliktfall: Nach letztem Sync Datei in A geändert und in B ist neuer A  B kopieren ist älter B  A kopieren existiert in B, aber nicht in A A  B umbenennen B  A umbenennen B  A kopieren auch in B löschen Es ex. Verschiedene Möglichkeiten, die Änderungen zu interpretieren und entsprechend das Backup zu gestalten. Netzwerkdienste

Synchronisationsstrategien Situation: Ordner in A gegenüber Ordner in B existiert in beiden Dateien darin synchronisieren existiert in A, aber nicht in B neuer umbenannt: B  A umbenennen älter umbenannt: A  B umbenennen neu erstellt: A  B kopieren mit Inhalt in B neu gelöscht: auch in A löschen mit Inhalt existiert nicht in A, aber in B analog behandeln, s.o. Problem: Versionsgeschichte (z.B. Löschinformation) ist nicht vorhanden  Journaling Filesystem ist nötig! Netzwerkdienste

Wer darf wann schreiben ? Dateisysteme im Netz Zugriffssemantiken Nutzer A Dateisystem Nutzer B Netz Wer darf wann schreiben ? Netzwerkdienste

Dateisysteme im Netz Zugriffssemantiken Read Only File Problemlos, da alle Kopien aktuell sind, unabhängig von der Pufferung Operationssemantik race conditions Alle Änderungen werden sofort umgesetzt; die zeitlich nächste Operation bemerkt die Folgen der vorigen Sitzungssemantik race conditions Alle Änderungen werden nur auf einer Kopie ausgeführt. Am Ende der Sitzung wird das Original überschrieben. Transaktionssemantik Atomare Transaktion: Während der Sitzung ist die Datei gesperrt. Problem: Zugriffssemantik hängt von der Implementierung ab (Hardware, Existenz von Puffern, Netzprotokollen, ...) Beispiel Operationssemantik: Reihenfolge der Operationen = Inhalt hängt von der Kommunikationsgeschwindigkeit (Leitungsgeschwindigkeit, Netzstruktur, CPU-Takt, BS-Version, Lastverteilung, ...) ab. Netzwerkdienste

Dateisysteme im Netz Zustandsbehaftete vs. zustandslose Datei-Server = verbindungsorientierte Kommunikation vs. verbindungslose Kommunikation Server-Dienst/Verbindung eröffnen Datenstrukturen für Zugriff aufsetzen (Kennungen etc.) Zugriffsrechte prüfen Puffer einrichten Server-Dienst/Verbindung nutzen Mit Dateikennung lesen/schreiben Auftragskopien werden über gleiche Sequenznummern erkannt Server-Dienst/Verbindung schließen Puffer leeren + deallozieren Datenstrukturen abbauen Netzwerkdienste

Dateisysteme im Netz Zustandsbehaftete vs. zustandslose Server Fazit: Vorteile Schneller Zugriff: keine Adreßinfo, keine Berechtigungsprüfung Effizienter Cache: Strategien möglich (read ahead etc.) Vermeiden von Auftragskopien Nummerierung der Aufträge Dateisperrung möglich (Exklusiver, atomarer Zugriff) Datenbanken! Nachteile Client crash: kein Löschen der Strukturen+Puffer Server crash: kein Löschen der Strukturen+Puffer, Dateizustand ungewiß Begrenzte, gleichzeitig benutzte Dateienzahl: begrenzte Speicherbelegung Fazit: Server(Verbindung) mit Zustand kann Dateien reservieren, Auftragskopien vermeiden. Server(Verbindung) ohne Zustand ist fehlertoleranter, kann mehr Benutzer gleichzeitig verwalten. Netzwerkdienste

Dateisysteme im Netz Beispiel Unix NFS-Server Auftrag: file locking Network Lock Manager Client Benutzer prozeß NFS-Client statd lockd Server statd lockd NFS-Server File locking Zustandslose Client & Server Zugriffsinfo auf Client +Server gespeichert File lock durch RPC 4) Status /etc/sm 3) 6) 1) 5) Auftrag OK 7) 2) Datei Vorteile einer 2-Stellvertreterprozeß-Architektur: a) Bei client/server crash werden die Tabellen unabhängig von Benutzerprozessen wieder aufgebaut b) Bei weiteren Sperranfragen an die gleiche Datei prüft der lokale Monitorprozeß, ob der frühere Benutzerprozeß, der sperren ließ, noch am Leben ist. Wenn nein, wird die Datei entsperrt und steht allen anderen Interessenten wieder zur Verfügung. ABER: Dies ist kein Schutz vor Verklemmungen ! 7) Frage: Sind Verklemmungen möglich ? Netzwerkdienste

Dateisysteme im Netz: Cache Cache und Puffer Vorteil: Puffer auf Client beschleunigt Lesen/Schreiben Nachteil: lokaler Puffer führt zu Inkonsistenz bei Zugriffen anderer Rechner Mögliche Pufferorte: Benutzerprozeß Netzdateisystem Transport lokaler Treiber Leiter Platte Client Server Benutzerprozeß Heap/Stack Transport Client Ausgangspuffer Leiter 1GHz auf 3 km=10kBit Transport Server Eingangspuffer Netzdateisystem Dateipuffer Lokaler Treiber Blockpuffer Plattencontroller Schreib-/Lesepuffer Die Informationsmenge im Leiter zwischen zwei Rechnern errechnet sich zu 1GHz=109 Bits/sec, c=3x108 m/sec also 10x108/3x108 = 3,3 Bits/m. Bei 3 000 m Rechnerabstand über Lichtleiter sind dies 10.000 Bits =10kB Probleme gibt es immer dann, wenn ein paralleler Zugriff bestimmte Puffer NICHT benutzt, sondern seine eigenen hat. Netzwerkdienste

Dateisysteme im Netz : Cache Problem: Konsistenz der lokalen Cache A B Datenobjekt A, B lesen A schreibt B schreibt Puffer A Puffer B ? Objektpuffer Inkonsistenz ! Netzwerkdienste

Dateisysteme im Netz: Cache Cache und Puffer: Konsistenzstrategien für lokalen Cache Zentrale Kontrolle Vor dem Lesen Vergleich der Änderungsinfos (VersionsNr, Quersummen) zwischen Client und Server aber: aufwändig! Delayed Write Sammeln der Änderungen, dann erst schicken aber: Sitzungssemantik verändert Write On Close Sitzungssemantik: lokale Kopie geht an Server bei close() aber: Inkonsistenz durchs Sitzungprotokoll Write Through Änderungen gehen am Puffer vorbei sofort zum Original aber: langsam Fazit: Puffern auf Serverseite ist einfacher - auf Clientseite effizienter, aber komplexer (semant.Protokolle!) Netzwerkdienste

Dateisysteme im Netz: Cache Beispiel UNIX NFS-Cachestrategien Asynchrone RPC durch basic input output biod – Dämonen Read ahead Vorauseilende Anforderung von Benutzerblöcken Delayed write Pufferung aller Schreibdaten, flush() alle 3 s (Daten) , 30 s (Verzeichnisse), bei sync(), Puffer belegt Write through bei exklusiv gesperrten Dateien Code aus Effizienzgründen im Kernel Netzwerkdienste

Dateisysteme im Netz: Dateiserver Implementierung eines Dateiserver durch Prozesse Client Server Anwenderprozeß Netzdateimanager Dateitre i ber Gerätetreiber Netzdatei - treiber Transport Netzanschluß tre Betriebssystemaufruf System call Vorteil symmetrisches System, jeder kann beides sein Nachteil Kopieren der Systempuffer kernel space/user space Netzwerkdienste

Dateisysteme im Netz: Dateiserver Implementierung eines Dateiserver durch Treiber Client Server Anwenderprozeß Dateitre i ber Gerätetreiber Netzdatei - treiber Transport Netzanschluß tre Betriebssystemaufruf System call Vorteil schnelles System Nachteil asymmetrische Kerne Netzwerkdienste

Dateisysteme im Netz Beispiel Unix Das NFS-System Client Server Mount() zum Einhängen eines Server-Dateisystems Prozesskommunikation zum mount-demon Nfs_svc() im kernel mode auf dem Server Virtual i-nodes für virtuelles Dateisystem Client Server System call NFS Anwenderprozeß Netz MS-DOS file sy s tem UNIX Cl i ent Gerätetreiber Virtual File System y UDP/IP Systemaufruf-Verteiler Netzwerkdienste

Dateisysteme im Netz Beispiel Windows NT Netzdateisystem Server Client Verbindungsorientierter Netzaufbau durch Redirector mit Transport Driver Interface TDI über virtual circuits (Kanäle) Kernel Thread pool im Server Client Server System call Systemaufruf-Verteiler I/O-Manager MS-DOS file s y stem NT-file system Redirec- tor Gerätetreiber Netz- transport OS/2-file Treiber Anwenderprozeß Netz Netzwerkdienste

Dateisysteme: Sicherheitsaspekte Problem Inkonsistente Netz-Kopplung von Systemen bei unterschiedlichen Sicherheitsmechanismen ! z.B. Authentifizierung bei unterschiedlich langen Namen und Groß/Kleinschreibung Unix/WinNT vs MS-DOS, fehlende ACLs, ... Beispiel Unix NFS-Sicherheitssystem NIS Benutzerliste (yellow pages) verwaltet von NIS RPC hat Zugriffsrechte user/group/other SuperUserID=0 auf Client  UserId=-2 auf Server („external Super User“) konsist. Behandlung von gleichen NutzerIds unterschiedl. Systeme Beispiel Windows NT NT 4.0: ACL, Netzbenutzer müssen beim SAM registriert sein mit gleichem Paßwort, sonst Nachfrage bzw. Ablehnung NT 5.0: Kerberos-System bei netzweiter Zugangskontrolle Netzwerkdienste

Dateisysteme: Virtueller Massenspeicher Storage Area Network SAN asym. Pooling LAN Ortsinfo S A N file server metadata server Block I/O Ein virtueller Massenspeicher kann aus einem Netzwerk bestehen, das nicht nur die Speicherfunktionen intern organisiert, sondern auch die Zugriffsrechte, die Datensicherung (backup) und Zugriffsoptimierung (Lastverteilung, Datenmigration) selbst regelt. Konflikte gibt es dabei mit unabhängigen Untereinheiten, die selbst diese Funktionen übernehmen wollen (z.B. NAS oder SAN-in-a-box). Asymmetr. Pool: Ein Server dient als Metadaten-Server (Wo sind welche Daten) und gibt Block-I/O Informationen an die anderen Symm.Pool (3-tiers-Lösung): Die Speichergeräte sind nur mit mehreren Metadaten-Servern über ein extra Netzwerk verbunden; die Metaserver hängen über das SAN an den NAS Network Attached Storage Lun 2 Netzwerkdienste

Dateisysteme: Speichernetze Speicherkonfigurationen des Storage Area Network SAN Netzwerkdienste

Dateisysteme: Speichernetze Info SNIA-Schichtenkonzept Netzwerkdienste

Kommunikation in Netzen Netzwerke Kommunikation in Netzen Dateisysteme im Netz Arbeitsmodelle im Netz Dienste im Netz Netzwerkdienste

Arbeitsmodelle im Netz Anforderungen an Load Sharing Facility-Systeme Ausgewogene Lastverteilung verschiedener Jobarten&Leistungsklassen Zentrale Warteschlangen für Rechenzeit, Speicherbedarf, I/O-Geräte.. Jobdurchlaufzeiten minimieren Transparente Lizenzverwaltung (unabh. von RechnerId) Normaler, interaktiver Betrieb soll möglich sein Nutzung der Rechner nachts, im Urlaub, an Wochenenden.. Übersichtliche Konfiguration, leichte Wartbarkeit Netzwerkdienste

Arbeitsmodelle im Netz Probleme bei der Lastverteilung Jobübermittlung kostet Zeit (nur größere Arbeitspakete!) Datenübermittlung kostet Zeit (nur kommunikationsarmer Code!) Inhomogene Rechnerarchitekturen, inkompatibler Maschinencode (nur portabler Code!) Netzwerkdienste

Arbeitsmodelle im Netz Konzept Netzcomputer NC: HW: CPU, Hauptspeicher, Bildschirm/Tastatur,Netzanschluß SW: Nur Mikrokern, Keine Peripherie Vorteile Billigere Hardware (Anschaffung) Aktuelle Daten und Programme (zentrale Wartung) Billigere Wartung (Konfiguration, SW-Pflege, HW,..) Höhere Datensicherheit (Ausfall, Datendiebstahl,Viren..) Ressourcennutzung (Massenspeicher, Peripherie,...) Nachteile Erhöhter Netzaufwand (HW für Netz und Server) Erhöhter Pufferaufwand (RAM für Netz- und Datenpuffer, swap-Disks,...) Benutzerbevormundung (Zentrale entscheidet über Daten+Applikationen) Netzwerkdienste

Arbeitsmodelle im Netz Arbeitsverteilung durch JAVA-Applets Lastverteilung durch portablen Byte-Code Sicherheit durch Java Virtual Machine (byte code interpreter) NC-Ablaufumgebung („Betriebssystem“) der Applets Interpretation des Java Byte Code Hauptspeicherverwaltung (garbage collection) Isolierung gleichzeitig ablaufender Programme (sand box) Standardfunktionen Grafik-Ein/Ausgabe, Audiowiedergabe Kein Platten/Peripheriezugriff unsignierter Applets Browser-Ablaufumgebung Java Plug-in: applikationsabhängige Funktionserweiterung Netzwerkdienste

Arbeitsmodelle im Netz Mobile Peripherierechner bei unzuverlässigen Verbindungen Probleme Roaming Keine konstante Arbeitsumgebung für Außendienstmitarbeiter, Telearbeiter, ... bei wechselnden Arbeitsplätzen Wartung Keine Konfigurationspflege, Programmaktualisierung, Datensicherung, ... Lösungen Zentrale Aktualisierung Pro: konsistente Wartung. Contra: Nicht-einheitliche Systeme verboten Dezentrale Aktualisierung Pro: lokal angepasste Nicht-Standardfkt. Contra: arbeitsaufwändig Kernfunktionen zentral gewartet: Schattenserver! Netzwerkdienste

Arbeitsmodelle im Netz Schattenserver zur Datenhaltung Initiale Festlegung gespiegelter Pfadteile Arbeit wie ein Netzcomputer (Daten+Programm-Cache) Aktualisierung durch Cache-Snooper (Server-Schatten) Server Arbeitsplatz PC Netzwerkdienste

Arbeitsmodelle im Netz Schattenserver Vorteile Automatische Datei- und Programmaktualisierung ohne Administratoraufwand! Atomatische Datensicherung Netzunabhängiger stand-alone Betrieb möglich Benutzerangepaßte Konfiguration Rechnerunabhänge Konfiguration Geringere Wartungskosten Netzwerkdienste

Arbeitsmodelle im Netz Beispiel Linux Coda-Dateisystem Abfangen von Systemaufrufen CreateFile, OpenFile, CloseFile, RenameFile Client Server User process RPC Kernel system call Cache Manager Server process process I/O Manager File filter driver cache file Server Regular file driver system file system Hard disk Netzwerkdienste

Arbeitsmodelle im Netz Windows NT Schattenserver Deklaration von Netz-bekannten Ordnern („Freigabe“) Einrichtung als „Offline-Dateien“ Resynchronisierung („Offline-Aktualisierung“) bei login/logout. Semantik (Überschreiben, Speichern mit neuem Namen, usw.) individuell pro Datei oder einmalig für alle Dateien festgelegt. Netzwerkdienste

Kommunikation in Netzen Netzwerke Kommunikation in Netzen Dateisysteme im Netz Arbeitsmodelle im Netz Dienste im Netz Netzwerkdienste

Dienste im Netz DNS - Domain Name Service: Hierarchie der Domänen Netzwerkdienste

Dienste im Netz DNS - Domain Name Service Zuordnung IP-Nummer  Internetname 192.138.228.1 siemens.com hierarchisches System: Jeder Domäne ihr DNS (top level .de ca. 8 Stück) Beispiel Konsoleneingabe an DNS nslookup siemens.com Server:styx.rbi.informatik.uni-frankfurt.de Address: 141.2.15.5 Name: siemens.com Address: 192.138.228.1 Netzwerkdienste

Dienste im Netz FTP - File Transfer Protocol verbindungsorientiert Anzeige des Inhaltsverzeichnisses des Ordners im Dateisystem Senden einer Datei Empfangen einer Datei Umbenennen/Löschen von Dateien WWW - World Wide Web verbindungslos die „Killerapplikation“ fürs Internet, weil einheitliche Namen im Netz (URL) einfache Navigation Hyperlinks: „auf Knopfdruck“ zwischen den Seiten genormte Seitenbeschreibungssprache HTML Bilder, Audio und Video in einem gemeinsames Dokument verbindliches Protokoll (z.B. HyperText Transport Protocol HTTP) zum Transport von Dokumenten zwischen Server und Client Netzwerkdienste

Dienste im Netz EMAIL - Electronic Mail Typische Merkmale: Asynchrones, zeitlich entkoppeltes Senden und Empfangen Der Sender kann weiterarbeiten, ohne auf den Erhalt der Nachricht durch den Empfänger warten zu müssen. Die Nachrichten werden zwischengespeichert Keine direkte Verbindung zwischen Sender und Empfänger muss ex. SMTP für synchrones Senden (und Empfangen), POP für asynchr. Empfangen, IMAP für Mailbox-Dienst (virt. Ordner) NEWS - Usenet Dezentrale Diskussionsforen Name ist hierarchisch organisiert: z.B. comp.lang.c, rec.games.chess Top level: sci science-Wissenschaft soc society-Gesellschaft, Politik rec recreation-Hobbys, Essen Trinken comp computer alt alternative-Klatsch, Tratsch, Unkonventionelles Netzwerkdienste

IT-Konsolidierung ? Middleware Problem: heterogener Chaos aus Produkten und Normen Netze Sprachen Protokolle BS RechnerHW IT-Konsolidierung ? Netzwerkdienste

Middleware Mögliche Lösung: Monokultur Probleme: - teuer - dauert lange, um alles zu implementieren - Firmenabhängigkeit Bessere Lösung: VermittlungsSW „Middleware“ Netzwerkdienste

Middleware Kommunikation Middleware setzt direkt auf Transportprotokollen auf: Applikationen werden unabhängig vom Transportprotokoll Netzwerkdienste

Middleware und 3-tiers System 3-Schichten-System (SAP/R3) Middleware mittlere Schicht = Middleware Netzwerkdienste

Middleware-Arten Spezielle Anwendungen Allgemeine Dienste Dateitransfer Fernzugriff auf gemeinsame Dateien Datenbankzugriff Datenzugriff auf entfernte DB Transaktionsverarbeitung Koordination verteilter Transaktionen Groupware Zusammenarbeit in Gruppen Workflow Organisation arbeitsteiliger Prozesse Allgemeine Dienste Virtual Shared Memory: Zugriff auf virtuell gemeinsamen Speicher Remote Procedure Call (RPC) Aufruf einer entfernten Prozedur Message Passing Send/Receive–Kommunikation Object Request Broker Dienstvermittlung im Netz Netzwerkdienste

Dienstvermittlung im Netz CORBA = Common Object Request Broker Architecture Dienstvermittler Aufgaben Initiale Registrierung aller Dienste im Netz Registrierung einer Anfrage Ermitteln des passenden Servers Übermitteln des Auftrags + Parameter Übermitteln des Ergebnisses Auftragsabschluß Referenzimplementierung durch Object Management Group OMG 1989 Problem: langsam! Netzwerkdienste

Dienstvermittlung im Netz Die sieben Trugschlüsse verteilter Anwendungen Das Netzwerk ist immer verfügbar Die Wartezeit (engl. latency) ist Null Die Übertragungsrate (Bandbreite) ist unendlich groß Das Netzwerk ist sicher Der Aufbau des Netzwerks ändert sich nicht Es gibt nur einen Administrator Es fallen keine Transportkosten an Gegenkonzept: Jini Java Intelligent Network Infrastructure Netzwerkdienste

Dienstvermittlung im Netz Java-Technologie Jini Code-Mobilität Protokoll-unabh. Programme Flexibilität & Integration der Netzknoten mit RMI Leasing: Automat. Rekonfiguration des Netzwerks Anwendung: Thin client/Thick Server Jini TP = Transaktions-Processing Monitor für Banken Legacy = Altanwendungen In Java Beans sind bereits Object Transaction Monitore enthalten Netzwerkdienste

Dienstvermittlung im Netz Microsoft Middleware COM binäre Schnittstellendef. für IPC auf selbem Rechner DCOM verteiltes COM im Netz (RPC und MS-IDL) COM+ DB-Anwendung mit Transaction Server MTS incl. Lastverteilung, DB-Cache, async. Aufrufe .NET Programmier- + Laufzeitumgebung für ORB & uPnP Netzwerkdienste

Service-Orientierte Architektur SOA Problem: Viele alte, teuer zu wartende Dienste Lösung: Kapselung durch Middelware-Ansatz Die Dienste implementieren bei fest definierten Funktionszusicherungen bestimmte Leistungen, ohne dabei anzugeben, auf welche Art dies geschieht. Gemeinsames Kommunikationsprotokoll Ihr Aufruf wird durch einen für alle Module einheitlichen, losen (d.h. nachrichtenbasierten) Kommunikations­mechanismus (SOA-Protokoll SOAP) sichergestellt. Voraussetzung: Modellierung der Geschäftsprozesse (OASIS 06) Grafik, Regeln ("Business Process Management" BPM) Spezifikationen ("Business Process Execution Language" BPEL) OASIS Oktober 2006 Version 1.0 Referenzmodell SOA-RM Netzwerkdienste

Software-Busstruktur der SOA Beispiel: Handelsprozess durch Enterprise Service Bus (IBM) Asynchrone Abwicklung einer Bestellung order Manage-ment service service interface XML transform service service interface compliance service service interface Han-del service service interface Abrechnung service service interface logging service service interface http- Nachrichten (request/reply) Netzwerkdienste

Beispiel: Web Services WOA veröffentlichen entdecken entdecken Web services standards One of the key attributes of Internet standards is that they focus on protocols and not on implementations. The Internet is composed of heterogeneous technologies that successfully interoperate through shared protocols. This prevents individual vendors from imposing a standard on the Internet. Open Source software development plays a crucial role in preserving the interoperability of vendor implementations of standards. The following standards play key roles in Web services: Universal Description, Discovery and Integration (UDDI), Web Services Description Language (WSDL), Web Services Inspection Language (WSIL), SOAP, and Web Services Interoperability (WS-I). The relationship between these standards is described in the Figure. The UDDI specification defines open, platform-independent standards that enable businesses to share information in a global business registry, discover services on the registry, and define how they interact over the Internet. For more information on UDDI, refer to www.uddi.org WSIL is an XML-based open specification that defines a distributed service discovery method that supplies references to service descriptions at the service provider's point-of-offering, by specifying how to inspect a Web site for available Web services.  A WSIL document defines the locations on a Web site where you can look for Web service descriptions. Since WSIL focuses on distributed service discovery, the WSIL specification complements UDDI by facilitating the discovery of services that are available on Web sites that may not be listed yet in a UDDI registry. A separate topic in this documentation discusses the Relationship between UDDI and WSIL.  For more information on WSIL, refer to www.ibm.com/developerworks/webservices/library/ws-wsilspec.html WSDL is an XML-based open specification that describes the interfaces to and instances of Web services on the network. It is extensible, so endpoints can be described regardless of the message formats or network protocols that are used to communicate. Businesses can make the WSDL documents for their Web services available though UDDI, WSIL, or by broadcasting the URLs to their WSDL via email or Web sites. WSDL is described as a separate topic in this documentation. For more information on WSDL, refer to www.w3.org/TR/wsdl SOAP is an XML-based standard for messaging over HTTP and other Internet protocols. It is a lightweight protocol for the exchange of information in a decentralized, distributed environment. It is based on XML and consists of three parts: An envelope that defines a framework for describing what is in a message and how to process it. A set of encoding rules for expressing instances of application-defined data types. A convention for representing remote procedure calls and responses. SOAP enables the binding and usage of discovered Web services by defining a message path for routing messages. SOAP may be used to query UDDI for Web services. For more information on SOAP 1.1 (SOAP 1.2 is not supported by the Web services tools), refer to www.w3.org/TR/SOAP Figure 2. Relationships between SOAP, UDDI, WSIL and WSDL. A service provider hosts a Web service and makes it accessible using protocols such as SOAP/HTTP or SOAP/JMS. The Web service is described by a WSDL document that is stored on the provider's server or in a special repository. The WSDL document may be referenced by the UDDI business registry and WSIL documents. These contain pointers to the Web service's WSDL files. The WS-I Simple SOAP Binding Profile and WS-I Attachments Profile are outlines of requirements to which WSDL and Web service protocol (SOAP/HTTP) traffic must comply in order to claim WS-I conformance. The Web services WS-I validation tools currently support WS-I Simple SOAP Binding Profile 1.0 and the Attachment Profile 1.0. To view the specifications, refer to the WS-I Web site, and under Resources select Documentation: http://www.ws-i.org Several new Web services standards are also supported by Rational® Developer products. These include: JAX-RPC JAX-RPC stands for Java™ API for XML-based RPC, also known as JSR 101. It is a specification that describes Java Application Programming Interfaces (APIs) and conventions for building Web services and Web service clients that use remote procedure calls (RPC) and XML. It standardizes the Java to WSDL and WSDL to Java mappings, and provides the core APIs for developing and deploying Web services and Web service clients on the Java platform. For more information refer to the official specifications. JSR-109 and JSR-921 JSR-109 and JSR-921 (Implementing Enterprise Web Services) define the programming model and run-time architecture to deploy and look up Web services in the J2EE environment; more specifically, in the Web, EJB, and Client Application containers. One of its main goals is to ensure vendors' implementations interoperate. For more information, refer to the official specifications: JSR-109 JSR-921 WS-S These tools support the OASIS Web Services Security 1.0 standard. For more information on the various components of this standard, refer to: Web Services Security: SOAP Message Security V1.0 Web Services Security: Username Token Profile V1.0 Web Services Security: X.509 Token Profile V1.0 Web services tooling supports the following specifications: Technology or specificationVersion or level supportedTransportsHTTP/HTTPSv1.0 and v1.1JMS MessagingSOAP specificationv1.1SOAP Attachements DescriptionUDDIv2.0WSDLv1.1WSILv1.0SecurityWS-SecurityOASIS Standard 1.0IneroperabilityWS-I Basic Profile1.1.2WS-I Simple SOAP Binding Profile1.0.3WS-I Attachments Profile1.0Other Standards JAX-RPCv1.0 for J2EE 1.3, v1.1 for J2EE 1.4JSR 109J2EE 1.3JSR 921J2EE 1.4 Netzwerkdienste

SOA Anforderungen robuste, skalierbare Datenübertragung Kapselung der Services: Keine inkompatiblen Protokolle, Datenformate, Interaktionsmuster der Legacy-, Java-, .NET-Applikationen Serviceorchestrierung: Modellierung der Geschäftsprozesse und Abbildung auf services Verteilte Services: unabhängige Installation, Skalierung, Konfigurierung Zentrale Installation, Administration, Überwachung, Wartung der Services Gemeinsame Datenformate (XML): einheitliche Weiterverarbeitung, Dokumentation, Auditing möglich Netzwerkdienste

Middleware Vorteile SOA Neue oder geänderte Geschäftsprozesse können schneller und damit preisgünstiger durch Kombination bestehender Dienste realisiert werden. Durch die Modularisierung, klare Aufgabentrennung und Funktionskapselung werden die Systeme beherrschbarer und leichter wartbar. Damit ist auch eine Auslagerung unwirtschaftlicher Teile an Fremdanbieter (outsourcing) wird durch die Modularisierung leichter möglich. Bewährte, ältere Systeme können weiter genutzt werden, ohne Neuentwicklungen zu blockieren oder sie mit Kompatibilitäts- forderungen zu belasten (Investitionsschutz). Die älteren Einzeldienste können dann Stück für Stück durch moderne Versionen (z.B. Hardware-Software-Kombinationen) ersetzt werden. Netzwerkdienste