3 - J (suc2)
3 - J (suc2)
3 - J (suc2)
Kartei Details
Karten | 54 |
---|---|
Sprache | Deutsch |
Kategorie | Scherzfragen |
Stufe | Grundschule |
Erstellt / Aktualisiert | 07.01.2014 / 15.01.2014 |
Weblink |
https://card2brain.ch/box/3_j_suc2
|
Einbinden |
<iframe src="https://card2brain.ch/box/3_j_suc2/embed" width="780" height="150" scrolling="no" frameborder="0"></iframe>
|
Lernkarteien erstellen oder kopieren
Mit einem Upgrade kannst du unlimitiert Lernkarteien erstellen oder kopieren und viele Zusatzfunktionen mehr nutzen.
Melde dich an, um alle Karten zu sehen.
vorteil Middleware
wird für den Anwendungsentwickler die Umsetzung der Kommunikation einfacher, wobei
alle Aspekte der Netzwerkprogrammierung so weit wie möglich (und sinnvoll) von der verteilten Anwendung verborgen werden
Der Anwendungsentwickler kann sich auf die Lösung des eigentlichen Anwendungsproblems konzentrieren
aufgaben der middleware !!!
abschirmung von netzwerksachen (protokollen, übertragungsfehler, ereignissen..)
Ortstranzparenz (server und client haben das gefühl lokal zu kommunizieren)
Kommunikationsprotokolle:(ist sache der middleware...)
Computer-Hardware (unterschiede neutralisieren)
Betriebssysteme (unabhängig)
Programmiersprachen (unabhängig)
Middleware-Kategorien
Kommunikationsorientierte Middleware KOM
Anwendungsorientierte Middleware AOM
Kommunikationsorientierte Middleware (KOM)
KOM konzentriert sich auf die Bereitstellung einer geeigneten Kommunikationsinfrastruktur für Komponenten einer verteilten Anwendung
Aufgaben: Kommunikation
Marshalling und Unmarshalling
Fehlerbehandlung bzw. Fehlerbehebung
Kommunikationsorientierte Middleware (KOM)
Aufgaben
Heterogenität in der Hardware:
Heterogenität der Programmiersprachen
Fehlerbehandlung bei der Übertragung
Kommunikationsorientierte Middleware (KOM) - Architektur
Das Programmiermodell ist die Sicht des Entwicklers auf die Architektur definiert, wie die Architektur zur Entwicklung der Anwendung zu verwenden ist
Es wird zwischen drei Programmiermodelle unterschieden:
Entfernte Prozeduraufrufe (RPC)
Entfernte Methodenaufrufe (CORBA, RMI)
Das nachrichtenorientierte Modell (MOM)
Anwendungsorientierte Middleware (AOM)
AOM stellt eine Erweiterung der KOM dar, die n eben reiner Kommunikation eine Reihe zusätzlicher Dienste der verteilten Anwendung zur Verfügung stellt
Konzeptionell stellt die anwendungsorientierte Middleware eine kommunikationsorientierte Middleware, welche um Laufzeitfunktionalität und Dienstkomponenten erweitert wurdeAOM: Ressourcenverwaltung
Das Ziel der Ressourcenverwaltung ist die Verbesserung von Performance, Skalierbarkeit und Verfügbarkeit von Anwendungen
AOM: Nebenläufigkeit
In der Regel werden verteilte Anwendungen von mehreren Anwender parallel benutzt
Um diese Parallelität zu gewährleisten werden die Aufrufe isoliert in separaten, nebenläufigen Threads oder Prozessen abgearbeitet
AOM: Verbindungsverwaltung
Ein Lösungsansatz ist die Verwaltung einer Anzahl von Verbindungen (auf Vorrat) in einem Pool
AOM: Verfügbarkeit
Je nach Verfügbarkeitsanforderungen, sehen die Lösungen unterschiedlich aus (Redundanz)
AOM: Sicherheit
Zugriffskontrolle (Authentifizierung), womit die Sicherstellung der Identität des Benutzers gemeint ist und
Vergabe von Zugriffsrechten (Autorisierung), womit die Benutzungsrechte für bestimmte Dienste an die Benutzer vergeben werden
AOM: Verschiedene Dienste:
Namensdienst
Sitzungsverwaltung (Sessionhandling)
Transaktionsverwaltung (Datenkonsistenz, ACID)
Persistenz
AOM: Technologien
Object Request Broker (ORB)
Application Server (AS)
Middleware-Plattformen
Applikation
<Interprozesskommunikation>
Eine Applikation besteht aus einem oder mehreren Prozessen
Prozesse
<Interprozesskommunikation>
sind Objekte des Betriebssystems
ermöglichen einer Anwendung den sicheren Zugriff auf die Ressourcen des Betriebssystems
laufen in eigenem Speicherbereichen und sind dadurch voneinander isoliert
Für den Austausch von Daten zwischen Prozessen ist eine Interprozesskommunikation nötig
IPC (InterProcessCommunication)
<Interprozesskommunikation>
IPC basiert auf dem Austausch von Nachrichten und Daten zwischen Prozessen:
IPC kann unterschiedlich umgesetzt werden
über Dateien
über Pipes (nur lokal)
über Sockets (sowohl lokal als auch entfernt)
mit Hilfe einer Middleware
Kommunikationsmodel
<Interprozesskommunikation>
Kommunikationsmodel legt das Protokoll für den Ablauf der Kommunikation zwischen Prozessen (IPC) fest
synchroner Kommunikation und
asynchroner Kommunikation
Synchrone Kommunikation
<Interprozesskommunikation>
Vorteile
Eher einfacher zum Implementieren
Synchronisation beim Zugriff auf gemeinsame Ressourcen gleich erledigt
Nachteile
zum Teil ineffizient (das Warten)
braucht sichere und schnelle Netzwerkverbindung
Empfängerprozess muss verfügbar sein
enge Kopplung zwischen Sender und Empfänger
Asynchrone Kommunikation
Realisierung mittels Warteschlangen
<Interprozesskommunikation>
Vorteile
lose Kopplung von Prozessen geringere Fehlerabhängigkeit der Empfänger muss nicht empfangsbereit sein effizienter (kein Warten)
Nachteile
aufwendiger bzw. komplizierter in der Implementierung (Warteschlangen) komplizierte Protokolle nicht immer sinnvoll
verteiltes System läuft in der Regel in einer heterogenen Umgebung
<Interprozesskommunikation>
unterschiedliche Hardwarearchitekturen
unterschiedliche Betriebssysteme (Plattformen)
unterschiedliche Programmiersprachen
Damit die Komponenten des verteilten Systems miteinander kommunizieren können, müssen sie alle ein gemeinsames Format für Daten benutzen
Marshalling
<Interprozesskommunikation>
Unter marshalling versteht man die Transformation einer beliebigen Nachricht in eine übertragbare Nachricht, wobei
die Datenstruktur in eine zusammenhängende Nachricht "planiert" wird und
die zu sendenden Daten aus dem lokalen in das gemeinsame Format übersetzt werden
Daraus resultiert ein Strom von bytes, welcher übertragen werden kann: eine übertragbare Nachricht
Unmarshalling
<Interprozesskommunikation>
Auf der Seite des Empfängers müssen die empfangenen Daten aus dem gemeinsamen Format in das lokale Format des Empfängers übersetzt werden
Dieser Prozess wird unmarshalling genannt
Unmarshalling wird immer auf der Seite des Empfängers ausgeführt
IPC mit sockets
<Interprozesskommunikation>
Vorteile:
direkte Kontrolle aller Transportparameter grössere Flexibilität bei der Entwicklung neuer Protokolle bessere Performance
Nachteile
die Datenrepräsentation wenig komfortable Entwicklung von Anwendungen
IPC mit Netzwerkprogrammierung mit Middleware
<Interprozesskommunikation>
Middleware ist eine zusätzliche Schicht, die sich zwischen Transportschicht (TCP/UDP) und Anwendung befindet
Vorteile
Bequeme Entwicklung von Anwendungen Lösung des Datenrepräsentationsproblems Evtl. weitere Dienste „von Haus aus“ verfügbar
Nachteile
Ein (unter Umständen grosser) Overhead muss in Kauf genommen werden Schlechtere Performance im Vergleich zu Socket-Programmierung
Local Procedure Call (LPC)
<Interprozesskommunikation>
Aufruf einer Prozedur, welche sich im gleichen Speicherraum (Prozess) befindet
Keine Interprozesskommunikation mit LPC möglich
vorteile / nachteile LPC
<Interprozesskommunikation>
Vorteile:
Bessere Performance, da alle Prozeduren im gleichen Prozess bzw. Speicherraum
Zuverlässige Kommunikation
Einfachere Parameterübergabe, da lokaler Stack für alle Prozeduren gemeinsam und verfügbar
Einfacher Zugriff auf gemeinsame Daten, da alle Prozessdaten gemeinsam
Nachteile:
Keine Interprozesskommunikation möglich Folie
Remote Procedure Call (RPC)
<Interprozesskommunikation>
RPC steht für den "entfernten Aufruf von Prozeduren„
Mit "entfernt" ist eine Prozedur gemeint, welche
in einem anderen Prozess ausgeführt wird bzw.
sich in einem anderen Speicherraum befindet
Stellt eine Art der Interprozesskommunikation
Die kommunikationswillige Prozesse können
auf dem gleichen System oder
auf unterschiedlichen Systemen ausgeführt werden
LPC vs. RPC
<Interprozesskommunikation>
LPC ist einfacher zu implementieren, da sich die ganze Kommunikation (Nachrichtenaustausch) in einem gleichen Speicherraum (gleicher Prozess) abspielt
RPC ist weniger performant Kommunikation erfolgt in Form von Nachrichten, welche von einem zu anderem Prozess übertragen werden Parameter, welche übergeben werden müssen, müssen in die Nachricht passend verpackt werden
RPC ist komplexer in der Implementierung, da zusätzliche Protokolle für das Senden von Nachrichten benötigt
-
- 1 / 54
-