Diplomarbeit Integration von OMG Audio / Video Streams in TINA-DPE

Transcrição

H UMBOLDT-U NIVERSITÄT ZU B ERLIN
I NSTITUT FÜR I NFORMATIK
L EHRSTUHL
FÜR
S YSTEMANALYSE
Diplomarbeit
Integration von
OMG Audio / Video Streams
in TINA-DPE
Helge Hesse
Betreuer:
Prof. Dr. Joachim Fischer
Dipl.-Inf. Olaf Kath
2
Inhaltsverzeichnis
1
Einleitung
9
2
Das Referenzmodell für offene und verteilte Verarbeitung
13
2.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.2 ODP Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.3 ODP Verteilungstransparenzen . . . . . . . . . . . . . . . . . . .
16
2.4 ODP Modellierungssichten . . . . . . . . . . . . . . . . . . . . . .
17
2.5 ODP Modellierungssprachen
. . . . . . . . . . . . . . . . . . . .
19
2.5.1 Enterprise-Modellierungssprache . . . . . . . . . . . . . .
19
2.5.2 Informationsmodellierungssprache . . . . . . . . . . . . .
19
2.5.3 Computational-Modellierungssprache . . . . . . . . . . .
20
2.5.4 Engineering-Modellierungssprache . . . . . . . . . . . . .
23
2.5.5 Technology-Modellierungssprache . . . . . . . . . . . . .
24
2.6 ODP-Referenzpunkte . . . . . . . . . . . . . . . . . . . . . . . . .
25
2.7 ODP Stream-Binding-Konzepte . . . . . . . . . . . . . . . . . . .
25
2.7.1 Binden in der Computational-Modellierungssicht . . . .
26
2.7.1.1
Das ODP-Bindungsobjekt . . . . . . . . . . . . .
27
2.7.2 Binden in der Engineering-Modellierungssicht . . . . . .
28
2.7.2.1
3
Etablierung eines Kanals . . . . . . . . . . . . .
30
Realisierung der ODP Stream-Binding-Konzepte
31
3.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
3.2 Telecommunications Information Networking Architecture . . .
32
3.2.1 Überblick über die TINA-Architektur . . . . . . . . . . .
32
3.2.2 TINA-Teilarchitekturen . . . . . . . . . . . . . . . . . . .
32
3.2.3 Verteilte Verarbeitungsumgebung - DPE . . . . . . . . .
33
3
Inhaltsverzeichnis
3.2.4 Referenzpunkte . . . . . . . . . . . . . . . . . . . . . . . .
34
3.2.5 Servicearchitektur . . . . . . . . . . . . . . . . . . . . . .
36
3.2.6 TINA-Connection-Management . . . . . . . . . . . . . . .
37
3.2.6.1
Informationsmodellierung . . . . . . . . . . . . .
37
3.2.6.2
Computational-Modellierung . . . . . . . . . . .
44
3.3 OMG Control and Management of Audio / Video Streams . . . .
46
3.3.1 Überblick über der AVS-Standard . . . . . . . . . . . . .
46
3.3.2 Konzepte des Standards . . . . . . . . . . . . . . . . . . .
46
3.3.2.1
Erweiterung der Object-Management-Architektur 46
3.3.2.2
Ziele der Streaming-Architektur . . . . . . . . .
48
3.3.2.3
Komponenten der Streaming-Architektur . . . .
49
3.3.3 Die AVS Informationsspezifikation . . . . . . . . . . . . .
50
3.3.3.1
Das AVS-Informationsmodell . . . . . . . . . . .
53
3.3.4 Die AVS Computational-Spezifikation . . . . . . . . . . .
54
3.3.4.1
AVS Computational-Modell für das leichte Profil 55
3.3.4.2
AVS Computational-Modell für das volle Profil .
55
3.3.5 Stream-Binding-Szenarien . . . . . . . . . . . . . . . . . .
55
3.3.5.1
Stream-Binding-Szenario für das leichte Profil .
57
3.3.5.2
Stream-Binding-Szenario für das volle Profil . .
58
4 Verwandte Arbeiten
61
4.1 IONA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
4.2 Humboldt Universität, NTT . . . . . . . . . . . . . . . . . . . . .
63
5 Integration von OMG Audio/Video Streams in TINA-DPE
5.1 Einführung und Rahmenbedingungen . . . . . . . . . . . . . . .
65
5.2 Gegenüberstellung von TINA und OMG Audio/Video Streams .
66
5.2.1 Gemeinsamkeiten . . . . . . . . . . . . . . . . . . . . . . .
66
5.2.2 Unterschiede . . . . . . . . . . . . . . . . . . . . . . . . . .
67
5.3 Beschreibung der Ausgangssituation . . . . . . . . . . . . . . . .
69
5.4 ODP-Spezifikation des AVS-Terminals . . . . . . . . . . . . . . .
70
5.4.1 Informationsspezifikation . . . . . . . . . . . . . . . . . .
70
Das Informationsobjekt SFEPBridge . . . . . . . .
71
5.4.1.1
4
65
Inhaltsverzeichnis
5.4.1.2
Das Informationsmodell . . . . . . . . . . . . . .
73
5.4.1.3
und
Die
SFEPBridge-Medienbeschreibung
Aspekte der Dienstqualität . . . . . . . . . . . .
73
5.4.2 Computational-Spezifikation . . . . . . . . . . . . . . . .
74
5.4.2.1
Anwendung der ODP Stream-Binding-Konzepte
74
5.4.2.2
Das Bridge-Konzept in der ComputationalModellierungssicht . . . . . . . . . . . . . . . . .
76
Voraussetzungen für die Teilnahme des AVSTerminals am TINA-Connection-Management .
78
5.4.2.4
Die Schnittstellen der Objekte BBM und Bridge
79
5.4.2.5
Computational-Interaktionen . . . . . . . . . . .
79
5.4.3 Engineering-Spezifikation . . . . . . . . . . . . . . . . . .
84
5.4.2.3
5.4.3.1
Ein Engineering-Modell der AVS-Objekte . . . .
84
5.4.3.2
Ein Engineering-Modell für die Bridge-Objekte
86
5.4.3.3
Engineering-Modell für das AVS-Terminal . . .
88
5.4.3.4
Zusammenfassung der Engineering-Spezifikation 90
5.4.4 Technology-Spezifikation . . . . . . . . . . . . . . . . . . .
5.4.4.1
Auswahlkriterien für einen terminallokalen
Transportmechanismus . . . . . . . . . . . . . .
90
91
6
Zusammenfassung und Ausblick
93
7
Anhang
95
Literaturverzeichnis
101
8
105
Thesen zur Diplomarbeit
5
Inhaltsverzeichnis
6
Abbildungsverzeichnis
2.1 Die fünf ODP-Modellierungssichten . . . . . . . . . . . . . . . .
17
2.2 Instanziierung eines Objektes aus einer Schablone . . . . . . . .
22
2.3 Engineering-Konzepte . . . . . . . . . . . . . . . . . . . . . . . .
23
2.4 ODP Referenzpunkte . . . . . . . . . . . . . . . . . . . . . . . . .
25
2.5 Instanziierung eines Bindungsobjektes aus einer Schablone . .
27
2.6 Erzeugen der Schnittstellen . . . . . . . . . . . . . . . . . . . . .
27
2.7 Zusammengesetztes Binden . . . . . . . . . . . . . . . . . . . . .
28
2.8 Konfiguration eines Kanals . . . . . . . . . . . . . . . . . . . . .
29
3.1 TINA DPE-Infrastruktur . . . . . . . . . . . . . . . . . . . . . . .
33
3.2 TINA Business Roles und Business Relationships
. . . . . . . .
35
3.3 TINA Sitzungen . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
3.4 Stream-Binding auf Anwendungsebene . . . . . . . . . . . . . .
38
3.5 Klassendiagramm eines abstrakten Verbindungsgraphen . . . .
39
3.6 Klassendiagramm eines Logical-Connection-Graphen . . . . . .
40
3.7 Dekomposition einer Stream-Flow-Verbindung . . . . . . . . . .
42
3.8 Klassendiagramm eines Nodal-Connection-Graphen . . . . . . .
42
3.9 Struktur eines Layer-Netzes . . . . . . . . . . . . . . . . . . . . .
43
3.10 Computational-Modellierungssicht . . . . . . . . . . . . . . . . .
44
3.11 OMG Streams-Architektur . . . . . . . . . . . . . . . . . . . . . .
47
3.12 Komponenten der AVS-Spezifikation . . . . . . . . . . . . . . . .
49
3.13 Das AVS-Informationsmodell . . . . . . . . . . . . . . . . . . . .
53
3.14 Initialisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
3.15 Aufbau einer Stream-Verbindung im leichten Profil . . . . . . .
57
3.16 Binden im vollen Profil: Finden kompatibler Endpunkte . . . .
58
3.17 Binden im vollen Profil: Aufbau von Flow-Verbindungen . . . .
59
7
Abbildungsverzeichnis
8
4.1 IONA Szenario zum Binden von zwei FEPs . . . . . . . . . . . .
62
4.2 Das SFEPBridge-Informationsobjekt . . . . . . . . . . . . . . . . .
63
5.1 SFEPAV S vs. SFEPT INA . . . . . . . . . . . . . . . . . . . . . . . .
70
5.2 Einführung des Informationsobjektes SFEPBridge . . . . . . . . .
71
5.3 Das Informationsmodell für den integrierten Ansatz . . . . . . .
73
5.4 Computational-Objekte mit Stream-Schnittstellen verschiedenen Typs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
5.5 Das Bridge-Objekt als Computational-Objekt mit zwei StreamSchnittstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
5.6 Bridge Binding Manager als Bindungsobjekt für MMDevice und
Bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
5.7 Das Stream-Binding Szenario des integrierten Ansatzes . . . .
80
5.8 Beispiel eines AVS-Engineering-Modells . . . . . . . . . . . . . .
84
5.9 Bridge-Engineering-Spezifikation . . . . . . . . . . . . . . . . . .
86
5.10 Transport kontinuierlicher Daten über zwei Kanäle . . . . . . .
87
5.11 Transport kontinuierlicher Daten über einen Kanal . . . . . . .
88
5.12 Das AVS-Engineering-Modell des AVS-Terminals . . . . . . . . .
89
1 Einleitung
Die Infrastruktur der Telekommunikationsnetze wurde in den letzten Jahren intensiv ausgebaut. Die Welt der Telekommunikation bildet heute einen
offenen Markt. Durch die Deregulationsbestrebungen der letzten Zeit haben
jetzt mehr Unternehmen die Möglichkeit, eine eigene Telekommunikationsinfrastruktur aufzubauen und diese am Markt anzubieten. Die Entwicklung
geht von proprietären Lösungen bis zu weltweit verbundenen Netzen, über
die Daten mit unterschiedlichen Anforderungen an die Übertragungsqualität transportiert werden können.
Es ist ein Zusammenwachsen der Informations- und Telekommunikationsindustrie zu einem einzigen Markt zu beobachten. Wurden anfänglich ausschließlich sprach- und textbasierte Informationen übermittelt, so sind heute
ganz neue Anwendungen realisierbar. Insbesondere multimediale Applikationen können auf der Grundlage breitbandiger Netze erstellt und genutzt
werden.
Die Zusammenarbeit der Informations- und Telekommunikationsindustrie
setzt die Verwendung allgemein anerkannter Standards und die Offenlegung
der Schnittstellen voraus. Nur so ist eine schnelle Entwicklung und Integration neuer Anwendungen möglich. Aus diesem Grund wurde 1993 ein internationales Konsortium von Telekommunikationsunternehmen unter dem
Namen Telecommunication Information Networking Architecture Consortium
(TINA-C) gegründet. Die Initiative hat innerhalb von fünf Jahren eine Architektur für die Einführung leistungsfähiger Telekommunikationsanwendungen entwickelt. Auf der Grundlage des Referenzmodells für offene verteilte Verarbeitung (engl. Reference Model of Open Distributed Processing, RMODP) [9] wurde eine Softwarearchitektur für verteilte Anwendungen entworfen.
Durch offene Schnittstellen, definiert in Referenzpunkten, ist es möglich,
sehr schnell neue Produkte zu entwickeln und die Interoperabilität mit bestehenden Anwendungen sicherzustellen.
Eine schon länger existierende Organisation ist Open Management Group
(OMG). Sie wurde 1989 mit dem Ziel gegründet, die Entwicklung objektorientierter Technologien in verteilten Verarbeitungsumgebungen zu standardisieren, um die Wiederverwendbarkeit, Portabilität und Interoperabilität ob-
9
1 Einleitung
jektorientierter Software zu sichern.
OMG arbeitet als übergeordnetes Gremium, das die Entwicklungen der Mitglieder koordiniert. Dazu veröffentlicht es regelmäßig RFPs (engl. Request
For Proposal), zu denen die Mitglieder Vorschläge einreichen können und
über deren Annahme die stimmberechtigten Mitglieder entscheiden.
Für die Entwicklung multimedialer Anwendungen wurde 1996 das RFPDokument “Control and Management of Audio/Video Streams“ [7] herausgegeben. Im darauf folgenden Jahr wurde eine gemeinsame Vorlage mehrerer Firmen als Standard angenommen [8]. Er definiert Softwareschnittstellen
und beschreibt Interaktionsszenarien zum Aufbau von Verbindungen für den
Transport kontinuierlicher Daten zwischen multimedialen Anwendungen.
Der OMG-Standard konzentriert sich auf die Spezifikation der Endgeräte.
Auf das Management zugrundeliegender Telekommunikationsnetze wird verzichtet, anstelle dessen wird von Ende-zu-Ende-Verbindungen zwischen den
Geräten ausgegangen. Das Management von Verbindungen zur Übertragung
kontinuierlicher Daten ist einer der TINA-Schwerpunkte, während dort wiederum keine Spezifikation der Schnittstellen von Endgeräten erfolgt. Von der
Zielsetzung passen beide in orthogonaler Weise zueinander.
Um ein funktionierendes Zusammenspiel zwischen OMG AVS-konformen
Endgeräten und TINA-Netzmanagement zu erreichen, wird in dieser Arbeit
ein Modell entwickelt, das die Verbindung der beiden unterschiedlichen Konzepte realisiert. Es wird gezeigt, wie beide Standards zusammengeführt werden können. Dabei wird auf bereits existierende Forschungsergebnisse aufgebaut [17].
Als Grundlage der Modellierung werden die Ausdrucksmittel des Referenzmodells ODP genutzt. Zu diesem Zweck werden zuerst die ODP-Prinzipien
eingeführt. Diese werden bei der Vorstellung relevanter TINA-Konzepte genutzt. Anschließend wird der AVS-Standard vorgestellt. Dadurch wird die
Voraussetzung geschaffen, ein gemeinsames Modell zu entwerfen, das die Architektur der OMG und die des TINA-Konsortiums vereint. Das Ergebnis
der Integration ermöglicht es, AVS-konforme Geräte unverändert mit einer
TINA-orientierten Telekommunikationsplattform zu nutzen.
Die Arbeit gliedert sich in folgende Teile:
Kapitel 1 gibt eine Einführung in die Thematik der Arbeit.
Kapitel 2 erklärt das ODP-Referenzmodell. Es werden die Grundlagen
und die darauf aufbauenden Prinzipien und Modellierungssichten vorgestellt.
Kapitel 3 unterteilt sich in zwei Abschnitte. Sie stellen die StreamBinding-Konzepte von TINA und des AVS-Standards vor.
10
Kapitel 4 beschreibt bereits bestehende Forschungsarbeiten.
Kapitel 5 entwirft ein gemeinsames Modell beider Standards. Dieses
Modell wird es ermöglichen, daß OMG Audio/Video Streams-konforme
Geräte in TINA-orientierten Telekommunikationsnetzen genutzt werden können. Die Struktur orientiert sich dabei an den Modellierungssichten des ODP-Referenzmodells.
Kapitel 6 gibt eine Zusammenfassung und einen Ausblick.
In dieser Arbeit wird die alte Rechtschreibung verwendet, wie es der deutsche Hochschulverband empfohlen hat. Der Text wurde mit dem Satzsystem
LATEX in einer 10 Punkt Times Schriftart gesetzt. Alle englischen Fachbegriffe
sind kursiv hervorgehoben. Schnittstellenbeschreibungen sind in der Schriftart Courier notiert.
11
1 Einleitung
12
2 Das Referenzmodell für offene und
verteilte Verarbeitung
2.1
Einführung
Das Referenzmodell für offene und verteilte Verarbeitung (engl. Reference
Model of Open Distributed Processing (RM-ODP)) [9, 10, 11, 12], ist eine gemeinsame Empfehlung der Standardisierungsgremien ITU-T und ISO. Es ist
ein Rahmenwerk für die Spezifikation verteilter Systeme. RM-ODP charakterisiert ein verteiltes System durch die folgenden Merkmale:
Die Komponenten des Systems können örtlich verteilt sein. Interaktionen können zwischen lokalen und entfernten Komponenten auftreten.
Die Komponenten können parallel ausgeführt werden.
Es kann kein globaler Zustand des Systems festgestellt werden.
Einzelne Komponenten des Systems können unabhängig voneinander
ausfallen.
Die Kommunikation und Verarbeitung kann nicht durch eine globale
Uhr synchronisiert werden.
Das Referenzmodell adressiert Probleme, die bei der Verteilung, Zusammenarbeit und Portabilität verteilter Systeme auftreten. In diesem Zusammenhang wird erstmals der Begriff Dienst verwendet. In dieser Arbeit
wird mit der Bezeichnung Dienst eine Funktion bezeichnet, die von einer Systemkomponente erbracht und von einer anderen Komponente genutzt wird.
Die ODP-Standardisierung erlaubt, verteilte Systeme mit den folgenden Eigenschaften zu entwickeln [9]:
Offenheit: Diese Eigenschaft sichert die Portabilität verschiedener Komponenten eines Systems. Ohne Modifizierungen soll die Ausführung von Komponenten auf verschieden Verarbeitungseinheiten möglich sein. Ebenso wird
die Kommunikation zwischen unterschiedlichen Komponenten sichergestellt.
13
2 Das Referenzmodell für offene und verteilte Verarbeitung
Modularität: Diese strukturelle Eigenschaft zielt auf die Autonomie einzelner Teile des Systems. Sie bildet die Grundlage für die Flexibilität eines Systems, indem einzelne Teile austauschbare Komponenten bilden.
Sicherstellung von Qualitätsanforderungen: Diese Eigenschaft zielt auf
ein Systemverhalten unter Beachtung bestimmter Qualitätsanforderungen.
Dazu zählt Verläßlichkeit und Geschwindigkeit, mit der ein Dienst erbracht
wird. Da nicht davon ausgegangen werden kann, daß alle Komponenten eines
Systems permanent verfügbar sind, muß ein System auch flexibel gegenüber
Fehlern reagieren können (Fehlertolleranz).
Transparenz: Diese System-Eigenschaft soll gegenüber Applikationen die
technische Realisierung der Verteilung von Komponenten verbergen. Die Existenz von heterogener Hard- und Software, aber auch das Ersetzen einzelner
Komponenten soll für eine Applikation nicht sichtbar (transparent) sein.
RM-ODP besteht aus vier Dokumenten, den ITU-T Empfehlungen X.901 bis
X.904 [9, 10, 11, 12], mit folgendem Inhalt:
X.901 gibt eine Motivation, indem es einen Überblick über RM-ODP, die
Schlüsselkonzepte und eine Einführung in die Architektur gibt. Im letzten Abschnitt werden Kriterien definiert, anhand derer sich die Konformität von Implementierungen zum Standard überprüfen lassen. Dazu
wird das Konzept der Referenzpunkte eingeführt. Anhand mehrerer Systeme werden Beispiele für ODP-Spezifikationen gegeben.
X.902 definiert Konzepte zur Beschreibung von verteilten Systemen.
X.903 definiert, wie ODP-Systeme zu spezifizieren sind. Dabei werden
die in X.902 eingeführten Konzepte benutzt. Das Dokument stellt charakteristische Merkmale vor, die ODP-Systeme auszeichnen.
X.904 enthält eine Formalisierung der in X.902 vorgestellten Modellierungskonzepte. Die Formalisierung wird durch eine Interpretation der
ODP-Konzepte durch Ausdrucksmittel standardisierter formaler Beschreibungstechniken erreicht.
14
2.2 ODP Grundlagen
2.2
ODP Grundlagen
X.902 und X.903 definieren grundlegende Begriffe, die bei der Modellierung
von ODP-Systemen verwendet werden. Die folgenden Begriffe werden auch
in dieser Arbeit benutzt:
Eine Entität ist ein konkretes oder abstraktes Element der modellierten Welt.
Ein Objekt ist das Modell einer Entität. In Abhängigkeit vom Abstraktionsniveau können Objekte unterschiedliche Dinge repräsentieren. Sie
sind von verschiedener Granularität, so daß ein Objekt eine Komposition von Objekten sein kann. Jedes Objekt ist charakterisiert durch sein
Verhalten. Ein Objekt ist von anderen unterscheidbar, d.h. es besitzt eine Identität. Ein Objekt kann eine Menge von (Name,Wert)-Tupeln besitzen, sie werden als Attribute des Objektes bezeichnet. Die Wertebelegung eines Attributs kann sich während der Lebenszeit eines Objektes
ändern.
Die Umgebung eines Objektes ist der Teil eines Modells, der nicht
Teil des Objektes ist.
Das Verhalten eines Objektes ist die Menge aller möglichen Aktionen, an denen ein Objekt teilnehmen kann. Zugehörig sind Einschränkungen bezüglich des möglichen Auftretens dieser Aktionen. Damit beschreibt das Verhalten alle möglichen Zustandsänderungen eines Objektes.
Der Zustand eines Objektes beschreibt die Belegung seiner Attribute
zu einem bestimmten Zeitpunkt. Der aktuelle Zustand eines Objektes
ergibt sich aus den vorausgegangenen Aktionen. Mögliche Folgeaktionen werden durch den aktuellen Zustand bestimmt.
Eine Aktion ist ein Vorgang, der in Verbindung mit einem Objekt abläuft. Es wird in interne Aktionen und Interaktionen unterschieden. Bei
einer Interaktion ist die Umgebung des Objektes beteiligt.
Eine Schnittstelle beschreibt eine Menge von Interaktionen sowie Einschränkungen bezüglich des möglichen Auftretens. Ein Objekt kann
mehrere Schnittstellen besitzen, wodurch sowohl funktionale Dekomposition als auch Verteilung ermöglicht wird. Objekte können nur über
Schnittstellen mit ihrer Umgebung interagieren.
Komposition ist eine Kombination von Objekten, die zu einem neuen
Objekt auf einem anderen Abstraktionsniveau führt.
15
Dekomposition ist die Spezifikation eines gegebenen Objektes als eine
Komposition.
Eine Schablone ist die Spezifikation der gemeinsamen Eigenschaften
einer Menge von Entitäten. Eine Schablone enthält genügend Informationen, um Instanzen von Objekten zu erzeugen. Es gibt Schablonen für
Objekte, Schnittstellen und weitere Entitäten.
2.3 ODP Verteilungstransparenzen
Jedes ODP-System benötigt Unterstützung durch eine Kommunikationsplattform, die Interaktionen zwischen Instanzen von Objekten ermöglicht.
Verteilungstransparenzen werden benutzt, um Aspekte eines ODP-Systems
zu verbergen, die durch die netzweite Verteilung einzelner Objekte entstehen.
Die Kommunikationsplattform unterstützt dafür eine Menge von Transparenzen:
Access:
verbirgt Unterschiede der Datenrepräsentation und Aufrufmechanismen, um
die Zusammenarbeit zwischen Objekten zu ermöglichen.
Failure:
verbirgt Fehlfunktionen oder den Ausfall von Objekten. Damit kann Fehlertoleranz in einem verteilten System sichergestellt werden.
Location:
verbirgt die räumliche Verteilung bei der Identifizierung und dem Binden von
Schnittstellen.
Migration:
verbirgt vor einer Entität den Umstand, daß sie in einer neuen Umgebung
ausgeführt wird.
Replication:
verbirgt die Benutzung einer ganzen Gruppe kompatibler1 Objekte zur Bereitstellung einer Schnittstelleninstanz. Dadurch können die Performanz und
die Verfügbarkeit erhöht werden.
Persistence:
verbirgt vor einem Objekt die Deaktivierung und Wiederaktivierung von Objekten. Dadurch wird die Dauerhaftigkeit von Objekten gewährleistet, auch
wenn das System notwendige Ressourcen zeitweilig nicht bereitstellen kann.
Transaction:
verbirgt die Koordinierung von Aktionen zwischen Objekten zur Gewährleistung von Konsistenz.
1 Kompatibilität bezieht
16
sich auf das Verhalten der Objekte.
2.4 ODP Modellierungssichten
2.4
ODP Modellierungssichten
Um die Komplexität verteilter Systeme beherrschbar zu machen, führt
RM-ODP mehrere, in Beziehung zueinander stehende Modellierungssichten
(engl. viewpoints) ein. Jede Modellierungssicht definiert dabei eine andere
Abstraktion des Gesamtsystems. Abstraktion bezieht sich nicht auf die Granularität der betrachteten Entitäten eines Systems, wodurch die Modellierungssichten keine Hierarchie bilden. Es wird von den für den Schwerpunkt
der Betrachtung unwichtigen Dingen abgesehen (abstrahiert). Dabei wird
das Ziel verfolgt, die speziellen Anforderungen der am Designprozeß beteiligten Gruppen zu erfüllen. So werden für dasselbe System mehrere Modelle
entwickelt, die in Art und Umfang auf die konkrete Aufgabenstellung der
Designer ausgerichtet sind. So gibt es Modellierungssichten, die auf die Beschreibung und Analyse ausgerichtet sind, während andere sich auf das Verhalten und die Realisierung des Systems konzentrieren.
Es sind fünf Modellierungssichten definiert, die untereinander in Beziehung
stehen, die jedoch keine Folge von Modellierungsschritten bilden:
Abbildung 2.1: Die fünf ODP-Modellierungssichten
Enterprise
Modellierungssicht
Informationsmodellierungssicht
ODP
System
Computational
Modellierungssicht
Engineering
Modellierungssicht
Technology
Modellierungssicht
Enterprise-Modellierungssicht
Die Enterprise-Modellierungssicht beschreibt den Zweck eines Systems innerhalb des Unternehmens. Es werden die Anforderungen und der Anwendungsbereich des Systems untersucht. Dabei werden die Aktivitäten des Systems im Kontext einer Organisation betrachtet und die Rollen beteiligter
Personen identifiziert. Schließlich werden die für das System geltenden Regeln (engl. Policies) aufgestellt.
17
Informationsmodellierungssicht
Die Informationsmodellierungssicht beschreibt, welche Informationen verarbeitet, gespeichert und übertragen werden. Es werden Informationsobjekte
identifiziert und ihre Attribute beschrieben. Erkannte Beziehungen und Abhängigkeiten zwischen Informationsobjekten werden in einem Informationsmodell dargestellt.
Computational-Modellierungssicht
Die Computational-Modellierungssicht dekomponiert das System in eine
Menge interagierender Computational-Objekte (engl. Computational Objects, COs). Sie kapseln Daten und Funktionalität in einer Einheit. Objekte interagieren untereinander über wohldefinierte Schnittstellen. Eine
Computational-Spezifikation umfaßt die Beschreibung der Objekte, die Informationsverarbeitung innerhalb der Objekte, die Beschreibung der Schnittstellen sowie die Interaktionen, die über diese Schnittstellen zwischen Objekten auftreten.
Engineering-Modellierungssicht
Die Engineering-Modellierungssicht beschreibt die Systemunterstützung,
die eine Verteilung der Objekte aus der Computational-Modellierungssicht
ermöglicht. Computational-Objekte werden auf eine Menge von BasicEngineering-Objekten (BEOs) abgebildet. Zusätzlich werden Infrastrukturobjekte eingeführt, die die unter 2.3 vorgestellten Verteilungstransparenzen
sicherstellen. Dazu zählen insbesondere Bindungs- und Protokollobjekte, die
Interaktionen zwischen Objekten auf verschiedenen Verarbeitungseinheiten
ermöglichen.
Technology-Modellierungssicht
In dieser Modellierungssicht werden die zur Implementierung eines verteilten Systems geeigneten Technologien beschrieben. Betrachtet werden z.B.
verwendete Kommunikationsprotokolle und Programmiersprachen.
18
2.5
ODP Modellierungssprachen
Um ein ODP-System in einer bestimmten Modellierungssicht zu repräsentieren, sind Konzepte zur Beschreibung zu definieren, durch die das Modell
spezifiziert werden kann. Diese Konzepte bilden eine Modellierungssprache (engl. Viewpoint Language) zur Spezifikation des Modells in einer Modellierungssicht. Jede Sprache besitzt genügend Ausdrucksmittel, um ODPEntitäten, Applikationen und Regeln in dieser Sichtweise auszudrücken.
2.5.1
Enterprise-Modellierungssprache
Die Enterprise-Modellierungssprache führt Konzepte ein, um den Zweck eines ODP-Systems im Kontext des Unternehmens zu beschreiben, in dem es
installiert ist. Folgende Fragen stehen dabei im Mittelpunkt:
Welches Ziel wird mit dem System innerhalb der Organisation verfolgt ?
Wer benutzt das System ?
Für welchen Zweck wird das System benutzt ?
In welcher Wechselbeziehung steht das System mit seiner Umgebung ?
Welchen Einschränkungen unterliegt das System ?
Ein Unternehmen wird durch mehrere Enterprise-Objekte modelliert. Durch
die Zuweisung verschiedener Rollen werden die Objekte zueinander in Beziehung gesetzt. Die Rollen bezeichnen Nutzer, Eigentümer und Anbieter
von Informationen. Eine Schlüsselrolle spielt das Konzept des Vertrags
(engl. Contract), der Enterprise-Objekte verbindet und gegenseitige Verpflichtungen festlegt. Ein Vertrag drückt die gemeinsamen Ziele der Objekte aus,
beschreibt die Pflichten der einzelnen Objekte und nennt geltende Bestimmungen (engl. Policies), die Einschränkungen bezüglich der Objektinteraktionen beschreiben.
2.5.2
Informationsmodellierungssprache
Ein ODP-System besteht aus mehreren Komponenten. Voraussetzung für
den Informationsaustausch zwischen den Komponenten ist eine einheitliche
Vorstellung über die Bedeutung der Informationen, die ausgetauscht bzw.
verarbeitet werden. Eine unterschiedliche Interpretation der Informationen
würde dazu führen, daß sich das System anders als erwartet verhält.
19
Konzepte der Informationsmodellierungssprache
Informationsobjekte und Beziehungen:
Die Informationsmodellierungssprache enthält Konzepte zur Spezifikation
der Struktur und Bedeutung der in einem ODP-System gespeicherten und
manipulierten Informationen. Dazu wird ein ODP-System durch Informationsobjekte und deren Beziehungen untereinander dargestellt. Ein Informationsobjekt ist eine abstrakte Entität in der realen Welt, im ODP-System oder
in anderen Modellierungssichten. Die elementare Form ist das atomare Informationsobjekt, welches in vielen Spezifikationssprachen als einfacher Wert
repräsentiert wird. Komplexe Informationen werden als kombinierte Informationsobjekte dargestellt, während Zusammenhänge zwischen Informationsobjekten durch Beziehungen (engl. Relationships) ausgedrückt werden.
Schemata:
Neben den Informationsobjekten und ihren Beziehungen besteht eine Informationsspezifikation aus einer Menge verwandter Schemata, bei denen drei
Varianten unterschieden werden: invariante, statische und dynamische Schemata.
Ein invariantes Schema enthält Aussagen, die bei jedem gültigen (d.h.
definierten) Verhalten des Systems zu jeder Zeit wahr sein müssen.
Ein statisches Schema enthält Annahmen, die zu einem gegebenen Zeitpunkt wahr sein müssen, beispielsweise kann so der initiale Zustand
eines Objektes spezifiziert werden.
Ein dynamisches Schema spezifiziert, wie sich Informationsobjekte
während des Systemeinsatzes verändern können. Es beschreibt die erlaubten Änderungen unter Beachtung der für dieses Objekt gültigen invarianten Schemata. Zusätzlich können in einem dynamischen Schema
Informationsobjekte erzeugt und zerstört werden.
Verschiedene Notationen können für die Spezifikation verwendet werden, so
daß die Betonung auf die Klassifizierung, die Zustände oder das Verhalten
der Informationsobjekte gelegt werden kann.
2.5.3
Computational-Modellierungssprache
Die Computational-Modellierungssicht beschreibt die funktionale Dekomposition des Systems und bildet damit die Grundlage für dessen Verteilung.
Dazu werden Einheiten eingeführt, die jeweils eine Teilfunktionalität des Systems beschreiben.
20
Konzepte der Computational-Modellierungssprache
Computational Object:
Das System wird als eine Konfiguration von Computational-Objekten (COs)
dargestellt. Gemäß dem Standard X.903 kann ein Objekt:
Operationsaufrufe durchführen, bzw. auf solche antworten,
Signale und kontinuierliche Daten senden bzw. empfangen,
Schnittstellen und Objekte aus Schablonen instanziieren,
Schnittstelleninstanzen binden,
den eigenen Zustand verändern,
Schnittstelleninstanzen und sich selbst löschen.
Den Schwerpunkt der Computational-Modellierungssprache bildet das Objektmodell. In diesem werden Objekte identifiziert und Schnittstellen beschrieben, über die Interaktionen zwischen Objekten stattfinden können.
Weiterhin werden die Aktionen definiert, die ein Objekt ausführen kann.
Computational Interfaces:
Interaktionen zwischen Objekten sind ausschließlich über Schnittstellen
möglich. Eine Schnittstelle ist charakterisiert durch eine Signatur, ihrem Verhalten und einer Umgebungsvereinbarung. Die Signatur ist abhängig vom
Typ der Schnittstellen, der entweder „operational“, „signal“ oder „stream“
sein kann:
Die Signatur einer Signal-Schnittstelle beschreibt eine Menge von Signalen,
die über diese Schnittstelle empfangen oder gesendet werden können. Ein Signal ist eine elementare, atomare Interaktion. Für jedes Signal wird angegeben, ob die Schnittstelle die Rolle des Initiators oder Empfängers einnimmt.
Die Signatur einer operationalen Schnittstelle umfaßt eine Menge von
Operationen, bei denen zwischen Anzeigen (engl. announcements) und Anfragen (engl. interrogations) unterschieden wird. Zur Signatur einer Anzeige
gehört ihr Name, sowie Anzahl, Namen und Typen der Parameter. Für eine
Operation wird zusätzlich eine Menge möglicher Terminierungen angegeben.
Eine Terminierung besteht aus einem Namen, sowie der Anzahl und Typen
der Parameter.
Eine Stream-Schnittstelle beschreibt eine Menge kontinuierlicher Datenströme (engl. flows). Für jeden Datenstrom wird seine Rolle angegeben, er ist
entweder Produzent oder Verbraucher.
21
Verhalten und Umgebungsvertrag:
Das Verhalten einer operationalen Schnittstelle beschreibt die erlaubten Sequenzen von Aktionen des Objektes, welches diese Schnittstelle unterstützt.
Das Verhalten kann interne Aktionen des Objektes umfassen und wird eingeschränkt durch die Umgebung des Objektes. Zur Spezifikation einer Schnittstelle gehört ein Umgebungsvertrag. In einem solchen Vertrag werden Parameter der Dienstgüte (engl. Quality of Service, QoS) festgelegt. Ein Objekt,
das eine Instanz dieser Schnittstelle erzeugt, garantiert dabei ein bestimmtes Maß an Dienstgüte. Aber nur unter der Bedingung, daß die Umgebung
ihrerseits die geforderten Voraussetzungen erfüllt.
Computational Interface Template:
Schnittstellen werden zur Laufzeit durch die Instanziierung von
Schnittstellen-Schablonen (engl. Interface Templates) erzeugt. Eine Schablone enthält die dafür notwendigen Informationen, d.h. die Signatur, das
Verhalten und die Umgebungsvereinbarung.
Eine Interaktion zwischen Objekten setzt den erfolgreichen Aufbau eines
Kommunikationspfades zwischen den Schnittstellen voraus. Dieser im ODP
Referenzmodell als Binden (engl. Binding) bezeichnete Vorgang wird im Kapitel 2.7 beschrieben.
Computational Object Template:
Jedes Computational-Objekt wird aus einer Schablone instanziiert. Diese
beinhaltet eine Menge von Schnittstellenschablonen, einen initialen Zustand
sowie die Spezifikation des Verhaltens und der Umgebungsvereinbarung. Abbildung 2.2 zeigt die Instanziierung eines Computational-Objektes aus einer
Schablone:
Abbildung 2.2: Instanziierung eines Objektes aus einer Schablone
computational object template
interface templates
Verhaltensspezifikation
Umgebungsvertrag
Initialer Zustand
computational interface template
stream interface template
operationale Signatur
Stream Signatur
Umgebungsvertrag
Umgebungsvertrag
control interface
computational
object
22
stream interface
2.5.4
Engineering-Modellierungssprache
Die Engineering-Modellierungssprache konzentriert sich auf die Erbringung
der notwendigen Unterstützung, um Interaktionen zwischen Objekten zu ermöglichen. Es werden Konzepte definiert, die eine verteilungstransparente
Interaktion von Objekten ermöglichen.
Konzepte der Engineering-Modellierungssprache
Basic Engineering Objects:
Die im Objektmodell identifizierten Computational-Objekte - die keine Bindungsobjekte sind - werden in der Engineering-Modellierungssicht als Basic
Engineering Objects (BEOs) sichtbar. Die Computational-Schnittstellen
werden auf Engineering-Schnittstellen abgebildet und ComputationalBindungen werden als lokale Bindungen oder Kanäle (engl. Channels)
sichtbar.
BEOs werden durch geschachtelte Gruppierungen in Beziehung zu verfügbaren Ressourcen gesetzt.
Knoten, Kapsel und Cluster:
Abbildung 2.3 zeigt die Konfiguration einer unabhängig verwalteten Einheit,
die als Knoten (engl. Node) bezeichnet wird.
Abbildung 2.3: Engineering-Konzepte
Node
Capsule
Basic
engineering
object
Basic
engineering
object
Channel
Cluster
Basic
engineering
object
Cluster
Basic
engineering
object
Basic
engineering
object
Cluster
Manager
Capsule
Basic
engineering
object
Cluster
Manager
Cluster
Manager
Capsule
Manager
Capsule
Manager
Cluster
Basic
engineering
object
Basic
engineering
object
Channel
Nucleus
23
Gesteuert wird der Knoten durch einen Kern (engl. Nucleus). Dieser ist verantwortlich für die Instanziierung und Initialisierung von Objektgruppen, erlaubt den Zugriff auf die Kommunikationsressourcen des Knotens und ist in
der Lage, eindeutige Bezeichner für Entitäten innerhalb des Knotens zu vergeben. Innerhalb eines Knotens existieren mehrere Kapseln (engl. Capsules).
Eine Kapsel besitzt einen Teil des Speichers und der Rechenkapazität des
Knotens. Er kann mit einem UNIX-Prozeß verglichen werden, der über einen
eigenen, geschützten Speicher verfügt. Über den Kapselmanager läßt sich
eine Kapsel steuern. Eine Kapsel enthält mehrere Cluster, in denen Basic
Engineering Objects gruppiert sind. Diese zusätzliche Gruppierung erlaubt
die Anwendung einer Operation auf eine definierte Teilmenge von Objekten innerhalb des Clusters, z.B. das Aktivieren oder Deaktivieren. Moderne
Betriebssysteme unterstützen dieses Konzept durch die Bereitstellung von
Threads (parallele Ausführungsstränge eines Prozesses). Operationen auf einem Cluster werden durch Interaktion mit dem Clustermanager ausgeführt.
Das Engineering-Konzept der Gruppierung von Objekten in Clusters bereitet den Aufbau von Kommunikationspfaden zwischen BEOs vor, indem es
unterschiedliche Konzepte für die Kommunikation von Objekten innerhalb
eines Clusters sowie über Clustergrenzen hinweg erlaubt. Der Aufwand für
die Kommunikation von Objekten innerhalb eines Clusters kann minimiert
werden, indem diese Aufgabe den Werkzeugen übertragen wird, die die umgebene Kapsel erzeugt haben (Compiler, Linker). Die Kommunikation kann
dann durch die Unterstützung eines sprachabhängigen Laufzeitsystems effizient organisiert werden.
Kanal:
Wenn Objekte aus verschiedenen Prozessen kommunizieren sollen, so ist dafür eine Engineering-Unterstützung Voraussetzung. Das RM-ODP führt dazu das Konzept des Kanals (engl. Channel) ein. Ein Kanal besteht aus einer Menge interagierender Engineering-Objekte. Diese Objekte sichern die
im Kapitel 2.3 geforderten Transparenzprinzipien. Der Aufbau eines Kanals
wird bei der Vorstellung der ODP Stream-Binding-Konzepte beschrieben.
2.5.5
Technology-Modellierungssprache
Die technologische Spezifikation beschreibt die Implementierung eines ODPSystems in Hinsicht auf die verwendeten Hardware- und Softwarekomponenten. Der Spielraum wird dabei durch Kosten und Verfügbarkeit von Technologien eingeschränkt. Die in der technologischen Modellierungssicht enthaltenen Informationen bilden den Übergang von der Spezifikation eines Systems
zu seiner Realisierung. Sie sind die Grundlage für das Testen von existierenden Standardkompenten auf ihre Konformität zur Spezifikation des Systems
24
2.6 ODP-Referenzpunkte
in den anderen Modellierungssichten. Insbesondere kann untersucht werden,
ob eine verwendbare Technologie eine Funktion mit hinreichender Qualität
erbringen kann. Beispielsweise kann überprüft werden, ob eine Technologie das in der Computational-Modellierungssicht definierte Verhalten einer
Schnittstelle garantieren kann.
2.6
ODP-Referenzpunkte
Das Referenzmodell ermöglicht die Entwicklung offener, verteilter Systeme.
Damit ein System die Eigenschafft „offen“ erfüllt, muß es die Schnittstellen,
über die Interaktionen (engl. Interworking) mit anderen Systemen erfolgen
können, frei zugänglich machen. Um die Beschreibung zu vereinheitlichen,
wird das Konzept des Referenzpunktes eingeführt.
Potentielle Kandidaten für Referenzpunkte sind die Schnittstellen von Objekten. Im Zusammenhang mit Referenzpunkten unterscheidet das Referenzmodell vier Kategorien von Schnittstellen. Objekte besitzen Schnittstellen
zu Nutzern, zu anderen Objekten, zu Kommunikationsmechanismen und zu
Speichermedien. Dementsprechend werden die Referenzpunkte in vier Kategorien eingeteilt:
Abbildung 2.4: ODP Referenzpunkte
User
1
ODP System A
Application
ODP System B
3
Application
2
Application
4
1 RP zwischen einem System
und einem Nutzer
(engl. perceptual)
2 RP innerhalb eines Systems
(engl. programmatic)
3 RP zwischen zwei Systemen
(engl. interworking)
4 RP zwischen einem System
und einem externen
Speichermedium
(engl. interchange)
Spezifikationen von Referenzpunkten können in jeder der fünf Modellierungssichten erfolgen.
2.7
ODP Stream-Binding-Konzepte
Zu den grundlegenden Modellierungskonzepten von ODP gehören Objekte
und Schnittstellen. Bevor eine Interaktion zwischen Objekten stattfinden
kann, muß ein Kommunikationspfad zwischen den Schnittstellen aufgebaut
werden. Dieser Vorgang wird als „Binden“ bezeichnet.
25
ODP definiert unterschiedliche Aktionen zum Binden von Schnittstellen:
ODP Bindungsvorgänge
implizite
- nur für operationale Schnittstellen
explizite
primitive
zusammengesetzte
- in der Computational- Spezifikation
- durchgeführt durch
nicht modelliert
- durchgeführt durch ein
Bindungsobjekt
beteiligtes Objekt
- nur zwischen Schnittstellen des gleichen Typs
möglich
2.7.1
Binden in der Computational-Modellierungssicht
Ein explizites Binden ist sowohl für operationale als auch für StreamSchnittstellen definiert. Für operationale Schnittstellen ist zusätzlich ein
implizites Binden spezifiziert. Diese Form wird in der ComputationalModellierung nicht beschrieben, da der Bindevorgang ausschließlich durch
Engineering-Mechanismen realisiert wird. Für den Fall, daß es sich um ein
explizites Binden handelt, wird nach zwei Bindungsvorgängen (engl. Binding
actions) unterschieden: ein primitiver und ein zusammengesetzter Bindungsvorgang.
Das primitive Binden erlaubt die direkte Bindung von zwei Schnittstellen
des gleichen oder von verschiedenen Objekten. Es wird von einem der beteiligten Objekte durchgeführt. Voraussetzung ist, daß die Schnittstellen vom
gleichen Typ sind und eine komplementäre Signatur (Produzent/Konsument)
besitzen.
Das zusammengesetzte Binden bezeichnet das Binden von Schnittstellen
durch Unterstützung eines Bindungsobjektes (engl. Binding Object). Damit
wird auch das Binden von mehr als zwei Schnittstellen möglich, wodurch sich
Punkt-zu-Mehrpunkt bzw. Mehrpunkt-zu-Mehrpunkt Verbindungen realisieren lassen.
ODP gestattet das Binden von Schnittstellen mit unterschiedlichem Typ
nur unter Anwendung zusammengesetzter Bindungsaktionen durch ein Bindungsobjekt [13]. Damit stellt das ODP-Bindungsobjekt die leistungsfähigste
Methode zur Bereitstellung von Stream-Verbindungen in der ComputationalModellierungssicht dar.
26
2.7 ODP Stream-Binding-Konzepte
2.7.1.1
Das ODP-Bindungsobjekt
Das Bindungsobjekt wird wie jedes Computational-Objekt aus einer Schablone erzeugt. Der Initiator des Vorgangs kann eines der beteiligten Objekte
oder ein außenstehendes, drittes Objekt sein:
Abbildung 2.5: Instanziierung eines Bindungsobjektes aus einer Schablone
Binding Object template
ates
instanti
Computational
Object
(Initiator)
Binding
Object
Durch Kenntnis der Schablone kann der Initiator die entsprechende Operation zum Binden von Schnittstellen rufen. Als Parameter werden die zu bindenden Schnittstellen übergeben. Das Bindungsobjekt instanziiert eine Steuerungsschnittstelle sowie eine passende Menge von Stream-Schnittstellen:
Abbildung 2.6: Erzeugen der Schnittstellen
ControlIF
Computational
Object
(Initiator)
bind ( in StreamIF1, in StreamIF2,
out ControlIF )
Computational
Object 1
Stream
Interface 1
Binding
Object
Computational
Object 2
Stream
Interface 2
Im nächsten Schritt benutzt das Bindungsobjekt primitive Bindungsaktionen, um seine Schnittstellen mit denen der Objekte CO1 und CO2
zu binden:
27
Abbildung 2.7: Zusammengesetztes Binden
ControlIF
Computational
Object
(Initiator)
returns ControlIF
Computational
Object 1
Binding
Object
primitive bindings
Computational
Object 2
Das Resultat eines zusammengesetzten Bindens ist gewöhnlich die Rückgabe
einer Steuerungsschnittstelle durch das Bindungsobjekt. Damit werden der
Zugriff auf weitere Funktionen und die Manipulation der Bindung möglich.
Diese Operationen erlauben:
Das Anfordern von Benachrichtigungen (engl. notifications) über aufgetretene Fehler oder Änderungen von Dienstgüteparametern. Zu diesem
Zweck stellt das initiierende Objekt eine Schnittstelleninstanz bereit,
die entsprechende Benachrichtigungsoperationen unterstützt.
Das Hinzufügen oder Entfernen von Schnittstelleninstanzen zur Bindung.
Die Kontrolle über Dienstgüteparameter der Bindung, insbesondere
beim Transport kontinuierlicher Daten über Stream-Schnittstellen.
Das Anfordern von Benachrichtigung über Ereignisse, welche von
Engineering-Objekten festgestellt wurden (z.B. der Beginn oder eine
Unterbrechung der Übertragung kontinuierlicher Daten). Auch hierfür
wird eine Schnittstellenreferenz an das Bindungsobjekt übermittelt.
Das Lösen der Bindung.
2.7.2
Binden in der Engineering-Modellierungssicht
Die in der Computational-Betrachtung vorgestellten Bindungen werden im
Engineering-Modell entweder als Kanäle oder als lokale Bindungen sichtbar.
Wenn sich die zu bindenden Objekte innerhalb derselben Kapsel befinden,
so wird die Bindung systemspezifisch realisiert und bedarf keiner weiteren
Engineering-Unterstützung. Befinden sich die Objekte aber in unterschiedlichen Kapseln (oder sogar in verschiedenen Knoten), so realisiert ein Kanal
die nötigen Verteilungstransparenzen.
28
2.7 ODP Stream-Binding-Konzepte
Abbildung 2.8 zeigt den Aufbau eines Kanals und verdeutlicht den Zusammenhang zur Computational-Betrachtung des Bindungsobjektes. Ein Kanal
besteht aus einer Konfiguration von Stub, Binder und Protocol Object.
Abbildung 2.8: Konfiguration eines Kanals
ControlIF
Binding
Object
Computational
Object
Computational
Object
Computational specification
Engineering specification
Node
Node
ControlIF
Capsule Cluster
Basic
Engineering
Object
Channel
Control
Object
Cluster
Basic
Engineering
Object
Stub
Stub
Binder
Binder
Protocol
Object
Nucleus
Channel
Capsule
Protocol
Object
Nucleus
Stubs interagieren direkt mit dem Basic-Engineering-Objekt. Sie kodieren und dekodieren die Parameter operationaler Schnittstellen
(engl. marshalling), wofür sie Informationen über den Typ der unterstützten
Schnittstelle benötigen. Die beiden anderen Bestandteile Binder und Protocol
Object benötigen keine typspezifischen Informationen über die Schnittstelle,
da sie komplette Nachrichten übertragen, ohne sie interpretieren zu müssen.
Das Binder-Element stellt die Ende-zu-Ende Integrität des Kanals sicher und
behandelt den Ausfall und die Migration von Objekten. Damit ist es verantwortlich für viele der Verteilungstransparenzen. Protocol Object realisiert die
Interaktionen zwischen den Binder-Elementen in der geforderten Qualität
und Zuverlässigkeit. Falls der Kanal technische oder organisatorische Grenzen überschreitet, so ist ein interceptor notwendig. Dieser ist in der Lage,
Format- und Protokollumsetzungen vorzunehmen oder die Berechtigung des
Zugriffs zu kontrollieren.
29
2.7.2.1 Etablierung eines Kanals
Das Binden in der Engineering-Modellierungssicht bedeutet das Aufbauen
eines Kanals zwischen zwei oder mehreren BEOs. Die erste Voraussetzung
dafür ist, daß die zu bindenden Schnittstellen identifiziert werden können.
Wenn eine Schnittstelle instanziiert wird, so wird von der Laufzeitumgebung
und dem Kern des Knotens ein eindeutiger Bezeichner vergeben. Dieser wird
als Schnittstellenreferenz (engl. Interface Reference) bezeichnet.
Die Empfehlung X.930 [14] beschreibt den konzeptionellen Aufbau einer Referenz, ihre Bestandteile sind:
eine Kennzeichnung des Typs (operational, stream oder signal),
die Adresse zur Zeit der Instanziierung (bezeichnet den Knoten innerhalb des Netzes und innerhalb des Knotens eindeutig die Schnittstelleninstanz),
zusätzliche, vom Typ abhängige Informationen.
Das Binden der Schnittstellen wird in Zusammenarbeit mit den Kernen der
beteiligten Knoten durchgeführt. Daher muß ein Kern beim Erzeugen einer
Schnittstellenreferenz hinreichende Informationen in der Referenz hinterlegen, wie der Kern zum Binden kontaktiert werden kann. Das bedeutet, daß
der Kern Kommunikationsschnittstellen identifizieren muß, an denen eine
Kern-Kern-Interaktion stattfinden kann. Dazu gehören das verwendete Protokoll und dafür spezifische Parameter. Die für die Kern-Kern Interaktion
verwendeten Schnittstellen und Protokolle sind im allgemeinen unabhängig
von denen, die für die Bindung der BEOs ausgewählt werden.
Im Referenzmodell ODP ist durch das Bindungsobjekt ein Konzept der
Computational-Modellierungssicht zur Bindung von Stream-Schnittstellen
beschrieben. In der Engineering-Modellierungssicht wird durch Kanäle die
verteilungstransparente Interaktion zwischen BEOs unterstützt.
Aufbauend auf diesen Konzepten kann der Transport kontinuierlicher Daten
zwischen multimedialen Anwendungen realisiert werden.
30
3 Realisierung der ODP
Stream-Binding-Konzepte
3.1
Einführung
Bereits mehrere Konsortien1 haben Spezifikationen verteilter Verarbeitungsumgebungen für multimediale Dienste entwickelt. Unter ihnen
Microsoft, DAVIC (Digital Audio-Visual Council), IMA (Interactive Multimedia Association, OMG und das TINA-Konsortium. Allen gemeinsam
ist ein objektorientierter Ansatz und eine Verankerung innerhalb der
Telekommunikations- und Computerindustrie. Sie unterscheiden sich jedoch in der Akzeptanz bei den Herstellern. Eine breite Unterstützung zu
erhalten, versprechen der von OMG veröffentlichte Standard „Control and
Management of Audio/Video Streams“ (AVS) sowie die TINA-Architektur.
AVS bildet eine geeignete Grundlage für die Entwicklung multimedialer
Anwendungen, während durch TINA u.a. eine detaillierte Architektur von
Transportnetzen beschrieben ist.
Die wesentlichen Konzepte von AVS und TINA werden im folgenden Kapitel
erläutert, bevor in Kapitel 5 das Modell eines integrierten Ansatzes vorgestellt wird.
Es werden die ODP-Konzepte für die Realisierung verteilter multimedialer
Dienste spezialisiert. Die Betrachtungen konzentrieren sich dabei auf das
Binden von Stream-Schnittstellen. Die damit in Zusammenhang stehenden
Konzepte der Informations, Computational- und Engineering- Modellierungssichten werden konkretisiert.
Aus den Betrachtungen zu beiden Standards werden sich Ansatzpunkte ergeben, an denen mit einer Integration von AVS in die TINA-Architektur begonnen werden kann.
1 Der
Begriff Konsortium steht hier verallgemeinernd für Organisation, Gruppen und
einzelne Unternehmen.
31
3 Realisierung der ODP Stream-Binding-Konzepte
3.2 Telecommunications Information Networking Architecture
Das TINA Konsortium (Telecommunications Information Networking Architecture Consortium) hat sich 1993 als ein Zusammenschluß international führender Firmen der Computer- und Telekommunikationsindustrie gegründet.
Ziel der auf fünf Jahre ausgelegten Unternehmung war es, eine offene Architektur für verteilte Anwendungen der Telekommunikation zu definieren.
Auf dieser Grundlage sollen eine schnelle Einführung und ein effizientes Management komplexer Anwendungen möglich sein. Die Entwicklung wurde
durch Laborexperimente und Feldversuche begleitet, bei denen die Architektur ständig auf ihre Anwendbarkeit überprüft wurde. Obwohl die Spezifikation noch nicht abgeschlossen ist, begann bereits die zweite Phase mit dem
Ziel, marktreife Produkte zu entwickeln.
Im folgenden Abschnitt werden die Grundlagen der durch das TINAKonsortium definierten Architektur vorgestellt.
3.2.1
Überblick über die TINA-Architektur
Die Architektur basiert auf objektorientierten Technologien. Sie integriert
Ergebnisse von ITU-T, vom ATM-Forum, von OMG und von anderen Organisationen. Sie wurde auf Grundlage des Referenzmodells für ODP entwickelt und spezialisiert dessen Konzepte für die Anforderungen verteilter
Telekommunikationsanwendungen. TINA setzt das Konzept der Trennung
zwischen Anwendungen und Kommunikationsinfrastruktur um, deutlich erkennbar an der Unterteilung der Architektur. Damit sind eine unabhängige
Weiterentwicklung einzelner Komponenten sowie die Integration bereits vorhandener, im allgemeinen TINA-unbewußter Anwendungen möglich.
3.2.2
TINA-Teilarchitekturen
Die TINA-Architektur ist in die folgenden vier Komponenten gegliedert:
Die Servicearchitektur definiert Konzepte zum Design und zur Implementierung von Telekommunikationsdiensten. Es wird ein allgemeines
Modell zum Abonnieren, zum Zugriff und zur Nutzung von Diensten
beschrieben.
Die Netzarchitektur beschreibt das Management von Netzen, dazu gehört auch der Aufbau von Verbindungen.
Die Computing-Architektur beschreibt die Umgebung, die Objektinteraktionen ermöglicht. Sie wird als Distributed Processing Environment
(DPE) bezeichnet.
32
Die Managementarchitektur beschreibt Komponenten zur Steuerung,
Verwaltung und Abrechnung der Nutzung von Ressourcen.
Die Architektur umfaßt eine Vielzahl von Modellen und Prinzipien, von denen nicht alle zum Verständnis der Stream-Binding-Konzepte betrachtet werden müssen. Notwendig sind der Aufbau der Verarbeitungsumgebung, die
Einordnung der Anwendungen in die Servicearchitektur, die Beschreibung
von Interaktionspunkten und der Aufbau von Stream-Flow- und NetworkFlow-Verbindungen.
3.2.3
Verteilte Verarbeitungsumgebung - DPE
Eines der Hauptziele des TINA-Konsortiums war die Spezifikation einer verteilten Verarbeitungsumgebung (engl. Distributed Processing Environment,
DPE). In der DPE-Spezifikation [16] werden die ODP-Engineering-Konzepte
einer verteilten Verarbeitungsumgebung konkretisiert. Diese Plattform bildet die Grundlage, auf der TINA-Anwendungen entwickelt werden können.
In der Computational-Modellierungssicht wird Objektinteraktion als Aufruf
von Funktionen an operationalen Schnittstellen bzw. als Transport kontinuierlicher Daten über Stream-Schnittstellen beschrieben. Im Mittelpunkt
stehen dabei die Beschreibung von Computational-Objekten und die Definition von Schnittstellen, über die Interaktionen stattfinden können. Die
Engineering-Modellierungssicht beschreibt, wie Objektinteraktion realisiert
werden kann. In dieser Ebene ist TINA-DPE eingeordnet. Die Umgebung erfüllt die vom Referenzmodell ODP an eine Engineering-Spezifikation gestellten Transparenz-Forderungen. Abbildung 3.1 zeigt den Aufbau der TINAInfrastruktur [21].
Abbildung 3.1: TINA DPE-Infrastruktur
applications
NCCE
A
DPE node A
DPE
platform B
NCCE
B
DPE node B
DPE
platform C
NCCE
C
infrastructure
DPE
platform A
DPE node C
kernel transport network
33
TINA-Anwendungen werden innerhalb von DPE-Knoten ausgeführt. Jeder
Knoten enthält eine DPE-Plattform, die folgende Aufgaben übernimmt:
Unterstützung des Objektlebenszyklus (Instanziierung, Aktivierung
und Deaktivierung von Engineering-Computational-Objekten2 (eCOs)).
Unterstützung von Objektkommunikation über operationale und
Stream-Schnittstellen.
Unterstützung von Anwendungen durch zusätzliche Dienste. (z.B. Namensdienst)
Aus Anwendungssicht abstrahiert die DPE-Plattform von der verwendeten Verarbeitungs- und Kommunikations-Hardware (Native Computing and
Communication Environment). Für Ende-zu-Ende-Verbindungen zwischen
DPE-Knoten ist das kernel-Transportnetz (kernel Transport Network) verantwortlich.
Die DPE-Plattform ermöglicht Interaktionen zwischen Objekten verschiedener DPE-Knoten. In der DPE-Spezifikation [21] wird OMG-CORBA (Common
Object Request Broker Architecture) als Basistechnolgie favorisiert. CORBA
beschreibt eine Architektur für die Interaktion verteilter Objekte. Wichtigster Bestandteil ist ORB (Object Request Broker). ORB ermöglicht die Ausführung von Operationen an entfernten Objekten. Viele der CORBA-Dienste
wurden mit einigen Erweiterungen als TINA-DPE Objektdienste integriert,
wie z.B. Notification-, Trading- und Naming-Service.
Abbildung 3.1 verdeutlicht die prinzipielle Trennung zwischen Anwendung
und DPE-Plattform. Damit wird eine von Transporttechnologien abstrahierende Infrastruktur geschaffen, auf deren Grundlage TINA-Anwendungen
entwickelt und betrieben werden können. Die Interaktionen zwischen Anwendung und DPE-Plattform, zwischen DPE-Plattformen untereinander
sowie zwischen DPE-Plattform und kTN werden durch Referenzpunkte
(engl. Reference Points, RPs) definiert.
3.2.4
Referenzpunkte
TINA nutzt verschiedene Konzepte des Referenzmodells ODP. Dazu zählen
die in Abschnitt 2.6 vorgestellten Referenzpunkte. Von den vier Kategorien
verwendet die TINA-Architektur die Interworking und Interchange RPs und
bezeichnet sie als Intra-Domain- bzw. Inter-Domain-Referenzpunkte. Domänen sind ein Konzept der Enterprise-Modellierungssicht und basieren auf Eigentum an Ressourcen.
2 Ein
Computational-Objekt wird in der Engineering-Modellierungssicht durch ein
Engineering-Computational-Objekt repräsentiert.
34
Anhand typischer Interessen und Funktionen wird eine Menge von Business
Roles identifiziert.
Ein Konsument (engl. Consumer) ist der Verbraucher von TINADiensten. Seine Teilnahme ist nicht durch das Erzielen von Gewinnen
motiviert.
Ein Makler (engl. Broker) bietet Informationen zum Finden von Anbietern und Diensten an.
Ein Drittanbieter (engl. 3rd-party Service Provider) bietet Dienste
zum Weiterverkauf an.
Ein Wiederverkäufer (engl. Retailer) bietet dem Konsumenten Dienste an, die von einem Drittanbieter eingekauft wurden.
Ein Verbindungsanbieter (engl. Connectivity Provider) bietet Dienste
zum Datentransport an.
Da der Vertreter einer Domäne gleichzeitig mehrere Business Roles einnehmen kann (z.B. Drittanbieter gegenüber einem Konsumenten und Konsument gegenüber einem Verbdindungsanbieter), werden Referenzpunkte nicht
zwischen Domänen sondern zwischen Business Roles identifiziert. Abbildung 3.2 zeigt die im TINA Business-Modell [28] bis jetzt identifizierten Referenzpunkte:
Abbildung 3.2: TINA Business Roles und Business Relationships
Business Relationships:
Application related
Broker
Ret
Bkr
Bkr
Bkr
Ret
Consumer
Retailer
3Pty
Bkr
3rd party
Service Provider
DPE related
RtR
TCon
TCon
ConS
3Pty
ConS
Connectivity
Provider
CSLN
Bkr
LNFed
Retailer
3Pty
3rd Party
Bkr
Broker
TCon
Terminal
Connection
ConS
Connectivity
Service
LNFed
Layer Network
Federation
CLSN
Client Server
Layer Network
TCon
Ein Referenzpunkt wird in mehreren Modellierungssichten spezifiziert, wobei die Informations- und die Computational-Beschreibung eine zentrale Rolle einnehmen.
35
Das Informationsmodell beschreibt die Informationen, die ausgetauscht werden. Die Computational-Modellierung beschreibt das Objektmodell und das
dynamische Verhalten von Objekten, z.B in Form von Event Traces. TINA
verwendet für die Beschreibung der Objekte ODL (Object Definition Language) [22]. Für jedes Objekt werden eine Verhaltensspezifikation in natürlicher (englischer) Sprache und eine Spezifikation der Schnittstellen des Objektes gegeben. Das Informationsmodell sowie Event Traces werden in OMTNotation beschrieben.
3.2.5
Servicearchitektur
TINA definiert ein allgemeines Sitzungsmodell (engl. Session Model) für alle
Dienste einer TINA-konformen Umgebung. Die Definition eines Dienstes ist
sehr weit gefaßt und beschreibt ihn als eine Menge von Funktionen, die von
einem Diensterbringer angeboten wird. Die Teilnehmer eines Dienstes werden durch eine Sitzung in eine temporäre (für die Zeit der Nutzung existierende) Relation gesetzt. In der Computational-Modellierungssicht setzt eine
Sitzung die bei einem Dienst beteiligten Computational-Objekte in Relation
zueinander.
Die Servicearchitektur [27] definiert eine grundsätzliche Trennung zwischen
dem Zugang (engl. Access) und der Nutzung (engl. Usage) des Dienstes. Während einer Access-Sitzung autorisiert sich ein potentieller Nutzer gegenüber
dem Anbieter eines Dienstes. Verläuft der Vorgang erfolgreich, instanziiert
der Anbieter eine Service-Sitzung und übermittelt dem Nutzer die notwendigen Informationen zum Zugriff. Probleme der Autorisierung und Sicherheit
werden in dieser Arbeit nicht betrachtet.
Innerhalb der Usage-Sitzung wird weiter in eine Service- und eine
Communication-Sitzung unterteilt.
Die Service-Sitzung bildet den Kontext einer temporären Beziehung zwischen
Teilnehmern eines Dienstes. Sie umfaßt Informationen und Funktionen zur
spezifischen Steuerung des Dienstes, der Vereinbarung von Dienstparametern sowie der Kontrolle über die Dienstteilnehmer.
Die Communication-Sitzung repräsentiert eine allgemeine Sicht auf StreamVerbindungen und eine technologieunabhängige Beschreibung von Kommunikationsressourcen zur Bereitstellung von Ende-zu-Ende Verbindungen. Eine Communication-Sitzung kann mehrere Verbindungen steuern,
die vom Typ Punkt-zu-Punkt oder auch Punkt-zu-Mehrpunkt sein können.
Für die technologische Realisierung von Ende-zu-Ende-Verbindungen auf
der Grundlage verfügbarer Kommunikationsressourcen (Netze) startet eine
Communication-Sitzung ein oder mehrere Connectivity-Sitzungen.
36
Eine Connectivity-Sitzung realisiert Netzverbindungen und verbirgt vor der
Communication-Sitzung netzwerktopologische Gegebenheiten. Dazu zählt
die Einbeziehung mehrerer Verbindungsanbieter oder das Aufbauen von Verbindungen über Teilnetze mit unterschiedlichen Technologien. Abbildung 3.3
zeigt eine integrierte Übersicht:
Abbildung 3.3: TINA Sitzungen
Consumer Domain
Retailer Domain
Access Session
3rd Party Domain
Access Session
Service Session
11
00
00
11
1
0
Communication Session
1
0
0
1
11
00
0
1
0
1
11
00
01
1
0
01
1
0
000
111
0
1
0
1
000
111
0
1
0
1
000
111
01
1
0
Connectivity Provider Domain
Connectivity Session
3.2.6
TINA-Connection-Management
Im Abschnitt 3.2.5 wurde erläutert, daß eine Communication-Sitzung eine
Connectivity-Sitzung startet, um für Stream-Verbindungen zwischen Anwendungen eine Menge von Netzverbindungen aufbauen zu lassen. Die Trennung
in zwei Sitzungen entspricht dem Ansatz, Verbindungen aus einer logischen,
applikationsorientierten sowie einer netzwerkorientierten Sichtweise zu beschreiben. Bei der Modellierung des TINA-Connection-Managements in der
Informations- und Computational-Modellierungssicht werden StreamFlowund Network-Flow-Verbindungen unterschieden. Mit diesen Ressourcen arbeitet das TINA-Connection-Management.
3.2.6.1
Informationsmodellierung des Connection-Managements
Die Spezifikation des Network Resource Information-Modells NRIM [26] beschreibt das Informationsmodell eines TINA-Netzes.
37
Um unterschiedlichen Schwerpunkten bei der Betrachtung gerecht zu werden, wurde das Modell in vier Fragmente geteilt:
(1) Network
Fragment:
Es wird die topologische Struktur eines Netzes beschrieben. Das gesamtheitlich als Connectivity Layer
Network (CLNW) bezeichnete Netz wird als Komposition einzelner Layer Networks (LNW) dargestellt.
(2) Connectivity
Fragment:
Es werden Informationsobjekte und Beziehungen definiert, die für die Beschreibung von Verbindungen
notwendig sind.
(3) Termination
Point Fragment:
Die charakteristischen Informationen der Terminierungspunkte von Verbindungen werden beschrieben.
(4) Other
Fragments:
Es werden Informationsobjekte für die Abbrechnung
von Leistungen und der Umgang mit Fehlersituationen beschrieben.
Die Fragmente (2) und (3) sind für eine Integration von AVS-konformen Produkten auf der Basis eines unveränderten TINA-Netzes wichtig, da beide
Fragmente in Beziehung zur Schnittstelle zwischen DPE und Connectivity
Layer-Netz stehen.
Abbildung 3.4 zeigt die logische Sicht auf ein TINA-Netz. Die Realisierung von Verbindungen über unterschiedliche Teilnetze wird vor den Anwendungen verborgen, sodaß sie auf Anwendungsebene als Ende-zu-EndeVerbindungen sichtbar sind.
Abbildung 3.4: Stream-Binding auf Anwendungsebene
Application
(CPE attached to network)
CO
Stream
Interface
CO
TINA
Network
CO
Stream Flow Connection
Source Stream Flow End Point
Sink Stream Flow End Point
Die Anwendungen verfügen über Stream-Schnittstellen, wie sie im ODPKapitel 2.5.3 eingeführt wurden.
38
Eine Stream-Schnittstelle ist eine Menge von Quellen und Senken, die innerhalb der TINA-Architektur als Stream Flow End Points (SFEPs) bezeichnet
werden. Ein SFEP-Objekt beschreibt einen Terminierungspunkt, der Daten
empfängt oder sendet. SFEP ist ein Informationsobjekt und besitzt die folgenden Attribute:
Attribut
Bedeutung
Name
Bezeichnung des SFEP-Objektes.
Direction
SFEPs sind unidirektional. Direction kann die Werte
source oder sink annehmen.
Administrative
State
Kann den Zustand locked oder unlocked annehmen.
Unlocked zeigt an, daß eine Verbindung besteht und
Daten transportiert werden können.
FlowQoS
Beschreibt applikationsbezogene QoS-Parameter.
Verbindung zwischen SFEPs werden durch Stream-Flow-Verbindungen
(Stream Flow Connections, SFCs) modelliert. SFCs transportieren Informationen in unidirektionaler Weise von einer Quelle zu einer oder mehreren
Senken.
Verbindungsgraphen
Der Aufbau sowie die Modifikation von Verbindungen läßt sich in der Informationsmodellierungssicht durch die Manipulation von Verbindsgraphen
(engl. Connection Graph, CG) beschreiben. Sie erlauben eine Modellierung
auf unterschiedlichen Abstraktionsniveaus.
Das aus dem Eurescom Projekt P 103 [18] stammende Konzept wurde in die
TINA-Architektur vereinfacht übernommen. Von dem in Abbildung 3.5 gezeigten abstrakten Klassendiagramm können spezialisierte Graphen abgeleitet werden.
Abbildung 3.5: Klassendiagramm eines abstrakten Verbindungsgraphen
Connection Graph
1..*
Flow Connection
ConnectionTopology
Flow Connection
Branch
OperationalState
Root
Flow End Point
1..*
Leaf
Directionality
39
Ein Verbindungsgraph enthält eine oder mehrere Flow-Verbindungen
(engl. Flow Connections, FCs). Eine Flow-Verbindung setzt Flow-Endpunkte
(engl. Flow End Points, FEPs) in Relation zueinander. Das Attribut
ConnectionTopology beschreibt die Topologie der Verbindung. Genau ein
FEP-Objekt nimmt die Rolle „Root“ (Quelle) und mindestens ein Objekt
die Rolle „Leaf“ (Senke) ein. Dadurch lassen sich Punkt-zu-Mehrpunkt
Verbindungen modellieren. Eine solche Verbindung besteht aus einzelnen
Punkt-zu-Punkt Verbindungen zwischen einem Leaf- und dem gemeinsamen Root-Terminierungspunkt. Ein Zweig (engl. Branch) repräsentiert
eine solche Beziehung zwischen einer Flow-Verbindung und einem LeafTerminierungspunkt. Den Zustand des Zweiges beschreibt das Attribut
OperationalState.
Neben der Eigenschaft, Quelle oder Senke von Informationen zu sein (Directionality), besitzt ein Terminierungspunkt weitere Attribute, die vom Niveau
der Abstraktion abhängig sind.
Vom abstrakten Verbindungsgraphen wird für die Modellierung von Verbindungen innerhalb der TINA-Sitzungen ein Logical-, Nodal- und PhysicalVerbindungsgraph abgeleitet.
Das Konzept der Verbindungsgraphen wird innerhalb der Communicationund Connectivity-Sitzung verwendet, um Anforderungen zum Aufbau von
Verbindungen auszudrücken.
Die Communication-Sitzung beschreibt Verbindungen auf Anwendungsebene. Die innerhalb einer Sitzung aufgebauten Verbindungen werden in einem
Logical-Connection-Graphen (LC-Graphen) gruppiert.
Abbildung 3.6: Klassendiagramm eines Logical-Connection-Graphen
Logical Connection Graph
1..*
ConnectionTopology
Branch
{ xor }
Root
Stream Flow End Point
OperationalState
Leaf
1..*
Ein LC-Graph enthält Stream-Flow-Verbindungen (SFCs), die Stream-FlowEndpunkte (SFEPs) zueinander in Relation setzen. Während der abstrakte
Graph bidirektionale Verbindungen zuläßt, beschreibt das Informationsmo-
40
dell SFCs immer als unidirektional. Diese Eigenschaft drückt sich in der Beschränkung aus, daß ein Endpunkt entweder die Rolle „Root“ oder „Leaf“ einnimmt. Ein „Root“-Endpunkt kann an mehrere „Leaf“-Endpunkte gebunden
sein, wodurch Punkt-zu-Mehrpunkt Verbindungen modelliert werden können.
Die SFEP-Attribute beschreiben die Charakteristik der kontinuierlichen Daten, die von einem SFEP-Objekt gesendet bzw. empfangen werden.
Der Austausch kontinuierlicher Daten zwischen Anwendungen, modelliert
durch LC-Graphen, benötigt eine Unterstützung auf Netzebene. Auf physikalischer Ebene ist ein TINA-Netz in zwei Hauptteile gegliedert. Den einen
Teil bildet das Connectivity-Layer-Netz, den anderen bilden die kommunikationsbezogenen Ressourcen innerhalb eines DPE-Knotens. Dieser kann entweder ein multimediales Endgerät (z.B. Video-Telefon) oder ein Computer mit
TINA-konformen Anwendungen sein. Das Connectivity-Layer-Netz ist die Zusammenfassung aller Komponenten des Transportnetzes.
Das Transportnetz übernimmt bzw. übergibt Daten an einem Network-FlowEndpunkt (NFEP). Ein NFEP-Objekt ist ein Informationsobjekt, das einen
technologieunabhängigen Endpunkt einer Netzverbindung repräsentiert. Die
Verbindung zwischen zwei oder mehreren NFEP-Objekten wird durch eine
Network-Flow-Verbindung (NFC) modelliert. Im Gegensatz zu einem SFEPObjekt kann ein NFEP-Objekt gleichzeitig Quelle als auch Senke von Informationen sein. Damit kann eine Network-Flow-Verbindung eine der folgenden Konfigurationen besitzen:
Eine bidirektionale Punkt-zu-Punkt-Verbindung zwischen zwei NFEPObjekten. Informationen werden in beide Richtungen übertragen.
Eine unidirektionale Punkt-zu-Punkt-Verbindung zwischen zwei
NFEP-Objekten. Informationen werden vom „Root“-NFEP zum „Leaf“NFEP übertragen.
Eine unidirektionale Punkt-zu-Mehrpunkt-Verbindung. Informationen
werden von einem „Root“-NFEP zu mehreren „Leaf“-NFEPs übertragen.
Network-Flow-Verbindungen bilden einen Physical-Connection-Graphen, das
Klassendiagramm entspricht dem in Abbildung 3.6 gezeigten. Die Einschränkung, daß ein Endpunkt nur eine der beiden Rollen annehmen kann, gilt nur
für den Fall, daß die Network-Flow-Verbindung die Konfiguration Punkt-zuMehrpunkt besitzt.
Die Unterscheidung in anwendungs- und netzbezogene Endpunkte erfordert
die Modellierung einer weiteren Ressource, der Terminal-Flow-Verbindungen
(TFCs). Diese entstehen durch das Binden von SFEP- an NFEP-Objekte.
41
Die Spezifikation des Network-Resource-Information-Modells erlaubt auch
eine Terminal-Flow-Verbindung zwischen zwei SFEP-Objekten (Kardinalität 1,2 im Nodal-Connection-Graphen). Voraussetzung ist, daß sich alle
Endpunkte innerhalb des gleichen Knotens (CPE) befinden. Damit können
Stream-Flow-Verbindungen innerhalb eines Knotens modelliert werden.
Die Informationsobjekte SFEP und NFEP beschreiben die Charakteristik der
übertragenen Informationen auf unterschiedlichem Niveau. Einem SFEPObjekt sind anwendungsorientierte QoS-Parameter zugeordnet, während einem NFEP-Objekt netzbezogene Parameter zugeordnet sind. Die Abbildung
bzw. Anpassung der Parameter ist Aufgabe der Terminal-Flow-Verbindung.
Abbildung 3.7: Dekomposition einer Stream-Flow-Verbindung in zwei
Terminal- und eine Network-Flow-Verbindung
DPE Node
Terminal Flow
Connection
Transport Network
DPE Node
Terminal Flow
Connection
Application
Application
Network Flow
Connection
SFEP
NFEP
NFEP
SFEP
Es ist möglich, daß mehrere TFCs in einem Terminal ein gemeinsames
NFEP-Objekt haben, so daß ein Multiplexing mehrerer Stream-FlowVerbindungen auf eine einzige Network-Flow-Verbindung möglich ist. Umgekehrt können mehrere NFEP-Objekte einem SFEP-Objekt zugeordnet
werden, sodaß eine Stream-Flow-Verbindung durch mehrere Network-FlowVerbindungen unterstützt werden kann.
Eine Terminal-Flow-Verbindung bildet einen unidirektionalen Transportweg
zwischen Endpunkten unterschiedlichen Typs, die sich immer im gleichen
DPE-Knoten befinden. Da es sich um eine Punkt-zu-Punkt-Verbindung handelt, existieren keine Zweige im Verbindungsgraphen.
Abbildung 3.8: Klassendiagramm eines Nodal-Connection-Graphen
Nodal Connection Graph
1..*
42
1,2
Terminal Flow Connection
0,1
Network Flow End Point
Innerhalb der Communication-Sitzung können Verbindungen mit Hilfe von
Verbindungsgraphen und den bereits vorgestellten Informationsobjekten beschrieben werden. Die Communication-Sitzung startet eine ConnectivitySitzung, um Network-Flow-Verbindungen durch verfügbare Netzressourcen
zu realisieren. Die TINA-Netzarchitektur wird durch ein sehr detailliertes Informationsmodell beschrieben. In dieser Arbeit ist die Schnittstelle zwischen
Transportnetz und DPE-Knoten interessant, und damit auch die als Informationsobjekte modellierten Terminierungspunkte Network Trail Termination Point (NWTTP) und aufgrund einer Kolokationsbeziehung das Objekt
Network Connection Termination Point (NWCTP).
Abbildung 3.9: Struktur eines Layer-Netzes
NWCTP
NWTTP
Subnetwork1
NWTTP
Subnetwork2
Subnetwork
Connection
Subnetwork3
Link Connection
Trail
Verbindungen zwischen DPE-Knoten werden durch Trails repräsentiert.
Trails terminieren in NWTTPs, die die charakteristischen Parameter einer
Ende-zu-Ende-Verbindung beschreiben. Die NRIM-Spezifikation motiviert,
Spezialisierungen von NWCTP abzuleiten, die technologieabhängige Attribute enthalten.
Ein Layer-Netz besteht aus mehreren Teilnetzen (engl. Subnetworks), die
durch Links miteinander verbunden sind. Die Bereitstellung einer TrailVerbindung erfordert den Aufbau von Verbindungen in allen Teilnetzen, die
durch die Trail-Verbindung überspannt werden. Wie Abbildung 3.9 verdeutlicht, ist einem Trail-Terminierungspunkt immer ein NWCTP am gleichen
Ort zugewiesen.
Der vorgestellte Teil des Informationsmodells hat Terminierungspunkte und
Verbindungen auf unterschiedlichem Niveau gezeigt, die für die Anbindung
eines DPE-Knotens an ein Netz wichtig sind.
43
3.2.6.2 Computational-Modellierung des Connection-Managements
In der Computational-Modellierungssicht wird das Connection-Management
durch eine Menge interagierender Computational-Objekte beschrieben. Im
Gegensatz zu anderen Ansätzen, bei denen Verbindungen durch eine zentrale Instanz gesteuert werden3 , wird das Management von Ressourcen verteilt
durchgeführt. Dadurch wird eine Steuerung großer Netze möglich, und es
werden Anforderungen an Skalierbarkeit und administrative Autonomie erfüllt. Eine ODL-Beschreibung der Computational-Objekte ist im Anhang von
Network Components Specification [24] nachzulesen.
Die Schnittstellen, an denen Objekte über Domängrenzen hinweg interagieren, sind in den Computational-Spezfikationen der jeweiligen Referenzpunkte beschrieben.
Abbildung 3.10: Computational-Modellierungssicht
Ret−RP
Service Provider Domain
UAP
SSM
Service Session
TCSM
CSM
Communication
Session
CC
Connectivity
Session
FCC
TCon−RP
LNC
TLA
TM
Consumer Domain
Connectivity Provider Domain
UAP: User Application
TCSM: Terminal Communication
Session Manager
TLA:
Layer Network
SSM: Service Session Manager
FCC: Flow Connection Controller
CSM: Communication Session Manager LNC: Layer Network Coordinator
CC: Connection Coordinator
TM: Trail Manager
Terminal Layer Adapter
Interaktionen zwischen Computational-Objekten
UAP repräsentiert eine TINA-Anwendung in der Domäne des Nutzers. Die
Anwendung verfügt i.A. über Stream-Schnittstellen und hat somit Bedarf an
3 Einen
44
solchen Ansatz stellt OMG Audio/Video Streams dar.
der Bereitstellung von Flow-Verbindungen zur Übertragung kontinuierlicher
Daten.
In jedem Terminal existiert genau ein Terminal-Communication-SessionManager-Objekt (TCSM). TCSM ist für die Zuordnung von SFEPs zu NFEPs
verantwortlich. NFEPs werden durch eines der Terminal-Layer-AdapterObjekte (TLA) bereitgestellt.
Zur Nutzung eines vom Provider angebotenen Dienstes interagiert die
Anwendung mit einem dienstspezifischen Service-Session-Manager-Objekt
(SSM). Zu den Aufgaben des SSM-Objektes zählt die Steuerung über die Teilnehmer der Sitzung. Dazu besitzt es Operationen zum Hinzufügen, Einladen
und Entfernen von Nutzern, sowie zur Modifikation der Bindungen zwischen
Stream-Schnittstellen.
Multimediale Dienste erfordern die Übertragung kontinuierlicher Daten
zwischen den Teilnehmern. Um Stream-Flow-Verbindungen zwischen Anwendungen bereitzustellen, erzeugt das SSM-Objekt einen CommunicationSession-Manager (CSM). Ein CSM-Objekt kann eine oder mehrere StreamFlow-Verbindungen steuern. Dazu bietet es Operationen zum Erzeugen
und Aktivieren von Stream-Flow-Verbindungen sowie zum Hinzufügen
und Entfernen von Zweigen bestehender Verbindungen an. Stream-FlowVerbindungen werden durch die in Abschnitt 3.2.6.1 vorgestellten Logical
Connection-Graphen beschrieben.
Das CSM-Objekt ist verantwortlich für die Abbildung der Stream-Flow- auf
Network-Flow-Verbindungen. CSM beauftragt Objekte der Verbindungsanbieterdomäne mit der Bereitstellung der Network-Flow-Verbindungen. Wähend dieses Prozesses wird eine Trail-Verbindung bereitgestellt. Für den
Trail-Terminierungspunkt (NWTTP) wird vom Terminal Layer Adapter ein
NFEP-Objekt erzeugt und an Terminal Communication Session Manager
übermittelt. TCSM kann durch Zuordnung der NFEPs zu SFEPs des ssUAPObjektes die nodalen Bindung abschliessen.
Sobald die Terminal-Flow-Verbindungen aufgebaut sind, ist der StreamBinding-Prozeß mit ssUAP abgeschlossen. Der Dienst kann gestartet und
kontinuierliche Daten zwischen den Stream-Schnittstellen transportiert werden.
45
3.3 OMG Control and Management of Audio / Video Streams
3.3.1
Überblick über der AVS-Standard
Die Verfügbarkeit hoher Netzbandbreiten und die steigende Leistungsfähigkeit von CPUs führen zu einer wachsenden Bedeutung von Anwendungen, die eine Übertragung kontinuierlicher Daten benötigen. Aktuelle Netztechnologien schaffen die technische Grundlage für eine steigende Qualität
multimedialer Übertragungen.
Verteilte Verarbeitungsumgebungen wie CORBA [6] unterstützen eine Anfrage/Antwort Semantik verteilter Anwendungen. Implementierungen des
CORBA Internet-Inter-ORB-Protokolls (IIOP) führen für jede Anfrage eine
Speicheranforderung aus und kopieren die Daten mehrmals, wodurch die Latenzzeit deutlich erhöht wird. Zusätzlich benötigt das Kodieren und Dekodieren der Daten viel CPU-Zeit und führt zu einem geringen Datendurchsatz.
Wenn Erweiterungen möglich sind, die einen hohen Durchsatz mit geringer
Latenzzeit ermöglichen, können multimediale Anwendungen von der Portierbarkeit und Flexibilität profitieren, die ihnen CORBA bietet.
Die OMG erkannte 1996 dieses Problem und veröffentlichte ein RFPDokument (engl. Request For Proposal) mit dem Titel „Control and Management of Audio/Video Streams“ [7]. Es erbittet Lösungsvorschläge, um OMA4 konformen Anwendungen die Übertragung kontinuierlicher Daten zu ermöglichen. Damit können in standardisierter Form Stream-Verbindungen zwischen Objekten aufgebaut und gesteuert werden.
Auf das RFP-Dokument antworteten die Firmen IONA [15], Lucent [30] und
Siemens-Nixdorf [3]. Aus den initialen Einsendungen wurde ein gemeinsamer Ansatz [8] entwickelt und der OMG als überarbeiteter Vorschlag eingereicht. Er wurde im Dezember 1998 von der OMG als offizieller Standard
angenommen. Dieser wird in dieser Arbeit kurz als AVS bezeichnet.
AVS beschreibt Informationen nicht durch Informationsobjekte und Beziehungen. In Vorbereitung eines integrierten Modells von TINA und AVS wird
in Kapitel 3.3.3 ein Informationsmodell für den AVS-Standard entworfen.
3.3.2
Konzepte des Standards
3.3.2.1 Erweiterung der Object-Management-Architektur
Die Object-Management-Architektur (OMA) bildet die Grundlage aller Entwicklungen der OMG. Sie besteht aus den fünf Komponenten Object Request
Broker (ORB), Object Services, Common Facilities, Domain Interface und
4 OMA:
46
Object Management Architecture, das grundlegende Objektmodell der OMG
Application Objects.
ORB ermöglicht verteilungstransparente Interaktionen zwischen Objekten
und realisiert die Engineering-Unterstützung für das ODP-Konzept einer
operationalen Schnittstelle. Es werden die beiden Operationsarten „Anzeige“
und „Anfrage“ unterstützt. Der Austausch kontinuierlicher Daten zwischen
Stream-Schnittstellen ist über ORB nicht möglich und war bei der CORBAEntwicklung auch nicht vorgesehen. Insbesondere lassen sich keine Aussagen über die Verzögerung der Datenübertragung von Klient zu Server oder
den erreichbaren Durchsatz beim Datentransport treffen. Gerade diese Parameter sind entscheidend für multimediale Anwendungen. CORBA gewährleistet die Sicherheit der Datenübertragung, die bei operationaler Objektinteraktion in den allermeisten Fällen auch notwendig ist. Das Ziel bei der Übertragung kontinuierlicher Daten ist aber nicht absolute Verlustfreiheit, sondern das kontinuierliche Eintreffen der Daten beim Empfänger. Das erneute
Senden verlorener Pakete führt zu einer Verzögerung der nachfolgenden Daten. Bei einer Videoübertragung würde dieses Vorgehen zu „Ruckeln“ und zu
Asynchronität zwischen Bild und Ton führen. Die menschliche Warnehmung
reagiert am empfindlichsten auf Störungen einer Audioübertragung. Während Bildprobleme noch tolleriert werden, sinkt die Akzeptanz eines Dienstes
bei Tonstörungen erheblich.
Sicherheit und Kontinuität bei der Datenübertragung verhalten sich orthogonal zueinander und können mit verschiedenen Technologien realisiert werden.
Abbildung 3.11 zeigt die im AVS-Standard verwendete Architektur, wie sie
bereits im RFP-Dokument [7] vorgeschlagen wurde:
Abbildung 3.11: OMG Streams-Architektur
StreamEndPoint
Stream
Stream
Flow Data
EndPoint
(Source)
Interface
Control
Object
Control and
Management
Object
Interface
Control
Object
Data Flow
Stream
Adapter
Flow Data
EndPoint
(Sink)
Data Flow
Basic Object
Adapter
Basic Object
Adapter
Stream
Adapter
ORB Core
Request
Flow
47
Die in der Abbildung herausgestellte Gruppierung mit der Bezeichnung
„StreamEndPoint“ besteht aus drei logischen Bestandteilen: einem Objekt
mit Schnittstellen zur Steuerung der Gruppierung, einem Objekt, das kontinuierliche Daten produziert bzw. konsumiert, und einem Adapterobjekt das
Daten über ein Netz transportiert. AVS spezifiziert die Schnittstellen des
Management- sowie des Steuerungsobjektes und beschreibt Interaktionsszenarien.
Objektinteraktionen innerhalb der StreamEndPoint-Gruppierung sowie der
Datenfluß zwischen Quelle/Senke und Adapterobjekt werden nicht spezifiziert. Dadurch sind gerätespezifische Optimierungen möglich. Insbesondere
bleibt offen, ob die Flow-Terminierung durch Hardware- oder Softwarekomponenten realisiert wird.
Die Abbildung verdeutlicht, daß die Übertragung kontinuierlicher Daten
zwischen Quellen und Senken über einen ORB-unabhängigen Transportweg erfolgt. Nur die Konfiguration der Stream-Adapter zur Bereitstellung
eines Transportpfades erfolgt über CORBA-Interaktionen zwischen dem
Steuerungs- und den Adapter-Objekten. Diese Differenzierung ist entscheidend für das Erreichen einer hohen Performanz.
Der AVS-Standard beschreibt IDL-Schnittstellen, Interaktionsszenarien und
ausgetauschte Informationen.
3.3.2.2 Ziele der Streaming-Architektur
Die Ziele der AVS-Spezifikation sind:
Standardisierter Aufbau und Steuerung von Stream-Verbindungen. Dadurch können Produkte für Anbieter und Konsumenten
von Inhalten unabhängig voneinander entwickelt werden, während die
Kompatibilität aller Produkte gesichert ist.
Unterstützung unterschiedlicher Transportprotokolle. Um eine
performante Stream-Verbindung zu realisieren, können Transportprotokolle wie z.B. UDP [20], TCP [1] oder AAL5 [2] verwendet werden. Die
Architektur erlaubt die Verwendung weiterer, eventuell erst in Zukunft
entwickelter Protokolle.
Unterstützung unterschiedlicher Typen von Quellen und Senken. Die AVS-Architektur erlaubt die Stream-Terminierung sowohl
in Hard- als auch in Software. Das ermöglicht z.B. eine Video-FlowGenerierung aus einer Kamera oder einem Videoserver gleichermaßen.
48
3.3.2.3
Komponenten der Streaming-Architektur
Die AVS-Spezifikation standardisiert eine Menge von Schnittstellen die zur
Implementierung multimedialer Anwendungen geeignet sind. Die Schnittstellen ermöglichen:
die Konfiguration multimedialer Geräte,
Stream-Flow-Endpunkte von Anwendungen bereitstellen zu lassen, und
die den Aufbau und Steuerung von Stream-Verbindungen.
Die Konfiguration der Geräte umfaßt alle notwendigen Parametriesierungen
des Senders sowie aller Empfänger. Das Ziel besteht in der Festlegung auf
ein Format der kontinuierlichen Daten sowie zusätzliche QoS-Parameter.
Abbildung 3.12 zeigt die Komponenten der AVS-Spezifikation.
Abbildung 3.12: Komponenten der AVS-Spezifikation
StreamCtrl
MMDevice
MMDevice
VDev
VDev
StreamEndPoint
StreamEndPoint
Producer
One object per device
Consumer
One object per stream
MultiMedia Device
Die MMDevice-Schnittstelle abstrahiert die spezifischen Eigenschaften von
multimedialen Geräten. Diese können in Form physischer Geräte wie z.B. Kameras oder in logischer Form wie z.B. Dateien existieren. Sie unterstützt eine
potentiell beliebige Anzahl von Stream-Verbindungen indem es für jede Verbindung ein virtuelles Gerät (VDev) sowie einen Stream-Terminierungspunkt
(StreamEndPoint) bereitstellt.
49
VDev
Eine VDev-Schnittstelle wird dynamisch von MMDevice bei der Beantwortung einer Stream-Verbindungsanfrage erzeugt.
Jedes Gerät unterstützt eine Menge von Kodierungen. Die VDev-Schnittstelle
erlaubt die Festlegung einer Kodierung sowie das Aushandeln von QoSParametern mit der Gegenstelle. Für diese Aufgabe stellt die Schnittstelle die Operationen set_format(string flowname, string format) sowie set_dev_params(string flowname, propSeq props) bereit. Die
Menge der unterstützten Kodierungen sowie die akzeptierbare Bandbreite
der QoS-Parameter kann über Properties festgestellt werden.
StreamCtrl
Die StreamCtrl-Schnittstelle ermöglicht die Bereitstellung von StreamVerbindungen zwischen zwei oder mehr MMDevice-Objekten.
StreamCtrl ist die OMG-Realisierung des ODP-Bindungsobjektes. Die
StreamCtrl-Schnittstelle bietet Operationen zum Auf- und Abbau sowie
zur Steuerung von Stream-Verbindungen an.
StreamEndPoint
Eine StreamEndPoint-Schnittstelle wird dynamisch von MMDevice für jede
aufzubauende Stream-Verbindung erzeugt. Während VDev für das Format
der Daten verantwortlich ist, ist es Aufgabe des StreamEndPoint-Objektes
Daten an einem Netzterminierungspunkt zur Verfügung zu stellen oder von
dort zu empfangen. Das StreamEndPoint-Objekt verbirgt die transportspezifischen Parameter einer Stream-Verbindung. Dazu zählen das verwendete
Protokoll sowie davon abhängige Parameter.
3.3.3
Die AVS Informationsspezifikation
Der AVS-Standard enthält kein explizites Informationsmodell, so wurden
keine Informationsobjekte im Sinne von RM-ODP identifiziert. Dennoch lassen sich die enthaltenen Informationen aus Properties (engl. Eigenschaften)
ableiten, die Computational-Objekten zugeordnet worden sind. Anhand dieser Properties können Informationsobjekte und Beziehungen beschrieben
werden. Zur Vorbereitung eines integrierten Informationsmodells von AVS
und aus Bestandteilen von TINA, wird in diesem Kapitel ein Informationsmodell für den AVS-Standard entworfen. Dazu werden Informationsobjekte
und ihre Beziehungen untereinander bestimmt.
50
AVS beschreibt ein Rahmenwerk, das den Austausch kontinuierlicher Daten
zwischen multimedialen Anwendungen ermöglicht. In diesem Zusammenhang werden Informationen verwaltet, die:
Senken bzw. Quellen von Informationen beschreiben in Bezug auf
Quality-of-Service der Daten die sie liefern bzw. empfangen können,
den Endpunkt eines Transportnetzes beschreiben in Bezug auf spezifische Parameter des Netzprotokolls,
Assoziationen zwischen
Verbindungen,
Endpunkten
beschreiben,
also
Stream-
die Kodierung der kontinuierlichen Daten auf Anwendungsebene charakterisieren,
für eine Verbindung vereinbarte Quality-of-Service-Parameter beschreiben.
Diese Informationen werden durch die beiden Informationsobjekte
StreamFlowEndPoint und StreamFlowConnection modelliert. Zusätzlich
werden zwei Aggregationsobjekte StreamEndPoint und StreamConnection
eingeführt. StreamEndPoint repräsentiert eine Stream-Schnittstelle, die
durch StreamConnection in Relation zu anderen Schnittstellen gesetzt wird.
Es gibt in AVS keine Informationsobjekte, die vergleichbar sind mit denen
aus TINA bekannten Objekten NetworkTrailTerminationPoint (NWTTP) oder
dessen abstrakter Repräsentation NetworkFlowEndPoint (NFEP). Diese Informationsobjekte werden in TINA als eigenständige Objekte modelliert, da
sie unabhängig von einer Relation zu einem SFEP-Objekt existieren und manipuliert werden können. Ein NWTTP-Objekt kann als Terminierungspunkt
einer Ende-zu-Ende-Verbindung bereitgestellt werden, ohne daß er in Verbindung mit einem SFEP-Objekt steht. Diese Trennung ist in AVS nicht möglich. Ein Netzterminierungspunkt kann nur durch ein SFEP-Objekt erzeugt
und mit einem anderen verbunden werden. Die Idee, einen Netzterminierungspunkt als eigenständiges Objekt in das Informationsmodell aufzunehmen, entspricht also nicht dem AVS-Konzept. Informationen, die die Charakteristik und den Zustand des Terminierungspunktes beschreiben, sind so
eng mit einem SFEP-Objekt verbunden, daß sie als Attribute in das SFEPInformationsobjekt eingehen.
Informationsobjekt StreamFlowEndPoint
Das Informationsobjekt StreamFlowEndPoint (SFEP) beschreibt die charakteristischen Eigenschaften einer Quelle oder Senke kontinuierlicher Daten.
Dazu zählen unterstützte Medienformate, sowie Parameter von Netzprotokollen.
51
Das Format der Daten kann ein definiertes und damit für alle Seiten bekanntes Byte-Layout wie z.B. MPEG sein. Um beliebige IDL-getypte Daten
zu übertragen, wird in AVS ein spezielles Protokoll eingeführt. Das als Simple
Flow Protocol (SFP) bezeichnete Protokoll definiert die Struktur von Nachrichten, die zwischen Sender und Empfänger ausgetauscht werden können.
Eine Nachricht enthält u.a. den Typ, die Gesamtlänge und eine variable Anzahl von Nutzdaten. Da SFP nur die Struktur und die logische Abfolge von
Nachrichten definiert, ist die Interpretation der Nutzdaten nicht festgelegt.
SFP ist optional in Bezug auf Unterstützung und Verwendung. Es kann dynamisch festgestellt werden, ob der Partner SFP unterstützt und dann entschieden werden, ob SFP als Transportprotokoll verwendet wird.
Wenn anstatt SFP ein bekanntes Audio- oder Video-Format verwendet wird,
so wird es durch zusätzliche QoS-Parameter charakterisiert. Das Aushandeln der Parameter setzt ihre eindeutige Bezeichnung voraus. Zu diesem
Zweck definiert AVS eine Menge von Parametern speziell für Audio- und
Video-Flows. Diese Parameter werden von den Geräten ausgetauscht, um die
Stream-Kompatibilität zu sichern.
Es muß mindestens ein Transportprotokoll vom unterstützen werden. Ein
SFEP-Attribut beschreibt das verwendete Protokoll und eine dazu spezifische Adresse. Diese Adresse beschreibt eindeutig den Terminierungspunkt
der Netzverbindung.
Die Attribute des Informationsobjektes StreamFlowEndPoint und eine Beschreibung ihrer Bedeutung gibt die folgende Tabelle. Die Attribute sind abgeleitet aus Properties von Computational-Objekten.
Attribut
Bedeutung
Direction
Charakterisiert den SFEP als Quelle oder Senke.
FlowName
Enthält den Flow-Namen.
AvailableFormats Enthält eine Liste der unterstützten Kodierungen.
(z.B. “MPEG, MJPEG “)
UsedFormat
Beschreibt die für eine Stream-Flow-Verbindung
vereinbarte Kodierung.
ApplicationQoS
Enthält die für eine Stream-Flow-Verbindung vereinbarten Quality-of-Service-Parameter der Kodierung. (z.B. “video_framerate=25“)
NetworkQoS
Enthält eine Liste der für eine Transportverbindung vereinbarten Quality-of-Service-Parameter. (z.B. “Bandwith_Min=115000“)
NetworkAddress
Beschreibt das verwendete Netzprotokoll und eine für dieses Protokoll spezifische Adresse. (z.B.
“TCP=vidserver.linux.org:31000“)
52
Eine einheitliche Bezeichnung für die Namen der ApplicationQoS- und
NetworkQoS-Parameter, der gültigen Belegungen sowie der Einheiten numerischer Werte wurden im AVS-Standard definiert.
Informationsobjekt StreamFlowConnection
Die Bindung von SFEPs wird durch das Informationsobjekt StreamFlowConnection (SFC) modelliert. Durch SFC wird eine Quelle mit einer oder
mehreren Senken in Beziehung zueinander gesetzt. Die Topologie wird durch
das Attribut Topology beschrieben.
Informationsobjekte StreamInterface und StreamConnection
Das Informationsobjekt StreamInterface erlaubt die Aggregation mehrerer
SFEPs. Das StreamInterface-Objekt repräsentiert die Stream-Schnittstelle
einer Anwendung.
Durch das Informationsobjekt StreamConnection werden StreamInterfaceObjekte in Relation gesetzt. Es modelliert die Verbindung zwischen StreamSchnittstellen und ist eine Aggregation von StreamFlowConnections.
3.3.3.1
Das AVS-Informationsmodell
Abbildung 3.13 zeigt das aus dem AVS-Standard abgeleitete Informationsmodell:
Abbildung 3.13: Das AVS-Informationsmodell
StreamInterface
connects
2..*
0..1
StreamConnection
StreamFlowEndPoint
Direction
FlowName
AvailableFormats
UsedFormat
ApplicationQoS
NetworkQoS
NetworkAddress
source
1
connectivity
0..1
{xor}
sink
1..*
connectivity
0..1
StreamFlowConnection
Topology
53
Die Assoziationen bezeichnen die folgenden Einschränkungen der Beziehungen zwischen Objekten:
StreamConnection verbindet zwei oder mehrere StreamInterfaces
StreamFlowEndPoint kann nur eine der Rollen „source“ oder „sink“ annehmen.
StreamFlowConnection besitzt genau eine Quelle und eine oder mehere
Senken.
Der AVS-Standard stellt im Anhang A gemäß der RFP-Anforderung eine
Computational-Lösung für Mehrpunkt-zu-Mehrpunkt-Verbindungen vor. Die
dort gegebene Lösung setzt sich aus der Verwendung mehrerer Punkt-zuPunkt und einer Punkt-zu-Mehrpunkt-Verbindung zusammen. Durch Einführung eines weiteren Informationsobjektes läßt sich das bestehende Informationsmodell auch für diese Topologie erweitern. Dieses Objekt aggregiert
eine Menge von StreamConnection-Objekten für die gilt, daß genau eines
die Topologie Punkt-zu-Mehrpunkt und alle anderen die Topologie Punkt-zuPunkt besitzen.
3.3.4
Die AVS Computational-Spezifikation
Die im vorhergehenden Abschnitt modellierten Informationsobjekte und Beziehungen werden auf Computational-Schnittstellen abgebildet, um auf die
enthaltenen Informationen zugreifen und sie manipulieren zu können.
Das AVS-Informationsmodell beschreibt Flow-Endpunkte und FlowVerbindungen sowie deren Aggregation zu Stream-Endpunkten und StreamVerbindungen. Eine Computational-Modellierung muß nicht für jedes Informationsobjekt auch eine Computational-Schnittstelle bereitstellen. Es ist
möglich, ein Computational-Modell zu entwickeln, welches nur Schnittstellen
für Stream-Endpunkte und Stream-Verbindungen enthält. Eine Operation,
die an einer Computational-Schnittstelle eines Stream-Endpunktes aufgerufen wird, wird auf alle enthaltenen Flows angewendet. Aktionen auf
Flow-Basis sind über diese Schnittstellen nicht möglich.
Die AVS-Architektur beschreibt zwei als „Profile“ bezeichnete ComputationalModelle:
1. Im vollen Profil (engl. Full Profile) werden Flow-Endpunkte und FlowVerbindungen auf IDL-Schnittstellen abgebildet.
2. Im leichten Profil (engl. Light Profile) werden für Flow-Endpunkte und
Flow-Verbindungen keine IDL-Schnittstellen bereitgestellt.
54
3.3.4.1
AVS Computational-Modell für das leichte Profil
Im AVS-Standard werden alle in Abschnitt 3.3.2.3 vorgestellten Schnittstellen jeweils einem Computational-Objekt zugeordnet. Das ComputationalModell im leichten Profil besteht damit aus den Objekten MMDevice, VDev,
StreamEndPoint und StreamCtrl. Jedes der Objekte besitzt genau eine
Schnittstelle, deren vollständige IDL-Beschreibung im Anhang B des AVSStandards enthalten ist. Die Interaktionen zwischen den Objekten werden in
den Stream-Binding-Szenarien in Abschnitt 3.3.5 beschrieben.
3.3.4.2
AVS Computational-Modell für das volle Profil
Im Computational-Modell für das volle Profil existieren alle Objekte des
leichten Profils und zusätzlich die Objekte FDev, FlowEndPoint und
FlowConnection. Diese bieten Operationen zur Steuerung einzelner FlowEndpunkte bzw. Flow-Verbindungen.
Die Möglichkeit der Bereitstellung von Objektrefenzen für diese Objekte bereitet Engineering-Modelle vor, in denen Flow-Endpunkte zu verschiedenen
Kapseln und verschiedenen Knoten zugeordnet werden können.
FDev
Im vollen Profil bietet ein MMDevice-Objekt für jedes Flow-Gerät eine FDevSchnittstelle an. Beispielsweise bietet ein MMDevice-Objekt das eine Kamera
repräsentiert, zwei FDev-Schnittstellen an (für Audio und Video getrennt).
Über die FDev-Schnittstelle können FlowEndPoint-Objekte erzeugt werden.
FlowEndPoint
Das FlowEndPoint-Objekt vereint die Funktionalität von VDev und
StreamEndPoint, jedoch nur für einen einzigen Flow.
FlowConnection
Das FlowConnection-Objekt ermöglicht die Bereitstellung und Steuerung einer Flow-Verbindung analog dem StreamCtrl-Objekt, jedoch nur für einen
Flow.
3.3.5
Stream-Binding-Szenarien
Ein wesentliches Ziel der AVS-Spezifikation war die Entwicklung eines standardisierten Mechanismus zum Aufbau von Stream-Verbindungen. Dieser
Abschnitt beschreibt wie die Objekte der AVS-Architektur interagieren, um
Stream-Verbindungen aufzubauen bzw. steuern zu können.
55
Das ODP-Referenzmodell beschreibt allgemeine Voraussetzungen beim Binden von Stream-Schnittstellen. Die Schnittstellen müssen vom gleichen Typ
sein und eine komplementäre Signatur besitzen. Die zu bindenden Flows einer Schnittstelle müssen eine paarweise entgegengesetzte Richtung besitzen.
Daher existieren Stream-Schnittstellen im allgemeinen paarweise. ODP sieht
dafür eine Subtypisierung von Stream-Schnittstellen vor [9, Seite 24].
Der AVS-Standard beschreibt die beiden Schnittstellentypen als A-Partei
und B-Partei. Beide Parteien sind komplementär zueinander, sodaß eine
Stream-Verbindung auf der einen Seite von einer A-Partei und auf der
anderen Seite von einer B-Partei terminiert ist. Für jede Quelle der APartei enthält die B-Partei eine Senke und umgekehrt. Die AVS-Spezifikation
definiert dafür zwei unterschiedliche IDL-Typen StreamEndPoint_A und
StreamEndPoint_B, mit der gemeinsamen Basisklasse StreamEndPoint. Dadurch wird sichergestellt, daß die Bindung von zwei Endpunkten typsicher in Bezug auf die Flow-Richtung ist. Nur ein MMDevice-Objekt mit
einer StreamEndPoint_A-Schnittstelle kann die Quelle in einer Punkt-zuMehrpunkt sein. Dazu bietet die Schnittstelle Operationen zum Hinzufügen
und Entfernen von StreamEndPoint_B-Schnittstellen.
Stream-Binding zwischen zwei Parteien vollzieht sich in mehreren Schritten,
in Abbildung 3.14 sind die ersten zwei dargestellt.
Abbildung 3.14: Initialisierung
1: bind(aMMDevice, bMMDevice)
:StreamCtrl
Initiator:
2.1: aSEP, aVDev := create_A()
aMMDevice:MMDevice
aVDev:VDev {new}
aSEP:StreamEndPoint_A {new}
2.2: bSEP, bVDev := create_B()
bMMDevice:MMDevice
bVDev:VDev {new}
bSEP:StreamEndPoint_B {new}
1. Erzeugen des Bindungsobjektes. Es wird ein StreamCtrl-Objekt erzeugt, entweder durch eine der zu bindenden Parteien oder durch eine
dritte Anwendung. Der Initiator ruft am StreamCtrl-Objekt die Operation bind_devs(aMMDev, bMMDev) auf, wobei a und b Referenzen von
MMDevice-Objekten sind.
Den Stream-Aufbau steuert ab jetzt das StreamCtrl-Objekt.
56
2. Erzeugen der Endpunkte. Das StreamCtrl-Objekt ruft an einem
MMDevice-Objekt die Operation create_A() an dem anderen create_B(). Als Ergebnis werden zwei Objektreferenzen geliefert. Eine ist vom Typ VDev, die zweite vom Typ StreamEndPoint_A bzw.
StreamEndPoint_B. Für die betrachtete Punkt-zu-Punkt-Topologie ist
es gleichwertig, welches Objekt die StreamEndPoint_A-Schnittstelle bereitstellen soll.
Die weiteren Interaktionen sind davon abhängig, ob das volle Profil verwendet werden soll und ob beide Seiten dieses unterstützen.
3.3.5.1
Stream-Binding-Szenario für das leichte Profil
Das StreamCtrl-Objekt kann vor dem dritten Schritt prüfen, ob beide
StreamEndPoint-Objekte das volle Profil unterstützen. Die Überprüfung erfolgt durch Aufruf der Operation get_property_value(“Flows“), die jeweils eine Liste der Flow-Namen eines StreamEndPoint-Objektes liefert. Danach wird für jeden Flow die Operation get_fep(“flowName“) gerufen.
StreamEndPoint-Objekte, die nur das leichte Profil unterstützen werfen als
Ergebnis sofort eine Ausnahme (engl. exception), da sie keine Schnittstellen für einzelne Flow-Endpunkte bereitstellen. Falls diese Operation an einem der beiden StreamEndPoint-Objekte fehlschlägt, wird das Binden der
Stream-Schnittstellen nach dem leichten Profil durchgeführt:
Abbildung 3.15: Aufbau einer Stream-Verbindung im leichten Profil
3.1: setPeer(bVDev)
:StreamCtrl
3.2: setPeer(aVDev)
aVDev:VDev
bVDev:VDev
4: connect(bSEP)
aSEP:StreamEndPoint_A
bSEP:StreamEndPoint_B
5: bSinkFlowSpec request_connection(aSinkFlowSpecs)
3. Konfiguration der virtuellen Geräte. Das StreamCtrl-Objekt
ruft nacheinander an beiden VDev-Objekten die Operation
set_peer(peerVDev). Dadurch erhält ein VDev-Objekt die Möglichkeit, die Kompatibilität der eigenen Flows mit denen des Partners zu überprüfen. Mit den Operationen set_format(...) und
set_dev_params(...) einigen sie sich Flow-basiert auf Kodierung
und QoS-Parameter.
57
4. Start Stream-Aufbau. StreamCtrl ruft an StreamEndPoint_A die Operation connect(StreamEndPoint_B).
Stream-Binding ist ab jetzt unter der Steuerung der StreamEndPointObjekte, StreamCtrl hat darauf keinen weiteren Einfluß.
5. Stream-Aufbau im leichten Profil. StreamEndPoint_A erzeugt für
jede Senke der Stream-Schnittstelle einen Terminierungspunkt. Die
Wahl des Transportprotokolls ist dabei nur durch die verfügbaren
Protokollstacks eingeschränkt. Das StreamEndPoint-Objekt beginnt
an den Terminierungspunkten auf eingehende Verbindungen zu warten. Parallel dazu ruft es an StreamEndPoint_B die Operation request_connection(flowspec). Die Informationen, die flowspec
beschreibt, sind das Transportprotokoll sowie protokollspezifische Parameter (z.B. TCP=pandora.informatik.hu-berlin.de:12000).
StreamEndPoint_B erzeugt für alle Flows der flowspec-Beschreibung
Terminierungspunkte des entsprechenden Transportprotokolls und verbindet sie mit denen von StreamEndPoint_A. Anschließend erzeugt
es Terminierungspunkte für die Senken und liefert deren flowspecBeschreibung als Ergebnis der request_connection()-Operation
zurück. StreamEndPoint_A verarbeitet die flowspec-Beschreibung in
der gleichen Weise. Danach sind die Terminierungspunkte der beiden
StreamEndPoint-Objekte miteinander verbunden.
3.3.5.2 Stream-Binding-Szenario für das volle Profil
Ob Stream-Binding auf Flow-Basis durchgeführt wird, kann erst nach dem
zweiten Schritt (“Erzeugen der Endpunkte“) entschieden werden. Die ersten beiden Schritte, also das Instanziieren des Bindungsobjektes sowie das
Bereitstellen von StreamEndPoint- und VDev-Objekten, werden sowohl im
leichten als auch im vollen Profil durchgeführt. Danach existiert das Bindungsobjekt und kennt die StreamEndPoint-Objekte der beiden Parteien.
Nach dem Aufruf der Operation get_property_value(“Flows“) an beiden Objekten kennt es die einzelnen Flow-Namen und stellt über die folgenden Schritte Flow-Verbindungen her:
Abbildung 3.16: Binden im vollen Profil: Finden kompatibler Endpunkte
3.1: (i=1..n) aFEP:=get_fep(name:FlowName)
aSEP:StreamEndPoint_A
3.2: (i=1..n) bFEP:=get_fep(name:FlowName)
:StreamCtrl
bSEP:StreamEndPoint_B
5: (i=1..n) connect(aFEP, bFEP)
4: (i=1..n) is_fep_compatible(bFEP)
:FlowConnection {new}
aFEP:FlowConsumer {new}
bFEP:FlowProducer {new}
4: get_property()
58
3. Abfrage der FlowEndPoint-Objekte Für jeden Flow-Namen fordert
StreamCtrl ein FlowEndPoint-Objekt an.
4. Finden kompatibler Endpunkte. Für jeden Endpunkt der A-Seite
iteriert das StreamCtrl-Objekt über die Endpunkte der B-Seite und versucht Paare kompatibler Endpunkte festzustellen. Zwei Endpunkte gelten als kompatibel, wenn die Operation is_fep_compatible() erfolgreich ist. Es ist Aufgabe des FlowEndPoint-Objektes festzustellen, ob
es mit dem Peer-Objekt ein gemeinsames Transportprotokoll sowie ein
gemeinsames Kodierungsformat unterstützt.
5. Erzeugen der Bindungsobjekte. Für jedes als kompatibel erkannte
FlowEndPoint-Paar wird ein FlowConnection-Objekt erzeugt. An diesem wird die Operation connect(aFEP, bFEP) aufgerufen.
Abbildung 3.17: Binden im vollen Profil: Aufbau von Flow-Verbindungen
:FlowConnection
6.1: set_peer(fep:sourceFEP)
7: flowSpec go_to_listen()
aFEP:FlowConsumer
8: connect_to_peer(flowSpec)
bFEP:FlowProducer
6.2: set_format(flowFormat)
6. Flow-Konfiguration. FlowConnection ruft die Operation set_peer
(bFEP) am FlowEndPoint-Objekt (Senke) auf, um die Konfiguration der Flow-Parameter zu ermöglichen. Über die Operationsrufe
set_dev_params() und set_format() werden Parameter eingestellt.
7. Bereitstellen eines Terminierungspunktes durch die Senke. FlowConnection ruft am FlowConsumer-Objekt die Operation
go_to_listen() auf. Das FlowConsumer-Objekt wählt ein gemeinsam unterstütztes Transportprotokoll aus und initialisiert einen entsprechenden Terminierungspunkt. Aus dem verwendeten Protokoll
sowie den protokollspezifischen Daten des Terminierungspunktes wird
eine flowspec-Beschreibung generiert und als Ergebnis der Operation
zurückgeliefert.
8. Aufbau der Flow-Verbindung. FlowConnection ruft mit dieser
Beschreibung die Operation connect_to_peer(flowspec) am
FlowProducer-Objekt auf. FlowPruducer erzeugt einen Terminierungspunkt gemäß dem Protokoll der flowspec-Beschreibung und
59
verbindet diesen mit dem Terminierungspunkt des FlowConsumerObjektes. Damit besteht eine aufgebaute aber noch nicht gestartete
Flow-Verbindung zwischen Produzenten und Konsumenten eines kontinuierlichen Datenstromes.
Die Stream-Binding-Szenarien des leichten und des vollen Profils haben verdeutlicht, daß im Standard Control and Management of Audio/Video Streams
die Bereitstellung von Transportverbindungen die Aufgabe der Anwendungsobjekten ist.
60
Mit der Aufgabe der Zusammenführung der Konzepte des OMG Standards
“Control and Management of Audio/Video Streams“ und TINA haben sich
zwischen 1998 und 1999 bereits mehrere Projekte beschäftigt [19, 5, 17]. Den
beiden in diesem Kapitel vorgestellten Arbeiten ist gemeinsam, daß sie auf
der Grundlage eines TINA-organisierten Netzes die Verwendung von OMG
AVS konformen Geräten ermöglichen wollen. Die zentralen Ideen der unterschiedlichen Ansätze werden in den folgenden Abschnitten vorgestellt.
4.1
IONA: A CORBA Framework for Multimedia Streams
Die Autoren schlagen eine Änderung des in der Network-ResourceArchitektur [25] beschriebenen Bindungsobjektes Communication Session
Manager (CSM) vor. Als Motivation zeigen sie die folgenden Analogien zwischen OMG-AVS und TINA-Konzepten:
Das CSM-Objekt abstrahiert einen logischen Verbindungsgraphen, der
aus mehreren Stream-Flow-Verbindungen (SFCs) besteht. SFCs lassen
sich auf das AVS-Konzept Flow Connection abbilden.
SFEPs entsprechen Flow End Points.
Die Aktivierung bzw. Deaktivierung von SFCs entspricht dem Starten
bzw. Stoppen von Flow Connections.
Das TINA CSM-Objekt soll die Aufgaben eines OMG Flow-ConnectionObjektes erfüllen und damit Flow End Points binden. Die Autoren empfehlen
die folgende Änderung der IDL-Beschreibung für SFEPs, um sowohl TINASFEPs als auch AVS-FEPs zu referenzieren:
61
// neu:
struct t_SFep {
t_IntRef tcsmRef;
t_Sfep_Cid SFepId;
};
// alt:
struct t_SFepRef {
t_IntRef tcsmRef;
t_Sfep_Cid SFepId;
};
struct t_SFepRef {
case 1 : FlowEndPoint
case 2 : t_SFep;
default : t_SFep;
};
Folgendes Szenario wird für einen TINA-Dienst beschrieben, der zwei FEPs
binden soll. Es beschreibt, wie eine Stream-Flow-Verbindung zwischen zwei
AVS-Geräten aufgebaut wird:
Abbildung 4.1: IONA Szenario zum Binden von zwei FEPs
Trading
Service
1
Consumer Domain
Retailer Domain
2.1
FDev
FlowEndPoint
Consumer Domain
TINA
Service
3,5
2.2
FDev
FlowEndPoint
CSM
1. Der Dienst nutzt einen TradingService, um die zu bindenden FDevs zu
finden (FDevs können FEPs erzeugen).
2. Der Dienst läßt jeweils eine
FEP-Instanz erzeugen.
3. Der Dienst ruft eine
Bindungsoperation am CSM-Objekt
mit den beiden erzeugten FEPs als
Parameter auf.
4. Die Verbindung wird durch das
CSM-Objekt bereitgestellt und
gestartet.
5. Der Dienst läßt die Verbindung durch
das CSM-Objekt abbauen.
Nach Aussage der Autoren läßt ihr Ansatz keine Stream-Flow-Verbindungen
zwischen FEPs und SFEPs zu. Damit wäre eine Bindung zwischen der
Stream-Schnittstelle eines OMG AVS-konformen Gerätes und einer TINAAnwendung nicht möglich. Diese Einschränkung bleibt unmotiviert. Die ge-
62
4.2 Humboldt Universität, NTT
zeigte Neudefinition der SFEP-Referenz alleine begründet dies nicht, da
sie sich nur auf einen Endpunkt bezieht. Die Modellierung eines SFCInformationsobjektes hätte diese Aussage belegen können, da SFCs Einschränkungen bezüglich des Typs der Endpunkte enthalten können.
Die Autoren lassen ein wesentliches Problem ungelöst. Es wird nicht beschrieben, wie das CSM-Objekt eine Netzverbindung zwischen zwei FEPs
herstellt. TINA Connection Management kann keine AVS-FEPs verbinden.
Folglich bleibt nur die AVS-Strategie, eines der beiden FEP-Objekte mit dem
Verbindungsaufbau zu beauftragen.
Das Ergebnis der Arbeit besteht in der Erweiterung des CSM-Objektes, um
Verbindungen zwischen zwei AVS-konformen Geräten aufbauen zu können.
Der gezeigte Ansatz leistet nicht mehr als der AVS-Standard [8] und ermöglicht nicht die gleichzeitige Verwendung von TINA-Anwendungen und AVSGeräten. Der Aufbau von Verbindungen, also die CSM-Aktionen für Schritt 4
in Abb. 4.1, wird den Anwendungen überlassen und nicht durch das TINA
Connection-Management realisiert.
4.2
OMG A/V Streams and TINA NRA: An integrative
Approach
Kath und Takita stellen in [17] ein Rahmenwerk für den Einsatz multimedialer Anwendungen in einem ATM-basierten Netz vor. Die Grundlage bilden dabei TINA-Konzepte der Informations-, Computational- und
Engineering-Modellierungssichten. Der Ansatz erlaubt die Verwendung von
multimedialen Produkten verschiedener Standards innerhalb der TINAKonsumentendomäne. Die Lösung ist damit allgemeiner als die in 4.1 gezeigte, die ausschließlich den Einsatz von OMG-AVS-Anwendungen ermöglicht.
Das Dokument beschreibt TINA-Informationsobjekte, die an der Schnittstelle
zwischen Konsumenten- und Verbindungsanbieterdomäne wesentlich sind.
Durch die Einführung des Informationsobjektes SFEPBridge wird die Bindung
zu spezifischen Produkten (SFEPProduct ) von der nodalen Bindung zwischen
SFEPBridge und NFEP entkoppelt:
Abbildung 4.2: Das SFEPBridge -Informationsobjekt
SFEPProduct
SFEPBridge
NFEP
Anwendung
Layer Network
anwendungsspezifische Bindung
nodale Bindung
63
Die Bindung zwischen SFEPProduct und SFEPBridge ist abhängig von dem verwendeten Produkt und kann durch verschiedene Technologien bereitgestellt
werden. Sie ist nicht abhängig von dem im Transportnetz verwendeten Protokoll.
Für das Beispiel eines OMG-AVS-Produktes wurde ein Objektmodell entworfen. Es enthält Computational-Objekte, die die Schnittstellen StreamEndPoint und VDev unterstützen. SFEPProduct wird mit SFEPBridge durch ein AVSspezifisches Bindungsobjekt gebunden.
Die von Kath und Takita gezeigte Lösung zeichnet sich gegenüber der von
IONA erbrachten durch eine Trennung zwischen AVS-spezifischer StreamBindung und der nodalen Bindung zischen SFEPs und NFEPs aus. Durch
die Einführung des Informationsbjektes SFEPBridge werden an den Schnittstellen der Konsumentendomäne alle notwendigen Informationen bereitgestellt, die für den Aufbau von Stream-Flow-Verbindungen durch das TINAVerbindungsmanagement benötigt werden.
64
5 Integration von OMG Audio/Video
Streams in TINA-DPE
5.1
Einführung und Rahmenbedingungen
Der Titel dieses Kapitels bezeichnet mit dem Wort „Integration“ die Zielstellung dieser Arbeit. Integration bezeichnet eine Eingliederung, in dieser Arbeit die Eingliederung von AVS-konformen Geräten in TINA CPE (Customer
Premises Equipment). Dieses Kapitel beschreibt ein Terminal, das die Anforderungen an TINA-CPE erfüllt und gleichzeitig mit AVS-konformen Geräten
ausgestattet ist. Ein AVS-konformes Gerät muß keine Hardware enthalten,
es ist nur eine dem AVS-Standard konforme Implementierung der Schnittstellen gefordert. Ein damit ausgestattetes Terminal wird im folgenden als
AVS-Terminal bezeichnet. Das AVS-Terminal soll mit möglichst präzisen Modellierungsmethoden beschrieben werden.
Der AVS-Standard nutzt als Modellierungssprache natürliche (englische)
Sprache und zur Schnittstellenbeschreibung IDL. TINA ist durch ODPModellierungssichten beschrieben. Die im AVS-Standard verwendeten Ausdrucksmittel reichen nicht aus oder sind zu unpräzise, um TINA-Konzepte
darzustellen, die für das AVS-Terminal notwendig sind. Die Schnittstellen
des integrierten Modells sollen offengelegt werden, das Referenzmodell ODP
ist eine dafür geeignete Methode.
Es sind die Anforderungen festzulegen, die für das Modell des AVS-Terminals
gelten sollen. Für das AVS-Terminal sollen die gleichen Anforderungen bezüglich des Verhaltens mit der Umgebung bestehen wie für TINA-CPE, da
sich ein AVS-Terminal innerhalb TINA genauso verhalten soll, wie in [26]
beschriebene TINA-CPEs.
Der integrierte Ansatz beschreibt ausschließlich das AVS-Terminal, daher ist
eine Modifikation von Komponenten außerhalb des AVS-Terminals nicht erlaubt. Ansonsten müßten diese in die Modellierung einbezogen werden.
AVS-Geräte enthalten eine Software, die konform zum Standard „Control and
Management of Audio/Video Streams“ [7] ist. Diese Software soll für den Einsatz im AVS-Terminal nicht geändert werden. Daraus ergibt sich, daß nur die
im Standard beschriebenen Schnittstellen zur Verfügung stehen. Es sind kei-
65
ne Anpassungen an die Besonderheiten des AVS-Terminals möglich, in dem
die Geräte betrieben werden sollen.
Die in Abschnitt 3.2.6 gezeigten Stream-Binding-Konzepte auf der Grundlage
des TINA-Transportnetzes werden auch im integrierten Ansatz genutzt. Insbesondere wird der Communication-Session-Manager als Bindungsobjekt für
den Aufbau von (logischen) Stream-Verbindungen genutzt. Zur Bereitstellung
von Network-Flow-Verbindungen durch das TINA-Connection-Management
muß das AVS-Terminal an mindestens ein TINA-Netz angeschlossen sein.
Damit sind drei Anforderungen für das AVS-Terminal identifiziert:
1. Das AVS-Terminal ist TINA-CPE-konform.
2. OMG AVS-konforme Geräte werden ohne Anpassungen eingesetzt.
3. Es werden keine CPE-externen Änderungen vorgenommen.
5.2 Gegenüberstellung von TINA und OMG Audio/Video
Streams
In Kapitel 3 wurden die Stream-Binding-Konzepte von OMG-AVS und TINA
vorgestellt. Bevor ein integriertes Modell entworfen wird, erfolgt eine Gegenüberstellung der beiden Standards. Sie zeigen einige Gemeinsamkeiten, besitzen aber auch konzeptionelle Unterschiede.
5.2.1
Gemeinsamkeiten
Stream-Schnittstellen
Anwendungen können kontinuierliche Daten an Stream-Flow-Endpunkten
empfangen und versenden. Stream-Flow-Endpunkte werden zu StreamSchnittstellen gruppiert.
Datentransport zwischen verschiedenen Knoten
Kontinuierliche Daten können zwischen verschiedenen Knoten transportiert
werden, sofern sie durch ein Netz verbunden sind.
Objektinteraktionen
Operationale Objektinteraktion wird durch OMG CORBA unterstützt.
Bereitstellung von Stream-Verbindungen
Stream-Verbindungen werden durch ein Bindungsobjekt bereitgestellt.
66
5.2 Gegenüberstellung von TINA und OMG Audio/Video Streams
Dienstgüte
An Stream-Flow-Verbindungen können Dienstgüteanforderungen gestellt
werden.
Topologie
Stream-Flow-Verbindungen sind unidirektionale Punkt-zu-Punkt- oder
Punkt-zu-Mehrpunkt-Verbindungen.
5.2.2
Unterschiede
In Bezug auf Beschreibungstechnik und Stream-Binding-Konzepte unterscheiden sich AVS und TINA in den folgenden Punkten:
Modellierung
TINA orientiert sich in den Spezifikationen an den Modellierungssichten des
Referenzmodells ODP. Als Beschreibungstechnik wird OMT verwendet.
Der AVS-Standard folgt RM-ODP nicht so genau wie TINA. Die Beschreibungen enthaltener Informationen und Interaktionen zwischen ComputationalObjekten erfolgen gleichzeitig. Konzepte sind in natürlicher (englischer)
Sprache beschrieben. Operationale Schnittstellen von Objekten sind in
CORBA IDL notiert. Einige Interaktionsszenarien zwischen Objekten sind
durch freie Zeichnungen beschrieben.
Betrachtungsspektrum
Stream-Binding ist in TINA nur einer von vielen Aspekten bei der Beschreibung einer Plattform für verteilte Anwendungen.
AVS bezieht sich ausschließlich auf Stream-Binding-Konzepte. Durch die Verwendung von CORBA ist eine Plattform beschrieben.
Modellierung von Verbindungen
TINA unterscheidet in eine anwendungsorientierte (logische) und eine netzorientierte (physische) Sicht auf Verbindungen.
Zwischen logischen und physischen Verbindungen wird im AVS-Standard
nicht unterschieden.
Aufbau von Netzverbindungen
TINA-Connection-Management stellt Netzverbindungen auf Anforderung
von Anwendungen bereit. Der Aufbau von Netzverbindungen erfolgt ohne die
Beteiligung von Anwendungen.
67
In AVS werden Netzverbindungen durch die Anwendungen bereitgestellt.
Diese müssen das Netzprotokoll auf Grundlage der dem Terminal zur Verfügung stehenden Möglichkeiten aushandeln.
Netzmanagementkonzepte
Die TINA-Spezifikationen beschreiben u.a. den Aufbau und das Management
von Netzen [25]. Ende-zu-Ende-Verbindungen werden durch Aufbau mehrerer Teilnetzverbindungen bereitgestellt. Fehlfunktionen von Netzelementen
werden durch Komponenten des Ausfallmanagements erkannt und behandelt.
AVS betrachtet Netzverbindungen ausschließlich als Ende-zu-EndeVerbindungen. Durch diese Vereinfachung kann auf das Management einzelner Netzelemente verzichtet werden. Ausfälle sind durch die Nutzeranwendungen zu behandeln.
Verwaltung von Stream-FlowEndpunkten
Stream-FlowEndpunkte stellen in TINA eine vom Terminal verwaltete Ressource dar. Anwendungen können Endpunkte bei einem singulären Verwalter
(TCSM) anfordern. Nach Nutzungsende werden sie in den Pool der verfügbaren Endpunkte zurückgegeben.
In AVS werden Endpunkte nach Anforderung eines Bindungsobjektes durch
Anwendungen erzeugt und vernichtet. Mechanismen zum Schutz vor konkurrierendem Zugriff auf Resourcen sind nicht enthalten.
Medienbeschreibung und Dienstgüte
In TINA ist die Beschreibung der Daten, die ein SFEP bereitstellen bzw. konsumieren kann, in der SFEP-IDL-Spezifikation durch das Attribut “media“
vorgesehen. Eine Darstellung möglicher Belegungen ist in keiner der TINASpezifikationen enthalten. Es ist nicht zu erkennen, wie beispielsweise die
Quelle eines 44kHz Audiosignals zu notieren ist.
Im AVS-Standard enthält das Property-Element “currFormat“ eines StreamEndpunktes die SFEP-Medienbeschreibung. Es sind eine Menge standardisierter Parameter sowie möglicher Belegungen definiert. Mit ihnen lassen
sich charakteristische Werte von Audio- und Videosignalen beschreiben. Um
Dienstgüteanforderungen spezifizieren zu können, wurde eine Notation für
die Angabe von Unter- bzw. Obergrenzen von Werten eingeführt. Im Gegensatz zu den aktuellen TINA-Dokumenten enthält der AVS-Standard hinreichende Informationen zur Überprüfung der Kompatibilität von SFEPs und
zur Angabe von Dienstgüteparametern für Stream-Flow-Verbindungen.
68
5.3 Beschreibung der Ausgangssituation
5.3
Beschreibung der Ausgangssituation
Die Integration soll die Verwendung AVS-konformer Geräte innerhalb TINACPE ermöglichen. Die Schnittstellen, die zwischen der Konsumentendomäne sowie den anderen Domänen in der TINA-Architektur spezifiziert sind,
werden im integrierten Modell beibehalten. Die Makler-, Drittanbieter-,
Wiederverkäufer- und Verbindungsanbieterdomäne bilden die Umgebung der
Konsumentendomäne.
Das AVS-Terminal besitzt – als Bestandteil der Konsumentendomäne – drei
Schnittstellen mit ihrer Umgebung, identifiziert durch die Referenzpunkte
Broker (Bkr), Retailer (Ret) [29] und Terminal Connection (TCon) [23].
Der Broker-Referenzpunkt bezeichnet die Schnittstelle zu einem Verzeichnisdienst. Die Funktionalität zum Finden von Diensten wurde in einem eigenen
Referenzpunkt beschrieben, da sich das Finden orthogonal zum Nutzen von
Diensten verhält. Die Aufgabe des Verzeichnisdienstes gilt als erfüllt, bevor
der gefundene Dienst gestartet wird. Umgekehrt ist es für die Dienstnutzung unbedeutend, auf welchem Weg der Dienst gefunden wurde. Der BrokerReferenzpunkt hat damit keine Bedeutung für die Nutzung von AVS-Geräten
in einem TINA-Dienst, insbesondere nicht für den Aufbau von Stream-FlowVerbindungen zwischen dem AVS-Terminal und anderen CPEs.
Ein wichtiges Kriterium für den Erfolg der Integration ist die Einhaltung der
in den Referenzpunkten Ret und TCon gegebenen Spezifikationen, da nur
dann das AVS-Terminal als CPE-konform gilt.
Die Spezifikation eines TINA-Referenzpunktes besteht aus mehreren
Bestandteilen, einem Informations-, einem Computational- und einem
Engineering-Teil. Diese spezifizieren Entitäten, die über Domängrenzen hinweg sichtbar sind. Dazu zählen Informationsobjekte sowie ComputationalSchnittstellen. Spezifikationen von Intra-Domain-Referenzpunkten (z.B.
Term) enthalten Aussagen über Objektinteraktionen innerhalb einer Domäne. Diese haben nicht den Charakter einer Vorschrift. Daher ist es zulässig,
die Informations- bzw. Computational-Modelle um neue Objekte zu erweitern, die zusätzliche Informationen repräsentieren bzw. eine erweiterte
Funktionalität bereitstellen.
Die Integration von OMG AVS in die Konsumentendomäne baut auf
diese Möglichkeit auf, indem sie AVS-spezifische Informationen in das
Informationsmodell einfügt sowie neue Computational-Objekte beschreibt.
Das AVS-Terminal ist eine TINA-CPE-Einheit, die an mindestens ein
Layer-Netz angeschlossen ist. Damit gelten die folgenden Bedingungen für
das AVS-Terminal:
1. Es existiert ein TCSM-Objekt.
2. Für mindestens ein Layer-Netz existiert ein TLA-Objekt (Terminal
Layer Adapter).
69
3. Es existiert mindestens ein MMDevice-Objekt Multi Media Device. Die
Unterstützung des vollen Profils wird nicht gefordert.
4. Die Objektreferenzen sind bekannt, z.B. durch Anmeldung bei einem
Namensdienst.
5.4 ODP-Spezifikation des AVS-Terminals
5.4.1
Informationsspezifikation
Ausgehend von dem in Kapitel 3.2.6.1 vorgestellten TINA-Informationsmodell
und dem in Kapitel 3.3.3 entwickelten AVS-Modell wird ein gemeinsames
Informationsmodell für das AVS-Terminal modelliert.
Bestandteil des TINA-Informationsmodells für Verbindungsmanagement
sind Terminierungspunkte von Verbindungen. Die der Konsumentendomäne,
und damit auch dem AVS-Terminal als Vertreter diese Domäne, zugeordneten Informationsobjekte sind die Terminierungspunkte von Ende-zu-EndeVerbindungen. Der Schwerpunkt bei der Modellierung von Informationen des
AVS-Terminals liegt folglich in der Beschreibung von Verbindungsendpunkten. Da das TINA-Modell mit logischen und physischen Verbindungsgraphen
als Grundlage dient, wird auch im AVS-Terminal in logische und physische
Endpunkte von Verbindungen unterschieden.
Die zur Beschreibung von Verbindungen verwendeten Informationsobjekte
beider Standards sind in Abbildung 5.1 gegenübergestellt. Diese sind in ein
gemeinsames Modell zu integrieren.
Abbildung 5.1: SFEPAV S vs. SFEPT INA
TINA
AVS
SFC AVS
connectivity
0..1
{xor}
sink
1..*
SFC TINA
connectivity 0..1
connectivity
0..1
{xor}
Root
source
SFEPAVS
connectivity
sink
1..*
NFC
0..1
connectivity
{xor}
Root
source
sink
SFEPTINA
endpoint
0..1
connectivity
70
SFC: Stream Flow Connection
NFC: Network Flow Connection
TFC: Terminal Flow Connection
1..*
0..1
Root
source
NFEP
1..2
endpoint 0..1
SExtremity
SFEP: Stream Flow End Point
NFEP: Network Flow End Point
0..1 connectivity
NExtremity
TFC
0..*
connectivity
Der naive Ansatz, SFEPT INA durch SFEPAV S zu ersetzen, ist nicht korrekt, da
AVS nicht zwischen logischen und physischen Verbindungen unterscheidet.
SFEPs stehen ausschließlich in Beziehung zu anderen SFEPs (indirekt über
ein SFC-Objekt). Eine Beziehung zu NFEPs, wodurch eine nodale Bindung
(TFC) entsteht, ist nicht zu motivieren. Diese Beziehung wäre auch deshalb
problematisch, da sowohl SFEPAV S als auch NFEP Attribute zur Beschreibung einer physischen Flow-Verbindung enthalten.
Ein solches Informationsmodell, in dem SFEPT INA durch SFEPAV S ersetzt
wird, liegt dem Entwurf von IONA [5] zu Grunde, die Probleme wurden in
Abschnitt 4.1 diskutiert.
Da die Konformität zum AVS-Standard erhalten bleiben soll, können
SFEPAV S -Objekte nicht in Beziehung zu NFEP-Objekten gesetzt werden. Zur
Lösung dieses Problems wird die aus [17] stammende Idee eines SFEPBridge Objektes verwendet. Hier wird es dazu genutzt, ein integriertes Modell zu
ermöglichen, daß die existierenden Informationsobjekte nicht verändert. Es
erlaubt eine AVS-konforme Modellierung der Beziehung zwischen SFEPs
und eine TINA-konforme Beschreibung der Zuordnung von SFEPs zu NFEPs
durch TFCs.
Die folgende Abbildung zeigt SFEPBridge in Assoziation mit zwei FlowVerbindungen:
Abbildung 5.2: Einführung des Informationsobjektes SFEPBridge
SFC AVS
SFEPAVS
SFC TINA
SFEPBridge
SFEPTINA
SFEP: Stream Flow End Point
SFC:
5.4.1.1
Das Informationsobjekt SFEPBridge
Die SFEP-Objekte beider Standards besitzen jeweils ein Attribut zur Beschreibung der Flow-Richtung. Das Attribut wird mit einem Wert belegt,
der das SFEP-Objekt als Quelle oder Senke charakterisiert. SFEPAV S bzw.
SFEPT INA können damit nicht gleichzeitig Quelle und Senke sein. Eine
Stream-Flow-Verbindung besteht zwischen zwei SFEPs1 , die eine entgegengesetze Richtung besitzen. Das SFEPBridge -Objekt fügt sich in der StreamFlow-Verbindung zwischen zwei SFEPs ein, im integrierten Ansatz zwi1 Die
Aussage gilt für alle Zweige in einer Stream-Flow-Verbindungen mit der Topologie
Punkt-zu-Mehrpunkt
71
schen SFEPAV S und SFEPT INA . Ist beispielsweise das Richtungsattribut des
SFEPAV S -Objektes mit Quelle belegt, so soll durch SFEPBridge ein kontinuierlicher Datenaustausch zu einem SFEPT INA -Objekt mit der Eigenschaft Senke
ermöglicht werden. Dazu wird SFEPBridge gegenüber SFEPAV S als Senke charakterisiert, gegenüber SFEPT INA als Quelle.
Als Informationsobjekt besitzt SFEPBridge die in der folgenden Tabelle gezeigten Attribute.
Attribut
Bedeutung
FlowName
Bezeichnet den Flow-Namen.
DirectionAV S
Charakterisiert die Rolle gegenüber SFEPAV S .
DirectionT INA
Charakterisiert die Rolle gegenüber SFEPT INA .
MediaDesc
Beschreibt die verwendete Kodierung.
ProtocolAV S
Bezeichnet das verwendete Protokoll der Transportverbindung zu SFEPAV S .
AddressAV S
Enthält die protokollspezifische Adresse der Verbindung zu SFEPAV S .
NFEP
Bezeichnet das zugeordnete NFEP-Objekt.
Zwei Richtungsattribute sind die besondere Eigenschaft des BridgeKonzeptes in der Informationsspezifikation. Dazu besitzt das Informationsobjekt die zwei Attribute “DirectionT INA “ und “DirectionAV S “. Beide Attribute
besitzen immer eine unterschiedliche Belegung. Mit dieser Festlegung ist
die Verwendung von zwei Attributen zwar redundant, verdeutlicht aber das
Konzept.
Das Attribut FlowName bezeichnet den Flow-Namen. Da die Zuordnung
der Quelle einer Stream-Schnittstelle zur Senke einer anderen Schnittstelle nur über den Flow-Namen erfolgt, sind die Flow-Namen von SFEPAV S und
SFEPT INA identisch.
MediaDesc beschreibt das Medienformat2 der zwischen SFEPAV S und
SFEPT INA transportierten Daten. SFEPBridge nimmt keine Konvertierung
der Daten vor.
Durch die Attribute ProtocolAV S und AddressAV S wird der für den Datentransport zu SFEPAV S verwendete Terminierungspunkt beschrieben.
NFEP enthält das zu SFEPBridge zugeordnete NFEP-Objekt.
2 Medienformate
72
sind in RFCs von IETF definiert.
5.4.1.2
Das Informationsmodell
Abbildung 5.2 zeigt das für den integrierten Ansatz entworfene Informationsmodell mit SFEPBridge als Verbindungselement der beiden Standards. SFEPBridge ist eine Spezialisierung von SFEPT INA . Damit ist es
möglich, Stream-Flow-Verbindungen zwischen einer beliebigen Kombination von SFEPBridge - und SFEPT INA -Objekten zu beschreiben. Für TerminalFlow-Verbindungen gibt es keine Unterscheidung zwischen SFEPT INA und
SFEPBridge .
Abbildung 5.3: Das Informationsmodell für den integrierten Ansatz
SFC TINA
connectivity
0..1
connectivity
{xor}
sink
1..*
NFC
0..1
connectivity
Root
sink
source
SFEPTINA
endpoint
1..2
FlowName
0..1 connectivity
{xor}
1..*
0..1
Root
source
NFEP
SExtremity
endpoint 0..1
NExtremity
SFEPAVS
SFEPBridge
FlowName
endpoint
AVSExtremity
1..*
con.
TFC
0..1
connectivity
endpoint
{SFEP_AVS.FlowName = SFEP_Bridge.FlowName
0..1
BridgeExtremity
SFC AVS
connectivity
connectivity
TransportProtocol
OperationalState
Das SFCAV S -Objekt beschreibt eine Verbindung zwischen einem SFEPAV S und einem SFEPBridge -Objekt mit gleichen Flow-Namen. Die beiden Attribute
bezeichnen das verwendete Transportprotokoll sowie den Zustand der Verbindung.
Die SFCT INA - und NFC-Modellierungen wurden unverändert in das integrierte Informationsmodell übernommen. Damit bleiben auch die Modelle der logischen und physischen Verbindungsgraphen erhalten.
5.4.1.3
Die SFEPBridge-Medienbeschreibung und Aspekte der Dienstqualität
Bereits bei der Gegenüberstellung der beiden Standards in Abschnitt 5.2 wurde auf die unterschiedliche Darstellung von Medienformaten aufmerksam gemacht.
73
Das im integrierten Informationsmodell eingeführte SFEPBridge-Objekt enthält ein Attribut zur Medienbeschreibung, also der charakteristischen Eigenschaften der Daten, die an diesem Stream-Flow-Endpunkt empfangen bzw.
an ihn gesendet werden können. Da SFEPBridge einen Stream-Flow-Endpunkt
des OMG-Gerätes gegenüber einem TINA-Dienst repräsentiert, sollte die Medienbeschreibung semantisch der des SFEPAV S -Objektes möglichst entsprechen. Dazu ist ein Algorithmus zur Abbildung der AVS-Notation auf die
TINA-Notation notwendig.
Zur Zeit der Fertigstellung dieser Arbeit (September 2000) enthalten die
TINA-Spezifikationen keine Notation zur Darstellung von Medienformaten. Diese ist aber notwendig, um die Medienbeschreibung eines SFEPAV S Objektes in eine für die TINA-Welt interpretierbare Beschreibung zu bringen. Für diese Arbeit soll gelten, daß die Notation der Medienbeschreibung in
TINA aus dem AVS-Standard übernommen wird. Mit dieser Festlegung gilt,
daß das SFEPBridge -Medienformat identisch mit dem des SFEPAV S -Objektes
ist.
Bei einem Auftrag zur Bereitstellung von Flow-Verbindungen kann die Einhaltung gegebener Dienstgüteeigenschaften gefordert werden, die für diese
Verbindung gelten sollen. Für Stream-Flow-Verbindungen werden die Kriterien durch Parameter der Anwendungsebene beschrieben. Beispielsweise
kann für eine Stream-Flow-Verbindung, die Audiodaten im Medienformat
“mp3“ transportiert, gefordert werden, daß die Kodierung mit mindestens
128 Bit erfolgt. Network-Flow-Verbindungen erbringen die physische Übertragung der Daten einer Stream-Flow-Verbindung. Dienstgüteparameter auf
Anwendungsebene haben direkten Einfluß auf die Bestimmung der Anforderungen an die Netzverbindung.
Der integrierte Ansatz setzt jeweils ein SFEPAV S -Objekt in Beziehung zu einem SFEPBridge-Objekt. Diese Beziehung läßt sich als SFC betrachten, wodurch Aussagen über die gestellten Güteanforderungen zu treffen sind. Im
AVS-Terminal werden an diese Verbindung die gleichen Anforderungen gestellt, wie sie für SFC zwischen SFEPBridge und remote-SFEPs gelten. Mit
dieser Festlegung werden Anforderungen eines TINA-Dienstes an eine Nutzeranwendung direkt auf das AVS-Gerät übertragen.
5.4.2
Computational-Spezifikation
5.4.2.1 Anwendung der ODP Stream-Binding-Konzepte
Zu den Betrachtungsgegenständen der Computational-Modellierungssicht
gehört das Binden der Stream-Schnittstellen von Computational-Objekten.
Für den integrierten Ansatz muß also das Bereitstellen von StreamVerbindungen beschrieben werden. Eine solche Verbindung wird auf der
74
einen Seite durch eine Stream-Schnittstelle eines AVS-Gerätes des AVSTerminals terminiert. Der andere Terminierungspunkt ist eine TINAStream-Schnittstelle eines Computational-Objektes, z.B. des in der ServiceArchitektur eingeführten User-Application-Objektes (UAP). Zwischen den
Stream-Schnittstellen dieser beiden Computational-Objekte wird im integrierten Ansatz ein kontinuierlicher Datenaustausch ermöglicht.
Abbildung 5.4: Computational-Objekte mit Stream-Schnittstellen verschiedenen Typs
MMDevice
AVS Stream-Schnittstellen (SEP)
MMDevice: Multi Media Device,
Computational-Objekt mit
AVS-Stream-Schnittstelle
UAP
TINA Stream-Schnittstellen (SI)
UAP:
User Application,
Computational-Objekt mit
TINA-Stream-Schnittstelle
Das Referenzmodell ODP beschreibt ein Bindungsobjekt als leistungsfähigste Methode zur Bereitstellung von Stream-Verbindungen (vgl. Abschnitt 2.7
auf Seite 25). Ein Bindungsobjekt erlaubt es, Stream-Schnittstellen mit unterschiedlichem Typ zu binden. Die Verbindung zwischen den Schnittstellen
von MMDevice und UAP kann durch ein ODP-Bindungsobjekt bereitgestellt
werden.
CSM ist das Bindungsobjekt des TINA-Connection-Managements und unterstützt nur Schnittstellen vom TINA-Typ Stream Interface (SI). CSM ist
die IDL-Spezifikation der AVS-Schnittstelle StreamEndPoint (SEP) nicht
bekannt. Damit kann es nicht als Bindungsobjekt für die ComputationalObjekte der Abbildung 5.4 eingesetzt werden.
Des weiteren funktioniert das StreamEndPoint-Objekt nur mit der StreamBinding-Semantik des AVS-Standards. Demnach ist es auf die Existenz eines
StreamEndPoint-Objektes als Peer angewiesen.
Das Objektmodell mit MMDevice und UAP ermöglicht bis jetzt keine Bindung der Stream-Schnittstellen unter Verwendung von CSM. Durch Einführung eines weiteren Computational-Objektes kann der Austausch von kontinuierlichen Daten zwischen diesen Objekten dennoch ermöglicht werden.
Dieses Objekt besitzt den Charakter eines Adapters, der eine Umsetzung
zwischen den Konzepten vornimmt und den jeweiligen Partner vor einem
Objekt verbirgt. Das Objekt tritt gegenüber MMDevice und UAP als Partner
für Interaktionen über operationale- und für Datenaustausch über StreamSchnittstellen auf.
75
Der Adapter motiviert eine Modellierung der Bridge nicht nur als Informationsobjekt, sondern auch als ein Computational-Objekt. Das Informationsobjekt SFEPBridge besitzt zwei Richtungsattribute, diese Eigenschaft wird in der
Computational-Modellierungssicht durch zwei Stream-Schnittstellen3 eines
Computational-Objektes sichtbar. Durch die im Informationsmodell definierte Beschränkung der Belegung beider Attribute (entgegengesetzte Richtung)
sind die Stream-Schnittstellen von komplementärer Signatur.
5.4.2.2 Das Bridge-Konzept in der Computational-Modellierungssicht
Das Informationsobjekt SFEPBridge wird in der Computational-Modellierungssicht als ein Computational-Objekt mit zwei Stream-Schnittstellen
dargestellt. Die Konfiguration der zu bindenden Computational-Objekte im
integrierten Ansatz zeigt Abbildung 5.5.
Das Bridge-Objekt besitzt genau zwei Stream-Schnittstellen, davon ist eine
vom AVS-Typ SEP, die andere ist vom TINA-Typ SI. Als ComputationalObjekt besitzt das Bridge-Objekt damit eine Stream-Schnittstelle des AVSStandards und eine von TINA.
Abbildung 5.5: Das Bridge-Objekt als Computational-Objekt mit zwei
Stream-Schnittstellen
i_BridgeControl
MMDevice
Bridge
TINA Stream-Schnittstellen (SI)
AVS Stream-Schnittstellen (SEP)
Bridge: Computational-Objekt
mit zwei Stream-Schnittstellen
unterschiedlichen Typs
UAP
MMDevice: Multi Media Device,
Computational-Objekt mit AVS-Stream-Schnittstelle
UAP:
User Application,
Computational-Objekt mit TINA-Stream-Schnittstelle
Das im letzten Abschnitt eingeführte Informationsmodell enthält keine Assoziation zwischen einem AVS- und einem TINA-Stream-Flow-Endpunkt.
Und damit auch nicht zwischen den zu Stream-Schnittstellen aggregierten
Stream-Flow-Endpunkten.
Die SFEP-Objekte des Informationsmodells werden im ComputationalModell durch Stream-Schnittstellen repräsentiert. Da es im Informations3 Eine
76
Stream-Schnittstelle ist eine Aggregation von SFEPs.
modell keine Assoziation zwischen SFEPAV S und SFEPT INA gibt, enthält das
Computational-Modell keine Computational-Bindung zwischen den StreamSchnittstellen SEP und SI.
Sowohl aus dem Informations- als auch dem bis jetzt entworfenen
Computational-Modell ist ersichtlich, daß der Transport kontinuierlicher
Daten zwischen MMDevice und UAP nicht durch eine einzige Bindung von
zwei Stream-Schnittstellen ermöglicht werden kann. Es sind zwei Bindungen bereitzustellen, zwischen MMDevice und Bridge und zwischen Bridge
und UAP. Als Bindungsobjekt für die Objekte Bridge und UAP wird CSM
verwendet. Für die Bindung zwischen MMDevice und Bridge wird ein neues
Bindungsobjekt modelliert, das Objekt wird als Bridge Binding Manager
(BBM) bezeichnet.
Die Konfiguration der Computational-Objekte für den integrierten Ansatz
zeigt die folgende Abbildung.
Abbildung 5.6: Bridge Binding Manager als Bindungsobjekt für MMDevice
und Bridge
BBM
CSM
i_BridgeControl
MMDevice
MMDevice
Bridge
UAP
Interaktion an operationaler Schnittstelle
BBM: Bridge Binding Manager
CSM Communication Session Manager
Die Funktionalität von BBM besteht in der Bereitstellung einer Verbindung
zwischen genau zwei Stream-Schnittstellen des AVS-Standards. BBM stellt
eine Verbindung zwischen MMDevice- und Bridge-Objekt her. Die besondere
Beachtung des AVS-Terminals und die Optimierung der Stream-Verbindung,
die BBM gegebenüber dem AVS-StreamCtrl-Objekt auszeichnet, werden in
der Engineering- bzw. Technology-Modellierungssicht sichtbar.
77
5.4.2.3 Voraussetzungen für die Teilnahme des AVS-Terminals am
TINA-Connection-Management
Vor dem Entwurf der Schnittstellen der neu eingeführten COs BBM und
Bridge sollen zunächst die für die Umgebung des AVS-Terminals bereitzustellenden Schnittstellen diskutiert werden. Die Referenzpunkte Ret und
TCon fordern von einer CPE die Existenz der Schnittstellen von TCSM und
TLA. Die Modellierung der Objekte, die diese Schnittstellen unterstützen
und damit die erwartete Funktionalität erbringen, ist nicht vorgeschrieben.
Für das AVS-Terminal ergeben sich damit zwei Möglichkeiten. Die erste besteht in der Bereitstellung der Funktionalität durch neue Objekte des AVSTerminals (BBM, Bridge oder weiteren). Die zweite baut auf die Nutzung der
im AVS-Terminal existierenden Objekte TCSM und TLA auf. Eine Neuimplementierung ist dann notwendig, wenn spezifische Anforderungen des AVSTerminals eine Änderung der Funktionalität erfordern.
Die Aufgaben eines TLA-Objektes bestehen in der Bereitstellung und Manipulation von NWTTPs auf Anforderung von Objekten der Verbindungsanbieterdomäne. Nach erfolgter NWTTP-Bereitstellung für eine Network-FlowVerbindung wird ein NFEP-Objekt als technologieunabhängige Sicht auf den
Trail-Terminierungspunkt an das TCSM-Objekt übermittelt. Anhand der von
TCSM bei der SFEP-Anmeldung vergebenen Korrelations-ID kann TCSM
den TFC-Aufbau abschließen. Die Funktionen des TLA-Objektes werden im
AVS-Terminal unmodifiziert verwendet, da der Aufbau von Network-FlowVerbindungen weiterhin durch das TINA-Connection-Management erfolgt.
Im AVS-Terminal wird der Aufbau der terminallokalen Stream-FlowVerbindung zwischen MMDevice und Bridge an die Benachrichtigung über
die NFEP-Bereitstellung gekoppelt. Diese und andere Benachrichtigungen
können an der i_NotifyCtrl-Schnittstelle des TCSM-Objektes bestellt
werden. Die Verwendung dieser Schnittstelle ist die einzige Besonderheit
des AVS-Terminals in Zusammenhang mit dem TCSM-Objekt. Durch die
i_NotifyCtrl-Schnittstelle kann das im AVS-Terminal bereits existierende TCSM-Objekt ohne Modifikationen genutzt werden.
Das Bridge-Objekt wurde als Computational-Objekt mit zwei StreamSchnittstellen entworfen. Die Bindung der TINA-konformen StreamSchnittstelle mit der eines UAP-Objektes erfolgt durch das TINA-ConnectionManagement. Die zweite Stream-Schnittstelle des Bridge-Objektes wird mit
der des MMDevice-Objektes gebunden. Diese Bindung erfolgt durch das
BBM-Objekt und kann, wie im AVS-Standard beschrieben, im leichten oder
im vollen Profil erfolgen. Für das AVS-Terminal wird das leichte Profil verwendet. Das volle Profil bietet die (Engineering-)Möglichkeit der Verteilung
einzelner Flow-Endpunkte auf unterschiedliche Knoten. Diese Eigenschaft
wird nicht benötigt, da sich alle Endpunkte des MMDevice- und des BridgeObjektes innerhalb des AVS-Terminals befinden.
78
Zur Vorbereitung der Stream-Flow-Verbindung zwischen MMDevice und
Bridge gehört die Instanziierung einer AVS-Stream-Schnittstelle durch das
Bridge-Objekt.
Damit sind die im AVS-Terminal notwendigen Voraussetzungen identifiziert,
die für Interaktionen mit dem TINA-Connection-Management während des
Bindungsprozesses notwendig sind.
5.4.2.4
Die Schnittstellen der Objekte BBM und Bridge
Das Computational-Objekt BBM besitzt die drei Schnittstellen i_Factory,
i_BridgeBindingManager und i_Notify.
Die Schnittstelle i_BridgeBindingManager wird vom ssUAP-Objekt4 zur
Bereitstellung von TINA-Stream-Schnittstellen für ein vom Nutzer ausgewähltes MMDevice-Objekt genutzt. An i_Notify empfängt BBM Benachrichtigungen des TCSM-Objektes.
Das Bridge-Objekt besitzt die Schnittstellen i_BridgeCtrl zur Steuerung der Stream-Verbindungen zu einem MMDevice-Objekt sowie
i_Configurator und i_BridgeSEP für Interaktionen mit dem AVS-Gerät.
Die IDL-Beschreibung der Schnittstellen befinden sich im Anhang.
5.4.2.5
Computational-Interaktionen - Stream-Binding-Szenario
Das Szenario beschreibt beschreibt die Bereitstellung mehrerer StreamFlow-Verbindungen. Die Bindung zwischen der Stream-Schnittstelle des
MMDevice-Objektes im AVS-Terminal und eines UAP-Objektes einer anderen CPE wird durch eine Folge von Interaktionen zwischen ComputationalObjekten hergestellt. Es ist nicht entscheidend, ob das UAP-Objekt, mit dem
das MMDevice-Objekt gebunden wird, eine TINA-Anwendung ist, oder ob es
sich dabei ebenfalls um eine Anwendung eines AVS-Terminals handelt.
Das folgende Szenario baut auf einer bestehenden Service-Sitzung auf.
Damit ist eine dienstspezifische Komponente einer Anwendung im AVSTerminal instanziiert und eine für Einladungen bereitgestellte Schnittstelle dem User Session Manager (USM) in der Anbieterdomäne bekannt.
Ausgehend von der bestehenden Service-Sitzung werden der Aufbau einer
Communication-Sitzung und die Verarbeitung der Benachrichtigung über
die NFEP-Zuordnung während des Aufbaus der zugehörigen ConnectivitySitzung beschrieben. Das Szenario folgt den Schnittstellenbeschreibungen
und dem Verhalten der Objekte der Network Component Specification [24],
dem Nachfolgedokument von Network Ressource Architecture [25].
4 Das
Objekt ssUAP bietet einem Nutzer die im AVS-Terminal registrierten MMDeviceObjekte zur Auswahl an.
79
80
16: sinks = request_connection(sources:FlowSpec)
:BridgeSEP {new}
5: si = configureSI(aVDev:VDev, reqFlows:t_MediaDescList)
13: (i=1..n) notify(list:t_notify_list)
9: setNotificationDestination(self:i_Notify)
8: (i=1..n) registerSFEP(name:t_SFEPName)
14: connectToSEP(sfeps:t_SFEPBridgeDescList)
15: connect(aSEP:StreamEndPoint, sfeps:t_SFEPBridgeDescList)
:BridgeCtrl {new}
:Configurator {new}
4: si = setup(aVDev:VDev,
aSEP:StreamEndPoint,
reqFlows:t_MediaDescList)
:BridgeBindingManager
7: (i=1..n) set_format(name:flowName, media:MediaDesc)
aSEP:StreamEndPoint {new}
aVDev:VDev {new}
6: flowNameSeq := get_property("Flows")
aMMDev:MMDevice
3: aSEP, aVDev := create_A()
1: si = addPartyPaSBInd(reqFlows:t_MediaDescList)
2: si := prepareNodalBinding(aMMDevice:MMDevice, reqFlows:t_MediaDescList )
:ssUAP
:TLA
:CSM
11: (i=1..n) correlate(name:t_SFEPName, id:t_Id)
12: (i=1..n) associate(id:t_Id, finalNFEP:t_NFEP)
:TCSM
:SSM
10: addUSR(si:t_SFEPDescList)
:USM
0: si = addParticipantsPartyPaSBInd()(reqFlows:t_MediaDescList)
Abbildung 5.7: Das Stream-Binding Szenario des integrierten Ansatzes
1. User Session Manager (USM) sendet eine Aufforderung zur StreamBinding-Teilnahme an die dienstspezifische Anwendung (ssUAP). Einer
der übergebenen Parameter ist eine Liste von Mediabeschreibungen der
zu diesem Dienst gehörenden Flows.
2. ssUAP beauftragt das BridgeBindingManager-Objekt mit der Bereitstellung einer TINA-Stream-Schnittstelle für ein durch den Parameter
aMMDevice gewähltes AVS-Gerät.
3. BridgeBindingManager fordert von MMDevice die Erzeugung eines VDev- und eines StreamEndPoint-Objektes. Danach wird ein
BridgeCtrl-Objekt erzeugt.
4. Das BridgeCtrl-Objekt wird für das MMDevice-Objekt konfiguriert.
5. BridgeCtrl instanziiert die Objekte Configurator und BridgeSEP. Das
Configurator-Objekt wird mit der Konfiguration des VDev-Objektes für
den TINA-Dienst beauftragt.
6. Das Configurator-Objekt parametrisiert die einzelnen Flows des VDevObjektes für die vom TINA-Dienst geforderten Kodierungen. Dazu erfragt es vom VDev-Objekt zuerst die Flow-Namen. Danach erfragt es
einzeln die Flow-Richtungen.
7. Für korrespondierende Flow-Namen wird durch set_format() die
vom TINA-Dienst geforderte Kodierung eingestellt.
Für jeden Flow der TINA-Dienstbeschreibung, für den VDev einen
Flow mit gleichem Namen und entgegengesetzter Richtung enthält
und bei dem die Einstellung der Kodierung gelungen ist, wird eine t_SFEPBridgeDesc-Struktur erzeugt. Damit entsteht eine SFEPListe, die eine Teilmenge der von VDev und dem TINA-Dienst verwendeten SFEPs darstellt.
Die SFEP-Liste wird als TINA-Schnittstellenbeschreibung des AVSGerätes an BridgeCtrl zurückgegeben. BridgeCtrl liefert die Beschreibung als Ergebnis der setupSI()-Operation an BridgeBindingManager zurück.
8. BridgeBindingManager registriert die SFEP-Namen am TCSM. Die
Objektreferenz von TCSM ist durch Registrierung am Namensdienst
bekannt.
9. BridgeBindingManager bestellt Benachrichtigungen am TCSM, um
später über die Zuweisung von NFEPs zu SFEPs informiert zu werden.
Die TINA-Schnittstellenbeschreibung wird an ssUAP zurückgegeben.
ssUAP gibt sie als Ergebnis der addPartyPaSBInd()-Anforderung an
das USM-Objekt zurück und dieses weiter an SSM.
81
10. SSM beauftragt CSM, eine Communication-Session zu erzeugen, und
übergibt als Parameter die Stream-Schnittstellen der Dienstteilnehmer.
11. CSM generiert eine Korrelations-ID für jeden SFEP, die ID wird TCSM
übermittelt. Diese ID ordnet SFCs und NFCs einer TFC zu, sie wird
durch den Aufruf correlate() dem TCSM mitgeteilt.
Diese ID wird später von TLA verwendet, um TCSM die Auswahl des
gewählten NFEP-Objektes mitzuteilen, dann erst kann TCSM den
TFC-Aufbau abschließen.
Nach diesem Schritt befindet sich das AVS-Terminal in dem folgenden Zustand:
Das AVS-Terminal verfügt über eine TINA-Stream-Schnittstelle, deren
SFEPs in Name, Richtung und Charakteristik (Kodierung) einer Teilmenge der SFEPs des AVS-Gerätes entsprechen.
Die erzeugten SFEPs sind TCSM bekannt.
TFCs sind noch nicht vollständig aufgebaut.
Die nachfolgenden Aktionen von CSM bauen eine Connectivity-Sitzung auf.
Die dabei stattfindenden Interaktionen sind unabhängig von den Erweiterungen des AVS-Terminals und wurden im Collaboration-Diagramm 5.7 nicht
notiert. Mit dem Aufbau der Connectivity-Sitzung beauftragt CSM das Objekt
Connection Coordinator (CC) aus der Verbindungsanbieterdomäne. CC stellt
Network-Flow-Verbindungen zwischen NFEPs her. Die Auswahl der verwendeten NFEP-Objekte eines Terminals wird am Terminal Layer Adapter bekanntgegeben.
Diese Benachrichtigung enthält die Korrelations-ID. TCSM kann dadurch
die Terminal-Flow-Verbindung eindeutig identifizieren und dieser das NFEPObjekt zuordnen.
In einer TINA-CPE ohne AVS-Erweiterung wäre der TFC-Aufbau abgeschlossen und TFC in einem aktivierbaren Zustand. Für das AVS-Terminal gilt diese Aussage noch nicht. Es muß zunächst eine Verbindung für den Transport
der Daten zwischen StreamEndPoint und BridgeSEP bereitgestellt werden.
12. TLA sendet eine Benachrichtigung an TCSM über die endgültige
NFEP-Auswahl.
13. TCSM leitet die Benachrichtigung an das zuvor registrierte Objekt
BridgeBindingManager weiter. BridgeBindingManager speichert den
NFEP-Namen in der SFEPBridgeDesc-Struktur.
82
14. Wenn für alle SFEPs eine Zuordnung erhalten wurde, ruft BridgeBindingManager die Operation connectToSEP() am BridgeCtrl-Objekt
auf.
15. BridgeCtrl- ruft connect() an BridgeSEP auf.
16. BridgeSEP interagiert mit dem SEP-Objekt gemäß der Semantik des
AVS-Standards. Das Ziel ist der Aufbau von Flow-Verbindungen zwischen Endpunkten des StreamEndPoint- und des BridgeSEP-Objektes.
Dazu wird für jedes SFEPBridge-Objekt, dessen Attribut DirectionAV S die
Belegung Sink hat, ein Flow-Endpunkt (FEP) erzeugt. Flow-Endpunkte
werden für ein bestimmtes Transportprotokoll erzeugt. Da SFEPBridge
bereits ein NFEP-Objekt zugeordnet worden ist, kann überprüft werden, ob die Adresse des Netzterminierungspunktes verwendet werden kann. Diese Optimierungssmöglichkeit wird in der EngineeringSpezifikation erläutert.
Die zur Verfügung stehenden Protokolle werden von der Verarbeitungsumgebung bestimmt. Da das Protokoll von beiden Endpunkten der
Flow-Verbindung unterstützt werden muß, wird vor Bereitstellung eines Flow-Endpunktes die Unterstützung durch das StreamEndPointObjekt erfragt. Protokolle, die sich besonders für terminallokale FlowVerbindungen eignen, werden in den Technology-Betrachtungen diskutiert.
Die Adressen der erzeugten FEPs werden mit der Operation request_connection() an StreamEndPoint übermittelt.
StreamEndPoint stellt Endpunkte für alle lokalen Senken bereit und
verbindet sie mit den als Parameter übergebenen FEP-Adressen. Für
SFEPs mit der Eigenschaft Source werden weitere Endpunkte erzeugt
und als Rückgabewert an BridgeSEP geliefert.
BridgeSEP erzeugt Endpunkte für jedes SFEPBridge-Objekt mit
dem Attribut dir=Source (Richtung gegenüber dem TINA-Dienst).
Anschließend werden sie mit den aus dem Rückgabewert von
request_connection erhaltenen Adressen verbunden.
Damit ist der Aufbau der Terminal-Flow-Verbindungen im AVSTerminal beendet. Sie sind in einem aktivierbaren Zustand.
Die von StreamEndPoint und BridgeSEP erzeugten Endpunkte sowie deren
Verbindungen stellen Ressourcen der Engineering-Modellierungssicht dar.
Sie entsprechen dem Modell von ODP-Kanälen und benötigen die Unterstützung der umgebenden Verarbeitungseinheit (das AVS-Terminal). Die verschiedenen Möglichkeiten der technologischen Realisierung der Verbindung
83
zwischen StreamEndPoint und BridgeSEP – dazu zählt z.B. die Auswahl geeigneter Transportprotokolle – werden im Kapitel „Technology-Spezifikation“
beschrieben.
5.4.3
Engineering-Spezifikation
Jedes Computational-Objekt des integrierten Ansatzes besitzt in
der Engineering-Spezifikation ein korrespondierendes EngineeringComputational-Objekt (eCO). eCOs werden Kapseln zugeordnet, in denen
sie ausgeführt werden können. Das AVS-Terminal bietet die zur Ausführung
notwendige DPE-Unterstützung.
5.4.3.1 Ein Engineering-Modell der AVS-Objekte
Zu AVS-Geräten gehört eine Implementierung, die die Schnittstellen des
AVS-Standards bereitstellt. Der AVS-Standard enthält keine Vorgaben bezüglich der Engineering-Realisierungen dieser Implementierung. Daher sind
mehrere Engineering-Modelle möglich. Die Implementierung kann in Form
einer dynamisch ladbaren Bibliothek (engl. Dynamic Load Library) oder als
ausführbare Datei (engl. Executable) vorliegen. Das in diesem Abschnitt entworfene Modell ordnet alle eCOs des AVS-Gerätes einer Kapsel zu.
Abbildung 5.8: Beispiel eines AVS-Engineering-Modells
AVS Terminal
AVS Capsule
Capsule
Manager
Cluster
Manager
Factory
MMDevice
Cluster
Manager
VDev
Device
Driver
Device
StreamEnd
Point
Coding
Object
Coding
Object
Channel
Transport kontinuierlicher Daten
Objekterzeugung
Channel
Operationale Schnittstelle
Durch diese Zuordnung ist ausgeschlossen, daß für die Flow-Verbindung zwischen AVS-Objekten und Bridge technologische Verfahren angewendet werden können, die nur innerhalb einer Kapsel möglich sind. Dadurch würden
AVS-Geräte von der Verwendung im AVS-Terminal ausgeschlossen werden,
deren Software als ausführbare Datei vorliegt.
84
In dem hier entworfenen Modell enthält die Kapsel zwei Cluster. Im Referenzmodell ODP wird eine Kapsel durch das Objekt Capsule-Manager und
werden Cluster durch Cluster-Manager-Objekte gesteuert. Sie werden zur Instanziierung von Clusters und Objekten benötigt.
Das Computational-Objekt MMDevice wird auf das Engineering-Objekt Factory abgebildet. Es unterstützt die Schnittstelle MMDevice und ist einem Cluster zugewiesen. Das zweite Cluster enthält das Engineering-Objekt DeviceDriver, das eine gerätespezifische Implementierung der Schnittstellen VDev
und StreamEndPoint bereitstellt. DeviceDriver stellt das gerätespezifischen
Objekt eines AVS-Gerätes dar. Es kann kontinuierliche Daten bereitstellen
und konsumieren. Die Quelle bzw. die Senke dieser Daten ist spezifisch für
das AVS-Gerät. Es kann sich dabei um ein physisches Gerät handeln, von
dem Daten gelesen bzw. an das Daten gesendet werden können (z.B. ein Mikrophon oder ein Lautsprecher). In diesem Fall interagiert DeviceDriver über
eine gerätespezifische Schnittstelle mit dem Gerät, z.B. durch ioctrl()Systemrufe. Quellen und Senken müssen nicht an physische Geräte gebunden werden. Die Senke kontinuierlicher Daten kann eine graphische Oberfläche sein, z.B. ein Fenster des X-Window-Systems. Die Ansteuerung erfolgt
über eine für Anwendungen bereitgestellte Schnittstelle (Application Programming Interface, API).
In der AVS-Kapsel terminieren ein oder mehrere Kanäle für den Transport kontinuierlicher Daten. Für den Transport der Daten über einen Kanal ist das Objekt CodingObject verantwortlich. Es empfängt Daten vom
DeviceDriver-Objekt und sendet sie über den Kanal bzw. empfängt Daten vom
Kanal und übergibt sie an das DeviceDriver-Objekt. CodingObject kodiert und
dekodiert die Daten in das für die Flow-Verbindung ausgehandelte Format.
Alternative Engineering-Modelle
Für die AVS-Objekte sind weitere Engineering-Modelle möglich. Das hier gezeigte Modell ist nur ein Beispiel. Implementierungen für konkrete Geräte
können andere Engineering-Modelle zur Grundlage haben. Die Bestimmung
der Engineering-Computational-Objekte wird sich an der verwendeten Hardware und an unterstützten Flows orientieren. Die Objekte können spezialisierte Schnittstellen von MMDevice, VDev und StreamEndPoint unterstützen. Zusätzlich können die Schnittstellen des vollen Profils FlowEndPoint
und FDev unterstützt werden.
Aus dem AVS-Standard läßt sich die Forderung ableiten, daß alle
Engineering-Modelle die Schnittstellen vom Basistyp MMDevice, VDev und
StreamEndPoint unterstützen müssen. Dieses Kriterium definiert die Menge
der möglichen Modelle.
Das in Abbildung 5.8 gezeigte Modell erfüllt dieses Kriterium.
85
5.4.3.2 Ein Engineering-Modell für die Bridge-Objekte
Die Bridge-Objekte werden zusammen einer Kapsel zugeordnet, die die
Schnittstellen i_BridgeBindingManager, i_Notify, VDev und StreamEndPoint unterstützt. Das BridgeBindingManager-Objekt wird in dieser
Kapsel einem Cluster zugeordnet und erzeugt BridgeCtrl-Objekte jeweils in
einem anderen Cluster. Damit können BridgeCtrl-Objekte parallel in der
Kapsel ausgeführt werden, wodurch mehrere AVS-Geräte im AVS-Terminal
unabhängig voneinander verwendet werden können. Die Lebenszeiten der
BridgeCtrl-Clusters sind unabhängig voneinander und durch die Dauer der
Verwendung des jeweiligen AVS-Gerätes bestimmt.
Abbildung 5.9: Bridge-Engineering-Spezifikation
AVS-Terminal
i_BridgeBindingManager
Bridge Capsule
Capsule
Manager
Cluster
Manager
i_Factory
BridgeBinding
Manager
i_Notify
Factory
i_BridgeCtrl
Cluster
Manager
Configurator
i_Configurator
VDev
StreamEnd
Point
BridgeCtrl
BridgeSEP
Flow
Adapter
i_BridgeSEP
Cluster
Manager
Objekterzeugung
Das BridgeSEP-Objekt instanziiert während des Bindungsprozesses mehrere FlowAdapter-Objekte jeweils in einem neuen Cluster. Dadurch können sie
parallel ausgeführt werden, und blockierendes Warten auf das Eintreffen von
Daten über den Kanal hat keine Auswirkungen auf den Datenfluß der ande-
86
ren Kanäle. Die Funktion des FlowAdapter-Objektes besteht darin, Daten, die
über eine Trail-Verbindung am AVS-Terminal eintreffen, zum CodingObject
der AVS-Kapsel zu transportieren. Die folgende Abbildung verdeutlicht den
Transport der Daten:
Abbildung 5.10: Transport kontinuierlicher Daten über zwei Kanäle
AVS Terminal
AVS Capsule
Bridge Capsule
Device
Driver
BridgeSEP
StreamEnd
Point
Coding
Object
StreamEnd
Point
Flow
Adapter
Channel
Channel
Objekterzeugung
In dieser Konfiguration terminieren am FlowAdapter-Objekt zwei Kanäle. Möglichkeiten der technologischen Realisierung des Kanals zum CodingObject werden im nächsten Abschnitt erläutert. Daten, die am TrailTerminierungspunkt (NWTTP) des Terminals eintreffen, werden vom
FlowAdapter-Objekt auf einen lokalen Speicherbereich kopiert und anschließend über den Kanal zum CodingObject transportiert. Die Daten werden
dabei nicht verändert.
Der Kanal zwischen CodingObject und FlowAdapter-Objekt wird gemäß dem
AVS-Standard aufgebaut (Stream-Binding-Szenario in Abschnitt 5.4.2.5). Im
oben gezeigten Bild stellt CodingObject eine Senke dar. Der AVS-Standard
legt für den Aufbau von Flow-Verbindungen fest, daß die Seiten in der die
Flow-Verbindung terminiert (Senke), einen Terminierungspunkt bereitstellt
und die Adresse an den Sender übermittelt. Für die im Bild gezeigte Konfiguration baut FlowAdapter eine Verbindung (Kanal) zu dem vom CodingObject erzeugten Terminierungspunkt auf. BridgeSEP hat dabei Einfluß auf das
verwendete Protokoll (es wird über die StreamEndPoint-Schnittstelle ausgehandelt), nicht jedoch auf die vom DeviceDriver-Objekt gewählte Adresse des
Terminierungspunktes.
87
Für die umgekehrte Flow-Richtung stellt CodingObject die Quelle
dar. Der Terminierungspunkt wird in diesem Fall vom BridgeSEPObjekt bereitgestellt. BridgeSEP kann durch Aufruf der Operation
get_property(“AvailableProtocols“) an der StreamEndPointSchnittstelle von DeviceDriver feststellen, welche Protokolle unterstützt
werden. Ist das Protokoll der Netzverbindung ein Element dieser Liste, dann
können z.B. für AAL5 die VCI/VPI-Kennungen von NWCTP der Netzverbindung als Adresse des Terminierungspunktes an das DeviceDriver-Objekt
übermittelt werden. Das DeviceDriver-Objekt erzeugt CodingObject, das die
Daten direkt über den Netzterminierungspunkt des AVS-Terminals sendet.
Durch BridgeSEP wird kein FlowAdapter-Objekt erzeugt:
Abbildung 5.11: Transport kontinuierlicher Daten über einen Kanal – ein
Kopieren ist nicht notwendig
AVS Terminal
AVS Capsule
Bridge Capsule
Device
Driver
BridgeSEP
StreamEnd
Point
StreamEnd
Point
Coding
Object
Channel
Objekterzeugung
5.4.3.3 Engineering-Modell für das AVS-Terminal
Neben den bereits zugeordneten Objekten von AVS und Bridge existieren im
AVS-Terminal die Objekte ssUAP, TCSM und TLA. ssUAP wird als eigenständige Kapsel des AVS-Terminals modelliert, da es mehrere Nutzeranwendungen in einer TINA-CPE geben kann, die unabhängig von allen anderen
Objekten existieren. TINA-CPEs verfügen über mehrere TLA-Objekte, eins
für jedes Layer-Netz, an das sie angeschlossen sind. Da die Funktion eines
Layer-Netzes unabhängig von dem Zustand anderer Netze ist, bildet jedes
88
TLA-Objekt eine eigene Kapsel. TCSM existiert genau einmal in jeder CPE,
die Lebenszeit ist an kein anderes Objekt gekoppelt und bildet damit eine
eigene Kapsel.
Damit sind alle Objekte des AVS-Terminals Ressourcen zugeordnet. Abbildung 5.12 enthält das Engineering-Modell. Sie zeigt das AVS-Terminal in
einer Konfiguration, in der eine Flow-Verbindung in der AVS-Kapsel terminiert:
Abbildung 5.12: Das AVS-Engineering-Modell des AVS-Terminals
AVS-Terminal
Application Capsule
Cluster
Manager
Capsule
Manager
ssUAP
Manager
i_PartyPaSBInd
i_BridgeBindingManager
Bridge Capsule
Cluster
Manager
AVS Capsule
i_Factory
Capsule
Manager
Cluster
Manager
i_Notify i_NotifyCtrl
TFC Manager
Cluster
Manager
Configurator
VDev
StreamEnd
Point
i_TlaTcsm
i_Configurator
VDev
StreamEnd
Point
Cluster
Manager
i_Terminal
ComSControl
i_BridgeCtrl
MMDevice
Device
Driver
Cluster
Manager
Notifier
Factory
Cluster
Manager
Capsule
Manager
SFEP Manager
i_SFEPCtrl
BridgeBinding
Manager
Factory
Device
TCSM Capsule
Capsule
Manager
BridgeCtrl
BridgeSEP
TLA Capsule
Capsule
Manager
i_BridgeSEP
Cluster
Manager
Coding
Object
Flow
Adapter
Cluster
Manager
Channel
NFEP Manager
i_tcontlaNfepControl
Channel
Objekterzeugung
Ein Engineering-Modell für einen allgemeineren Ansatz
Das AVS-Terminal wurde als eine mit AVS-Geräten ausgestattete TINACPE definiert. Unter Abänderung dieser Definition – bei der AVS- und
Bridge-Objekte nicht genau einem Knoten zugeordnet werden – sind weitere Engineering-Modelle möglich. Diese lassen mehr Varianten der Zuordnung von Objekten zu Knoten zu. Beispielsweise können die AVS-Objekte
89
einem anderen Terminal zugeordnet werden als die Bridge-Objekte, sofern
CORBA-Interaktionen zwischen eCOs von AVS und Bridge möglich sind und
Stream-Endpunkte eine Verbindung für den Transport kontinuierlicher Daten bereitstellen können. Neben der Unterstützung der drei Schnittstellen
des AVS-Standards durch Objekte dieses Knotens werden keine weiteren Forderungen an den Knoten gestellt.
Die Verallgemeinerung erlaubt die Verwendung eines AVS-Gerätes auf einem
anderen Knoten als dem der Bridge-Objekte (die weiterhin benötigt werden).
Dem AVS-Gerät kann der Trail-Terminierungspunkt nicht mehr als FEPAdresse zugewiesen werden, da sich dieser im AVS-Terminal und nicht im
Knoten des AVS-Gerätes befindet. Ein Kopieren der Daten im Bridge-Objekt
ist nicht zu vermeiden.
Der in [17] verfolgte Ansatz enthält ein solches Modell, er gibt keine Einschränkungen bezüglich der Zuordnung von eCOs zu Knoten vor.
5.4.3.4 Zusammenfassung der Engineering-Spezifikation
Die aufgezeigten Varianten der Engineering-Spezifikation haben gezeigt, daß
es mehrere Möglichkeiten für die Zuordnung von Engineering-Objekten zu
den Ressourcen (Kapseln, Clusters) des AVS-Terminals gibt. Sie werden im
wesentlichen motiviert durch die Anzahl möglicher Instanzen, der logischen
Zusammengehörigkeit von Funktionalität und der Unabhängigkeit der Lebenszeit von Objekten. Die Entscheidung, ob ein einziger Kanal für den
Transport kontinuierlicher Daten zwischen AVS-Gerät und einem TINADienst genügt, ist von der Flow-Richtung und dem Transportprotokoll der
Netzverbindung abhängig.
5.4.4
Technology-Spezifikation
Die Technology-Spezifikation beschreibt die Auswahl verwendeter Technologien. Sie enthält eine Abbildung von Engineering-Konzepten auf technologische Lösungen. Der Schwerpunkt liegt auf der Implementierung von operationalen und Stream-Kanälen [9].
Für operationale Kanäle wird CORBA [6] verwendet. Es sind mehrere
Sprachabbildungen (engl. Language Mappings) definiert worden, sodaß
durch IDL-Compiler für verschiedene Programmiersprachen Stub-Objekte
eines ODP-Kanals generiert werden können.
Eine Implementierung des AVS-Terminals benötigt keine herstellerspezifischen Erweiterungen, sodaß die Wahl eines CORBA-Produktes beliebig ist,
solange es zu CORBA 2.0 konform ist. Die Produkte ORBIX 2000 der Firma
90
IONA, Visibroker von Inprise und ORBacus von OOC gehören zu den bekanntesten Vertretern. Alle Produkte sind konform zu CORBA 2.0 und eignen sich
gleichermaßen für operationale Interaktionen zwischen eCOs von AVS, TINA
und des integrierten Ansatzes.
Für Stream-Kanäle zur Übertragung kontinuierlicher Daten bietet CORBA
keine Unterstützung, aus diesem Grund wurde der Standard „Control and
Management of Audio / Video Streams“ entwickelt. Im AVS-Terminal wird
für jeden Flow ein Kanal zwischen den beiden Flow-Endpunkten CodingObject und FlowAdapter benötigt. In der Engineering-Spezifikation wurde definiert, daß sich beide Endpunkte in unterschiedlichen Kapseln des gleichen
Knotens befinden. Die Implementierung eines Protokollobjektes kann damit
alle Möglichkeiten der Interprozeßkommunikation nutzen, die das Betriebssystem des AVS-Terminals unterstützt. Für den Transport kontinuierlicher
Daten sind das UDP-Protokoll und Named Pipes5 besonders geeignet, da sie
zeichenorientiert arbeiten. Ein anderes Verfahren ist die Verwaltung eines
Ringpuffers in einem von verschiedenen Kapseln adressierbaren Speicherbereich6 . Ein Ringpuffer stellt eine bestimmte Anzahl Rahmen bereit, die vom
Protokollobjekt des Source-FEP-Objektes beschrieben und vom Sink-FEPObjekt gelesen werden. Die Adresse eines Flow-Endpunktes auf Named-PipeBasis ist die Position der Datei im Dateisystem.
5.4.4.1
Auswahlkriterien für einen terminallokalen Transportmechanismus
Das Zwischenspeichern der Daten im FlowAdapter-Objekt führt zu einer zusätzlichen Verzögerung des Empfangs der Daten in der AVS-Kapsel bzw. am
TINA-Dienst. Eine geringe Latenzzeit sowie ein hoher Datendurchsatz sind
wichtige Merkmale der Dienstgüte. Sie bilden die Hauptkriterien bei der Auswahl des Protokolls. Des weiteren sollte die CPU-Belastung gering sein.
Der Transport von Daten über Named Pipes bzw. Ringpuffer in Memory Mapped Files sind die effizientesten Methoden, Daten innerhalb eines Knotens zu
transportieren. Das gewählte Protokoll muß von beiden FEP-Objekten unterstützt werden. Die Möglichkeit der Verwendung eines der beiden Protokolle sollte in jedem Fall überprüft werden, bevor ein anderes Protokoll verwendet wird. Werden sie durch das AVS-Produkt nicht unterstützt, so können auch für terminallokale Verbindungen verbreitete Netzprotokolle wie z.B.
TCP oder UDP verwendet werden.
5 Named
Pipes werden nicht von Microsoft Windows NT unterstützt.
Windows NT ermöglicht Memory Mapped Files, UNIX bietet zusätzlich Shared
Memory
6 Microsoft
91
92
6 Zusammenfassung und Ausblick
Die Aufgabe der vorliegenden Arbeit bestand darin, in einem TINAorganisierten Netz die Verwendung multimedialer Geräte zu ermöglichen,
die konform zum OMG-Standard „Control and Management of Audio /
Video Streams“ (AVS) sind. Die besondere Eigenschaft multimedialer Anwendungen und Geräte ist, daß sie Quellen und Senken kontinuierlicher
Daten bereitstellen. Diese Daten werden über Stream-Flow-Verbindungen
transportiert.
Die von AVS und TINA verwendeten Konzepte, die in Zusammenhang mit
der Bereitstellung von Stream-Flow-Verbindungen stehen, wurden in dieser
Arbeit eingeführt und gegenübergestellt.
Es hat sich gezeigt, daß durch die Einführung neuer Informations- und
Computational-Objekte ein Modell entwickelt werden kann, das die Integration von AVS-konformen Geräten in die verteilte Verarbeitungsumgebung
TINA-DPE ermöglicht. Die Schnittstellen des AVS-Standards sowie die Spezifikationen der TINA-Referenzpunkte Ret und TCon bildeten dabei den Ausgangspunkt.
Bei der ODP-Spezifikation wurde deutlich, daß einige Varianten des
Engineering-Modells die Möglichkeiten der Zuordnung des AVS-Gerätes zu
beliebigen Knoten der Verarbeitungsumgebung erlauben, während andere
für die Verwendung des AVS-Gerätes in TINA-CPE geeignet sind.
Die Leistungsfähigkeit des vorgestellten Bridge-Konzeptes kann deutlich erhöht werden, sobald ein Rahmenwerk für die Medienbeschreibung von TINADiensten vorliegt. Dann kann die Adapterfunktionalität nicht nur für die
Netz- sondern auch für die Stream-Verbindungen bereitgestellt werden. Die
Annahme der Kompatibilität der Medienformate würde entfallen. Ein Adapter auf Stream-Ebene könnte eventuell notwendige Transformationen der
Daten vornehmen.
Der OMG-AVS-Standard hat bis jetzt nur geringe Akzeptanz gefunden. Insbesondere im Internet-Bereich haben sich proprietäre Lösungen zum Transport kontinuierlicher Daten durchgesetzt.
Das Bridge-Konzept kann in weiteren Arbeiten als Grundlage für die Integration anderer Produkte in ein TINA-organsiertes Netz dienen.
93
6 Zusammenfassung und Ausblick
94
7 Anhang
Abkürzungsverzeichnis
AVS
Audio Video Streams
BBM
Bridge Binding Manager
BEO
Basic Engineering Object
CO
Computational Object
CORBA
Common Object Request Broker Architecture
CPE
Customer Premises Equipment
CSM
Communication Session Manager
DPE
Distributed Procesing Environment
FC
Flow Connection
FEP
Flow End Point
IDL
Interface Definition Language
LCG
Logical Connection Graph
NFEP
Network Flow End Point
NFP
Network Flow Connection
NRIM
Network Resource Information Model
NWCTP
Network Connection Termination Point
NWTTP
Network Trail Termination Point
ODP
Open Distributed Processing
OMA
Object Management Architecture
OMG
Object Management Group
ORB
Object Request Broker
PCG
Physical Connection Graph
RFP
Request For Proposal
95
7 Anhang
SC
Stream Connection
SEP
Stream End Point
SFEP
SFP
Simple Flow Protocol
SFP
SI
Stream Interface
SSM
Service Session Manager
TCSM
Terminal Communication Session Manager
TFC
Terminal Flow Connection
TINA
Telecommunications Information Networking
Architecture
TLA
Terminal Layer Adapter
UAP
User Application
USM
User Session Manager
96
IDL-Schnittstellenbeschreibungen der eingeführten Objekte
// AVS IDL-Beschreibungen
#include <MediaStreams.idl> // enthält Schnittstellen des
// leichten Profils
// TINA IDL-Beschreibungen
#include <naming.idl>
#include <sfepcoms.idl>
#include <TCSM.idl>
// allgemeine Typen
// SFEP und MediaDesc
// definiert i_Notify
typedef string t_SFEPBridgeName;
typedef sequence<t_SFEPBridgeName> t_SFEPBridgeNameList;
typedef t_SFEPBridgeDesc {
t_SFEPBridgeName
name;
t_SFlowDirection
dir; // gegenüber TINA-Dienst
t_MediaDesc
media;
t_NFEPName
nfep;
};
typedef sequence<t_SFEPBridgeDesc> t_SFEPBridgeDescList;
typedef t_SFEPBridgeDescList t_SI;
enum t_SuccessCriterion {BestEffort, AllOrNone};
module BBM {
interface i_BridgeBindingManager {
// Stellt TINA Stream-Schnittstelle bereit
void prepareNodalBinding(in MMDevice aMMDev,
out t_SI si);
// Zerstört die Bridge-Verbindung
void destroyNodalBinding(in MMDevice aMMDev);
// zerstört das Objekt
void destroy();
};
97
7 Anhang
interface i_Factory {
i_BridgeBindingManager create();
};
// an i_Notify kann TCSM Benachrichtigungen
// über die Fertigstellung von TFCs senden
interface i_Notify : CommonTypes::i_Notify {
};
}; // module BBM
module Bridge {
interface i_BridgeCtrl
{
// Setup
void setup(in StreamEndPoint aSEP);
// Gibt eine Beschreibung der bereitgestellten
// Stream-Schnittstelle zurück
void getSI( out t_SI desc);
// Aufbau der Stream-Verbindung zu SEP
void connectToSEP(in t_SFEPBridgeNameList sfeps,
out t_SFEPBridgeNameList failList);
// Starten und
void start(in
in
out
Stoppen einzelner Flows
t_SuccessCriterion
crit,
t_SFEPBridgeNameList sfeps,
t_SFEPBridgeNameList failList);
void stop(in t_SuccessCriterion crit,
in t_SFEPBridgeNameList sfeps,
out t_SFEPBridgeNameList failList);
// Auflösen der StreamConnection zu SEP
void releaseNodalBinding();
// Zerstören des BridgeCtrl-Objektes
void destroy()
};
98
// Schnittstelle für Interaktionen mit AVS-VDev
interface i_Configurator : VDev {
void configureSI(out t_SI);
};
// Schnittstelle für Interaktionen mit AVS-StreamEndPoint
interface i_BridgeSEP : StreamEndPoint {
};
}; // module Bridge
99
7 Anhang
100
[1] RFC 793: Transmission Control Protocol (TCP), September 1981.
http://www.ietf.org/rfc/rfc0793.txt.
[2] ATM User-Network Interface Specification V3.1 (UNI V3.1), 1994.
ftp://ftp.atmforum.com/pub/approved-specs/af-uni-0010.002.pdf.tar.Z.
[3] Siemens Nixdorf AG. Control and Management of A/V Streams, Initial
Submission, OMG Document Number telecom/97-02-02. Technical report, Februar 1997.
http://www.omg.org/docs/telecom/97-02-02.pdf.
[4] Rumbaugh Booch, Jacobsen. The Unified Modeling Language. Technical
report, Rational Software Corporation, September 1996.
[5] M. Chapman D. McGrath. A CORBA Framework for Multimedia Streams. Technical report, IONA Technologies, Januar 1998.
[6] Object Management Group. The Common Object Request Broker: Architecture and Specification. Object Management Group, Inc., Framingham,
MA, USA, July 1995.
[7] Object Management Group. Control and Management of A/V Streams,
Request for Proposel, omg document number telecom/96-08-01. Technical report, Mai 1996.
[8] Siemens-Nixdorf IONA Technolgies, Lucent Technologies. Control and
Management of A/V Streams, omg rfp submission, omg document number telecom/97-05-07, Mai 1997.
[9] ITU-T. ITU Recommendation X.901 | ISO/IEC 10746-1: ODP Reference
Model Part 1: Overview and guide to use. Technical report, ITU-T, 1993.
ftp://ftp.dstc.edu.au/pub/arch/RM-ODP/PDFdocs/part1.pdf.
Model Part 2: Foundations. Technical report, ITU-T, 1993.
ftp://ftp.dstc.edu.au/pub/arch/RM-ODP/PDFdocs/part2.is.pdf.
101
Model Part 3: Architecture. Technical report, ITU-T, 1993.
Model Part 4: Architectural Semantics. Technical report, ITU-T, 1993.
ftp://ftp.dstc.edu.au/pub/arch/RM-ODP/PDFdocs/np43.pdf.
[13] ITU-T. Binding Model, chapter 8.4.2. In [9], 1993.
[14] ITU-T. ITU-T Recommendation X.930 Information Technology - Open
distributed processing - Interface references and binding. Technical report, ITU-T, September 1998.
[15] IONA Technologies Ltd. Control and Management of Audio/Video Streams, Initial Submission, OMG Document Number telecom/97-02-01.
Technical report, Februar 1997.
[16] TINA DPE WG members. TINA DPE Architecture Version 2.0b0, Draft
for WG review. Technical report, TINA-C, November 1997.
file://u/tinac/97/resources/dpe/docs/arch/dpe20.
[17] W.Takita O. Kath. OMG A/V Streams and TINA NRA: An integrative
Approach. Technical report, Humboldt University, NTT Japan, 1999.
[18] Project Internal Report 2.3 P 103. Network Resource Model. Technical
report, Eurescom, 1992.
http://www.eurescom.de/~pub-deliverables/p100-series/p103/d6/d6a.zip.
[19] S.P. Rana P.H. Loosemore, E. Sellin. Multimedia stream binding for a
pan-European service platform. BT Technology Journal, 1999.
[20] J. Postel. RFC 768: User Datagram Protocol (UDP), August 1980.
http://www.ietf.org/rfc/rfc0768.txt.
[21] TINA-C Core Team. Engineering Modelling Concepts (DPE Architecture)
Version 2.0. Technical report, TINA-C, Dezember 1994.
[22] TINA-C Core Team. Computational Modelling Concepts Version 2.0.
Technical report, TINA-C, February 1995.
[23] TINA-C Core Team. The TCon Reference Point Version 1.0. Technical
report, TINA-C, November 1996.
http://www.tinac.com/specifications/documents/tconrp.pdf.
102
[24] TINA-C Core Team. Network Components Specification Version 2.2.
Technical report, TINA-C, December 1997.
http://www.tinac.com/specifications/documents/ncs.pdf.
[25] TINA-C Core Team. Network Ressource Architecture Version 3.0. Technical report, TINA-C, Februar 1997.
http://www.tinac.com/specifications/documents/nra_v3_public.pdf.
[26] TINA-C Core Team. Network Ressource Information Model Specification
Version 2.2. Technical report, TINA-C, Oktober 1997.
http://www.tinac.com/specifications/documents/nrim.pdf.
[27] TINA-C Core Team. Service Architecture Version 5.0. Technical report,
TINA-C, Juni 1997.
http://www.tinac.com/specifications/documents/sa50-main.pdf.
[28] TINA-C Core Team. TINA Business Model and Reference Points Version
4.0. Technical report, TINA-C, Mai 1997.
http://www.tinac.com/specifications/documents/bm_rp.pdf.
[29] TINA-C Core Team. The Ret Reference Point Version 1.1. Technical report, TINA-C, April 1999.
http://www.tinac.com/specifications/documents/ret111.pdf.
[30] Lucent Technologies. Initial Submission to Telecom RFP1 (Streams),
OMG Document Number telecom/97-02-03. Technical report, Februar
1997.
103
104
8 Thesen zur Diplomarbeit
These I
Sowohl OMG “Control and Management of Audio / Video Streams“ als auch
TINA ermöglichen den Transport kontinuierlicher Daten zwischen StreamSchnittstellen. Sie verwenden dazu unterschiedliche Konzepte, sodaß die Verwendung AVS-konformer Geräte in einem TINA-organisierten Netz zusätzliche Unterstützung benötigt.
These II
Die Offenlegung der Schnittstellen der Architektur des TINA-Konsortiums
bildet eine wesentliche Voraussetzung für die Spezifikation eines integrierten Modells. Nur durch die exakte Beschreibung der Schnittstellen und des
Verhaltens der Computational-Objekte von TINA und AVS konnte eine Möglichkeit zur Anpassung der unterschiedlichen Konzepte gefunden werden.
These III
Die Nutzung OMG-AVS-konformer Geräte in einem TINA-organisierten Netz
kann durch die Verwendung eines Bridge-Objektes ermöglicht werden.
These IV
Für die Spezifikation des integrierten Modells ist das Referenzmodell ODP
eine geeignete Methode.
These V
Durch das Bridge-Konzept kann die Zuordnung eines AVS-Gerätes sowohl zu
TINA-CPE als auch zu Knoten, die nicht den Anforderungen an TINA-CPE
genügen, erfolgen. Für beide Fälle können unterschiedliche EngineeringModelle spezifiziert werden.
These VI
Das Bridge-Konzept erweitert den Einsatzbereich von AVS-Geräten und
kann als Grundlage für die Integration weiterer Produkte in ein TINAorganisiertes Netz dienen.
105
8 Thesen zur Diplomarbeit
106
Erklärung
Hiermit erkläre ich, daß die vorliegende Arbeit von mir selbst und ohne jede
unerlaubte Hilfe nur unter Verwendung der angegebenen Quellen angefertigt wurde.
Berlin, den 14. September 2000
Helge Hesse
Einverständniserklärung
Hiermit erkläre ich mein Einverständnis, daß diese Arbeit in der Bibliothek
des Institutes für Informatik der Humboldt-Universität zu Berlin öffentlich
ausgelegt wird.
Berlin, den 14. September 2000
Helge Hesse

Diplomarbeit Integration von OMG Audio / Video Streams in TINA-DPE

Transcrição

Documentos relacionados

1 x 1 des Reisemanage ments

Mac Audio Car-HiFi-Lautsprecher Olympic Gold

Vollständigen Artikel als PDF herunterladen - All

TS_to_DVD

klicken - Anglerverband Chemnitz

Firmeninformation

ECO-Flow

factsheetnotebook PDF

psa[flight

psa[duro - Philips