Diese Objekte/Komponenten werden auf Rechnernetze verteilt, somit entstehen verteilte Systeme mit CORBA. Natürlich sollten diese Objekte eine gewisse Granularität haben um sie vernünftig verteilen zu können. Aus Leistungsgesichtspunkten und auch anwendungsmotiviert werden Komponenten auch auf einem Rechnerknoten platziert, diese kommunizieren mit leichtgewichtigen Fern-Prozeduraufrufen (LRPC)
Moderne Kleinkernarchitektur bietet effiziente Kommunikationsmechanismen, um die objekt/komponenten orientierte Sichtweise zu unterstützen, beispielsweise ist im L4-Kern ein LRPC doppelt so schnell wie ein herkömmlicher UNIX-Systemcall.
Verteilte Anwendungen setzen nicht mehr auf die Socket-Schnittstelle des Betriebssystems auf, sondern nutzen Middleware wie CORBA und höhere Dienste.
Diese Middleware soll nun besser und effizienter mit dem L4-Kern implementiert werden.
Die Kunden haben damit den Vorteil, daß sie mit CORBA eine normierte und investitionssichere Schnittstelle haben, die aktuellen Technologieen angepaßt werden kann.
|
|
Auf Linux wurde schon mit verschiedenen Segmenttypen experimentiert. Diese Segmente entsprechen einem Dataspace bei DROPS
Der Nutzer hätte den Vorteil, daß er zur Konfigurationszeit verschiedene Speichermechanismen festlegen könnte. Die Programmierung sollte sich nicht zu sehr unterscheiden, näheres soll untersucht werden.
Das Corba Component Modell kann mit verschiedenen IDL Erweiterungen ganze Applikationen spezifizieren. Darunter gibt es auch eine Sprache, die die Persistenz beschreibt. Diese könnte dann u.a. auch auf unsere Segmente abgebildet werden.
Interessant ist, welche Betriebssystemunterstüzung Mechanismen in Programmiersprachen benötigen.
Der C++-Exception Mechanismus könnte direkt minimal auf der L4-Umgebung laufen. Die Implementierung im gcc macht aber Berechnungen zur Laufzeit, die man eigentlich nicht in
Bootservern haben möchte. Die Erfinder hatten wohl an ein UNIX-ähliches System gedacht. Eine optimalere Implementierung verbessert dann auch die der traditionellen Systeme.
Gerade wegen der Investitionssicherheit ist es sehr wichtig, architekturunabhängig auf einer höheren Ebene zu Programmieren.
Systemprogrammiersprachen bauen möglichst wenig in die Sprache selber ein, und bieten Abstraktionsmechanismen, die sogar Sachen wie Threads in der Sprache formulieren zu können.
Bibilotheken wie ACE wrappen nach dem Wrapper Entwurfsmuster über das Betriebssystem. Daher sind solche Systeme auch spezialisierten Implementierungen vorzuziehen. Natürlich sind auch diese Systeme mit der Klein/Microkernarchitektur kritisch zu überprüfen.
Mit der Echtzeitfähigkeit des L4-Kerns ist so ein Desktopsystem auch sicher hervorragend für Multimedia gegeignet - und somit Endnutzerfähig. (Bemerkung: Das ist nur so eine Idee von mir - aber ich bin ja nicht allein auf der Welt und politisch verkauft sich diese Idee auch sicher besser :-)