next up previous contents
Next: Beispielmodellierungen Up: Repräsentation der Managed Objects Previous: Repr"asentation der physischen Komponenten

Repr"asentation der logischen Komponenten

Bei Betrachtung der folgenden logischen Komponenten f"allt ins Auge, dass dem Attribut Name im Normalfall eine Schl"usselrolle zugewiesen wird; lediglich das LogicalDevice erh"alt einen eigenen Schl"ussel, DeviceID .

Die Schl"ussel Name bzw. DeviceID sollen, vergleichbar mit dem Schl"ussel Tag der physischen Elemente, der Namensgebung Name-der-Klasse_Hostname_ID folgen, es sei denn, das Format wird eigens durch ein Attribut NameFormat spezifiziert. Die IDs werden auch hier eindeutig sein.

Dar"uber hinaus besitzen alle logischen Komponenten Attribute zur Erfassung des PrimaryOwner und des PrimaryOwnerContact .

Abbildung 4.3 gibt weiteren Aufschluss "uber die Klasse ComputerSystem , welche ein Computersystem im Allgemeinen repr"asentiert, d.h. ein Layer-3-Switch wird durch einer Instanz der Klasse ComputerSystem repr"asentiert, ebenso wie ein Router, eine Firewall oder ein Fileserver.


 
Figure 4.3:   Managed Object ComputerSystem

Abbildung 4.4 zeigt ein LogicalDevice . Hierbei lä"st eine Auspr"agung dieser Klasse mit einem Systemdevice vergleichen. So wird beispielsweise das Linux Networkdevice eth0 mit einer Instanz dieser Klasse repr"asentiert. Daher ist ein LogicalDevice nicht zwingend notwendig, beispielsweise besitzt ein Layer 3 Switch keine Instanz eines LogicalDevice . Wie bereits angedeutet erhält ein LogicalDevice neben Name das Schl"usselattribut DeviceID .


 
Figure 4.4:   Managed Object LogicalDevice

Die nachfolgende Zeichnung 4.5 stellt einen Service dar. Damit wird jener Teil Software bezeichnet, welcher f"ur die Kommunikation mit der Hardware zust"andig ist. Service meint also beispielsweise einen Ethernet-Service oder dergleichen.

Dar"uber hinaus leitet sich von dieser Klasse VLANService und SwitchService ab. Ein VLANService entscheidet, welcher Port welchem VLAN angehört, ein SwitchService ist f"ur das Durchleiten der Pakete erforderlich.

Wohl an dieser Stelle sollte auf eine Problematik hingewiesen werden. In unserem Modell wird ein Hub (also ein Multiport-Repeater) als SwitchService dargestellt. Dies mag zwar nicht recht der Semantik entsprechen, ist aber unabdingbar, will man mit CIM einen Hub modellieren, da es auf anderem Weg (noch) nicht m"oglich ist.

Ein weiteres Problem erwies sich bei Assoziationen der Instanz vom Typ PhysicalLink mit einer Instanz vom Typ SwitchPort . F"ur dieses Problem konnte keine Ableitung von CIM_Dependency gefunden werden. Soll auf eigene Anpassungen verzichtet werden, muss die Klasse CIM_Dependency direkt verwendet werden, wodurch aber die semantische Bedeutung auf der Strecke bleibt. Dieser Vorgehensweise wird sich auch bei den sp"ater besprochenen Beispielmodellierungen bedient.

In solchen Spezialf"allen besitzt das Common Information Model also demnach noch Ungereimtheiten.


 
Figure 4.5:   Managed Object Service
\begin{figure}
 \centerline{
 
\psfig {file=visio/service1.eps}

 }
 \end{figure}

ServiceAccessPoints (4.6) "offnen, wie der Name schon vermuten lä"st, den Zugang zu jeweiligen Services. Neben einer von ServiceAccessPoint direkt abgeleiteten Klasse VLAN , welche das jeweilige VLAN mit einer eindeutigen Nummer identifiziert, gibt es sogenannte Protokollendpunkte. Je nach betrachtetem Protokoll ist eine Klasse daf"ur zust"andig. Die g"angigsten sind dabei LANEndpoint , IPProtocolEndpoint und SwitchPort .

Der LANEndpoint erh"alt Information über die MAC Adresse, der IPProtocolEndpoint über die IP Adresse. Eine Instanz der Klasse SwitchPort repräsentiert den Port eines Switches.

Je nach Bedeutung k"onnen bestimmte ProtocolEndpoint s aneinandergeh"angt werden, so h"angt ein IPProtocolEndpoint im Normalfall an einem LANEndpoint .


 
Figure 4.6:   Managed Object ServiceAccessPoints
\begin{figure}
 \centerline{
 
\psfig {file=visio/sap1.eps}

 }
 \end{figure}


next up previous contents
Next: Beispielmodellierungen Up: Repräsentation der Managed Objects Previous: Repr"asentation der physischen Komponenten
Emanuel Heidinger
2/5/2004