Channel

 

Die Interaktionen zwischen Computational Objects einer Anwendung werden auf einer verteilten Plattform über Kanäle (Channels) zwischen den zugehörigen Basic Engineering Objects abgewickelt. Die Managementobjektklasse channel ist folglich die Abstraktion einer Kommunikationsverbindung innerhalb einer verteilten Anwendung bzw. eines verteilten Systemdienstes. Die interne Struktur eines Channels wird auf die Aggregationsbeziehungen zu den MOCs stub, binder, protocolObject und interceptor abgebildet. Im einfachsten Fall einer Punkt-zu-Punkt-Verbindung besteht ein Channel aus genau zwei Stubs, zwei Binders und zwei Protocol Objects; bei Multicast-Verbindungen sind dementsprechend mehrere dieser MOCs involviert. Befinden sich die kommunizierenden Objekte in unterschiedlichen administrativen, organisatorischen oder technischen Domänen, kommen noch ein oder mehrere Interceptors hinzu. Stubs, Binders um Protocol Objects werden im RM-ODP eingeführt, um eine Kommunikationsarchitektur zu definieren, die die in Abschnitt beschriebenen Transparenzen ermöglicht. CORBA kann beispielsweise als die Realisierung einer solchen Architektur angesehen werden. Da RM-ODP jedoch unabhängig von konkreten Systemen ist, wird nicht spezifiziert, wie diese Transparenzen realisiert werden bzw. welche Funktionen die Objekte implementieren. Darüber hinaus handelt es sich bei einem Channel um ein sehr allgemeines Konzept, mit dem sowohl Interaktionen wie RPCs als auch multimediale Datenströme beschrieben werden können. Daher ist es schwierig, den beschriebenen Objektklassen konkrete Managementinformation zuzuordnen, ohne die Allgemeinheit einzuschränken.

Das Attribut CommDomain in der Klasse protocolObject gibt die Kommunikationsdomäne (z.B. ,,OSI`` oder ,,Internet``) an, in welcher das Protokoll Objekt existiert. Innerhalb einer Kommunikationsdomäne können Protocol Objects ohne dazwischenliegendes Gateway (Interceptor) miteinander kommunizieren.

Die Attribute, die für die Klasse channel eingeführt werden, beschreiben Managementinformation für beliebige Arten von Kommunikationsverbindungen. Jeder Channel besitzt einen eindeutigen Identifikator (ID), den Zeitpunkt, an dem er kreiert wurde ( OpenTime) und einen Zustand (Status). Mögliche Zustände für einen Kanal sind «up», «down», «congested» oder «unknown». Bei der Einrichtung eines Kanals wird eine bestimmte Dienstgüte gefordert, die durch die Environment Constraints des zugehörigen Computational Interface Templates festgelegt ist. In der Praxis wird die Dienstgüte jedoch beim Verbindungsaufbau ausgehandelt. Die tatsächliche Dienstgüte eines Kanals kann über das Attribut CurrentQoS abgefragt werden. Den Zeitpunkt der letzten Konfigurationsänderung eines Kanals liefert das Attribut LastChange, den der letzten Aktivität LastActivity. Die Attribute ApplicationProtocol und TransportProtocol geben Auskunft über die eingesetzten Protokolle der Anwendungs- bzw. Transportschicht.

An einen Channel können mehrere Basic Engineering Objects gebunden sein. Zur Identifizierung der Kommunikationspartner dienen in diesem Fall Binding Endpoint Identifiers, die innerhalb eines Prozesses (Capsule) Gültigkeit haben und nichts mit den Engineering Object References zu tun haben. Es ist damit auf Anwendungsebene ein Multiplexen von Verbindungen (associations) über einen Kanal möglich, was sich im Modell in Form der Aggregationsbeziehung zur Klasse Association niederschlägt. Mögliche Attribute für diese Klasse sind ID, Duration, State und TransferredBytes.

Das Ziel der generischen MOCs channel und Association ist die Unterstützung eines Monitoring von Kommunikationsverbindungen innerhalb verteilter Anwendungen zum Zwecke des Fehler-, Leistungs- und Abrechnungsmanagements. Die Modellierung dieser beiden Klassen greift auf Vorschläge der Network Services Monitoring MIB [#!RFC1565!#] zurück (siehe auch Abschnitt ).