Beziehungen zwischen den Klassen des Computational und Engineering Viewpoint

 

  

Abbildung: Generische MOCs als Basis der Vererbungshierarchie

RM-ODP definiert die Abhängigkeiten zwischen den Konzepten verschiedener Sichten durch Strukturregeln der Viewpoint Correspondences. Wir gehen an dieser Stelle kurz auf die Beziehungen zwischen Computational und Engineering Viewpoint ein, die ebenfalls durch das Objektmodell wiedergegeben werden sollen.

Grundsätzlich wird ein Computational Object durch mehrere Basic Engineering Objects realisiert. Hierfür gibt es im Modell eine 1:n-Assoziation zwischen der Klasse compObject und basicEngObject. Da Basic Engineering Objects wiederum in Capsules enthalten sind, kann das Management über die Relationen zwischen den MOCs die zu einer Software-Komponente gehörenden Prozesse ermitteln. Weiterhin legt das Referenzmodell fest, daß ein Computational Interface durch genau ein Engineering Interface realisiert wird. Zur Adressierung eines Engineering Interface bei der Einrichtung eines Kanals dient die eindeutige Engineering Interface Reference. Innerhalb der IP-Welt kann beispielsweise ein Tupel, bestehend aus IP-Adresse und Port (Socket) bezüglich eines Transportprotokolls (TCP oder UDP) als Engineering Interface Reference angesehen werden. In einer CORBA-Umgebung kommt den IORs der CORBA-Objekte diese Aufgabe zu. Das Objektmodell sieht folglich eine von interface abgeleitete Klasse engInterface vor, die das Attribut Reference besitzt und eine 1:1-Beziehung zu compInterface eingeht.

RM-ODP gestattet die Bindung mehrerer Basic Engineering Objects an einen Kanal und damit an ein Engineering Interface. Zur Unterscheidung von Kommunikationsverbindungen einzelner Basic Engineering Objects, die über den gleichen Kanal abgewickelt werden, dient der sog. Binding Endpoint Identifier, der nur innerhalb des Basic Engineering Objects gültig ist. Das Attribut BindingEndpointID wird folglich der Klasse basicEngObject zugeordnet. In der IP-Welt ist eine Referenz auf einen Socket (File-Deskriptor) ein Beispiel für einen Binding Endpoint Identifier.

Insgesamt haben wir nun zahlreiche GAMOCs aus dem RM-ODP gewinnen können, die allgemeine verteilte Anwendungen entsprechend der zu Beginn dieses Abschnitts besprochenen vier unterschiedlichen Sichtweisen beschreiben. Hinsichtlich einer Top-down-Betrachtungsweise sind sie insofern als vollständig anzusehen, als sämtliche Anforderungen des RM-ODP an die Viewpoint-Sprachen ausgewertet wurden. Die Frage nach der erforderlichen Menge an Managementinformation bedingt demgegenüber eine Bottom-up-Analyse möglichst unterschiedlicher verteilter Anwendungen, um sicherzustellen, daß keine Informationen übersehen wurden. Konkret haben wir dabei verteilte Anwendungen wie Managementsysteme sowie Netzdienste wie WWW, NFS und NIS modelliert, um die Informationsmenge der GAMOCs anhand realer Anwendungen zu messen. Dies ist auch notwendig, um feststellen zu können, ob die Instrumentierungen dieser verteilten Anwendungen in der Lage sind, die geforderten Informationen auch tatsächlich zu liefern. Wir haben dazu einerseits bestehende Objektkataloge für Anwendungen aus anderen Managementarchitekturen untersucht (z.B. die Software-Objektkataloge der DMTF und des Internet-Managements sowie die Tivoli Application Management Specification [#!ams20!#]) und andererseits die Plausibilität der GAMOCs anhand der verschiedenen von uns entworfenen Objektmodelle geprüft. Hierbei hat sich herausgestellt, daß die in den anwendungsspezifischen MOCs vorhandenen Informationsmengen disjunkt waren. Folglich ist davon auszugehen, daß die in den GAMOCs enthaltene Managementinformation vollständig ist.

Die GAMOCs bilden das Grundgerüst der Basisklassen unserer Vererbungshierarchie und stellen somit bereits eine beträchtliche Anzahl an Managementinformation und -diensten bereit, die grundsätzlich von jeder verteilten Anwendung (und damit auch von verteilten kooperativen Managementsystemen) erbracht werden muß. Der in der Motivation dieser Arbeit vorgetragenen Forderung nach aussagekräftigen Basisklassen wurde hiermit Rechnung getragen. Wir werden im folgenden Abschnitt auf diesen Basis-MOCs unser Objektmodell verteilter kooperativer Managementsysteme aufbauen und auf die Möglichkeiten der Instrumentierung dieser Systeme eingehen.

Ferner werden wir in Kapitel anhand unserer prototypischen Implementierungen den Nachweis führen, daß die von uns gewonnenen GAMOCs auch tatsächlich hinreichend generisch sind, d.h. für eine Vielzahl von Diensten (wie z.B. NFS, NIS und WWW) und Anwendungen (verteilte kooperative Managementsysteme) gelten.