next up previous contents
Next: 3.5.4 Open Distributed Management Up: Das Referenzmodell für Open Previous: Computational Object Template

3.5.3 Engineering Viewpoint

  Der Engineering Viewpoint im RM-ODP beschäftigt sich mit den Konzepten, die für eine verteilte Plattform erforderlich sind, um den im Computational Model spezifizierten verteilten Anwendungen eine Systemunterstützung bieten zu können. Er legt das Augenmerk auf die Frage, wie die Objektinteraktionen aus dem Computational Model erreicht werden können und welche Ressourcen dafür gebraucht werden. Hierzu werden Infrastrukturobjekte bereitgestellt, die Mechanismen für die Kommunikation zwischen Objekten und für die Unterstützung von Orts- und Verteilungstransparenz realisieren. Es gibt aber keine Beschränkung auf bestimmte Maschinenarchitekturen wie z.B. RISC, Betriebssysteme (UNIX) oder Kommunikationsprotokolle (TCP/IP). Vielmehr handelt es sich um ein maschinenunabhängiges Modell eines erweiterten verteilten Betriebssystems für vernetzte Rechner.

Im folgenden werden zunächst die Infrastrukturobjekte, die der Engineering Viewpoint beschreibt, vorgestellt.

Die verteilte Plattform des ODP Engineering Model besteht aus einer Anzahl vernetzter autonomer Rechner, den sog. Nodes. Der Nucleus kontrolliert die Rechen-, Speicher- und Kommunikationsressourcen eines Nodes und kann daher mit dem Betriebssystem eines Rechners gleichgesetzt werden. Ein Node beherbergt genau einen Nucleus und mehrere Capsules. Mit Capsule wird das Konzept des traditionellen geschützten Prozesses in einem Rechner beschrieben. Ein Capsule besitzt seinen eigenen Adressraum und nutzt Teile der Speicher- und Rechenressourcen, die der Nucleus verwaltet. Der Adressraum des Capsule wird durch das Betriebssystem geschützt. Außerdem stellt es die kleinste Einheit für unabhängiges Fehlverhalten dar. Ein Capsule wiederum setzt sich aus ein oder mehreren Clusters von Basic Engineering Objects zusammen. Die Objekte des Computational Model werden zur Laufzeit durch Basic Engineering Objects realisiert. Die Vorstellung für einen Cluster ist ein Segment des virtuellen Speichers, welches Objekte einer Anwendung enthält. Ein Basic Engineering Object ist ein Modul eines Programms, welches nicht isoliert ausgeführt werden kann. Ein Cluster verbindet mehrere solcher Module (linked modules) zu Einheiten, um daraus ein ausführbares Programm zu bilden. Die beschriebene Enthaltenseinshierarchie des Engineering Viewpoints wird durch die Abbildung 3.13 verdeutlicht.


 
Abbildung 3.13:  ODP Engineering Model
20#20

Weiterhin definiert das Engineering Model Kommunikationskanäle ( Channels), welche die Bindungen aus dem Computational Model darstellen. Im Computational Viewpoint können Objekte, deren Computational Interfaces aneinander gebunden sind, Interaktionen eingehen. Zu jedem Computational Interface gibt es genau ein Engineering Interface, also eine in einem realen System identifizierbare Schnittstelle. Zum Instantiierungszeitpunkt eines Engineering Interface vergibt der Nucleus einen innerhalb einer bestimmten Domäne (Engineering Interface Reference Management Domain) eindeutigen Identifikator, die sog. Engineering Interface Reference. Anhand dieser Referenz kann ein Objekt eine verteilte Bindung eingehen. Besitzt also ein Objekt die Referenz einer Schnittstelle eines anderen Objekts, kann von den beteiligten Nucleus-Objekten ein Channel zwischen den Objekten aufgebaut werden, unter der Bedingung, daß die zugehörigen Computational Interfaces vom selben Typ sind.

Channels werden nur für Bindungen zwischen Objekten benötigt, die sich in Capsules unterschiedlicher Nodes befinden. Lokale Bindungen ( local bindings) zwischen Objekten im selben Cluster oder Capsule bzw. zwischen Objekten zweier Capsules im gleichen Node sind nicht Gegenstand der Standardisierung von ODP. Diese Art der Interprozeßkommunikation soll aus Gründen der Performance durch den Compiler oder mit Mitteln des Betriebssystems (z.B. durch shared memory) realisiert werden. Ein Beispiel für einen Kanal zwischen zwei verteilten Objekten wäre eine Verbindung auf Schicht sieben des OSI Referenzmodells.


 
Abbildung 3.14:  Generischer Aufbau eines Channel
21#21

Der Aufbau eines Kanals ist in Abbildung 3.14 dargestellt. Einer der Hauptgründe, warum Kanäle im RM-ODP genau spezifiziert werden, ist das Ziel, verschiedene Transparenzen in der verteilten Umgebung einführen zu können. Hierzu gehören u.a. Orts-, Migrations- und Replikationstransparenz. Diese Konzepte benötigen ein mächtiges Kommunikationsmodell. Ein Channel im RM-ODP setzt sich aus speziellen Engineering Objects zusammen, die diese Transparenzen realisieren sollen.

Stubs sind die Objekte in einem Kanal, die direkt mit den zu verbindenden Basic Engineering Objects interagieren. Sie sind abhängig vom Typ der unterstützten Schnittstelle. Bei einem Operation Interface übernehmen sie beispielsweise das Ein- und Auspacken der Parameter eines Prozeduraufrufs (marshalling). Binders sichern die Ende-zu-Ende-Integrität des Kanals. Neben dem Aufbau der Bindungen und der Fehlersicherung sorgen sie gemeinsam mit Unterstützungsobjekten, z.B. ein Verzeichnisdienst, außerhalb des Kanals für die Bereitstellung der angesprochenen Verteilungstransparenzen. Protokollobjekte realisieren das Transportsystem für den Kommunikationskanal mit einer ausreichenden Dienstgüte und Verläßlichkeit. Falls sich die zu verbindenden Objekte in unterschiedlichen Domänen technischer oder organisatorischer Art befinden, ist möglicherweise zusätzlich ein sog. Interceptor notwendig, der Format- und Protokollkonversionen durchführt oder Sicherheits- und Zugangskontrollen realisiert. Kanäle sind nicht auf Punkt-zu-Punkt-Verbindungen wie in der Abbildung beschränkt; das RM-ODP definiert auch Multicast-Verbindungen.


next up previous contents
Next: 3.5.4 Open Distributed Management Up: Das Referenzmodell für Open Previous: Computational Object Template
Copyright Munich Network Management Team