Die Interaktionen zwischen Computational Objects einer Anwendung werden auf der verteilten Plattform über Kanäle (Channels) zwischen den zugehörigen Basic Engineering Objects abgewickelt. Die Managementobjektklasse channel ist daher die Abstraktion einer Kommunikationsverbindung innerhalb einer verteilten Anwendung oder eines verteilten Systemdienstes.
Die interne Struktur eines Channels nach dem RM-ODP wird durch 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 aus entsprechend mehreren. Befinden sich die kommunizierenden Objekte in unterschiedlichen administrativen, organisatorischen oder technischen Domänen, kommen noch ein oder mehrere Interceptors hinzu. Stubs, Binders, Protocol Objects, etc. werden im RM-ODP eingeführt, um eine Kommunikationsarchitektur zu schaffen, die verschiedene Transparenzen, wie z.B. Ortstransparenz, für die verteilten Objekte ermöglicht. CORBA ist beispielsweise eine Realisierung einer solchen Architektur. Da der Standard aber unabhängig von konkreten Systemen ist, wird auch 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 beispielsweise innerhalb eines Konferenzsystems beschrieben werden können. Daher ist es schwierig, den beschriebenen Objektklassen konkrete Managementinformation zuzuordnen, ohne die Allgemeinheit zu beschränken. Zur Modellierung der Klassen für Binder, Protocol Object und Interceptor wären außerdem Aspekte des Netzmanagements zu betrachten, was über den Rahmen dieser Arbeit hinausgeht.
Das Attribut CommDomain in der Klasse protocolObject gibt die Kommunikationsdomäne - z.B. «OSI» oder «Internet» - an, in welcher das Protocol Object etabliert ist. Innerhalb einer Kommunikationsdomäne können Protocol Objects ohne dazwischenliegendes Gateway (Interceptor) miteinander kommunizieren.
Die Attribute, die im folgenden für die Klasse channel eingeführt werden, beschreiben Managementinformation, die auf Kommunikationsverbindungen beliebiger Art angewendet werden kann. 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 könnten «up», «down», «congested» oder «unknown» sein. 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 ist die Dienstgüte bei Verbindungsaufbau aber Gegenstand von Verhandlungen. Das bedeutet, daß auch Kanäle eingerichtet werden, die nicht die geforderte Dienstgüte erfüllen. Die tatsächliche realisierte Dienstgüte eines Kanals kann über das Attribut CurrentQoS abgefragt werden. Den Zeitpunkt der letzten Konfigurationsänderung eines Kanals liefert das Attribut LastChange, der Zeitpunkt der letzten Aktivität wird in LastActivity festgehalten. 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 dann sog. Binding Endpoint Identifier, die innerhalb eines Prozesses (Capsule) Gültigkeit haben und nicht mit den Engineering Object References verwechselt werden dürfen. Es ist also auf Anwendungsebene ein Multiplexen von Verbindungen (associations) über einen Kanal möglich. Dies wird durch die Aggregationsbeziehung zur Klasse Association modelliert. Mögliche Attribute für diese Klasse sind ID, Duration, State und TransferredBytes, deren Sinn sich aus dem Namen ergibt.
Die generischen Klassen channel und Association sollen ein Monitoring von Kommunikationsverbindungen innerhalb verteilter Anwendungen zum Zwecke des Fehler-, Leistungs- und Abrechnungsmanagements ermöglichen. Die Modellierung dieser beiden Klassen greift daher Vorschläge der Network Services Monitoring MIB [KF94] auf (siehe Kapitel 3.7.2).