Die Community zu .NET und Classic VB.
Menü

COM als Middleware - Seite 3

 von 

1.3 Middleware-Architekturen
Nächste Seite >>
1.1 Definition des komponentenbasierten Ansatzes
<< Vorherige Seite

1.2 Notwendigkeit von Middleware  

Wie aufgezeigt sind Komponenten ohne Framework durch differente Programmiersprachen, Plattformen etc. physisch voneinander getrennt und bedürfen daher für die Zusammenarbeit eines geeigneten Verbindungs- und Kommunikationskonzeptes [Engl. Gluing, Klebstoff]. Lösung bietet hier die Implementierung einer einfachen Transfersoftware, die es ermöglicht komponentenspezifische Datenstrukturen und Schnittstellen so zu konvertieren, dass sie vom jeweiligen Kommunikationspartner interpretierbar sind:


Abbildung 1: Komponentenkommunikation mit Transfersoftware

Es ergibt sich ein nur schwer verwaltbares Netzwerk mit einer Vielzahl individueller Einzelknoten an denen je eine spezifischen Transfersoftware der jeweils anderen zuarbeitet. Das Konzept der Middleware hingegen löst dieses Problem, indem sie die Schnittstellen der Knoten standardisiert und eine universelle Kommunikationsschicht als integralen Dienst offen legt:


Abbildung 2: Komponentenkommunikation mit Middleware

Somit bietet Middleware ein idealeres und logischeres Fundament für verteilte Applikationen an. Der Entwickler erhält während der Erstellung dynamisch verteilter Anwendungen hier eine deutlichere Unterstützung. Komponenten lassen sich ohne tiefere Kenntnisse der Netzwerkkommunikation erstellen. Gängige Middleware offeriert neben dem standardisierten Gluing meist weitere oft benötigte Dienste:

Lebenszyklus Generierung und Terminierung der Instanzen einer Komponente.
Naming Verwaltung von Instanzen einer Komponente sowie deren logische namentliche Zuordnung, bzw. Referenzierung in beispielsweise hierarchischer Form.
Konsistenz Gewährleistung der Zustandserhaltung von Instanzen einer Komponente während ihres Lebenszyklus.
Persistenz Zustandserhaltung von Instanzen über deren Terminierung hinaus.
Transaktion Ordnungsgemäße Durchführung von Transaktionen zwischen Objekten.
Sicherheit Identifikation, Autorisierung, Vertraulichkeit, Verschlüsselung.
Nachrichten Benachrichtigungsdienst für Ereignisse und asynchrone Kommunikation zwischen Objekten.
Trading Verzeichnisdienst, Beschreibung der Eigenschaften von Diensten.
Licensing Lizensierung von Komponenten.

Die erhöhte Verfügbarkeit von Middleware unterstreicht die Tendenz der Abkehr von der zentralen, hin zur verteilten Informationsverarbeitung. Anwendungen beschränken sich nicht mehr notwendigerweise auf einen Rechner, sondern können nun ein komplexes Netz aus Diensterbringern und Dienstnehmern bilden. Eine solche Struktur ist unter dem Begriff Client-Server-Architektur geläufig:

Middleware stellt Anwendern einheitliche Dienste über Standardschnittstellen zur Verfügung, die die Verteilung von Applikationen auch rechnerübergreifend unterstützen; die notwendige Kommunikation ist transparent. Eine Middleware bildet unabhängig vom Betriebssystem und Netzwerk eine Kommunikationsinfrastruktur mit einem eigenem Protokoll. Middleware dient als Bindeglied [Glue] in Client-Server-Architekturen vernetzter Systeme.
Clients sind eigenständige Applikationen, die im allgemeinen so konzipiert sind, dass sie Dienste respektive Aufgaben auf einem Server initiieren bzw. an ihn delegieren können. Client-Prozesse lassen sich dynamisch sowohl erzeugen, als auch zerstören. Üblicherweise sind Clients im Gegensatz zu Servern eher kurzlebige Objekte.
Server sind Subsysteme, welche einem oder mehreren Clients Dienste zur Verfügung stellen, bzw. Aufgaben für sie erledigen. Ein Server stellt eine Menge von Operationen [Prozeduren / Methoden] einer meist zuvor unbekannten Anzahl von Clients in einem kontinuierlich ablaufenden Prozess lokal als auch verteilt zur Verfügung. Üblicherweise sind Server langlebige Objekte.

Die wesentlichen Vorteile einer Client-Server-Architektur im Zusammenspiel mit einer Middleware liegen in folgenden Aspekten:

Lastverteilung: Die erforderliche Rechenleistung für eine in die Menge n unterteilbaren Dienste, muss nicht unbedingt auf einem System erbracht werden, sondern kann auf n heterogene Systeme verlagert sein. Dies reduziert die Anfragezeit und erhöht die potentielle Anfragedichte.
Skalierbarkeit: Ändert sich die Anzahl der Dienstnehmer oder sollen weitere Dienste hinzugefügt oder entfernt werden, so lässt sich ein Netz insgesamt flexibler auf die neuen Anforderungen skalieren.
Ausfallsicherheit Die Zuverlässigkeit erhöht sich im Gegensatz zum zentralen System. Der Ausfall einer Komponente führt nicht zwangsläufig zum vollkommenen Systemausfall. [Gracefull Deregulation]
Reorganisation: Existente Systeme sind ohne elementare Umstrukturierung an neue oder differente Systeme koppelbar. Durch den Erhalt vorhandener Infrastruktur wird so beispielsweise ein Investitionsschutz gewährleistet.

Da sich die Anwendungsbereiche für Software erweitern und der Bedarf nach verteilten Lösungen steigt, gewinnt der Einsatz von Middleware perspektivisch mehr Bedeutung. Hierbei ist die konzeptionelle Middleware eine nicht erreichte Zielvorstellung. Die derzeitigen gängigen Umsetzungen der Terminologie bergen durchaus Nachteile und Einschränkungen. So ist immer noch ein sehr spezialisiertes Verständnis der verwendeten Middleware und des zugehörigen Komponentenmodells erforderlich. Die theoretisch garantierte Plattform- und Sprachenunabhängigkeit, führt praktisch oft zu Problemen, da das Middlewareideal nicht immer vollständig erreicht wurde und sich oft erst unter einer speziellen Konfiguration aus Betriebssystemen und Programmiersprachen vollständig entfalten lässt.

Nächste Seite >>
1.3 Middleware-Architekturen
<< Vorherige Seite
1.1 Definition des komponentenbasierten Ansatzes