Koordinierte Dienstnutzung in offenen verteilten Dienstemärkten

Koordinierte Dienstnutzung
in o enen verteilten Dienstemarkten
Kay Muller{Jones
Vom Fachbereich Informatik
der Universitat Hamburg
zur Erlangung des akademischen Grades
Doktor der Naturwissenschaften
| Dr. rer. nat. |
genehmigte Dissertation
Promotionsausschu :
Vorsitzender: Prof. Dr. Jantzen (Universitat Hamburg)
Gutachter: Prof. Dr. Lamersdorf (Universitat Hamburg)
Prof. Dr. Mahr (Technische Universitat Berlin)
Tag der Disputation: 4. Dezember 1996

Fur Kathrin

Danksagungen
Zunachst mochte ich Prof. Dr. Lamersdorf danken, der mir im Rahmen meiner
wissenschaftlichen Mitarbeit am Fachbereich Informatik der Universitat
Hamburg eine Arbeitsatmosphare ermoglichte, die Freiraum fur die Umsetzung
innovativer Ideen bot. Zudem mochte ich ihm fur seine Anregungen zu der
vorliegenden Arbeit danken.
In diesem Zusammenhang mochte ich mich auch bei Prof. Dr. Mahr fur die mit
ihm gefuhrten Diskussionen bedanken.
Weiterhin bedanke ichmich bei den zahlreichen Studentinnen und Studenten,
die mit ihren Studien{ und Diplomarbeiten ma geblich zu dieser Arbeit
beigetragen haben, insbesondere Ludwig Brinckmann, Bernd Christiansen, Kai
Greese, Frank Gri el, Stefan Muller, Malte Munke, Se{Hyeon Oh und Andre
Sprenger.
Insbesondere mochteichmichauch bei meinem Kollegen Michael Merz und beim
Doktoranden Tuan Tu fur ihre Zusammenarbeit und Diskussionsbereitschaft
bedanken.
Nichtzuletzt danke ichauch unseren Projektpartnern von der GMD FOKUS in
Berlin und vom DSTC in Brisbane, Australien.

Zusammenfassung
Durch die zunehmende Verfugbarkeit moderner hochleistungsfahiger Kommunikationstechnologien
sind heutzutage wesentliche Voraussetzungen fur eine e ziente,
rechnerbasierte Unterstutzung weltweiter Kooperationen gegeben. Trotz der in einem
derartig globalen " Internet\ inharent vorhandenen Heterogenitat sollte dabei auf
verschiedenartigste Dienstleistungen zugegri en werden konnen, die nicht mehr am
Ort des Zugri s, sondern an beliebiger Stelle im Netzwerk angeboten werden konnen.
Durch einederartige Dienstnutzung wird die Scha ung elektronischer Dienstemarkte
motiviert, in denen | ahnlich zuherkommlichen Warenmarkten|eine gro e Vielfalt
und Vielzahl von Dienstleistungen angeboten und von unterschiedlichen Interessenten
in Anspruch genommen werden konnen.
Angesichts dieser neuartigen Moglichkeiten gewinnen derartige o ene verteilte
Dienstemarkte auch fur die Software{Entwicklung neuer verteilter Anwendungssysteme
zunehmend anInteresse. Einer der Hauptgrunde hierfur ist die Forderung nach Wiederverwendung,
um moglichst aufwendige und damit kostenintensive Neuentwicklungen
zu vermeiden. Um auf diese Weise die verteilt angebotenen Dienste nun inForm eines
Systembaukastens von Diensten bei der Entwicklung verteilter Anwendungen nutzen zu
konnen, sind |uber das Netz als reines Kommunikationsmittel hinaus | zusatzliche
systemtechnische Unterstutzungsmechanismen bereitzustellen. Diese sollen den Zugang
zu den Diensten ermoglichen und die dann verfugbaren Dienste auch koordiniert und
moglichst unberucksichtigt von Verteilungs{ und Heterogenitatsproblemen nutzbar
machen.
Die vorliegende Arbeitschlagt hierzu zunachst einen umfassenden und inherkommliche
verteilte Systemplattformen integrierten Losungsansatz vor, der sich dann konkret in
dem Entwurf und der prototypischen Realisierung der entwickelten Unterstutzungsmechanismen
in der verteilten Systemumgebung TRADE (Service Trading and Coordination
Environment) widerspiegelt. Dieser Ansatz zur systemtechnischen Unterstutzung
koordinierter Dienstnutzung in o enen heterogenen verteilten Dienstemarkten bietet
als wesentliche " generische\ Systemkomponenten zum einen Typmanagement{,
Dienstvermittlungs{ und Interzeptionsmechanismen, die einen weitgehend uneingeschrankten
Dienstzugang ermoglichen. Insbesondere die Dienstvermittlung stellt eines
der zentralen in dieser Arbeit untersuchten Probleme dar. Zum anderen werden
|auf den elementaren generischen Unterstutzungsdiensten aufbauend | allgemeine
Koordinationsmechanismen entworfen und imRahmen der TRADE{Realisierung
zur Verfugung gestellt. Diese unterstutzen die verteilungsabstrahierende Beschreibung
und Ausfuhrung sogenannter Kooperationsanwendungen. Der in dieser Arbeit hierfur
gewahlte Ansatz zeichnet sich vor allem durch seine Konzentration auf die Koordinationsaspekte
von Dienstnutzung aus. Dieses au ert sich unmittelbar auch inder im
Rahmen der hier dargestellten Arbeiten entwickelten Koordinationssprache PAMELA
(Petri net based Activity Management Execution Language) und einem dazugehorigen
Koordinationsmanager. Beide ermoglichen eine neuartige Sichtweise auf die Programmierung
verteilter Anwendungen unter Nutzung von in o enen verteilten Dienstemarkten
an beliebiger Stelle angebotenen Diensten.

Inhaltsverzeichnis
1 Einleitung 1
1.1 Potentiale und Probleme verteilter Systeme : : : : : : : : : : : : : 1
1.2 Das Paradigma der Dienstnutzung :::::::::::::::::: 5
1.3 Vision ausschlie licher Dienstnutzung :::::::::::::::: 5
1.4 Zielstellung und Uberblick :::::::::::::::::::::: 7
I Grundkonzepte zur Unterstutzung koordinierter Dienstnutzung
inheterogenen verteilten Dienstemarkten 11
2 Modellierung und Beschreibung von Diensten 13
2.1 Interoperabilitatsebenen ::::::::::::::::::::::: 13
2.1.1 Dienstmodellebene :::::::::::::::::::::: 14
2.1.2 Dienstbeschreibungsebene :::::::::::::::::: 15
2.1.3 Dienstreprasentationsebene :::::::::::::::::: 16
2.2 Dienstmodelle ::::::::::::::::::::::::::::: 18
2.2.1 Der Objektbegri in verteilten Systemen : : : : : : : : : : 18
2.2.2 Der Dienstbegri ::::::::::::::::::::::: 20
2.2.3 Modellierung von Schnittstellen ::::::::::::::: 22
2.3 Typisierung von Schnittstellen und Diensten : : : : : : : : : : : : 23
2.3.1 Schnittstellen{ und Diensttypen ::::::::::::::: 24
2.3.2 Beziehungen zwischen Diensttypen : : : : : : : : : : : : : 25
2.4 Formen von Dienstbeschreibungen :::::::::::::::::: 28
2.4.1 Benennung von Diensten ::::::::::::::::::: 29
2.4.2 Strukturelle Dienstbeschreibungen : : : : : : : : : : : : : 30
2.4.3 Beschreibung von Diensteigenschaften : : : : : : : : : : : 32
2.4.3.1 Dienstattribute ::::::::::::::::::: 32
2.4.3.2 Konzeptgraphen :::::::::::::::::: 33
2.4.4 Beschreibung des Verhaltens von Diensten ::::::::: 35
2.4.4.1 Protokollspezi kationen : : : : : : : : : : : : : : 35
2.4.4.2 Anwendung von Transitionssystemen ::::::: 37
2.4.4.3 Spezi kation von Vor{ und Nachbedingungen : : 38
2.4.5 Bewertung ::::::::::::::::::::::::::: 40
2.5 Zusammenfassung ::::::::::::::::::::::::::: 43

ii INHALTSVERZEICHNIS
3 Zugang zu Diensten in heterogenen Umgebungen 45
3.1 Grundlegende Problemstellungen :::::::::::::::::: 45
3.1.1 Heterogenitat auf Verarbeitungsebene :::::::::::: 47
3.1.2 Dienstzugangsphasen ::::::::::::::::::::: 49
3.1.2.1 Au nden von Diensttypen ::::::::::::: 49
3.1.2.2 Dienstauswahl ::::::::::::::::::: 51
3.1.2.3 Dienstzugri :::::::::::::::::::: 51
3.2 Diensttypmanagement :::::::::::::::::::::::: 52
3.2.1 Typmanagementinheutigen verteilten Systemplattformen 54
3.2.1.1 Schnittstellenrepository in CORBA : : : : : : : : 54
3.2.1.2 Typverwaltung inANSA:::::::::::::: 55
3.2.2 Aufgaben des Diensttypmanagements :::::::::::: 56
3.2.2.1 Anforderungen an Dienstbeschreibungen : : : : : 57
3.2.2.2 Arten von Typbeziehungen :::::::::::: 58
3.2.2.3 Ablage von Beziehungen und Typen ::::::: 63
3.2.2.4 Typbezeichner und Aliasnamen :::::::::: 63
3.2.2.5 Typverwaltungsdomanen :::::::::::::: 64
3.2.2.6 Diensttyphierarchien :::::::::::::::: 65
3.2.2.7 Typuberprufungen und {vergleiche : : : : : : : : 68
3.2.3 Grundlagen eines verteilten Diensttypmanagements :::: 71
3.2.3.1 Global eindeutige Typbezeichner ::::::::: 72
3.2.3.2 Austausch von Typbeschreibungen : : : : : : : : 73
3.3 Vermittlung und Verwaltung von Dienstangeboten ::::::::: 75
3.3.1 Mechanismen zur Dienstauswahl ::::::::::::::: 75
3.3.1.1 Namens{ und attributbasierte Dienstauswahl : : 75
3.3.1.2 Browsing{basierte Dienstauswahl ::::::::: 77
3.3.1.3 Diensttypbasierte Dienstauswahl ::::::::: 78
3.3.2 ODP{basiertes Trading :::::::::::::::::::: 78
3.3.2.1 Export und Import von Dienstangeboten : : : : : 78
3.3.2.2 Verwaltung von Dienstangeboten ::::::::: 80
3.3.2.3 Dienstangebotsauswahl ::::::::::::::: 83
3.3.3 Verteilte Dienstangebotsvermittlung ::::::::::::: 85
3.3.3.1 Kooperationsformen von Tradern ::::::::: 86
3.3.3.2 Aufbau direkter Trader{Kooperationen :::::: 90
3.3.3.3 Kooperationsprotokolle ::::::::::::::: 91
3.4 Domanenubergreifender Dienstzugri ::::::::::::::::101
3.4.1 Aufgaben von Interzeption ::::::::::::::::::102
3.4.1.1 Uberwindung technischer Heterogenitatsgrenzen : 103
3.4.1.2 Uberwachung und Kontrolle administrativer Heterogenitatsgrenzen
:::::::::::::::::106
3.4.1.3 Erweiterung von Plattformkonzepten :::::::107
3.4.1.4 Kompensation fehlender Domanenkonzepte :::108
3.4.2 Entwurfsvarianten von Interzeptoren ::::::::::::108
3.4.2.1 Statische Interzeption :::::::::::::::108
3.4.2.2 Dynamische Interzeption ::::::::::::::110
3.4.3 Ubermittlung von Fremdkonzepten :::::::::::::110
3.5 Zusammenfassung :::::::::::::::::::::::::::112

INHALTSVERZEICHNIS iii
4 Koordination von Diensten 115
4.1 Dienstnutzung inverteilten Anwendungen : : : : : : : : : : : : :116
4.1.1 Ubergang zur weitestgehenden Nutzung externer Dienste : 116
4.1.2 Benotigte Beschreibungs{ und Modellierungskonzepte :::119
4.2 Beschreibung und Modellierung koordinierter Dienstnutzung :::121
4.2.1 Kooperationsanwendungen und Anwendungsvorgange :::121
4.2.2 Petri{Netze als Beschreibungsgrundlage : : : : : : : : : :122
4.2.3 Beschreibungskonzepte ::::::::::::::::::::124
4.2.3.1 Datenkonzept ::::::::::::::::::::124
4.2.3.2 Kontroll u konzept ::::::::::::::::126
4.2.3.3 Dienstorientiertes Aktionskonzept :::::::::126
4.2.3.4 Nebenlau gkeitskonzept : : : : : : : : : : : : : :128
4.2.3.5 Strukturierungskonzept : : : : : : : : : : : : : :129
4.2.3.6 Fehlerbehandlungskonzept : : : : : : : : : : : : :130
4.2.3.7 Interaktionskonzept ::::::::::::::::132
4.2.3.8 Transaktionskonzept ::::::::::::::::134
4.3 Bewertung und erganzende Bemerkungen : : : : : : : : : : : : : :136
II TRADE: Eine verteilte Systemumgebung zur Vermittlung
und Koordination von Diensten 139
5 Systemunterstutzung fur den Dienstzugang 143
5.1 Diensttypmanagement in TRADE ::::::::::::::::::144
5.1.1 Beschreibung von Diensten ::::::::::::::::::145
5.1.1.1 Ein kanonisches Diensttypmodell :::::::::147
5.1.2 Beschreibung und Verwaltung von Beziehungstypen und
{instanzen :::::::::::::::::::::::::::148
5.1.2.1 Unterstutzung von Konformitatsbeziehungen :::149
5.1.2.2 Automatisierter Aufbau von Diensttyphierarchien 152
5.1.2.3 Suche nach konformen Diensttypen : : : : : : : :153
5.1.3 Austausch und Verarbeitung von Typbeschreibungen :::154
5.1.4 Aufbau des Typmanagers :::::::::::::::::::156
5.1.4.1 Typmanagerkern ::::::::::::::::::157
5.1.4.2 Repositories :::::::::::::::::::::157
5.1.4.3 Abbildungskomponenten : : : : : : : : : : : : : :158
5.1.4.4 Graphische Benutzerschnittstelle :::::::::158
5.1.5 Bewertung und erganzende Anmerkungen : : : : : : : : : :159
5.2 Dienstvermittlung und {verwaltung durch den TRADEr ::::::160
5.2.1 Komponenten des TRADErs :::::::::::::::::160
5.2.2 Dienstangebotsverwaltung und {vermittlung : : : : : : : :161
5.2.2.1 Verwendung attributbasierter Namensdienste : :162
5.2.2.2 Das Attributmanagementsystem : : : : : : : : : :164
5.2.2.3 Ablauf einer domanenbegrenzten Dienstangebotsvermittlung
:::::::::::::::::::166
5.2.3 Aufbau von Trader{Kooperationen : : : : : : : : : : : : :167
5.2.3.1 IWT{Testszenario :::::::::::::::::169

iv INHALTSVERZEICHNIS
5.2.3.2 Link{Kon gurationsmanager :::::::::::170
5.2.3.3 Verwaltung und Nutzung von Links im TRADEr 172
5.2.4 Bewertung und erganzende Anmerkungen ::::::::::175
5.3 Domanenubergreifender Dienstzugri ::::::::::::::::180
5.3.1 Voraussetzungen fur die Interzeption ::::::::::::181
5.3.2 Entwurfsziele fur eine Interzeptor{Komponente ::::::182
5.3.3 Der Interzeptionsmechanismus ::::::::::::::::183
5.3.3.1 Prinzipielle Funktionsweise ::::::::::::183
5.3.3.2 Entwurfsvarianten :::::::::::::::::186
5.3.4 Implementationsaspekte des Interzeptors ::::::::::187
5.3.5 Bewertung und erganzende Anmerkungen ::::::::::190
6 Entwicklung und Ausfuhrung von Kooperationsanwendungen 193
6.1 TRADE{Entwicklungsumgebung ::::::::::::::::::194
6.1.1 Diensterstellung ::::::::::::::::::::::::194
6.1.2 Entwicklung von Kooperationsanwendungen mittels der
Koordinationssprache PAMELA :::::::::::::::195
6.1.2.1 Zielstellung und Entwurfsentscheidungen : : : : :196
6.1.2.2 Sprachkonzepte :::::::::::::::::::197
6.1.2.3 PAMELA{Beispielspezi kation eines verteilten
kooperativen Anwendungsvorganges : : : : : : : :200
6.1.2.4 Sichtweisen der Anwendungsprogrammierung
mit PAMELA ::::::::::::::::::::203
6.2 Ablaufkontrolle ::::::::::::::::::::::::::::206
6.2.1 Einordnung des Koordinationsmanagers in TRADE ::::206
6.2.2 Schnittstellen des Koordinationsmanagers ::::::::::208
6.2.2.1 De nitionsschnittstelle :::::::::::::::208
6.2.2.2 Administrationsschnittstelle ::::::::::::209
6.2.2.3 Ausfuhrungsschnittstelle ::::::::::::::209
6.2.3 Steuerung von Anwendungsvorgangen ::::::::::::210
6.2.3.1 Objektorientierte Umsetzung von Petri{Netzen : 211
6.2.3.2 Steuerungsalgorithmen :::::::::::::::213
6.3 Bewertung und erganzende Anmerkungen ::::::::::::::216
III Zusammenfassung und Ausblick 219
A Koordinationssprache PAMELA 227
A.1 Beschreibung der Syntax und Semantik :::::::::::::::227
A.1.1 Darstellung der Programmstruktur :::::::::::::238
A.1.2 Vollstandige Grammatik :::::::::::::::::::239
A.1.3 Reservierte Schlusselworter :::::::::::::::::241
A.2 Anwendungsbeispiel: Work ow{Unterstutzung im Hotel ::::::242
A.2.1 Graphische Benutzerschnittstellen der Hotelanwendung : :245
B Beschreibung des kanonischen Typmodells 247
C Operationale Schnittstelle des Typmanagers 259

INHALTSVERZEICHNIS v
D TRADEr{Schnittstellen 269
D.1 Trading{Schnittstelle :::::::::::::::::::::::::269
D.2 Link{Management{Schnittstelle :::::::::::::::::::279
E De nitionsschnittstelle des Koordinationsmanagers 281
E.1 Schnittstellenbeschreibung ::::::::::::::::::::::281
E.2 Aus PAMELA generierter Programmkode : : : : : : : : : : : : :285
Abbildungsverzeichnis 287
Tabellenverzeichnis 291
Literaturverzeichnis 293

Kapitel 1
Einleitung
1.1 Potentiale und Probleme verteilter Systeme
Die Nutzung weltweiter Netzwerke und der dort angebotenen Dienstleistungen
gewinnt immer mehr an Bedeutung. Schlusseltechnologie dieser Entwicklung ist
die Telekommunikation. Durch Bereitstellung leistungsfahiger Kommunikationsmechanismen
bietet sie die notwendigen technischen Voraussetzungen, Rechner
lokal oder aber auch weltweit zu einer gemeinsamen Infrastruktur zu verbinden.
Moderne Hochleistungskommunikation [Zit95] ermoglicht hierbei eine e ziente
Ubermittlung gro er Mengen an Informationen mit hohen Geschwindigkeiten
auch uber weite Distanzen hinweg. In diesem Sinne stellt die Kommunikationstechnologie
eine der elementaren Wegbereiter{Technologien (engl. enabling technologies)
fur die Scha ung e zienter weltweiter rechnergestutzter Kooperation
dar.
Aufsetzend auf einer derartigen Kommunikationsinfrastruktur konnen verschiedenartigstekooperativeAnwendungen
entwickeltwerden, die die allgemeinen Potentiale
verteilter Verarbeitungfur ihre speziellen Anwendungszweckeausnutzen.
Aktuell diskutiert werden neuartige, sogenannte Gigabitanwendungen [Zit95], die
ein Hochstma an Verzogerungsfreiheit bei der Versendung gro er Datenmengen
auch uber gro e Entfernungen erfordern. Typische Anwendungsbeispiele sind
unter anderem Videokonferenzen, der Zugri auf graphische Informationen im
" World{Wide{Web\ des Internets, " Video{on{Demand\, Virtuelle Realitat\,
"
kooperative rechnergestutzte Gruppenarbeit oder das verteilte Spielen.
Neben diesen Gigabitanwendungen existieren noch eine Vielzahl anderer verteilter
Anwendungen, die direkten Nutzen aus der angebotenen Hochleistungskommunikation
ziehen. So zeigt sich der Hauptnutzen leistungsfahiger Kommunikation
nicht nur in der Versendung gro er Datenmengen in akzeptabler Zeit.
Vielmehr tragt die Ubertragungsgeschwindigkeit auch zueiner " virtuellen Nahe\
bei, so da die raumliche Verteilung der Komponenten, die oftmals uber weite
Distanzen eines verteilten Systems erfolgt, zunehmend anBedeutung verliert.
Insbesondere fur den kommerziellen Sektor ist dieses in Zeiten des Aufbaus weltweiter
unternehmensinterner und {ubergreifender Kooperationen sowie aufgrund

2 Einleitung
zunehmender Dezentralisierung und Auslagerung (engl. outsourcing) von Funktionsbereichen
wirtschaftlich von hohem Interesse. Typische Beispiele derartiger
kooperativer Anwendungen sind die Abwicklung weltweit verteilter Buchungstransaktionen
bei Fluggesellschaften oder Banken, die verteilte Abwicklung von
zum Teil auchunternehmensubergreifenden Geschaftsprozessen oder die gemeinsame
Nutzung teurer Ressourcen (beispielsweise massiver Parallelrechner) auch
uber weite Entfernungen hinweg.
Komplexitat bei der Entwicklung verteilter Anwendungen Die Art
der genannten Anwendungsbeispiele zeigt bereits deutlich, da Anwendungen
in verteilten Systemen aufgrund der Globalisierung verteilter Verarbeitung im
zunehmenden Ma e immer komplexer werdende Aufgaben zu erfullen haben.
Die Losung der anwendungsspezi schen Problemetragt jedoch nur zum Teil zur
zunehmenden Komplexitat bei der Entwicklung dieser verteilten Anwendungen
bei. Zusatzlich sind beim Ubergang von einer zentralen zu einer dezentralen,
verteilten Verarbeitung daruber hinausgehend auch Problemstellungen bei der
Anwendungsentwicklung und {ausfuhrung zuberucksichtigen, die sich durch die
systeminharenten Eigenschaften verteilter Systeme ergeben, wie beispielsweise
die raumliche Entfernung kooperierender Anwendungskomponenten mit neuartigen
Klassen von Fehlerfallen.
Weiterhin sind insbesondere Probleme der Heterogenitat zu berucksichtigen, die
sich beider Ausfuhrungverteilter Anwendungen in realen Umgebungen ergeben.
So kann generell nicht von einer homogenen Welt verteilter Verarbeitung ausgegangen
werden, sondern es mu vielmehr in weltweitenNetzeninder Regel
von einer hochgradig heterogenen Landschaft verteilter Verarbeitungskomponenten
ausgegangen werden. Heterogenitat auf dieser technischen Ebene au ert sich
unter anderem in der Wahl der verwendeten Rechner{Hardware, Betriebssystem{
Software und Programmiersprachen sowie der Nutzung verschiedener Kommunikationsprotokolle
und Netzubertragungsmechanismen.
Weitere Problemstellungen ergeben sich, wenn zusatzlich organisationelle Gesichtspunkte
berucksichtigt werden mussen, die sich aus der Autonomie der in
verteilten Systemen beteiligten autonomen Verwaltungsdomanen ergeben und
ma geblichen Ein u auf den Entwurf und die Steuerungverteilter Anwendungen
haben.
Forderung nach Verteilungsabstraktion und O enheit Die Fulle der genannten
Problemstellungen verdeutlicht bereits die Komplexitat einer Systemunterstutzung
fur kooperative Anwendungen in heterogenen verteilten Systemen.
Dieses betri t grundsatzlich sowohl die Entwicklung verteilter Anwendungen als
auchderen Ausfuhrung. Je mehr verteilungsbedingte Aspekteberucksichtigt werden
mussen, desto gro er ist die Forderung nach adaquater Verteilungsabstraktion,
die die Probleme heterogener verteilter Verarbeitung soweit wie moglich
verbirgt. Idealvorstellung ist hierbei, das existierende verteilte System trotz der
Heterogenitatsaspekteund spezi schen Verteilungsprobleme als ein logisches, in
sich homogenes System anzusehen, das eine Konzentration der Betrachtung auf

1.1 Potentiale und Probleme verteilter Systeme 3
die fur das System spezi schen Anwendungskomponenten erlaubt. Die unterliegende
Systemtechnik soll dabei moglichst nicht sichtbar sein. Diese Forderung
nach Abstraktion wird durch das im Rahmen internationaler Standardisierung
erarbeitete ODP{Referenzmodell1 [ODP95b] inpragnanter Form beschrieben:
" Transparency: Theproperty ofmasking from applications the details and the
di erences in mechanisms used to overcome problems caused by distribution.
This is a central requirementthat arises from the need to facilitate the construction
of distributed applications. Aspects of distribution which should be masked
(totally or partially) include: heterogeneity of supportingsoftware andhardware,
location and mobility of components, (...)\.
Das ODP{Referenzmodell unterscheidet unter anderem die folgenden Arten von
Abstraktionen: 2
Zugri sabstraktion (engl. access transparency) ermoglicht die Zusammenarbeit
von Anwendungskomponenten trotz Unterschiede inden Datenreprasentationen
und den Aufrufmechanismen.
Fehlerabstraktion (engl. failure transparency) verbirgt das Auftreten von
verteilungsbedingten Fehlern, so da Anwendungen weitgehend von einer
expliziten Fehlerbehandlung befreit sind.
Ortsabstraktion (engl. location transparency) verbirgt die Lokation einer
Anwendungskomponente, so da nur deren logischer Name, nichtjedoch die
physikalische Adresse, die sich unter Umstanden andern kann, verwaltet
werden mu .
Transaktionsabstraktion (engl. transaction transparency) verbirgt die Koordinationsmechanismen,
die bei einer uber mehrere Anwendungskomponenten
durchgefuhrten Aktivitat zur Erreichung von Konsistenz notwendig
sind.
Geeignete Verteilungsabstraktionen erleichtern die Entwicklung verteilter Anwendungen
im hohen Ma e und ermoglichen so die Konzentration des Anwendungsentwicklers
auf die eigentlichen, unabhangig von den Verteilungsaspekten
zu losenden Anwendungsprobleme.
Eng verknupft mit der Forderung nach Abstraktion ist die nach der O enheit
verteilter Verarbeitung. O enheit charakterisiert die Art und Weise, in der die an
einem verteilten System beteiligten, in der Regel heterogenen Komponenten miteinander
verknupft und gegenseitig benutzt werden konnen. Ein Hauptziel von
O enheit ist die Uneingeschranktheit, mit der diese Verknupfungen prinzipiell
moglich sind. Grundvoraussetzung hierfur ist die Scha ung einer Infrastruktur,
die die Grundlage fur die verarbeitungstechnische und organisationelle Zusammenarbeit
zur Verfugung stellt. In einer derartigen Infrastruktur mussen insbe-
1 Open Distributed Processing
2 In der deutschen Fachliteratur wird der Begri Transparenz oft als direkte Ubersetzung
von transparency benutzt, im Sinne von " durchscheinend, nicht sichtbar\. In dieser Arbeit
wird synonym der hier passendere Begri der Abstraktion verwendet.

4 Einleitung
sondere die verschiedenartigen Heterogenitatsaspekteder an einem verteilten System
beteiligten Kooperationspartner berucksichtigt, adaquat behandelt und die
entsprechenden Systemkomponenten entsprechend aneinander angeglichen werden.
In Konsequenz bedeutet somit die Scha ung von O enheit gleichzeitig auch
die Festlegung gemeinsamer, vereinheitlichender Standards, auf deren Grundlage
Rechner{ und Software{Systeme inwohlde nierter Art und Weise interagieren
und kooperieren konnen.
Ein insbesondere aus der Sicht verteilter Anwendungen wichtiger Teilaspekt
von O enheit ist hierbei die Interoperabilitat zwischen den einzelnen Anwendungskomponenten,
die eine weitgehend uneingeschrankte Kooperation der einzelnen
Komponenten ermoglicht. Grundvoraussetzung hierfur ist jedoch nicht
nur die kommunikationstechnischeInteroperabilitat, wie sie beispielsweise durch
das OSI{Referenzmodell [EF86] gewahrleistet wird. Vielmehr mussen zusatzliche
Mechanismen angeboten werden, die die Grundlage fur ein gemeinsames
Verstandnis von Interaktion und Kooperation auf Anwendungsebene zur
Verfugung stellen. Diese mussen sowohl systemtechnische Aspekte von Interoperabilitat,
wie beispielsweise die zur Kooperation notwendigen Interaktionsprotokolle,
als auch semantische Aspekte behandeln, die die anwendungsspezi sche
Kompatibilitat beabsichtigter Kooperationen betre en.
Resultate aktueller Bestrebungen zur Realisierung oener verteilter Verarbeitung
zeigen sich insbesondere in der zunehmenden Verfugbarkeit sogenannter
verteilter Systemplattformen wie beispielsweise das OSF Distributed Computing
Environment (DCE) [OSF92], die OMG Common Object Request Broker Architecture
(CORBA) [OMG91, OPR96], die Advanced Network Systems Architecture
(ANSA) [Mar91] und die Telecommunications Information Networking
Architecture (TINA) [NDC95]. Sie bieten jeweils integrierte systemtechnische
Losungsansatze zur Entwicklung und Ausfuhrung verteilter Anwendungen in heterogenen
verteilten Systemen an. Sie unterscheiden sich vor allem im Umfang
der jeweils realisierten Verteilungsabstraktion, die bei der Anwendungsprogrammierung
zur Verfugung steht. O enheit verteilter Verarbeitung bezuglich der
systemtechnischen Interoperabilitat von Anwendungskomponenten ist hierbei jedoch
de{facto zur Zeit nur dann gewahrleistet, wenn sie auf die Nutzung einer
bestimmten verteilten Systemplattform beschrankt wird. Eine uneingeschrankte
plattformubergreifende Zusammenarbeit heterogener, auf verschiedenen Systemplattformen
entwickelter undablaufender Anwendungskomponenten wird zur Zeit
in der Praxis noch nicht unterstutzt. Zur Erreichung plattformubergreifender Interoperabilitat
mussen daher erganzende Mechanismen entwickelt werden, die
ein Uberwinden der Heterogenitatsgrenzen zwischen den jeweiligen verteilten
Systemplattformen ermoglichen, wobei gleichzeitig auch administrative Aspekte
mit berucksichtigt werden mussen. Die Uberwindungder Heterogenitatsprobleme
verteilter Systemplattformen bildet eine der Grundvoraussetzungen fur Kooperation
in heterogenen verteilten Systemen.

1.2 Das Paradigma der Dienstnutzung 5
1.2 Das Paradigma der Dienstnutzung
Fur die Kooperation von beliebigen Anwendungskomponenten verteilter Systeme
mussen zunachst geeignete Kooperationsprotokolle vereinbart und de -
niert werden, die einen verbindlichen Standard bilden, auf dessen Basis eine
geregelte Interaktion der Komponenten untereinander statt nden kann. Gangige,
von heutigen verteilten Systemplattformen angebotene Kooperationsmodelle
sind unter anderem das Klienten{Diensterbringer{Modell, das Erzeuger{
Verbraucher{Modell sowie das Gruppen{Modell. Das am weitesten gebrauchliche
Modell ist hierbei das Klienten{Diensterbringer{Modell (engl. client/server
model) [Svo85, NM90, EM94]. Die Grundidee dieses Modells ist, da Anwendungskomponenten,
die sogenannten Server, Dienste anbieten, die von den Klienten
oder Kunden in Anspruch genommen werden konnen. Server und Klient
sind dabei Rollen, die wahrend eines Kooperationsvorganges von den beteiligten
Anwendungskomponenten eingenommen werden. Aufsetzendauf diesem grundlegenden
Paradigmader Diensterbringung und {nutzung lassen sich nun komplexe
o ene Dienstnutzungsumgebungen [Tsc94] aufbauen, in denen beliebige Dienste
angeboten und von potentiellen Dienstnutzern in Anspruch genommen werden
konnen. Die hierbei erbrachten Dienstleistungen konnen beispielsweise von elementaren
Betriebssystemdiensten zur Speicherverwaltung, generischen verteilten
Systemdiensten zur Datei{ und Transaktionsverarbeitung bis hin zu komplexen
Anwendungsdiensten zur Durchfuhrung von Datenbankrecherchen oder Flugreservierungen
reichen. Die Art undWeise der Nutzung dieser verschiedenen Arten
von Diensten hangt dabei ma geblichvon den Intentionen und Zielstellungen der
Dienstnutzer sowie der jeweiligen Anwendungssituation ab.
Die Dienstsicht bietet dabei die grundlegende Abstraktion, die eine einheitliche
Betrachtung und Behandlung der in o enen verteilten Systemen angebotenen
Funktionalitat ermoglicht. Die Granularitat der betrachteten Dienste kanndabei
von einfachen Diensten, beispielsweise dem Anbieten von Online{Informationen
oder der Addition zweier Zahlen, bis hin zu komplexen Anwendungsdiensten,
beispielsweise von Buchungssystemen, reichen. Auch bietet die Dienstsicht ein
hohes Ma an Skalierbarkeit. So kann durch Komposition einzelner Dienste mit
einfacher Funktionalitat ein neuer Dienst gescha en werden, der durch die Kooperation
der jeweiligen Teildienste einewesentlich machtigere Funktionalitat
erbringen kann.
1.3 Vision ausschlie licher Dienstnutzung
Das Prinzip der Verteilungvon Einzeldiensten auf verschiedene Rechnerknoten in
einem globalem Kommunikationsnetzwerk und deren anschlie ende koordinierte
Nutzung imRahmen einer verteilten Gesamtanwendungla t sich inRichtung
der Entwicklung o ener Markte von Diensten [TWH90, GGL + 95, MML94a]weiterfuhren,
in denen ahnlich wie in herkommlichen Warenmarkten (hier: elektronische)
Marktmechanismen die Kooperation und Dienstnutzungsbeziehungen zwischen
Dienstanbietern und Dienstnachfragern regeln [MML96, Mer96, Zbo96].

6 Einleitung
Derartige Marktebieten die Infrastruktur und notwendige Rahmenbedingungen,
um eine Vielfalt und Vielzahl von Diensten und Dienstleistungen auf exible und
e ziente Weise anzubieten.
Vom Blickwinkel der Software{Technik aus lassen sich diese Dienste dann
auch als Bestandteile eines weltweit verteilten Systembaukastens von Diensten
[MML95d, MML95e, GML96] verstehen, mit dessen Hilfe neue verteilte Anwendungen
auf einfache und e ziente Weise durch Wiederverwendung und Neukombination
vorhandener Diensteentworfen und realisiert werden konnen. Dabei la t
die von der unterliegenden Hochleistungskommunikation bereitgestellte virtuelle
Nahe bei der spateren Ausfuhrung der aus den verteilt ablaufenden Diensten
bestehenden Anwendung kaum mehr Unterschiede zueiner nur lokal auf einem
Rechner ablaufenden Anwendung erkennen.
Eine mogliche, hieraus resultierende Idealvorstellung ist es, die Entwicklung und
Realisierung von verteilten Anwendungen weitestgehend oder sogar ausschlie -
lich unter Nutzung extern angebotener Dienste durchzufuhren. Samtliche inder
Gesamtanwendungzuerbringende Teilaufgaben und deren Verarbeitung konnen
dabei aus der Klientenanwendung inexterne Dienste ausgelagert werden. Die
Aufgabe der Klientenanwendung beschrankt sich dann im Vergleich zur heute
ublichen Programmierung nur noch auf die Steuerung und Uberwachung der
Koordination der genutzten Dienste und die Verarbeitung von Benutzerinteraktionen.
Hierdurch verandert sich fur den Anwendungsprogrammierer nicht
nur der eigentliche Anwendungsentwurf und seine Programmierung, sondern
es ergeben sich fur ihn gleichzeitig auch erweiterte Moglichkeiten der Anwendungsausfuhrung.
Entsprechend lassensichdann zur Steuerung einer derartigen
Dienstnutzungdedizierte, generische Koordinationsdienste entwickeln, welchedie
bisherigen Kontrollfunktionen fur eine Vielzahl verschiedener Klientenanwendungen
ubernehmen.
Diese Art der Anwendungsausfuhrung stellt somit eine konsequente Weiterfuhrungdes
im vorherigen Abschnitt eingefuhrten Dienstnutzungsparadigmas
dar. Dabei werden die bisherigen Aufgaben einer Klientenanwendung, die
sich durch den Ubergang zur ausschlie lichen Dienstnutzung nur noch auf
koordinative Aspekte beschranken, selbst Gegenstand einer im Dienstemarkt
angebotenen Dienstleistung. Fur die Anwendungsausfuhrung bedeutet dieses
insbesondere, da die Kontrolle einer verteilten Anwendung prinzipiell an
beliebiger Stelle im weltweiten Kommunikationsnetzwerk erbracht werden kann.
In Konsequenz hei t dieses letztendlich fur den Anwendungsentwickler bzw.
auch fur die sonstigen Endanwender, da sie selbst nicht mehr uber die fur
die Ausfuhrungskontrolle benotigten, in der Regel kostenintensiven Verarbeitungsressourcen
verfugen mussen und stattdessen irgendwo im Dienstemarkt
vorhandene Rechenleistung nutzen konnen. 3
3 Dieser Ansatz konnte auch einen Beitrag zur derzeit gefuhrten Diskussion um die Funktionalitat
eines sogenannten " Internet{PCs\ bieten. Ein Internet{PC soll hiernach generell
nur den Zugri auf die im Internet angebotenen Dienste erlauben und dadurch bedingt selbst
keine anwendungsspezi schen Berechnungen mehr durchfuhren mussen. In diesem Fall konnte
dann unter Verwirklichung ausschlie licher Dienstnutzung und der Verwendung von Koordinationsdiensten
die vom Internet{PC zur Verfugung zustellende eigene Rechenleistung auf ein

1.4 Zielstellung und Uberblick 7
An dieser Stelle wird bereits ersichtlich, da neben den Systemmechanismen zur
Unterstutzungdes Dienstzugangs undder Dienstkoordination in o enen heterogenen
verteilten Systemumgebungen weiterhin auch geeignete Ausdrucksmittel zur
Verfugungstehen mussen, mit denen die verschiedenen Aspekteder Koordination
von Diensten beschrieben werden konnen. Diese Beschreibung dient beispielsweise
den genannten Koordinationsdiensten zur Unterstutzung der Ausfuhrung und
Steuerung der verteilten Anwendung unter Nutzung der benotigten elementaren
Dienste ohneRucksicht auf deren Art der Verfugbarkeit im Netzwerk.
1.4 Zielstellung und Uberblick
Die obige Vision ausschlie licher Dienstnutzung in o enen heterogenen verteilten
Dienstemarkten bildet den Ausgangspunkt der vorliegenden Arbeit. Sie de niert
zugleich auch das hier verfolgte Ziel des Entwurfes und der Realisierung von
geeigneten Systemmechanismen, die die Umsetzung einer derartigen Vision auf
der Basis heutiger heterogener verteilter Systemplattformen ermoglichen. Hierzu
sind insbesondere folgende Teilaufgaben zu bearbeiten, die entsprechend im
Verlauf der Arbeit vertieft behandelt werden:
ModellierungundBeschreibungvon Diensten als Grundlage fur ein gemeinsames
Dienstverstandnis und die wohlde nierte Nutzung von Diensten�
Unterstutzung von Dienstnutzern beim Dienstzugang inden Phasen der
Diensttyp ndung, der Dienstvermittlung und des Dienstzugri s�
Unterstutzung von Anwendungsentwicklern beim Entwurf und der Realisierungvon
verteilten Anwendungen unter weitestgehender bzw. ausschlie -
licher Verwendung externer Dienste�
Ausfuhrung und Steuerung der entwickelten verteilten Anwendungen.
Bei allen diesen Problemfeldern spielt die Berucksichtigungder in Dienstemarkten
vorhandenen Heterogenitatsprobleme eine wichtige Rolle. Diese zeigen sich
vor allem in Form von Heterogenitatsgrenzen zwischen den an Dienstemarkten
beteiligten Verwaltungsdomanen, die einen uneingeschrankten Dienstzugang
grundsatzlich zunachst verhindern. Zur Uberwindung der Heterogenitatsgrenzen
gilt esLosungsansatze zu entwickeln, die einen geeigneten Kompromi bereitstellen,
der die Autonomie der jeweiligen Verwaltungsdomanen weitestgehend
aufrecht erhalt, aber dennoch eine sinnvolle gegenseitige Nutzung der dort angebotenen
Dienste erlaubt. Hierfur ist zum einen eine Losung der technischen Heterogenitatsprobleme
zwischen den Verwaltungsdomanen erforderlich. Zum anderen
sind weiterhin auch administrative Heterogenitatsprobleme zubehandeln.
Neben verwaltungsbedingten Regeln, mit denen beispielsweise die Sichtbarkeit
von Diensten nach au en generell eingeschrankt werden kann, zeigen sie sich vor
Minimum zur Unterstutzung der Benutzerinteraktionen beschrankt werden.

8 Einleitung
allem bei der Beschreibung von Diensten. So kann generell nicht davon ausgegangen
werden, da semantisch aquivalente Dienste anverschiedenen Orten im
Netzwerkauch auf dieselbe Art und Weise beschrieben sind, so da sich dadurch
Interoperabilitatsprobleme bei der Dienstnutzung ergeben konnen. Diese Form
administrativer Heterogenitat la t sich auch nicht durch die Bereitstellung von
Losungen technischer Interoperabilitatsprobleme losen, die nur eine notwendige,
jedoch nochkeine hinreichende Voraussetzung fur die anwendungsspezi sche
Interoperabilitat bei der Dienstnutzung darstellen.
Entsprechend untergliedert sich die weitere Arbeit in insgesamt drei Teile:
Teil I behandelt verschiedene Grundkonzepte, die zur Unterstutzung koordinierter
Dienstnutzung in o enen heterogenen verteilten Dienstemarkten
benotigt werden.
Hierzu betrachtet Kapitel 2 zunachst die Aspekteder Modellierung undBeschreibungvon
Diensten. Dort wird insbesondere das dieser Arbeit zugrundeliegende
Dienstmodell entwickelt, welches auch der in Teil II beschriebenen,
im Rahmen dieser Arbeit entwickelten Systemumgebung TRADE
(Service Trading and Coordination Environment) zugrunde liegt. Zudem
werden verschiedene Arten von Dienstbeschreibungen vorgestellt, und es
wird der in dieser Arbeit gewahlte Beschreibungsansatz motiviert.
Kapitel 3 geht anschlie endauf die Aspektedes Dienstzugangs in heterogenen
Systemumgebungen und die oben genannten technischen und administrativen
Heterogenitatsprobleme ein. Schwerpunkt der dort durchgefuhrten
Untersuchungen ist die Identi zierung und Beschreibung von Techniken,
die eine adaquate Unterstutzung des Zugangs zu Diensten in o enen
verteilten Dienstemarkten erlauben. Das Kapitel entwickelt hierzu einen
integrierten Losungsansatz, der auf Systemebene einen weitgehend uneingeschrankten
Dienstzugang auch inheterogenen verteilten Umgebungen
erlaubt. Dieser Ansatz, der auf der Kooperation von sogenannten Typmanagern,
Tradern und Interzeptoren basiert, dient als Grundlage fur die anschlie
ende exemplarische Umsetzung dieser Systemkomponenten in TRA-
DE.
Abschlie end beschreibt Kapitel 4 den in dieser Arbeit entwickelten Ansatz
zur Beschreibung koordinierter Dienstnutzung. Aufbauend auf der in
Kapitel 2 vorgeschlagenen Dienstabstraktion und den in Kapitel 3 vorgestellten
Systemtechniken wird dort das Konzept der sogenannten Kooperationsanwendungen
vorgestellt. Dieses erlaubt eine modellhafte Sicht
auf Dienstnutzung in o enen heterogenen verteilten Dienstemarkten und
beinhaltet insbesondere Ausdrucksmittel, die zur Beschreibung der koordinativen
Aspekte beider ausschlie lichen Dienstnutzung benotigt werden.
Es bildet die Grundlage fur die Koordinationssprache PAMELA (Petri net
based Activity Management Execution Language), die das abstrakte Beschreibungsmodell
in eine fur den Anwendungsprogrammierer unmittelbar
nutzbare Form umsetzt.

1.4 Zielstellung und Uberblick 9
Teil II beschreibt den Entwurf und die Realisierung einer Systemumgebung
zur koordinierten Nutzung von Diensten in o enen heterogenen verteilten
Dienstemarkten. Dieser als TRADE bezeichnete Prototyp bietet eine
integrierte Umsetzung der in Teil I identi zierten Beschreibungsansatze
und Systemmechanismen zur Unterstutzung des Dienstzugangs und der
koordinierten Dienstnutzung imRahmen von Kooperationsanwendungen.
Grundlage fur die Realisierung bilden die beiden oben genannten verteilten
und zueinander heterogenen Systemumgebungen DCE und CORBA,
welche die technische Heterogenitat in o enen verteilten Dienstemarkten
beispielhaft widergeben.
Zunachst stellt Kapitel5dazu den Entwurf und die Realisierung eines in
TRADE realisierten Typmanagers, eines Traders und eines Interzeptors
vor, die insgesamt einen weitgehend uneingeschrankten Zugang zuallen
auf den derzeit wichtigsten praktischen verteilten Systemplattformen DCE
und CORBA angebotenen Diensten ermoglichen.
Anschlie endbeschreibt Kapitel 6 die Koordinationssprache PAMELA und
einen Koordinationsmanager, mit denen zum einen die koordinierte Nutzung
von Diensten beschreibbar und zumanderen diese Beschreibung auch
unmittelbar in der TRADE{Systemumgebung ausfuhrbar ist.
Teil III gibt abschlie end eine zusammenfassende Darstellung der in dieser Arbeit
behandelten Probleme und systemtechnischen Losungsansatze.
Hierbei wird insbesondere noch einmal die eingangs erwahnte Vision ausschlie
licher Dienstnutzung aufgegri en, und eswerden die in dieser Arbeit
erzielten Ergebnisse hinsichtlich ihrer Eignung fur die Umsetzung dieser
Vision in konkrete Systemumgebungen beurteilt.
Weiterhin nden sich inden Anhangen erganzende Informationen uber verschiedene
Realisierungsaspekte der TRADE{Systemumgebung. Die wichtigste dieser
Erganzungen bildet Anhang A,der eine umfangreiche Beschreibung der syntaktischen
und semantischen Aspekte der Koordinationssprache PAMELA umfa t.
Zudem beinhalten die nachfolgenden Anhange die Schnittstellenbeschreibungen
der in TRADE entwickelten Systemkomponenten.

Teil I
Grundkonzepte zur
Unterstutzung koordinierter
Dienstnutzung in heterogenen
verteilten Dienstemarkten

Kapitel 2
Modellierung und Beschreibung
von Diensten
Die Modellierung und Beschreibung von Diensten spielt eine zentrale Rolle
bei der koordinierten Dienstnutzung in o enen verteilten Systemen. Sie bildet
die notwendige Grundlage fur die wohlde nierte Zusammenarbeit einzelner Anwendungsobjekte
inverteilten Systemen, im speziellen von Dienstnehmern und
Diensterbringern in einem o enen Dienstemarkt. Im folgenden wird zuerst auf
den Begri der Interoperabilitat genauer eingegangen und verschiedene Betrachtungsebenen
unterschieden. Darauf aufbauend wird ein objektbasiertes Dienstmodell
fur die Modellierung von Anwendungkomponenten und der von ihnen
erbrachten Dienstleistungen vorgestellt. Hierbei wird unter anderem auch der
Begri des Diensttyps gepragt, der elementare Bedeutung fur diese Arbeit, insbesondere
fur die Entwicklung von Systemtechniken zur Vermittlung und Verwaltung
von Diensten in o enen heterogenen verteilten Systemen, besitzt. Im
Anschlu wird auf verschiedene Formen von Dienstbeschreibungen eingegangen,
wobei unter anderem auch der Aspekt der Interoperabilitat wieder aufgegri en
wird. Abschlie end erfolgt eine Zusammenfassungund Bewertungder Ergebnisse
dieses Kapitels.
2.1 Interoperabilitatsebenen
Bevor eine Nutzung von Diensten in heterogenen verteilten Systemen generell
statt nden kann, mu die Interoperabilitat von Dienstnehmern und Diensterbringern
sichergestellt werden. Hierfur ist ein vorheriger Abstimmungsproze
erforderlich, der prinzipiell auf drei verschiedenen Abstraktionsebenen statt ndet:
Ebene der Dienstmodelle: Auf dieser Ebene ist abzustimmen, auf welche
Art und Weise die in der " realen\ Welt vorhandenen Dienstleistungen, von
denen im allgemeinen nur eine vage und informelle Vorstellung herrscht,
reprasentiert werden konnen, damit diese computertechnisch handhabbar

14 Modellierung und Beschreibung von Diensten
werden. Ein Beispiel hierfur ist die Modellierung der Gegenstande der realen
Welt als eine Vielzahl miteinander kooperierender Objekte, die uber
Nachrichtenaustausch miteinander kommunizieren. Mit diesen Objekten
la t sich dann beispielweise eine einheitliche Reprasentation einer menschlichen
oder maschinellen Dienstleistung erreichen, wobei von den individuellen
Details ihrer realen Erbringung abstrahiert werden kann.
Ebene der Dienstbeschreibung: Hier erfolgt die Festlegung auf konkrete
Beschreibungstechniken, mit denen die Informationen eines bestimmten
Dienstmodells in einer geeigneten sprachlichen, textuellen oder graphischen
Form dargestellt werden konnen. Ein Beispiel hierfur sind Schnittstellenbeschreibungssprachen
(engl. interface de nition languages { IDL), die eine
textuelle Darstellung der Semantik einer erbrachten Dienstleistung erlauben.
Hierbei wird von den Aspekten ihrer konkreten Realisierung, beispielsweise
in einer bestimmten Programmiersprache, abstrahiert, weshalb
derartige Darstellungsformen auch als abstrakte Syntaxen [Sch93a] bezeichnet
werden.
Ebene der Dienstreprasentation: Auf dieser Ebene ist das Format zubestimmen,
mit denen die sprachlich, textuell oder graphisch abgefa ten
Dienstbeschreibungen zwischen Dienstnutzer und Diensterbringer ausgetauschtwerden
sollen. Derartige systemtechnischeTransferformatewerden
auch alskonkrete Syntaxen [Sch93a] bezeichnet, da sie von den konkret
vorhandenen Implementierungsmitteln einer Ablaufumgebungabhangen. In
dieser Arbeit wird hierfur der Begri der Dienstreprasentation verwendet
(siehe auch [GGL + 95]). So kann beispielsweise eine textuelle IDL{
Beschreibung im einfachsten Fall als einfache Zeichenkette reprasentiert
werden, die zwischen Dienstnehmer und Diensterbringer ausgetauschtwird.
Denkbar ist jedoch auch dieNutzung komplexer Datenstrukturen, auf die
die einzelnen Bestandteile einer IDL abgebildet werden, wodurch sichbeispielsweise
| ahnlich zurTransfersyntax in ASN.1 [ISO87] |eine Selbstbeschreibung
der Dienstreprasentation erreichen la t.
Damit die Interoperabilitat zwischen Dienstnehmer und Diensterbringer sichergestellt
werden kann, ist auf allen drei Ebenen eine Ubereinstimmung zu erzielen,
damit die auf den einzelnen Ebenen vorhandenen Modelle, Beschreibungen
und Reprasentationen einheitlich verstanden werden. Die drei Ebenen werden im
folgenden genauer beschrieben, wobei die Aspekteder Dienstmodelle und Dienstbeschreibungen
in den darau olgenden Abschnitten weiter vertieft werden.
2.1.1 Dienstmodellebene
Elementare Grundlage fur Dienstnutzung in o enen verteilten Systemen ist ein
gemeinsames und einheitliches Verstandnis des Begri es Dienst bzw. Dienstleistung
sowohl bei den Dienstnutzern als auch beiden Diensterbringern. Hierfur
ist die De nition eines Dienstmodells notwendig, mit denen Dienste der " realen\

2.1 Interoperabilitatsebenen 15
Welt einheitlich beschrieben werden konnen. Dabei sollten bei der Modellbildung,
d.h. dem Proze der Abbildung von realen Dienstleistungen in eine datenverarbeitungstechnischhandhabbare
Reprasentation, moglichst alle wesentlichen
Merkmale eines Dienstes beschrieben werden konnen. Modellbildung bzw.Abstraktion
bedeutet hierbei auch immer eine einschrankende Sichtweise auf das
reale System, um bestimmte gemeinsame Eigenschaften der dort betrachteten
Gegenstandeherausarbeiten zu konnen. Kontextunabhangigkeit bezeichnet dabei
die Abstraktion von Abhangigkeiten, die sich durch lokale Randbedingungen ergeben.
Zum Beispiel ist es fur die Betrachtung der Eigenschaften eines Dienstes
unwichtig, in welcher Programmiersprachediespatere Implementation eines konkreten
Diensterbringers durchgefuhrt wird.
Mit einem Dienstmodell werden gleichzeitig auch verbindliche Absprachen uber
Verhaltensaspekte getro en, die unter anderem die Interaktion von Dienstnehmer
und Diensterbringer regeln. Eine derartige Verhaltensregel ist beispielsweise
bei der im folgenden Abschnitt beschriebenen objektbasierten Dienstmodellierung
de niert, die festlegt, da auf den Zustandeines Objektes bzw. Diensterbringers
nur uber dessen extern angebotene Schnittstelle zugegri en werden kann. Wie
diese Schnittstelle selbst modelliert wird, beispielsweise in Form von Operationen
oder Datenstromen, ist ein weiterer Bestandteil des Dienstmodells. Hierbei
ist dann auch zuklaren, was unter einem Dienst genau zuverstehen ist. So wird
beispielsweise bei der Darstellung des RPC{orientierten Client/Server{Modells
in [Svo85] ein Dienst informell verstanden als " ... a software entity running on
one or more machines\, wobei diese De nition o en la t, ob ein Dienst mit einer
Prozedur oder mit der gesamten Menge der vom Server realisierten Prozeduren
gleichzusetzen ist.
Dienstmodelle stellen somit eine abstrakte Sichtweise auf Dienste inverteilten
Systemen zur Verfugung. Interoperabilitat auf Dienstmodellebene wird hierbei
entweder durch dieWahl eines gemeinsamen Dienstmodells oder durch eineindeutige
Abbildung zwischen verschiedenen Dienstmodellen erreicht. Im ersten
Fall mussen dann gegebenfalls die lokal verwendeten Dienstmodelle in das gemeinsam
verwendete Dienstmodell abgebildet werden.
2.1.2 Dienstbeschreibungsebene
Der Proze der Modellbildung auf der Dienstmodellebene ist eng verknupft mit
einer abstrakten Darstellungsform, der Dienstbeschreibung, mit deren Hilfe die
Informationen des Dienstmodells dargestellt werden. Sie sollte soausdrucksstark
sein, da die modellierten Eigenschaften der Dienste moglichst weitgehend darstellbar
sind. Dieses betri t sowohl die Beschreibung struktureller Aspekte, wie
beispielsweise der Operationssignaturen der Schnittstelle eines Objektes, als auch
semantischer Eigenschaften, die das Verhalten des Objektes an seiner Schnittstelle
festlegen. Die Auspragung einer bestimmten Syntax fur eine Dienstbeschreibung,
beispielsweise in textueller oder graphischer Form, kann dabei je nach
Anwendungsbereich gewahlt werden. Verteilte Systemplattformen, wie beispielsweise
CORBA oder DCE, bieten zur Beschreibung von Diensten in der Regel so-

16 Modellierung und Beschreibung von Diensten
genannte Schnittstellenbeschreibungssprachen (engl. interface de nition language
{ IDL) an, mit deren Hilfe die an einer Schnittstelle angebotenen Operationen
eines Objektes beschrieben werden.
Ein generelles Problem beim Ubergang von der Dienst{ zur Beschreibungsebene
ist der mogliche Verlust an Informationen. Ursache hierfur ist, da einige
Aspekte des Dienstmodells, insbesondere semantischeauf der Ebene der Dienstbeschreibungen
nicht reprasentierbar sind. Die genannten Schnittstellenbeschreibungssprachen
reichen in der Regel nichtaus, um beispielsweise die " Bedeutung\
eines Druckdienstes auszudrucken. Hierdurch bedingt kann es unter Umstanden
auch dazu kommen, da semantisch verschiedene Dienste auf dieselbe Art und
Weise beschrieben werden, da wesentliche Unterscheidungsmerkmale nicht dargestellt
werden konnen. Ein hierfur oft zitiertes Beispiel sind diebeiden Dienste
Stack und Queue, welche trotz syntaktischer Kompatibilitat der Schnittstellen,
beispielsweise mit den Operationen put und get, ein unterschiedliches Verhalten
aufweisen [RTL + 91]. Generell fuhrt der Informationsverlust dazu, da eine
Eineindeutigkeit zwischen Diensten im Dienstmodell und deren Beschreibung
nichtmehr gewahrleistet ist. Interoperabilitat auf Beschreibungsebenela t somit
nicht automatischauch auf die Interoperabilitat der hiermit beschriebenen Dienste
auf Dienstmodellebene schlie en. Erst durch Erweiterungen hinsichtlich der
Beschreibung auch von semantischen Aspekten von Diensten lassen sich derartige
unbeabsichtigten syntaktischen Kompatibilitatsbeziehungen zwischen semantisch
verschiedenen Diensten vermeiden. Abschnitt 2.4geht hierauf im Rahmen
der Darstellung verschiedener Ansatze von Dienstbeschreibungen genauer ein.
Weitere Probleme ergeben sich, wenn Dienstbeschreibungen auf der Grundlage
verschiedenartiger Diensttypmodelle de niert sind, die sich beispielsweise in
den Datentypen zur Darstellung der Ein{ und Ausgabeparameter der Operationen
unterscheiden. Diese Problematik tritt inder Regel dann auf, wenn Dienste
auf der Basis verschiedener verteilter Systemplattformen entwickelt und inder
jeweilgen Dienstbeschreibungssprache spezi ziert werden. Hier mu dann entweder
eine Einigung auf ein gemeinsames einheitliches Diensttypmodell erfolgen,
in das die jeweiligen lokalen Diensttypmodelle abgebildet werden, oder es wird
eine eineindeutige Abbildung zwischen den verschiedenartigen Diensttypmodellen
de niert. Eine derartige gegenseitige Abbildung zweier Dienstbeschreibungen
ist beispielsweise in [CM95] anhandder erweiterten Schnittstellenbeschreibungssprachen
von DCE und CORBA dargestellt, die als Grundlage fur eine plattformubergreifende
Dienstnutzung innerhalb der auf diesen beiden Plattformen
entwickelten TRADE{Systemarchitektur dient. Abschnitt 5.1.1.1 geht auf einige
Teilaspekte dieser Abbildung genauer ein.
2.1.3 Dienstreprasentationsebene
Um Dienstbeschreibungen in o enen heterogenen verteilten Systemen austauschen
zu konnen, ist zwischen den beteiligten Objekten ein gemeinsames Transferformat
zu de nieren, mit dem die in einer abstrakten Dienstbeschreibung
vorhandenen Informationen auf eindeutige Art und Weise ablegbar sind. Die Ab-

2.1 Interoperabilitatsebenen 17
bildung der Dienstbeschreibungineinederartige Dienstreprasentation [GGL + 95]
wird durch Kodierregeln gesteuert, die jeweils spezi sch fur das gewahlte Format
de niert sind. Dekodierregeln dienen umgekehrt dazu, samtliche Informationen
wieder aus der Dienstreprasentation zu entnehmen und ineineentsprechende
Dienstbeschreibung abzubilden. Die Dienstreprasentation versteht sich
somit als ein standardisierter Datencontainer, auf den mit Hilfe von Umwandlungsregeln
zugegri en werden kann. Prinzipiell kann durch verschiedenartige
Kodierregeln auch eineAbbildung auf mehrere verschiedene Dienstreprasentationen
durchgefuhrt werden. Dieses ist zum Beispiel der Fall bei der Umwandlung
der standardisierten Datenbeschreibungssprache ASN.1 [ISO87, Ros92] in
eine betriebssystemunabhangige Datenreprasentation. Hierfur konnen prinzipiell
verschiedene Abbildungen in Form von Encoding Rules de niert werden, wobei
zur Zeit jedoch nur eine Abbildung durch die sogenannten Basic Encoding Rules
(BER) standardisiert ist.
Abbildung 2.1 verdeutlicht das Grundprinzip der Umwandlung einer Dienstbeschreibung
ineine Dienstreprasentation und umgekehrt.
struct { char* interface_name;
char* operation_name; }
...
"Test" "operation_A"
"interface Test { void operation_A(); };"
Dienstrepräsentation A
Dienstbeschreibung
interface Test {
void operation_A ();
};
Kodierregeln A Kodierregeln B
interface Test {
void operation_A ();
};
char* interface_description;
Dienstrepräsentation B
Dekodierregeln A Dekodierregeln B
Dienstbeschreibung
Abbildung 2.1: Wechselseitige Umwandlung von Dienstbeschreibung und
Dienstreprasentation
Die Abbildung zeigt die Umwandlung einer einfachen CORBA{Schnittstellenbeschreibung
ineine Dienstreprasentation, deren Format abstrakt durch eine
Datenstruktur in der ProgrammierspracheCdargestellt ist. Die Dienstreprasentation
B stellt einevergleichsweise einfache Moglichkeit der Kodierung einer textuellen
Dienstbeschreibung inForm einer Zeichenkette dar. Im Vergleich hierzu
ist bei der Dienstreprasentation A bereits ein Interpretationsvorgang vorausgegangen,
bei dem die strukturellen Bestandteile der Dienstbeschreibung identi
ziert wurden. Diese Aufgabe der syntaktischen Analyse ubernimmt inder

18 Modellierung und Beschreibung von Diensten
Regel ein IDL{Parser, der die in der Schnittstellenbeschreibung enthaltenen Informationen
nach bestimmten Auswertungskriterien untergliedert. Anschlie end
erfolgt auf dieser Grundlage die Umwandlung in die Dienstreprasentation mit
Hilfe von Generierungsfunktionen, die eine Realisierung der Kodierregeln A darstellen.
Nachdem die Dienstreprasentation dem Empfanger ubergeben wurde,
kann dieser mit Hilfe entsprechender Dekodierregeln die dort enthaltenen Informationen
entnehmen, so da letztendlich die originare Dienstbeschreibungrekonstruiert
werden kann. Alternativ konnen auch andere Dekodierregeln verwendet
werden, die eine Abbildung in prinzipiell verschiedenartigste Reprasentationsformen
ermoglichen.
Interoperabilitat auf der Dienstreprasentationsebene setzt somit sowohl die Nutzung
einer gemeinsamen Dienstreprasentation als auch die Wahl wohlde nierter
Kodierungsregeln voraus, die eine eineindeutige Abbildung zwischen Dienstbeschreibung
und Dienstreprasentation gewahrleisten.
2.2 Dienstmodelle
Um die in heterogenen verteilten Systemen vorhandene Funktionalitat von Anwendungskomponenten
innerhalbvon verteilten Anwendungen nutzen zu konnen,
ist eine Abstraktion erforderlich, die Eigenschaften, Verhaltensweisen und erbrachte
Leistungen einer Anwendungskomponente in geeigneter Weise formal
erfa t. Diese Abstraktion wird durch einDienstmodell bereitgestellt, das unter
anderem den Begri des Dienstes in eindeutiger Art und Weise festlegt. Ein im
Rahmen verteilter SystemezunehmendanBedeutung gewinnender Ansatz ist die
objektbasierte Dienstmodellierung, die auch inder vorliegenden Arbeit verfolgt
wird. Die weitere Darstellung basiert unter anderem auf den im Rahmen des
ODP{Referenzmodells [ODP95c, Lin95, NS95, PSW96] und der ODP{Trading{
Funktion [ODP95a] entwickelten Konzepten. Eine Zusammenfassung dieses Objektmodells,
das im wesentlichen auf den Begri en von Objekt, Dienst, Schnittstelle
und Operation beruht, ndet sich auch in [Jon94].
2.2.1 Der Objektbegri in verteilten Systemen
Zentraler Begri des objektbasierten Dienstmodells ist das Objekt. Sowirdein
Objekt innerhalb des ODP{Referenzmodells [ODP95c] als eine elementare Einheit
verstanden, die eine Modularisierung und Strukturierung der im verteilten
System vorhandenen Komponenten ermoglicht. Dabei ist es gekennzeichnet
durch seine Identitat, die es unterscheidbar zu anderen Objekten macht, sowie
durch die Prinzipien von Kapselung, Abstraktion und Verhalten:
Kapselung (engl. encapsulation) beschreibt die Eigenschaft eines Objektes,
den Zugri auf seine internen Daten nur uber dessen wohlde nierte
Schnittstellen zuzulassen. So konnen keine Anderungen an den Daten
durch Seitene ekte erzeugt werden, die durch unkontrollierten, moglicherweise
unzulassigen Zugri anderer Objekte hervorgerufen werden konnen.

2.2 Dienstmodelle 19
Damit wird gleichzeitig auch eine Abstraktionsbarriere erzwungen, die die
interneVerarbeitungund Verwaltungder Daten nachau en hin vollstandig
verbirgt. Dieses sogenannte information hiding hat den Vorteil, da von
objektspezi schen Internas bei der Betrachtungeines Objektes abstrahiert
werden kann. So kann die einer Schnittstelle hinterliegende Funktionalitat
prinzipiell auch auf verschiedene Art und Weise durch ein Objekt implementiert
oder wahrend der Lebenszeit eines Objektes geandert werden,
ohne da dieses nach au en hin sichtbar wird. Da Objekte inverteilten
Systemen oftmals eine Vielzahl verschiedener Aufgaben und Funktionen
ubernehmen, konnen Objekte prinzipiell auch mehrere Schnittstellen besitzen.
Dies ermoglicht einefunktionale Separation der Gesamtfunktionalitat
eines Objektes, die anderen Objekten den Zugri auf gewunschteTeilfunktionalitaten
erleichtert. Ein Beispiel ist ein Objekt, welches neben seiner
individuellen Schnittstelle gleichzeitig auch einestandardisierte Systemverwaltungsschnittstelle
realisiert, uber die beispielsweise die Auslastung
erfragt werden kann.
Das Verhalten (engl. behaviour) eines Objektes hangt eng mit dessen Zustand
zusammen, welcher durch die internen Daten des Objektes bestimmt
wird. Das Verhalten ist hierbei de niert durch dieMenge aller potentiellen
Aktionen, an denen das Objekt beteiligt werden kann. Nach au en
hin au ert sich Verhalten durch entsprechende Reaktionen, die gleichzeitig
auchdieAnderung seines internen Zustandes widerspiegeln unddas weitere
Verhalten des Objektes bestimmen. Ein Objekt hei t verhaltenskompatibel
zu einem anderen, wenn es dieses ersetzen kann, ohne da in der au eren
Umgebung diese Ersetzung bemerkt wird.
Ein verteiltes System wird somit als ein Objektsystem [Jon94] verstanden, das
sich aus einer Ansammlung von einzelnen Objekten zusammensetzt. Abbildung
2.2 zeigt den Aufbau eines Objektes, wobei sich die dortige Schnittstelle aus
einer Menge einzelner Operationen (Op) zusammensetzt, die eine von mehreren
Moglichkeiten zur Realisierung einer Schnittstelle darstellen.
Objekt
Op
Interner Zustand
(Daten)
Schnittstelle
Op ... Op
Abbildung 2.2:Aufbau eines Objektes
Ausschlaggebende Kriterien fur die Wahl eines objektbasierten Ansatzes zur
Modellierung von Anwendungskomponenten sind vor allem deren Abstraktionsmoglichkeiten,
dieeine Objektsichtweise bietet (siehe zumVergleich auch
[ODP95b] und [PSW96]):

20 Modellierung und Beschreibung von Diensten
Durch eineabstrakte Objektsicht konnen alle Dienste inverteilten Systemen
unabhangig von kontextspezi schen Gegebenheiten in einheitlicher
Art und Weise betrachtet werden. Abstraktion bedeutet dabei unter anderem,
da Aspekte der Heterogenitat, die sich beispielsweise in verschiedenen
Dienstimplementierungen durch Wahl unterschiedlicher Programmiersprachen
oder verschiedener Kommunikationsmechanismen au ern konnen,
nicht berucksichtigt werden mussen. Erst hierdurch wirdesmoglich, eine
Konzentration auf die wesentlichen gemeinsamen Charakteristika von
Diensten zu erreichen, die unabhangig von deren interner Struktur sind.
Die Objektabstraktion ermoglicht eine strenge Separation der Objekte untereinander.
Dadurch bedingt konnen sie verandert, erweitert oder durch
andere Objekte ersetzt werden, ohne da eine Anderung anihrerUmgebung
vorgenommen werden mu . Dabei ist jedoch zubeachten, da die
von ihnen erbrachten Dienste auch weiterhin den Erwartungen der Umgebung
entsprechen, d.h. Objekte mussen ruckwartskompatibel sein. Diese
Fahigkeit zur Fortentwicklung und Erweiterung ist insbesondere in gro en
heterogenen verteilten Umgebungen von Wichtigkeit, die aufgrund ihrer
Gegebenheiten einem standigen Wandlungsproze unterworfen sind.
Mit Objekten la t sich einhoher Grad an Modularisierung des Gesamtsystems
erreichen, die eine Wiederverwendungvon Modulen und deren Komposition
zu neuen, in der Regel komplexeren Modulen unterstutzt. Diese
Eigenschaft ist besonders fur eine exible und e ziente Anwendungs{ und
Systementwicklung von Bedeutung.
Ahnliche Argumente fur den Einsatz objektbasierter bzw. objektorientierter
Technologien nden sich auch bei anderen Autoren, bespielsweise in [ND95], die
Objektorientierung vor allem als Organisationsprinzip und Paradigma der Wiederverwendung
verstehen. Das dort erklarte Ziel ist, eine komponentenbasierte
Anwendungsentwicklung zuunterstutzen, deren Hauptmerkmal in der Komposition
bestehender Objekte zuneuen Anwendungen besteht.
In Hinblick auf das in dieser Arbeit verfolgte Ziel, die koordinierte Nutzung von
Diensten im Rahmen verteilter Anwendungen zu unterstutzen, erscheint der Objektansatz
mit seinen oben genannten Vorteilen deshalb als besonders geeignet,
Anwendungskomponenten mit ihren erbrachten Dienstleistungen in ihren fur den
Aspekt der Dienstnutzung wesentlichen Eigenschaften adaquat zu beschreiben.
2.2.2 Der Dienstbegri
Wie schon oben dargestellt sind ein wesentliches Merkmal eines Objektes dessen
Schnittstellen, die die einzige Moglichkeit zum Zugri auf die im Objekt
abgekapselten Daten darstellen. In Anlehnung an die im Rahmen der internationalen
Standardisierung einer Dienstvermittlungskomponente, den ODP{Trader
[ODP95a], wird die an einer Schnittstelle angebotene Funktionalitat als ein
Dienst bezeichnet. Entsprechend wirddas den Dienst bereitstellende Objekt
Diensterbringer und der Nutzer eines Dienstes Dienstnehmer oder Dienstnutzer

2.2 Dienstmodelle 21
genannt. Da ein Objekt prinzipiell mehrere Schnittstellen besitzen kann, kann es
somit auch mehrere Dienste gleichzeitig anbieten. Ein Dienst kennzeichnet eine
bestimmte, von einem Diensterbringer zur Verfugunggestellte Dienstleistung, die
von Dienstnutzern fur ihre jeweiligen Ziele verwendet werden konnen. In [Mah95]
hei t es hierzu pragnant: " A service establishes an agreed relationship between
partners in two distinguished roles, a service provider and a service user. A service
is theresult generated by processes attheinterface between theprovider and
the userandby processes internal to the provider. A service is meant toproduce
bene t of a de nite type to the service user, and tomeet the users need.\ Seinen
Ursprung besitzt der hier gewahlte Dienstbegri im Client/Server{Modell
[Svo85, NM90], welches eine grundlegende Kooperationsformeines Klienten und
eines Servers beschreibt (Abbildung 2.3).
blockiert
Klient
Dienstaufruf
Ergebnisrückgabe
wartend
wartend
Server
Abbildung 2.3: Grundlegendes Client/Server{Modell
Klient und Server bezeichnen dabei die im Verlaufe einer Interaktion von den
Beteiligten eingenommenen Rollen, d.h. die eines Anfragenden (der Klient bzw.
Dienstnehmer) und eines Antwortenden (der Server bzw. Diensterbringer). Diese
Rollen konnen wahrendder Laufzeit auch gewechseltwerden. Bei der Interaktion
von Klient und Server wird hierbei von einem synchronen Ansatz ausgegangen,
bei dem der Klient einen Dienstaufruf initiiert und solange im blockiertem Zustand
wartet, bis das Eintre en der Antwort vom Server erfolgt.
Wie die eigentliche Realisierung des an einer Schnittstelle angebotenen Dienstes
letztendlich durch das Objekt erfolgt, ist nicht mehr Bestandteil des hier dargestellten
Dienstmodells. Durch diese Sichtweise la t sich die oben genannte Separation
von Objekten untereinander und eine Konzentration auf die Betrachtung
der au eren Eigenschaften und des Verhaltens von Objekten erreichen, ohne auf
kontextabhangige Implementierungsdetails eingehen zu mussen. Diese Abstraktion
ist insbesondere in heterogenen verteilten Systemen von Wichtigkeit, da
dort Objekte prinzipiell auf verschiedenste Art und Weise implementiert sein
konnen. Hier ergibt sich auch der wesentliche Unterschied dieses Dienstmodells
zu anderen Ansatzen, die zusatzlich noch die Implementation von Objekten betrachten.
Aus diesem Grund wird in Anlehnung an [CC91] und [Weg87] das obige
Dienstmodell auch alsobjektbasiert bezeichnet. In Abgrenzung hierzu werden

22 Modellierung und Beschreibung von Diensten
Systeme bzw. Modelle als klassenbasiert bezeichnet, wenn sie zusatzlich zuden
oben genannten Objekteigenschaften das Implementationskonzept der Klassenbildung
unterstutzen. Wird au erdem noch die Vererbung von Implementationskode
berucksichtigt, wird von objektorientierten Modellen gesprochen. Beispiele
fur objektbasierte Systemesindunter anderem die ProgrammierspracheModula{
2 [Wir82], deren Modulkonzept ebenfalls eine Trennung von Modulschnittstelle
und Modulimplementation vornimmt. Im Bereich verteilter Systemplattformen
sind hier unter anderem CORBA [OMG91] und ANSA [Cam91] zuerwahnen.
Weitere Beispiele nden sich in [CC91], wo verschiedene Aspekte objektbasierter
Programmsysteme untersucht werden. Beispiele fur objektorientierte Systeme
sindunter anderem die Programmiersprachen C++ [Str93] und Smalltalk
[GR83].
2.2.3 Modellierung von Schnittstellen
Prinzipiell existieren verschiedene Ansatze fur die Modellierung einer Schnittstelle,
die sich im Grad der angebotenen Abstraktion fur den Dienstnehmer unterscheiden.
Nach [ODP95c] konnen drei verschiedene Formen gewahlt werden:
Operationen (engl. operations) konnen ahnlich wie Prozeduren in prozedurorientierten
Sprachen, beispielsweise Modula [Wir82], an der Schnittstelle
aufgerufen werden.
Strome (engl. ows) sind Abstraktionen von Daten ussen, d.h. zusammenhangende
Abfolgen von Daten.
Datenstrome eignen sich insbesondere zur Unterstutzung der Kooperation
zwischen einem Erzeuger undeinem Verbraucher (engl. producer/consumer
model). Sie konnen beispielsweise dazu benutzt werden, um den Datenu
von Audio{ oder Videoinformationen in Multimedia{Anwendungen zu
modellieren. Ein Datenstrom ist durch seinen Namen und seinen Typ charakterisiert,
der die Art und das Format der auszutauschenden Daten beschreibt.
Signale (engl. signals) beschreiben die elementarste Form von Interaktion
uber atomare Aktionen, die zwischen einem initiierenden und einem reagierenden
Objekt ausgetauscht werden.
Anwendung nden Signale vor allem in ereignisbasierten Systemen, wo ein
bestimmtes Ereignis eine wohlde nierte Aktion bei einem anderen Objekt
auslost [Glo89].
Operationen und Strome konnen auf entsprechende Folgen von Signalen
abgebildet werden. Zum Beispiel la t sich eine Operation in Analogie zum
ISO/OSI{Referenzmodell [EF86] durch eineKombination der folgenden
Signale bzw. Primitiven darstellen: REQUEST, INDICATE, RESPONSE,
CONFIRM.
Die operationale Sichtweise eignet sich hierbei insbesondere zur Darstellung der
Interaktionen eines Dienstnehmers mit einem Diensterbringer, da sie eine einfa-

2.3 Typisierung von Schnittstellen und Diensten 23
che Ubertragungder aus dem Programmiersprachenbereichwohlbekannten Konzepte
von Prozeduren und Funktionen auch inverteilte Umgebungen ermoglicht.
Operationen sind hierbei eine verallgemeinerteForm des mit dem Client/Server{
Modell assoziierten Remote Procedure Calls (RPC) [Nel81, BN84, Sch92b]. Die
dem RPC unterliegende Idee ist dabei, die Abstraktion des lokalen Prozeduraufrufs
auch beieiner Verteilung der Prozeduren auf andere Rechnerknoten
aufrecht zu erhalten, d.h. der Dienstnutzer soll keinen Unterschied zwischen einem
lokalen und einem entfernten Prozeduraufruf bemerken. Die Durchfuhrung
einer Operation bzw. eines entfernten Prozeduraufrufs setzt sich inder Regel
aus drei elementaren Teilaktivitaten zusammen, die den Ablauf einer Interaktion
von Klient und Diensterbringer regeln:
1. Aufruf der Operation durch den Klienten,
2. Bearbeitung der mit der Operation verbundenen Aufgabe und
3. Beendigung,diesichentweder in der Ruckgabe von geforderten Resultaten
oder von Fehlermitteilungen beim Fehlschlagen der Bearbeitung au ert.
Die Beendigung ist jedoch eineoptionale Forderung und hangt grundsatzlich
von der Art des erbrachten Dienstes ab. Zum Beispiel ist bei einfachen
Empfangsdiensten, an die Klienten Benachrichtigungen schicken konnen,
eine Ruckbestatigung oftmals nicht erforderlich.
Wie auch schon in der Abbildung 2.3verdeutlicht worden ist, wird dabei von
einem sychronen Ablauf ausgegangen, bei dem der Dienstnehmer bis zum Erhalt
der Operationsresultate blockiert.
2.3 Typisierung von Schnittstellen und Diensten
Nachdem im vorherigen Abschnitt das dieser Arbeit unterliegende Verstandnis
des Dienstbegri s dargestellt worden ist, stellt sich die Frage nach Formalismen,
die eine abstrakte Darstellung bzw. Beschreibung von Diensten erlauben,
auf deren Grundlage Verfahren fur die Klassi kation und Vergleichbarkeit von
Diensten in o enen verteilten Systemen entwickelt werden konnen. Ein aus dem
Bereich der Programmiersprachen bekanntes und weitverbreitetes Konzept ist
das der Typisierung [CW85, Car89]. Ein Ziel von Typisierung ist unter anderem
die De nition von Bedingungen (engl. constraints), die die Interaktion von Objekten
untereinander festlegen. Im Originaltext hei t es dazu [CW85]: " Typed
versions of set theory, just like typed programming languages, impose constraints
on object interaction that prevent objects (in this case sets) from inconsistent
interaction with other objects.\ Bezogen auf Objekte ino enen verteilten Systemen
dienen Typen dazu, die von den Objekten angebotenen Dienste derartig zu
formalisieren, da eine unkontrollierte und somit eventuell inkonsistente Dienstnutzung
von Seiten der Dienstnehmer ausgeschlossen werden kann.
Ein Typ wird in diesem Zusammenhang oft auch alsPradikat [ODP95c] verstanden,
mit dessen Hilfe Aussagen daruber gemacht werden konnen, ob ein

24 Modellierung und Beschreibung von Diensten
Objekt bestimmte Eigenschaften erfullt oder nicht. Dabei sind insbesondere die
Schnittstellen eines Diensterbringers mit den dort vorhandenen Operationen zu
spezi zieren, die den Dienstnehmern zum Zugri auf die Dienste zur Verfugung
gestellt werden. Diese Forderung nach moglichst weitgehender Typisierung der
Schnittstellen von Objekten wird deswegen auch als strenge Typisierung bezeichnet
[CW85]. Sie bildet die Grundlage fur die Sicherstellung der Typsicherheit bei
der Interaktion zwischen zwei Objekten und stellt somit eine wichtige Grundvoraussetzungfur
die Interoperabilitat von Dienstnehmer und Diensterbringer in
o enen heterogenen verteilten Systemen dar.
2.3.1 Schnittstellen{ und Diensttypen
Zusatzlich zuden oben genannten grundlegenden Arbeiten zur Typisierung bilden
eine weitere wichtige Grundlage diejenigen Arbeiten, die im Rahmen der
internationalen Standardisierung des ODP{Referenzmodells [ODP95c, PSW96]
und der ODP{Trading{Funktion [ODP95a] durchgefuhrt worden sind. Das dort
de nierte Konzept der Schnittstellentypen bildet die formale Grundlage fur die
Typisierungder Schnittstellen von Objekten. EineausfuhrlicheDarstellung ndet
sich imdritten Teil des ODP{Referenzmodells [ODP95c], bei der jedoch imspeziellen
nur operationale Schnittstellen betrachtet werden. Aufbauend auf den in
[CW85] und [AC91] entwickelten typtheoretischen Ansatzen erfolgt dort gleichzeitig
auch die formale De nition einer Subtypbeziehung zwischen Schnittstellentypen,
die die Kompatibilitat von Schnittstellentypen de niert. Eine auf diesen
beiden Arbeiten aufsetzende, ausfuhrlichere Darstellung der formalen Semantik
von Schnittstellentypen und deren Subtypbeziehung ist in [NS95] vorgenommen
worden. Dort wird zusatzlich zuden bereits im ODP{Referenzmodell [ODP95c]
dargestellten Subtypregeln und Semantikde nitionen ein Algorithmus zur Uberprufung
von Schnittstellentypen (engl. interface type checking) vorgestellt und
seine Korrektheit und Vollstandigkeit bewiesen.
Ein Schnittstellentyp wird in Anlehnung an die oben erwahnten Arbeiten im
folgenden als ein Pradikat verstanden, das eine bestimmte Klasse von operationalen
Schnittstellen kennzeichnet. Ein Schnittstellentyp setzt sichdabei aus einer
Menge von Operationstypen zusammen, die die an einer Schnittstelle angebotenen
Operationen kennzeichnen.IndiesemFall ist die Schnittstelle eines konkreten
Objektes von einem bestimmten Schnittstellentyp, wenn sie das Pradikaterfullt,
die im Schnittstellentyp festgelegten Operationen anzubieten.
Eine Erweiterung des Schnittstellentypkonzeptes sind sogenannte Diensttypen
[ODP95a]. Ein Diensttyp besteht dabei zum einen aus einem Schnittstellentyp
undaus zusatzlichen Dienstattributtypen, die die Beschreibungvon Eigenschaften
eines Dienstes ermoglichen. Diensttypen bzw. Dienstattributtypen spielen insbesondere
bei der Vermittlung von Diensten eine wichtige Rolle, bei der konkrete
Objektinstanzen eines bestimmten Diensttyps aufgrund ihrer jeweiligen aktuellen
Eigenschaften unterschieden werden mussen. Auf den Aspekt der Dienstvermittlung
und die dortige Rolle von Diensttypen wird in Kapitel3nochausfuhrlich
eingegangen. Erganzende Darstellungen zum Diensttypkonzept nden sich au-

2.3 Typisierung von Schnittstellen und Diensten 25
erdem in [Jon94], [CM95] und [IBR93].
Zusammenfassend werden in dieser Arbeit funf verschiedene Arten von Typen
unterschieden:
Datentypen
{ einfache Datentypen (z.B. ganze Zahlen oder einzelne alphanumerische
Zeichen)
{ zusammengesetzte Datentypen, die Aggregate aus einfachen Datentypen
bilden (z.B. Felder oder Mengen)
Operationstypen, bestehend aus
{ einem Operationsnamen
{ einer Liste von Datentypen zur Darstellung von Parametern
{ einer Liste von Datentypen zur Darstellung von Ergebnissen
{ der Semantik der Operation
Schnittstellentypen, bestehend aus
{ einem Schnittstellentypnamen
{ einer Menge von Operationstypen
{ der Semantik der Schnittstelle
Dienstattributtypen, bestehend aus
{ einem Attributnamen
{ einem Datentyp zur Darstellung des Attributwertes
{ einer Attributkennung zur Kennzeichnung als dynamisch oder statisch
Diensttypen, bestehend aus
{ einem Diensttypnamen
{ einem Schnittstellentyp
{ einer Menge von Dienstattributtypen
2.3.2 Beziehungen zwischen Diensttypen
Mit Hilfe der obigen Schnittstellen{ und Diensttypen lassen sich dieSchnittstellen
von Objekten bzw. die dort angebotenen Dienste formalisieren. Typisierung
bildet hierbei die erste Voraussetzung fur eine wohlde nierte Dienstnutzung in
o enen verteilten Systemen. Ein weiterer wichtiger Aspekt bei der Dienstnutzung
ist die Berucksichtigung der Weiterentwicklung von Diensten bzw. Diensttypen.
Dieses ist insbesondere in o enen verteilten Systemen | speziell in o enen
Dienstemarkten [ML93a, GGL + 95] |von gro er Bedeutung, da dort im Prinzip
jederzeit neue Diensttypen angeboten oder bestehende weiterentwickelt werden

26 Modellierung und Beschreibung von Diensten
konnen. Um in solchen dynamischen Umgebungen dennoch einen wohlde nierten
und strukturierten Umgang mit Diensten erreichen zu konnen, ist es notwendig
Formalismen zu de nieren, die Beziehungen zwischen Schnittstellen{ und
Diensttypen in geeigneter Art und Weise ausdrucken konnen. Unter Benutzung
derartiger Beziehungen kann beispielsweise sichergestellt werden, da trotz Erweiterungen
der Schnittstelle eines Diensterbringers weiterhin die Typsicherheit
zu den Dienstnehmern, die auf der Basis des alten Schnittstellentyps entwickelt
wurden, vorhanden ist. Auchla t sich hierdurcheineVergleichbarkeit von Typen
erreichen, die unter anderem fur die Dienstvermittlung von besonderem Interesse
ist, bei der eine Zuordnung potentieller Dienstnehmer zu Diensterbringern
exibel auf der Basis von Diensttypen durchgefuhrt werden soll.
Beziehungen (engl. relations) zwischen Diensten konnen prinzipiell von verschiedenster
Art sein und sindabhangig von der beabsichtigten Zielstellung und auch
dem gewollten Grad von Ausdrucksstarke [CM95]. So konnen Beziehungen beispielsweise
darin bestehen, die Zusammengehorigkeit verschiedener Diensttypen
auszudrucken, die bezuglich ihrer Dienstsemantik an sich nicht in Beziehung stehen.
Eine derartige Beziehung konnte beispielsweise lauten: " Die Diensttypen A
und Bstehen in Beziehung, da sie im selben Software{Projekt verwendet werden\.
Diese Art von " semantischer\ Beziehung ist ein Beispiel fur durch Instanzen
de nierte Beziehungen, da diese nicht automatisch, sondern durch explizite
administrative Tatigkeiten fur jedes Paar von Diensttypen neu de niert werden
mussen. Hierzu im Gegensatz stehen die durch De nitionsregeln de nierten Beziehungen,
die eine automatische systemgesteuerte Vergleichbarkeit von Diensttypen
ermoglichen (siehe auch Abschnitt 3.2.2.2).
Eine durch De nitionsregeln de nierte Beziehung ist auch die oben bereits
erwahnte Subtypregel. Sie de niert die Beziehung von Schnittstellentypen, auf
deren Grundlage eine Uberprufung der Kompatibilitat des von einem Diensterbringer
angebotenen und von einem Dienstnehmer geforderten Schnittstellentyps
moglich ist. In diesem Zusammenhang wird Subtypisierung auch oft als Konformitat
bezeichnet, d.h. ein Schnittstellentyp A hei t konform zu einem anderem
Schnittstellentyp B, wenn ein Objekt vom Schnittstellentyp A immer fur ein Objekt
mit Schnittstellentyp B eingesetzt werden kann [RTL + 91]. Dieses Prinzip
der Ersetzbarkeit bedeutet in praktischer Anwendung, da ein Diensterbringer
durch einen anderen zu seinem Schnittstellentyp konformen Diensterbringer ausgetauscht
werden kann, ohne da sich hierdurch Anderungen fur die Dienstnehmer
ergeben (Abbildung 2.4). Die Abbildung zeigt zwei Diensterbringer mit den
Schnittstellentypen ST-A und ST-B, wobei ST-A konform zu ST-B ist. Hierdurch
bedingt kann Dienstnehmer 1 die Dienste beider Diensterbringer nutzen. Dieses
gilt jedochnicht fur den speziell auf Grundlage von Schnittstellentyp ST-A
entwickelten Dienstnehmer 2,daumgekehrt der Schnittstellentyp ST-B nichtkonform
zu ST-A ist.
Die im folgenden dargestellte De nition von Konformitat von Schnittstellentypen
stammt aus der verteilten Programmiersprache Emerald [RTL + 91] und ndet
sich inahnlicher Darstellung auch im ersten Teil des ODP{Referenzmodells
[ODP95b] und inanderen Programmiersprachen, wie beispielsweise der objekt-

2.3 Typisierung von Schnittstellen und Diensten 27
Dienstnehmer
Dienstnehmer
1
ST-B
2
ST-A
Dienstaufruf
ST-A
ST-B
Diensterbringer
ST-A ist konform
zu ST-B
Diensterbringer
Abbildung 2.4: Konformitat von Schnittstellen
orientierten Sprache Guide [KMV + 90].
De nition 2.1 (Konformitat von Schnittstellentypen) Seien S und T
zwei Schnittstellentypen. S hei t konform zuT(S T), wenn ein Objekt vom
Schnittstellentyp S immer fur ein Objekt vom Schnittstellentyp T ersetzt werden
kann. Die Ersetzung kann statt nden, wenn die folgenden vier Voraussetzungen
erfullt sind:
1. S besitzt mindestens die Operationen von T. (S kann mehr Operationen
haben.)
2. Fur jede Operation in T gilt, da die entsprechende Operation in S denselben
Operationsnamen und dieselbe Anzahl von Parametern und von Ergebnissen
besitzt.
3. Fur jede Operation in S gilt, da der Typ der Ergebnisse konform zum Typ
der Ergebnisse der entsprechenden Operation von T ist.
4. Fur jede Operation in T gilt, da der Typ der Parameter konform zum Typ
der Parameter der entsprechenden Operation von S ist.
Jeder Schnittstellentyp ist zu sich selbst konform.
Zwei Operationstypen sind genau dann konform zueinander, wenn die Punkte
zwei bis vier erfullt sind. Auch hier gilt, da jeder Operationstyp zu sich selbst
konform ist.
Die vierte Eigenschaft wird auch als Kontravarianz bezeichnet, da sie entgegengesetzt
zur sonstigen kovarianten Beziehung der beiden Schnittstellen{ und Ergebnistypen
steht. Ein einfaches Beispiel fur die Anwendungder Konformitatsbeziehung
ist das Hinzufugen einer neuen Operation zu einer bestehenden Schnittstelle
eines Dienstes.
Als Erweiterung zur obigen De nition 2.1 legt die folgende De nition die Konformitatsbeziehung
zwischen Diensttypen fest. Sie unterscheidet sichinder Berucksichtigung
der Dienstattributtypen, die einen Dienst in seinen Eigenschaften
naher beschreiben. Sie ist in ahnlicher Form auch in [IBR93] dargestellt.

28 Modellierung und Beschreibung von Diensten
De nition 2.2 (Konformitat von Diensttypen) Seien S und T zwei
Diensttypen. S hei t konform zu T (S T), wenn ein Objekt vom Diensttyp
S immer fur ein Objekt vom Diensttyp T ersetzt werden kann. Die Ersetzung
kann statt nden, wenn die folgenden vier Voraussetzungen erfullt sind:
1. Der Schnittstellentyp von S ist konform zum Schnittstellentyp von T.
2. S besitzt zumindest alle Dienstattribute, die auch T besitzt. (S kann auch
mehr Dienstattribute haben.)
3. Jedes Dienstattribut von S hat denselben Attributnamen wie das entsprechende
Dienstattribut von T, wobei
4. der Typ des Dienstattributs von S konform zu dem von T ist.
Jeder Diensttyp ist zu sich selbst konform.
Die Konformitat bzw. Subtypisierung von Schnittstellen{ und Diensttypen
ermoglicht den Aufbau von Typhierarchien, die die Kompatibilitatsbeziehungen
zwischen den Typen widerspiegeln. Typuberprufungen und {vergleiche konnen
dabei weitgehend automatisch, beispielsweise durch die in [NS95] oder [AC91]
vorgestellten Algorithmen, durchgefuhrt werden. Zur Verwaltung derartiger Typhierarchien
existieren in verteilten Systemen relativ neuartige Ansatze in Form
sogenannter Typmanager [IBR93, CM95] oder Typ{Ablagedienste (engl. type repository)
[ODP95c], auf deren Funktionen Abschnitt 3.2detailliert eingeht.
2.4 Formen von Dienstbeschreibungen
Auf der Dienstbeschreibungsebene existieren verschiedene Ansatze, um Dienste
bzw. Diensteigenschaften auf abstrakte Art und Weise darzustellen. Dabei
werden die Unterschiede zwischen Dienstbeschreibungen vor allem in dem Grad
ihrer Ausdrucksmachtigkeit deutlich, der sich direkt auch inden Moglichkeiten
zum Vergleich von Dienstbeschreibungen au ert. Wie schon anhand der am Anfang
dieses Kapitels dargestellten Interoperablitatsprobleme ersichtlich wurde,
stellt die Vergleichbarkeit und Uberprufbarkeit von Dienstbeschreibungen bzw.
Dienstreprasentationen eine wesentliche Grundlage dar, auf derer die Interoperabilitat
von Dienstnehmern und Diensterbringern in o enen verteilten Systemen
sichergestellt werden kann.
Ziel der folgenden Darstellung istes,verschiedene Ansatze von Dienstbeschreibungen
aufzuzeigen und bezuglich ihrer Verwendbarkeit zur Beschreibung von
Diensten in o enen verteilten Dienstemarkten zu untersuchen. Das untersuchte
Spektrum reicht von Dienstbeschreibungen mit relativ einfachen Beschreibungsmitteln
bis hin zu Ansatzen, die aufgrund komplexer Formalismen wesentlich
machtigere Ausdrucksmoglichkeiten besitzen. Es werden hierbei drei grobe
Kategorien von Dienstbeschreibungen unterschieden (siehe zumVergleich auch
[MML95f]):

2.4 Formen von Dienstbeschreibungen 29
Namensbasierte Ansatze
Strukturelle Ansatze
Erweiterte Ansatze
2.4.1 Benennung von Diensten
Im einfachsten Fall beschrankt sich die Beschreibung eines Dienstes auf die Benennung
des Schnittstellentyps. Ein Beispiel ist der Name " 0081f128-a244-10b5-
99d0-08005a921930\ zur Bezeichnungdes Schnittstellentyps eines Druckdienstes,
wie es am Beispiel der in Abbildung 2.5 gezeigten DCE{Dienstbeschreibung verdeutlicht
ist. Diese sogenannte UUID (engl. universal unique identi er) ist eine
durch entsprechendeWerkzeuge generierteeindeutige Zeichenkette, die einen bestimmten
Schnittstellentyp global eindeutig bezeichnet. Sie ist elementarer Bestandteil
jeder Schnittstellenbeschreibung in DCE, die in der DCE{spezi schen
Schnittstellenbeschreibungssprache (engl. interface de nition language { IDL) formuliert
ist. Print bezeichnet in der Abbildung einen symbolischen Schnittstellentypnamen,
der vom Benutzer fur programmiertechnische Aspekte zusatzlich
gewahlt werden mu . Im Gegensatz zur UUID mu der Name jedoch nicht weltweit
eindeutig sein. Weiterhin beinhaltet die Schnittstellenbeschreibung die Denition
der zur Print{Schnittstelle gehorenden, hier jedoch nicht dargestellten
Operationen in Form von Operationssignaturen, welche zur Generierung von sogenannten
Kommunikationsstubs (siehe Abschnitt 3.2.2.7) verwendet werden.
[
uuid(0081f128-a244-10b5-99d0-08005a921930),
version(1.0)
]
interface Print
{
/* interface operation definitions */
}
Abbildung 2.5: DCE{Schnittstellenname
UUIDs in DCE dienen zum einen zum Au nden geeigneter Dienste mit Hilfe
eines Namensdienstes, zum anderen ermoglichen sie eine rudimentare Kompatibilitatsprufungder
Schnittstellentypen zwischen Dienstnehmer und Diensterbringer
zum Zeitpunkt der Bindung bzw.des ersten Operationsaufrufs 1 .Eineweitere
Uberprufung des eigentlichen Operationsaufrufs anhand der in der Schnittstellenbeschreibung
vorhandenen Operationssignaturen ndet nicht statt.
1 Bei DCE fallen Bindung und der erste Operationsaufruf je nach verwendeter Bindungsme-
thode zeitgleich zusammen.

30 Modellierung und Beschreibung von Diensten
Da sich die Uberprufungder Aquivalenz zweier Schnittstellentypen auf die einfache
Gleichheit von Namen beschrankt, ist die Flexibilitat namensbasierter Typisierung
von Schnittstellen innerhalb gro er o ener heterogener verteilter Systeme
nur sehr eingeschrankt nutzbar. Dieses ist darin begrundet, da dort ein gemeinsames
Verstandnis uber die Semantik eines bestimmten Namens nur sehr schwer
zu erreichen ist bzw. eine zentral gesteuerte Vergabe von Namen aufgrund der
Dynamik o ener Dienstemarkte nicht oder nur in geringem Ma e, beispielsweise
durch weltweite Standardisierung von Typbezeichnern, durchgefuhrt werden
kann. So fuhrt der bei der ausschlie lichen Nutzung von Typnamen auftretende
Informationsverlust beim Ubergang von der Dienstmodell{ zur Dienstbeschreibungsebene
inder Regel zu den in Abschnitt 2.1 beschriebenen Interoperabilitatsproblemen.
Zum Beispiel konnen verschiedenartige Dienste bzw. Schnittstellentypen
unter Umstanden gleichartig benannt werden, so da die Interoperabilitat
von Diensten trotz identischer Typnamen nicht gewahrleistet werden
kann. Ebenso konnen gleichartige Schnittstellentypen verschiedenartig bezeichnet
werden, so da eine Typubereinstimmung auf der Grundlage einfacher Namensaquivalenz
nicht ermittelt werden kann. 2
Ein einfache Erweiterung namensbasierter Schnittstellentypisierung ergibt sich
durch Anwendung der in Abschnitt 2.3.2 dargestellten De nition uber die Konformitat
bzw. Subtypisierung zweier Schnittstellentypen, die auf der Basis der
strukturellen Eigenschaften von Schnittstellentypen, d.h. der Operationssignaturen,
de niert ist. Da im Fall von nur durch Namen bezeichneten Schnittstellentypen
diese zusatzlichen Informationen fur einen automatischen Vergleichsvorgang
nicht verfugbar sind, konnen Subtypbeziehungen nur durch administrative
Ma nahmen explizit de niert werden. Die Korrektheit dieser Beziehung anhand
der Konformitatsregeln kann ebenfalls nicht uberpruft werden. Dieses explizite
Prinzip ndet beispielsweise Verwendung innerhalb von DCE, wo durch Versionsnummern
(beispielsweise version(1.0) in Abbildung 2.5) die Beziehung
zweier Schnittstellentypen mit demselben Namen aufgezeigt wird. Die Konformitat
innerhalb von DCE beschrankt sich auf das Hinzufugen ein oder mehrerer
Operationen. Andere Beispiele sind ANSA und CORBA, welche ebenfalls auf
dem Prinzip der expliziten Subtypisierung beruhen.
Die oben gemachten Aussagen uber die namensbasierte Beschreibung von
Diensten lassen sich auch direkt auf das Diensttypkonzept ubertragen, welches
das Schnittstellentypkonzept umfa t.
2.4.2 Strukturelle Dienstbeschreibungen
In Anbetracht der Dynamik o ener Dienstemarkte mit neu hinzukommenden,
sich andernden und auch verschwindenen Dienst{ und Schnittstellentypen gestaltet
sich die explizite administrative Verwaltung von Subtypbeziehungen im
allgemeinen sehr aufwendig. Zusatzliche Probleme ergeben sich dadurch, da
durch die Heterogenitat in o enen Dienstemarkten eine global einheitliche und
2 Auf naturliche Weise wird dieses bereits durch die Nutzung verschiedener Sprachen verursacht,
beispielsweise die Verwendung von " Print\ imEnglischen fur " Drucken\ imDeutschen.

2.4 Formen von Dienstbeschreibungen 31
wohlde nierte Namensgebung von Dienst{ und Schnittstellentypen nur sehr eingeschrankt
moglich ist,soda in der Regel eine ausschlie lich auf der Basis
von Namen durchgefuhrte Vergleichbarkeit von Diensten nicht realisierbar ist.
Innerhalb kleiner geschlossener Verwaltungsbereiche kann der namensbasierte
Ansatz jedoch aufgrund der e zienten und einfachen Realisierbarkeit weiterhin
durchaus seine Berechtigung besitzen, da dortimallgemeinen die mit den
Bezeichnern verbundene Semantik und die verschiedenartigen Beziehungen zwischen
den verwendeten Typen bekannt sind. Auf dem Hintergrund weltweiter
o ener Dienstemarkte sindjedoch erweiterte Ansatze erforderlich, die das namensbasierte
Konzept um die Beschreibung struktureller, kontextunabhangiger
Eigenschaften von Diensten erganzen.
Ein erster Ansatz in diese Richtung ist die Einbeziehung struktureller Eigenschaften
von Diensten, wie sie beispielsweise zur De nition der Diensttypkonformitat
in Abschnitt 2.3.2 benutzt werden. Der Vorteil gegenuber dem namensbasierten
Ansatz liegt darin, da durch die zusatzliche Berucksichtigung der Signaturen
der Operationen und Dienstattribute ein wohlde niertes strukturelles Kriterium
gegeben ist, auf dessen Grundlage Typuberprufungen und {vergleiche automatisch
durch systemtechnischeVerfahren durchgefuhrt werden konnen. Die vorher
verwendeten kontextabhangigen Namen nden keine Berucksichtigung. So werden
zwei Schnittstellentypen, die dieselben Operationssignaturen besitzen, trotz
beispielsweise der unterschiedlichen Namen " Print\ und " Drucken\ aufgrund ihrer
strukturellen Ubereinstimmung als konform zueinander erkannt. Dieser Vorteil
au ert sich auch beider Verwaltung von Dienst{ und Schnittstellentypen in
Typhierarchien (siehe Abschnitt 3.2), bei der die Einordnung neuer Typen nun
implizit durch Systemmechanismen erfolgen kann, wahrend hingegen bei einer
namensbasierten Typverwaltung Beziehungen zu anderen Diensttypen explizit
beschrieben werden mussen. Des weiteren werden mittels der Signaturinformationen
auch genauere Kompatibilitatsuberprufungen zum Zeitpunkt der Dienstvermittlung
und Bindung moglich. Zusatzlich lassen sich nun auch die Operationsaufrufe
genauer untersuchen, welches mit der namensbasierten Typisierung
nicht moglich war.
Da Signaturen ausschlie lich zur Beschreibung struktureller Diensteigenschaften
dienen, mit denen sich semantische Aspekte von Diensten nur implizit, beispielsweise
durch dienstspezi sch gewahlte Operationsnamen, ausdrucken lassen,
bleibt das Problem der Interoperabilitat auf Dienstmodellebene jedoch weiterhin
bestehen, falls an sich semantisch verschiedenartige Dienst{ bzw. Schnittstellentypen
mit denselben Beschreibungsmitteln dargestellt werden. Hier mussen
dann, beispielsweise im Fall der Schnittstellentypen Stack und Queue, zusatzliche
administrative Ma nahmen vorgenommen werden, die deren jeweilige Eindeutigkeit
sicherstellen. Ein relativ einfacher und pragmatischer Losungsansatz
hierfur ndet sich inder verteilten Systemplattform ILU [JSS95] der Xerox Corporation.
Dort werden sogenannte Markenzeichen (engl. brands) vergeben, die
einen in der ILU{Schnittstellenbeschreibungssprache de nierten Schnittstellentyp
eindeutig kennzeichnen. Hierdurchwerden zwei Schnittstellentypen trotz der
Ubereinstimmung in strukturellen Aspekten als semantischverschieden erkannt.

32 Modellierung und Beschreibung von Diensten
2.4.3 Beschreibung von Diensteigenschaften
Die oben beschriebenen Ma nahmen zur Dienstbeschreibungreichen in der Regel
nicht aus, um Dienste in o enen verteilten Systemen hinreichend genau charakterisieren
zu konnen.Sobeinhalten Namen, wie beispielsweise die der Operationstypen
oder der Schnittstellentypen, im allgemeinen zwar gewisse semantische
Informationen uber die Art des erbrachten Dienstes, doch lassen sich mit ihnen
spezi sche Diensteigenschaften oder {merkmale nicht explizit ausdrucken.
2.4.3.1 Dienstattribute
Ein Beschreibungsansatz ist die Erganzung der Schnittstellentypinformationen
um Dienstattributtypen. Sie sind Bestandteil des Diensttypkonzeptes, welches bereits
inAbschnitt 2.3 eingefuhrt wurde. Abbildung 2.6 zeigt das Beispiel einer
um Dienstattribute erganzten CORBA{Schnittstellenbeschreibung, die als eine
Variante zur Beschreibung von Diensten innerhalb von TRADE verwendet wird.
Das dort de nierte Dienstattribut costPerPage besitzt den Typ float undkennzeichnet
den Preis pro Druckseite.
//@service type PrintService �
//@property static float costPerPage�
//@property dynamic long queueLength
interface Print {
void PrintJob (in string Data, out long JobNumber)�
}�
Abbildung 2.6: Erweiterung von Schnittstellenbeschreibungen um Dienstattribute
Die De nition der Dienstattributtypen ist hierbei zusammen mit dem Schnittstellentyp
Print ein wesentlicher Bestandteil der Dienstbeschreibungdes Diensttyps
PrintService. Diensterbringer als konkrete Instanzen dieses Diensttyps konnen
nun durch geeignete Wahl von Werten fur die Dienstattribute, beispielsweise
costPerPage =0.3,von anderen Diensterbringern unterschieden werden. Diese
Eigenschaft spielt insbesondere bei der Dienstvermittlung einewichtige Rolle.
Generell werden statische und dynamische Dienstattribute unterschieden, wobei
beispielsweise costPerPage als statisches Dienstattribut de niert ist, da sich
diese Eigenschaft wahrend der Lebenszeit eines Diensterbringers im allgemeinen
nichtoder nur sehr selten andert. Ein Beispiel fur ein dynamisches Dienstattribut
fur einen Druckdienst ware die aktuelle Warteschlangenlange, da sich diese Eigenschaft
je nach Auslastung permanent andern kann. Generell existieren jedoch
keine Regeln fur die Unterscheidunginstatischund dynamisch, sondern sie ist fur
jeden Diensttyp anwendungsabhangig zu de nieren, wobei auch die Konsequenzen
fur den Dienstauswahlproze einer Dienstvermittlungskomponente beruck-

2.4 Formen von Dienstbeschreibungen 33
sichtigt werden mussen. Dort kann es unter Umstanden sinnvoll sein, die in der
Regel recht zeitaufwendige Auswertung dynamischer Attribute moglichst weit
hinauszuzogern, um sie eventuell gar nicht mehr durchfuhren zu mussen (siehe
Abschnitt 3.3.2.3).
Die Attributierung von Diensten im Rahmen des oben dargestellten Diensttypkonzeptes
ist ein erster wesentlicher Schritt zur Beschreibungsemantischer Informationen
eines Dienstes. Attributierung ndet generell auchinanderen Bereichen
ahnliche Verwendung, um Informationen strukturiert anbieten zu konnen. Ein
Beispiel sind die Namensdiensteinverteilten Systemen, wie beispielsweise X.500
[Rad94] oder DCE CDS [OSF92], die das Einfugen von beschreibenden Attributen
zu Namenseintragen erlauben. Ein anderer Anwendungsbereich ist die strukturierte
Suche nach Informationen (engl. information retrieval) [SM83, ANS95].
Hier werden Attribute als inhaltsbeschreibende Schlusselworter verwendet, die
zur Indizierung von Texten dienen, die dann e zient mit Hilfe von Literaturdatenbanken
verwaltet werden konnen.
2.4.3.2 Konzeptgraphen
Eine Fortfuhrung der Attributierung von Diensten ist ein auf sogenannten Konzeptgraphen
[Sow84] aufbauender Ansatz, der in [PB96] ausfuhrlich beschrieben
ist. Grundlegende Idee dieses aus dem Bereich der Wissensreprasentation stammenden
Ansatzes ist die De nition von sogenannten Konzepten. Konzepte beschreiben
Dinge der Vorstellungswelt des Menschen und konnen sowohl abstrakter
als auch physikalischer Natur sein. In Anwendung auf Dienstbeschreibungen
kann dieses beispielsweise das physikalische Konzept eines Druckers mit dessen
abstrakter Eigenschaft seiner Druckgeschwindigkeit sein. Konzepte werden hierbei
durch Relationen verknupft, die die Beziehungen zwischen ihnen ausdrucken.
Aus formaler Sicht isteinKonzeptgraph ein endlicher, verbundener, gerichteter,
bipartiter Graph, dessen Knoten entweder Konzept{ oder Relationsknoten
sind. Abbildung 2.7 gibt ein Beispiel eines Konzeptgraphen zur Beschreibung
der Eigenschaften eines Druckers, wobei eckige Klammern Konzepte und runde
Klammern Relationen bezeichnen.
[Printer] -
-> (IS-A) -> [HARDWARE-DEVICE],
-> (CONNECTED-TO) -> [COMPUTER],
-> (VISUALIZES) -> [INFORMATION] -> (CAN-BE) -> [TEXTUAL],
-> [GRAPHICAL].,
-> (PRINTS-ON) -> [PAPER],
-> [SLIDES]..
Abbildung 2.7: Konzeptgraph zur Beschreibungder Eigenschaften eines Druckers
Informell ausgedruckt bedeutet diese Beschreibung: " Ein Drucker ist ein Gerat,

34 Modellierung und Beschreibung von Diensten
welches an einen Computer angeschlossen ist und Informationen entweder textuell
oder graphisch auf Papier oder Folien drucken kann\. Diese Beschreibung
kann anschlie endmitanderen Beschreibungen auf Ahnlichkeiten verglichen werden.
Eine Ahnlichkeit zweier Beschreibungen wird auf der Grundlage eines Ahnlichkeitsma
es ermittelt, das die sogenannte semantische Distanz zweier Konzeptgraphen
bestimmt [Sow84].
In Anwendung auf die Dienstsuche inverteilten Dienstemarkten konnen so mit
Hilfe von Konzeptgraphen Anfragen nach Dienstbeschreibungen formuliert werden,
die beispielsweise fur die Entwicklungvon verteilten Anwendungen benotigt
werden. Durch den Vergleich mit bereits vorhandenen Konzeptgraphen konnen
dann ahnliche Dienstbeschreibungen automatisiert gefunden werden. Dabei ist
der Anfragevorganginder Regel mehrstu g durchzufuhren, um den gewunschten
Dienst durch eineverfeinerte Wahl von Konzepten und Relationen schrittweise
einzugrenzen [PGM95].
Ein grundsatzliches Problem bei der Nutzung von Konzeptgraphen zur Beschreibung
von Diensten ist ahnlich wie bei den namensbasierten Typisierungsmechanismen
die Wahl geeigneter Bezeichner fur die Konzepteund Relationen. Da auch
hier Namen, beispielsweise die Relation CONNECTED-TO,kontextabhangig gewahlt
werden, eignen sich Konzeptgraphen eher fur die Verwendung innerhalb kleinerer
geschlossener Verwaltungsbereiche, da dort ein gemeinsames Verstandnis der
Konzepte und Beziehungen einfacher zu erreichen ist als im Rahmen weltweiter
Dienstemarkte. Um Konzeptgraphen in verteilten Dienstemarkten sinnvoll
nutzen zu konnen, ist eine Standardisierung von Konzept{ und Relationsnamen
erforderlich, die dem Benutzer einen wohlde nierten Begri srahmen fur eine efziente
Suche geeigneter Dienste bzw. Diensttypen bereitstellt. Abbildung 2.8
verdeutlicht den in [PB96] dargestellten Vorschlag zur standardisierten Beschreibung
von Diensttypen am Beispiel eines Druckdienstes.
[SERVICE-TYPE:{"PrintService"}] -
-> (CONSISTS-OF) -> [INTERFACE-TYPE:{"Print"}],
-> (CONSISTS-OF) -> [PROPERTY-TYPE:{"PrinterAttributes"}].
[INTERFACE-TYPE:{"Print"}] -
-> (CONSISTS-OF) -> [SIGNATURE:{"PrintJob"}].
[SIGNATURE:{"PrintJob"}] -
-> (IN_PARAMETER) -> [STRING:{"Data"}],
-> (OUT_PARAMETER) -> [LONG:{"JobNumber"}].
[PROPERTY-TYPE:{"PrinterAttributes"}] -
-> (STATIC-ATTRIBUTE) -> [FLOAT:{"costPerPage"}],
-> (DYNAMIC-ATTRIBUTE) -> [LONG:{"queueLength"}].
Abbildung 2.8: Standardisierte Bezeichner fur Konzepte und Relationen

2.4 Formen von Dienstbeschreibungen 35
Wie im Vergleich zur Dienstbeschreibung inAbbildung 2.6 deutlich wird, bieten
Konzeptgraphen eine mogliche Alternativezuden auf Schnittstellenbeschreibungssprachen
aufsetzenden Dienstbeschreibungen. Der Vorteil von Konzeptgraphen
liegt in ihrer Erweiterbarkeit, durch Einfuhrung neuer Konzepteoder Relationen
die Beschreibungneuartiger Aspektenahtlos integrieren zu konnen. Dieses
istinSchnittstellenbeschreibungssprachen ohne tiefergehende Anderungen der
Syntax im allgemeinen nicht moglich. Ein Beispiel fur eine moglicheErweiterung
ist das Hinzufugen von Informationen, die einem Klienten zur Generierung einer
zum Dienst passenden graphischen Benutzerschnittstelle dienen konnen. Dieses
Konzept ist beispielsweise im Generischen Klienten [ML93b, MML94a] verwirklicht
worden, der den interaktiven Zugang zu beliebigen Diensten ermoglicht.
2.4.4 Beschreibung des Verhaltens von Diensten
Dienstattribute und Konzeptgraphen stellen eine erste notwendige Erweiterung
dar, die eine Beschreibung semantischer Diensteigenschaften ermoglichen, die
uber die strukturellen Aspektedes Schnittstellentyps hinausgehen. Die von ihnen
gebotenen Beschreibungsmoglichkeiten reichen jedoch nicht aus, das nach au en
sichtbare dynamische Verhalten eines Dienstes (bzw. das einer Objektinstanz
dieses Dienstes) darzustellen.
2.4.4.1 Protokollspezi kationen
Ein erster Ansatz zur Erweiterung signaturbasierter Dienstbeschreibungen ist die
Nutzung von Transitionssystemen bzw. Automatenmodellen zur Beschreibung
des Verhaltens eines diensterbringenden Objektes. Diese dienen zur Beschreibung
des Protokolls an seiner Schnittstellen und legen die moglichen Reihenfolgen
von Operationsaufrufen fest, die in Abhangigkeit zum jeweiligen Zustand
des Objektes de niert sind. Aus diesem Grund werden derartige Objekte auch
als aktive Objekte [Nie93] im Gegensatz zu funktionalen Objekten bezeichnet,
die ausschlie lich in ihren statischen Eigenschaften, insbesondere den Operationssignaturen
der Schnittstellentypen, beschrieben werden. Begrundet wird diese
Sichtweise durch Einschrankungen der Ausdrucksmachtigkeit von Signaturen
[NP91]:
Keine einheitliche Dienstverfugbarkeit: Die Verzogerung oder Zuruckweisung
von Operationsaufrufen abhangig vom Zustand des Diensterbringers
ist nicht ausdruckbar.
Mehrere nebenlau g agierende Dienstnehmer: Der nebenlau ge Dienstzugri
mehrerer Dienstnehmer mit sich zumTeil beein u enden Handlungen
ist mit Signaturen nicht darstellbar.
AlternativeKooperationsprotokolle: Zu Client/Server{Protokollen alternative,
auf Nachrichtenaustausch beruhende Protokolle, beispielsweise Early
Reply [LHG86], konnen nicht formuliert werden.

36 Modellierung und Beschreibung von Diensten
Wiederverwendung: Signaturen bieten zuwenige Informationen uber das
Verhalten nebenlau g agierender Diensterbringer, um einesichere Wiederverwendbarkeit
in einem neuen Anwendungskontext sicherstellen zu
konnen.
Ziel ist es nun, zusatzlich zu den auf Signaturbeschreibungen de nierten
Vergleichbarkeits{ und Subtypisierungsmechanismen Verfahren zu entwickeln,
die Aussagen uber die Interaktionskonformitat (engl. interaction conformance)
bzw. Anfrageersetzbarkeit (engl. request substitutability) von Dienstnehmer und
Diensterbringer liefern.
Zentraler Begri ist hierbei das Protokoll, welches die Folge der von einem
Diensterbringer bedienbaren Anfragen bzw. Operationsaufrufe inAbhangigkeit
von dessen jeweiligen Zustand festlegt. Zur Modellierung des Protokolls eines
Diensterbringers mit seinen Zustandsanderungen wird ein kantenbeschriftetes
Transitionssystem [Mil89] verwendet, bestehend aus einer endlichen Menge von
Zustanden und Zustandsubergangen. Eine Zustandsanderung im Diensterbringer
ndet hierbei durch den Aufruf einer Operation an dessen Schnittstelle statt
und au ert sich imTransitionssystem im Ubergang von einem Zustand ineinen
anderen entlang der mit der entsprechenden Operation beschrifteten Kante. Ein
einfaches Beispiel eines Transitionssystems zeigt Abbildung 2.9 anhand der regularen
Typen Stack und Variable 3 mit jeweils denselben Operationssignaturen
get und put.
put
get
Stack
put
get
put
Variable
Abbildung 2.9: Transitionssysteme fur die Diensttypen Stack und Variable
Beide Typen bieten jeweils eine Moglichkeit zur Speicherung von Informationen.
Im Fall von Stack konnen mehrere Informationen abgelegt werden, wahrend der
Typ Variable nur einen Speicherplatz zur Verfugung stellt. Wie schon bei intuitiver
Betrachtung der Transitionssysteme deutlich wird, zeigen beide Typen
signi kante Unterschiede in ihrem nach au en gezeigtem Verhalten. So kann bei
Stack zu jeder put{Operation nur jeweils genau einget erfolgen, wahrend hingegen
bei Variable beliebig viele get{Operationen aufgerufen werden konnen.
Formal wird dieser Nachweis der Inkompatibilitat beider regularer Typen durch
die Anwendungwohlde nierter Vergleichsregeln gefuhrt, die auf den Reihenfolgen
(engl. traces) moglicher Operationsaufrufe formuliert sind. Der Vergleich wird
mit Hilfe eines auf der Aquivalenz endlicher Automaten beruhenden Algorithmus
[AHU74] realisiert. Mit diesem Algorithmus lassen sich auch Subtypbeziehungen
zwischen regularen Typen erkennen, die jedoch aus Komplexitatsgrunden auf
3 in Analogie zu Variablen in Programmiersprachen
put
get

2.4 Formen von Dienstbeschreibungen 37
einfache Automaten beschrankt sind. Wird zum Beispiel der obige Typ Stack
um eine Operation swap erganzt, die alternativ zu get und put aufgerufen werden
kann, so ist er als interaktionskonform erkennbar. Eine umfassende formale
Darstellung hierzu ndet sich unter anderem in [Nie93].
Eine vom Ansatz her ahnliche Verwendung wie bei den regularen Typen nden
Transitionssysteme auch bei dem Entwurf und der Entwicklung von Kommunikationsprotokollen
in verteilten Systemen, wie sie unter anderem durch das
OSI{Referenzmodell [EF86] standardisiert sind. Bei diesem sogenannten Protocol
Engineering [Sch92c] dienen Automatenmodelle als Grundlage fur formale
Beschreibungstechniken (engl. formal description technique { FDT), mit deren
Hilfe Protokolle spezi ziert und veri ziert werden konnen. Ein Protokoll wird
dabei verstanden als eine verbindliche Absprache zwischen zwei Protokollinstanzen
derselben Kommunikationsschicht, beispielsweise der Transportschicht des
OSI{Referenzmodells. Es legt fest, welche Protokolldateneinheiten zwischen den
Beteiligten ausgetauscht werden mussen, damit eine wohlde nierte Interaktion
moglich ist. Formale Beschreibungstechniken bestehen jeweils aus einer formalen
Syntax, die die Beschreibungsmittel zur Darstellung von Sprachausdrucken festlegt,
und einer formalen Semantik, die die eindeutige Interpretation der Sprachausdrucke
auf der Basis eines mathematisch de nierten semantischen Modells
festlegt [VS87]. KonkreteVertreter von formalen Beschreibungsmethoden, deren
Grundlage erweiterte endliche Automatenmodelle bilden, sind die international
standardisierten Sprachen Estelle und SDL. Beidesindumfassend in [Hog89]dargestellt.
Andere im Zusammenhang mit Kommunikationsprotokollen verwendete
formale Beschreibungssprachen sind unter anderem LOTOS [BB87], welche auf
einer Proze algebra aufbaut, und die Sprache Z [Spi89], deren formale Grundlage
die Pradikatenlogik erster Ordnung bildet.
Wesentlicher Unterschied der Kommunikationsprotokolle zu den durch regulare
Typen dargestellten Konformitatsprotokollen ist das Verstandnis von Protokoll.
So beschreiben Protokolle im Kommunikationsbereich immer die Interaktion von
zwei Protokollinstanzen, wahrend hingegen bei regularen Typen nur das Verhalten
einer Instanz, insbesondere des Diensterbringers von Interesse ist. Im ersten
Fall stehen die Zustandebeider Protokollinstanzen im engen Zusammenhang zueinander,
so da eine Anderung des Zustands einer Protokollinstanz gleichzeitig
auch Auswirkungen auf den Zustand der anderen besitzt. Der aktuelle Zustand
einer Interaktion ist dann abhangig von beiden Protokollinstanzen. Bei regularen
Typen hingegen ist nur der Zustand des Diensterbringers von Interesse, der sich
in Abhangigkeit von den Protokolldateneinheiten, d.h. den von einem Dienstnehmer
aufgerufenen Operationen, und seinem jeweiligen Zustand andern kann.
Welchen Ein u diese Anderungen auf den Zustand des Dienstnehmers haben,
wird durch regulare Typen jedoch nicht festgelegt.
2.4.4.2 Anwendung von Transitionssystemen
Praktische Anwendung nden regulare Typen bzw. kantenbeschriftete Transitionssysteme
beispielsweise im sogenannten Generischen Klienten [ML93b,

38 Modellierung und Beschreibung von Diensten
ML93a, MML94a], wo sie zur De nition von Protokollen zur Steuerung von
Operationsaufrufen dienen. Der Generische Klient realisiert einen einheitlichen
interaktiven Zugangdes Endbenutzers zu beliebigen Anwendungsdiensten in verteilten
Dienstemarkten. Zentrales Steuerungselement der Dienstnutzung ist die
Dienstreprasentation (sieheauchAbschnitt 2.1). Sie ist eine imverteilten System
versendbare Reprasentation von Dienstbeschreibungsinformationen und umfa t
alle wesentlichen Informationen uber den erbrachten Dienst. Sie beinhaltet die
Beschreibung der operationalen Schnittstelle, De nitionen zur Generierung der
zur Schnittstelle passenden graphischen Benutzerschnittstelle, Protokollinformationen
zur Steuerung der Dienstnutzung und eingebettete lokale Zustandsvariablen,
die einen Dialogzustand persistent speichern konnen. Hierbei ist sie ebenso
wie die obige auf Konzeptgraphen basierende Dienstbeschreibung nahtlos um
zusatzliche Beschreibungskomponenten erweiterbar, so da inkrementell die Beschreibungsmoglichkeiten
vergro ert werden konnen, beispielsweise durch Integration
von Kosteninformationen fur die Nutzung der angebotenen Operationen
[MML94a] und Ablaufbeschreibungen im Rahmen unternehmensubergreifender
Geschaftsprozesse [MML95b]. Eine Dienstreprasentation wird vom Diensterbringer
erzeugt undzumBindungszeitpunkt an den Generischen Klienten ubertragen,
der nach Interpretation der Beschreibungsinformationen fur den Benutzer ein
Bildschirmformular generiert, mit dessen Hilfe der Aufruf der Operationen des
Diensterbringers moglich ist. Eine Operation wird hierbei beispielsweise durch
zu den Ein{ und Ausgabeparametern der Operation passenden Ein{ und Ausgabefelder
und einen dazugehorigen Aktivierungsknopf reprasentiert. Die mogliche
Aufrufreihenfolge der Operationen legt das Interaktionsprotokoll fest, welches
Bestandteil der Dienstreprasentation ist. Unterstutzung uber die mogliche
nachste Auswahl einer ausfuhrbaren Operation erhalt der Benutzer beispielsweise
durch " Ausgrauen\ der Eingabefelder einer bestimmten Operation, das die
Nichtverfugbarkeit der Operation anzeigt.
Au er der Anwendung von Transitionssystemen als Grundlage fur Protokollbeschreibungen
erscheint der Ansatz des Generischen Klienten insbesondere wegen
seiner Visualierungsmoglichkeiten interessant, die eine benutzergerechteDarstellung
der abstrakten Sachverhalteeiner Dienstbeschreibung ermoglichen und das
Suchen geeigneter Dienste bzw. Diensttypen in verteilten Dienstmarkten erleichtern.
Hierdurchkonnen in der Phase der Diensttyp ndung(sieheAbschnitt 3.1.2)
gewunschte Diensttypen ermittelt werden und in ihrer Semantik untersuchtwerden,
was zusatzlich durch die Moglichkeit zum Testen und Ausprobieren der
interaktiv aufrufbaren Operationen sinnvoll unterstutzt wird.
2.4.4.3 Spezi kation von Vor{ und Nachbedingungen
Mit Hilfe von Vor{ und Nachbedingungen werden Aussagen uber das Verhalten
eines Diensterbringers getro en, welches durch dessen Zustand vor und nach der
Ausfuhrungeiner Operation bestimmt wird. Sie werden ausgedruckt als pradikatenlogischeFormeln,
die uber den formalen Parametern der Operationen de niert
sind. Abbildung 2.10 zeigt einen Ausschnitt einer in Larch/CORBA [LC93] beschriebenen
Spezi kation einer Druckwarteschlange mit der Operation enqueue.

2.4 Formen von Dienstbeschreibungen 39
typedef unsigned long JobID� exception QUEUE_FULL�
interface PrinterQueue {
}
uses Queue(PrinterQueue for C, JobID for E, unsigned long for Int)�
const unsigned long MAX_QUEUE_SIZE = 100�
void enqueue (in JobID id) raises (QUEUE_FULL) {
requires true�
modifies self�
ensures self' = append(self!,id)
except when len(self') > MAX_QUEUE_SIZE => raise(QUEUE_FULL)�
}
Abbildung 2.10: Beispiel einer um Vor{ und Nachbedingungen erweiterten COR-
BA IDL
Aufgabe der Operation enqueue ist die Entgegennahme neuer Druckauftrage,
wobei je nach Auslastung der Warteschlange gegebenfalls der Fehler QUEUE FULL
ausgelost wird. Da die Vorbedingung (requires true) in diesem Fall immer
wahr ist, kann ein Klient die Operation jederzeit aufrufen. Die Zeile modifies
self legt fest, da durch die Operation keine anderen Objekteau er dem Warteschlangenobjekt
verandert werden darf, wobei self das Objekt bezeichnet, bei
dem enqueue aufgerufen wurde. Die Nachbedingung ensures self' besagt, da
ein neuer Druckauftrag nur dann entgegengenommen wird, wenn die maximale
Lange der Warteschlange noch nicht uberschritten ist. Ansonsten wird ein Fehler
ausgegeben. self! bzw. self' bezeichnen hierbei den Zustandder Warteschlange
vor undnachdem Operationsaufruf. Der Zustand wird in diesem Kontext auch
als abstrakter Wert des Objekts bezeichnet. In der obigen Spezi kation wird der
abstrakte Wert Queue (Zeile uses Queue) verwendet, der formal in der Larch
Shared Language (LSL) [GHG + 93] spezi ziert ist, in der unter anderem auch die
Operation append de niert ist.
Fur diese LSL{Spezi kationen der abstrakten Werte existiert ein semi{
automatischer Theorembeweiser, der sogenannte Larch Proof Assistant, mit
dessen Hilfe ein Benutzer Aussagen uber die Korrektheit der spezi zierten
abstrakten Werte tre en kann. Dabei wird die Beweisfuhrung hauptsachlich
interaktiv durchden Benutzer gefuhrt, wobei der Therombeweiser ihn primar bei
Standardbeweisen durch automatische Beweisverfahren unterstutzt. Verfahren
oder Werkzeuge fur die Vergleichbarkeit von LSL{Spezi kationen, insbesondere
automatische Verfahren, existieren hingegen jedoch nicht.
Das wesentliche Problem bei der Spezi kation von Vor{ und Nachbedingungen
ist die Komplexitat, die derartige Spezi kationen in der Regel auszeichnen. So

40 Modellierung und Beschreibung von Diensten
hei t es beispielsweise in [LC93]: " The abstract values needed to describe such
application software as OMG and others hope to make available under CORBA
would seem to bevery complex. An ominous fact is thatthe size of a good user's
manual is typically a small book.\ Sokonnen derartige, komplexe Spezi kationen
unter Umstanden fur den Anwendungsprogrammierer sehr unubersichtlich
werden. Erschwerendkommt hinzu, da bedingt durch die Komplexitat die Uberprufungeiner
Subtypbeziehung zwischen zwei Typen, d.h. ob ein Subtyp weichere
Vorbedingungen und strengere Nachbedingungen besitzt [Ame91, LW93], nicht
automatischveri zierbar ist [AL90]. So liegt es in der Regel in der Verantwortung
eines Programmierers, die Subtybeziehungen zwischen zwei Diensten selbstandig
zu uberprufen, um sie dann anschlie end explizit in eine Subtyphierarchie einzuordnen.
In [Ame87] hei t es hierzu bei der Darstellung der Programmiersprache
POOL: " The behaviour of objects cannot be formalized in all its aspects, so the
compiler cannot check completely thatonetype is a subtype of another ... To ensure
thatasubtype really specializes its supertype with respect to itsbehaviour,
a certain discipline is required from the programmer: To the formal description
of the available methods and their parameter and resulttypes, an informal
description of the behaviour of the elements ofthe type should be added, and
whenever a programmer asserts asubtype relationship between two types, he
should check the condition on the associated behaviour description himself.\
Durch diese Einschrankungen sind auf Vor{ und Nachbedingungen basierende
Dienstbeschreibungen nur bedingt zur Uberprufung der Interoperabilitat zweier
Dienste in o enen verteilten Systemen nutzbar. Sie dienen jedoch als sinnvolle
erganzende Beschreibung der ansonsten nur durch Signaturen gekennzeichneten
Diensttypen und konnen beispielsweise fur das Suchen geeigneter Diensttypen
wahrend der Entwicklungsphase einer verteilten Anwendung vom Benutzer zum
besseren Verstandnis dessen Verhaltens genutzt werden.
2.4.5 Bewertung
Ausgangsbasis fur die Untersuchungverschiedener Ansatze zur Beschreibungvon
Diensten stellt die Betrachtung der verschiedenen Ebenen der Interoperabilitat
von Diensten in verteilten Systemen dar. Dabei hat sich insbesondere gezeigt,
da Interoperabilitatsprobleme inverteilten Systemen | unter Voraussetzung
eines gemeinsamen Dienstmodells | im wesentlichen durch zwei Ursachen hervorgerufen
werden:
1. Eine Problematik besteht inder Nutzung verschiedener Diensttypmodelle,
beispielsweise durch Wahl verschiedener Datentypen, durch die eine
Vergleichbarkeit von Diensten nicht durchfuhrbar ist. Zur Losung dieses,
durch die Heterogenitat verschiedener Dienstbeschreibungen hervorgerufenen
Problems mussen entsprechende Mechanismen de niert werden, die
die Abbildung zwischen den verschiedenartigen Diensttypmodellen oder die
Abbildung auf ein gemeinsames, vereinheitlichendes Diensttypmodell eindeutig
festlegen. Erst hierdurch kann ein Vergleich von Schnittstellentypen
durchgefuhrt und somit die Typsicherheit von Dienstnehmer und Dienster-

2.4 Formen von Dienstbeschreibungen 41
bringer gewahrleistet werden.
2. Eine zweite grundsatzliche Problematik betri t den Informationsverlust
beim Ubergangvon der Dienstmodell{ in die Dienstbeschreibungsebene. So
gehen dort in der Regel oftmals wesentlicheCharakteristika eines Dienstes,
vor allem semantische Aspekte, bei der Dienstbeschreibungverloren, so da
eine Eineindeutigkeit zwischen der Dienstbeschreibung und des hiermit beschriebenen
Dienstes nicht gewahrleistet ist. Dies wurde am Beispiel der
Dienste Stack und Queue deutlich, die trotz syntaktischer Gleichheit der
Operationssignaturen ein verschiedenartiges Verhalten aufweisen. Aus diesem
Grund wurden verschiedene Formen von Dienstbeschreibungen untersucht,
beginnend mit namensbasierten Ansatzen, die nur eine sehr geringe
Ausdrucksmachtigkeit besitzen, bis hin zu ausdrucksmachtigeren Beschreibungsformen,
mit denen Verhaltensaspektevon Diensten ausgedruckt werden
konnen.
Wichtiges Kriterium beider Beurteilung dieser verschiedenen Beschreibungsansatze
ist insbesondere deren Verwendbarkeit innerhalb o ener verteilter Systeme.
So werden beispielsweise in heutigen verteilten Systemplattformen, unter
anderem ANSA oder DCE, hauptsachlich die namensbasierten Formen von
Dienstbeschreibungen aufgrund ihrer einfachen Realisierung eingesetzt. Gleichzeitig
wird hiermit jedoch auch inKauf genommen, da die Interoperabilitat von
Dienstnehmer und Diensterbringer nur bedingt gewahrleistet werden kann, da
bis auf Namensaquivalenz keine weiteren Kriterien fur eine semantische Ubereinstimmung
existieren. Um namensbasierte Ansatze auch weiterhin im Rahmen
verteilter Systeme einsetzen zu konnen, ist hierfur eine weitreichende Standardisierung
sowohl von Typbezeichnern, insbesondere Diensttypbezeichnern, als
auch der Subtypbeziehungen zwischen diesen notwendig.
Eine exiblere Losung dieses Problems versprechen die strukturellen Beschreibungsansatze,
die die einfache Namensgebung um strukturelle Aspekte eines
Dienstes erganzen und auf die Benennung von Operationsnamen einschranken.
So werden hierbei die Signaturen der Operationen als kontextunabhangiges Vergleichskriterien
hinzugezogen, welche mit existierenden Vergleichsalgorithmen
automatisch auf strukturelle Aquivalenzen uberprufbar sind.
Der Automatisierbarkeit kommteinewesentliche Bedeutung zu, da alle wesentlichen
Schritte der Interaktion zwischen einem Dienstnehmer und einem Diensterbringer
in vielen verteilten Anwendungen hochgradig automatisiert ablaufen. Dieses
betri t vor allem die Phasen der Dienst ndung, der Bindung und des Zugri s
auf die Operationen des Diensterbringers. Diese Anforderung stellt auch einen
wesentlichen Schwachpunkt der verhaltensbeschreibenden Dienstbeschreibungsformen
dar, die zwar eine wesentlichhohere Machtigkeit bezuglichdes Ausdrucks
von verhaltensspezi schen Aspekten von Diensten besitzen, aufgrund ihrer Komplexitat
jedoch inder Regel nicht automatisch vergleichbar und zumTeil auch
nicht veri zierbar sind.
Sinnvoll eingesetzt werden konnen sie jedoch bei der interaktiven Suche von
Diensten bzw. Diensttypen. Hierbei konnen die Benutzer oder Programmierer

42 Modellierung und Beschreibung von Diensten
durchInterpretation des formal spezi zierten Verhaltens Ruckschlusse auf die Semantik
eines Dienstes ziehen, wobei gegebenfalls automatischeTeilverfahren, beispielsweise
zur Uberprufungder Aquivalenz von regularen Typen bzw. endlichen
Automaten, zur Unterstutzungeingesetzt werden konnen. Unterstutzungfur ein
derartiges interpretatives,benutzergesteuertes Vorgehen bieten auch Konzeptgraphen
und Dienstattribute, die spezielle Eigenschaften eines Dienstes naher charakterisieren
und dem Benutzer Hinweise auf die Semantik eines Dienstes liefern.
Da beide Konzepte jedochauf einer kontextabhangigen Namensgebungberuhen,
beispielsweise Namen von Attributen, gelten fur sie dieselben Einschrankungen
wie bei den namensbasierten Dienstbeschreibungen.
Zusammenfassend ergibt sich hieraus, da eine vollstandige Interoperabilitat eines
Dienstnehmers und eines Diensterbringers in o enen heterogenen verteilten
Systemen nicht erreichbar ist, sofern nicht verbindliche, d.h. standardisierte Absprachen
uber die Semantik eines Dienstes bzw. Diensttyps vereinbart werden.
Diese Forderung wird weiter dadurch verstarkt, da | wie aus der obigen Betrachtung
verschiedener Formen von Dienstbeschreibungen ersichtlich wird |
eine vollstandige Beschreibung der " Bedeutung\ eines Dienstes nicht moglich
ist. Au erdem ist die Beschreibung von Teilaspekten der Semantik, beispielsweise
des Verhaltens an der Schnittstelle, bereits derartig komplex, da eine
automatische Uberprufbarkeit und Vergleichbarkeit von Diensten gegenwartig
an die Grenzen der Realisierbarkeit sto t. Fragestellungen nach der generellen
Entscheidbarkeit dieser Problemstellungen sind hierbei noch unberucksichtigt.
Ein in diesem Zusammenhang wichtiger Aspekt zukunftiger Forschung istunter
anderem, inwieweit die sich gegenseitig widerstrebenden Ziele nachAutomatisierbarkeit
auf der einen und Ausdrucksmachtigkeit auf der anderen Seite moglichst
weitgehend angenahert werden konnen, so da in den meisten Anwendungsfallen
die Interoperabiltat zwischen Dienstnehmern und Diensterbringer durchautomatisierte
Uberprufungsverfahren sichergestellt werden kann. Zum gegenwartigen
Zeitpunkt bietet insbesondere die Beschreibung von Diensten mittels Dienstattributen
eine geeignete Kompromi losung, die vor allem im Umfeld der Dienstvermittlungsmechanismen,
unter anderem in [ODP95a], [KW94], [BB94], [MB92]
und [WT90], verwendet werden. Hierbei dienen die Dienstattribute als zusatzliches
Auswahlkriterium bei der Suche nach geeigneten Diensterbringern.
In heutigen verteilten Systemen beschrankt sich die Uberprufungvon Interoperabilitat
primar auf die Untersuchung der strukturellen Aspekte der operationalen
Schnittstellen von Diensten, wobei verteilte Systemplattformen, unter anderem
DCE, CORBA, ANSA und ILU,vor allem namensbasierte Ansatze verwenden. 4
Diese Beschrankung au ert sich unter anderem auch inden dort de nierten Subtypbeziehungen,
die sich als ein Spezialfall der in Abschnitt 2.3.2 beschriebenen
Konformitatsbeziehung auf das einfache Hinzufugen von Operationen zu einem
Schnittstellentyp konzentriert. Die Signaturen der Operationen nden keine
Berucksichtigung.
4 Eine genauere Betrachtung der Typisierungsaspekte aktueller verteilter Systemplattformen
ndet sich unter anderem in [BIBY95].

2.5 Zusammenfassung 43
Eine Grundproblematik heutiger verteilter Systemplattformen ist auch, da die
De nition und Verwaltung von Typen und Beziehungen zumeist eigenstandig
durch den Systembenutzer durchgefuhrt werden mu . Ein markantes Beispiel ist
hierbei DCE, wo dieVerantwortung uber die Korrektheit einer de nierten Subtypbeziehung
vollstandig beim Programmierer liegen. Eine weitere Uberprufung
dieser Beziehung durch das DCE{Laufzeitsystem ndet nicht statt (siehe auch
[MML95f]). Wunschenswert ware dort eine Systemkomponente, welche einededizierte
Behandlung von Typen und Typbeziehungen erlaubt. Hierdurch konnten
die in der Regel im Systemkern verborgenen Typisierungsmechanismen explizit
zuganglich gemacht werden. Auf diese Funktionen eines derartigen Typmanagements
geht Abschnitt 3.2 noch detailliert ein.
2.5 Zusammenfassung
Das in diesem Kapitel vorgestellte objektbasierte Dienstmodell mit seinem
Diensttypmodell bildet die Grundlage fur die Modellierung von Diensten bzw.
Dienstleistungen, die durch die Diensterbringer in o enen verteilten Systemen
erbracht werden. Grundlegende Abstraktion hierbei ist der Begri der operationalen
Schnittstelle, welche eineAbstraktionsbarriere zwischen der nach au en
gestellten Dienstleistung eines Objektes und seiner internen Implementation erzwingt.
Hierdurch wird es moglich, die im verteilten System angebotenen Dienste
auf abstrakteund einheitliche Weise zu betrachten, ohne spezi schekontextspezischeAbhangigkeiten
betrachten zu mussen. Die Typisierungvon Diensten durch
das Diensttypmodell legt dabei die Art und Weise fest, wie auf den Dienst eines
Objektes zugegri en werden kann. So beinhaltet der Schnittstellentyp alle wesentlichen
Informationen, die fur einen typsicheren Dienstzugri erforderlichsind.
Er ist selbst wiederum Bestandteil des Diensttyps, welcher den an der Schnittstelle
angebotenen Dienst anhand von Dienstattributen semantisch naher charakterisiert.
Ebenso wie der Schnittstellentyp dient erzumAufbau von Typhierarchien,
die auf der Grundlage der Konformitatsbeziehung entwickelt werden.
Diese eignen sich zur Darstellung der Dynamik o ener verteilter Dienstemarkte,
indem sie eine sinnvolle Strukturierung der sich fortentwickelnden Dienste
aufgrund wohlde nierter Ordnungskriterien ermoglichen. Wesentliche Voraussetzung
hierfur bieten die im Diensttyp de nierten Signaturbeschreibungen der
Operationen und der Dienstattribute.
Fur die weitere Darstellung dieser Arbeit stellt das objektbasierte Dienstmodell
die Ausgangsbasis dar, von der im folgenden Untersuchungen konkreter Systemtechniken
durchgefuhrt werden, mit deren Hilfe eine derartige, idealisierte
Sichtweise auf Dienste und deren Nutzung in o enen heterogenen verteilten
Dienstemarkten realisierbar ist. Es dient gleichzeitig auch als formale Grundlage
fur die in Teil II vorgestellte TRADE{Systemumgebung, die speziell fur die
Unterstutzung der Dienstnehmer bei der koordinierten Nutzung der in o enen
heterogenen verteilten Dienstemarkten angebotenen Dienste entwickelt worden
ist.

Kapitel 3
Zugang zu Diensten in
heterogenen Umgebungen
Im vorherigen Kapitel wurde speziell auf die Aspekte der Modellierung und Beschreibung
von Diensten eingegangen, mit denen sich eineeinheitliche und abstrakte
Sichtweise auf die in o enen heterogenen verteilten Dienstemarkten angebotenen
Dienstleistungen erreichen la t, ohne da spezi sche Details der Realisierung
derartiger Dienstemarkte berucksichtigt werden mussen. In dem vorliegenden
Kapitel werden hierauf aufsetzend diejenigen systemtechnischen Mechanismen
genauer untersucht, mit denen eine derartige, idealisierte Sichtweise auf
der Grundlage o ener heterogener verteilter Dienstemarkte verarbeitungstechnisch
umgesetzt werden kann. Gemeinsame Aufgabe der betrachteten Systemtechniken
ist die Realisierung eines weitgehend uneingeschrankten Zugangs zu
den dort vorhandenen Diensten. Hierbei mussen vor allem Heterogenitatsaspekte
berucksichtigt werden, die innerhalb globaler o ener verteilter Dienstemarkte
vorhanden sind. Sie spielen bei den hier betrachteten Losungsansatzen eine bedeutende
Rolle.
Im folgenden wird zuerst auf grundlegende Problemstellungen beim Zugang zu
Diensten in o enen heterogenen verteilten Dienstemarkten eingegangen und verschiedenePhasen
des Dienstzugangs unterschieden. Hierauf aufbauendstellen die
nachfolgenden Abschnittejeweils spezielle Systemtechniken vor, die eine adaquate
Unterstutzung dieser Dienstzugangsphasen bieten, wobei speziell die Fragen
des Diensttypmanagements,der Dienstvermittlung unddes Dienstzugri s schwerpunktma
ig behandelt werden.
3.1 Grundlegende Problemstellungen
Abbildung 3.1 gibt eine generelle Einordnung der in diesem Kapitel betrachteten
Verarbeitungsebene, dieeine systemtechnische Umsetzung der auf Modellebene
geforderten idealisierten und vereinheitlichenden Dienstabstraktion ermoglicht.
Die Verarbeitungsebenestellt hierfur die Systemtechniken zur Verfugung, mit de-

46 Zugang zu Diensten in heterogenen Umgebungen
Diensttyp
Modellebene
Diensterbringer
ANSA
Verarbeitungsebene
Rechnerknoten
DCE
Betriebssystem-/Kommunikationsebene
CORBA
Abbildung 3.1: Betrachtungsebenen des Dienstzugangs
ren Hilfe Diensterbringer realisiert werden konnen und der Zugang eines Dienstnehmers
zu den von ihnen erbrachten Diensten ermoglicht wird. Hierbei ist
eine der wesentlichen Aufgaben derartiger Systemtechniken, die Interoperabilitat
der Dienstnehmer und der Diensterbringer zu unterstutzen. Sie bildet eine
Grundvoraussetzung fur eine wohlde nierte Dienstnutzung in o enen verteilten
Dienstemarkten.
Die Umsetzungvon auf Modellebene abstrakt betrachteten Diensttypen auf konkrete
Diensterbringer in der Verarbeitungsebene ist in der Abbildung durch
Pfeile zwischen der Modell{ und Verarbeitungsebene angedeutet. Grundannahme
dieser Umsetzung ist das Vorhandensein eines einheitlichen Dienstmodells
auf Modellebene, welches die abstrakte Sichtweise auf die in o enen verteilten
Dienstemarkten angebotenen Dienstleistungen festlegt. Prinzipiell kann die Umsetzung
eines abstrakten Diensttyps durch mehrere verschiedene Diensterbringer
realisiert sein, die auch auf der Grundlage verschiedener verteilter Systemplattformen,
beispielsweise ANSA, DCE und CORBA, entwickelt worden sind.
Die Diensttypen werden mit Hilfe der plattformspezi schen Ausdrucksmittel beschrieben,
die beispielsweise bei den drei genannten in Form von Schnittstellenbeschreibungssprachen
angeboten werden. Aufgrund moglicher eingeschrankter
Ausdrucksmoglichkeiten kann es hierbei unter Umstanden notwendig sein,
Erweiterungen der Beschreibungsmittel vorzunehmen, um beispielsweise die Beschreibung
von Dienstattributen hinzufugen zu konnen.
Ausgangslage fur die Realisierung verteilter Systemplattformen auf der Verarbeitungsebene
bildet die Betriebssystem{ und Kommunikationsebene. Sie bietet
neben den Betriebssystemdiensten vor allem die notwendige Kommunikationsinfrastruktur,
die die im o enen verteilten System vorhandenen Rechnerknoten
miteinander verknupft. Voraussetzung hierfur ist die Einigung auf gemeinsame
Kommunikationsprotokolle, wie sie beispielsweise durch dieMechanismen

3.1 Grundlegende Problemstellungen 47
des OSI{Referenzmodells [EF86] oder durch den " de{facto\{Standard TCP/IP
[Com88] bereitgestellt werden. Auf dieser Grundlage konnen anschlie end verteilte
Systemplattformen entwickelt werden, mit deren Hilfe die Diensterbringer
und Dienstnehmer entwickelt und auf die vorhandenen Rechnerknoten verteilt
werden konnen. Diese Verteilung ist in der Abbildung durch entsprechende von
der Verarbeitungsebene ausgehende Pfeile verdeutlicht.
3.1.1 Heterogenitat auf Verarbeitungsebene
Abbildung 3.2 zeigt eine verfeinerte Darstellung der Verarbeitungsebene.
Verwaltungsdomäne A
(CORBA)
Trader
Typmanager
Server
Interzeptor
Verwaltungsdomäne C
(DCE)
Server
Klient
Interzeptor
Trader
Verwaltungsdomäne B
(DCE)
Klient
Server
Typmanager
Typmanager
Trader
Abbildung 3.2: Heterogenitatsgrenzen beim Zugang zu Diensten
Hauptgesichtspunkt ist die Betrachtung unterschiedlicher Verwaltungs{
Domanen, die jeweils durch die in o enen verteilten Systemen agierenden
Organisationen de niert werden. Domanen konnen selbst wiederum Unterdomanen
besitzen, so da mit ihnen organisationelle und auch geographische
Strukturen widergespiegelt werden konnen 1 . Innerhalb der Domanen konnen
verschiedene Dienste angeboten werden, die sowohl von domaneninternen als
auch von domanenexternen Dienstnehmern in Anspruch genommen werden
konnen. In ihrer Gesamtheit bilden die angebotenen Dienste einen o enen
verteilten und domanenubergreifenden Dienstemarkt.
Als Konsequenz der Aufteilung o ener verteilter Dienstemarkte inverschiedene
1 Ein detailliert ausgefuhrtes Domanenkonzept unter Berucksichtigung dieser Aspekte ndet
sich beispielsweise in [Tsc94].

48 Zugang zu Diensten in heterogenen Umgebungen
Verwaltungsdomanen ergeben sich Heterogenitatsgrenzen beim domanen{ bzw.
plattformubergreifenden Dienstzugang, die sich inzwei grobe Heterogenitatskategorien
einordnen lassen:
1. Technische Heterogenitat
2. Administrative Heterogenitat
Beide Arten werden im folgenden zusammenfassendauch als organisationelle Heterogenitat
bezeichnet, da sichtechnische und administrative Unterschiede zumeist
als Konsequenz der unterschiedlichen Anforderungen der am Dienstmarkt
beteiligten Organisationen, beispielsweise Dienstleistungsunternehmen, ergeben.
Die in der Abbildung 3.2 grauschattierten Komponenten (Trader, Typmanager
und Interzeptor) deuten bereits auf konkrete, in dieser Arbeit entwickelte
Losungsansatze hin, mit denen ein weitgehend uneingeschrankter Dienstzugang
in o enen heterogenen verteilten Dienstemarkten erreicht werden kann.
Technische Heterogenitat Wie oben bereits angedeutet wurde, ist aufgrund
der Autonomie der beteiligten Organisationen davon auszugehen, da bei der
Realisierung o ener verteilter Dienstemarkte verschiedenartige verteilte Systemplattformen
zum Einsatz kommen. Welche verteilte Systemplattform dabei innerhalb
einer Verwaltungsdomane generell genutzt wird, hangt ma geblich von
den dort verfolgten Zielen ab, die beispielsweise eine bestimmte Plattform fur
die spezi schen Belange der jeweiligen Verwaltungsdomaneamgeeignetesten erscheinen
lassen.
Eine direkte Folgerung aus der Existenz unterschiedlicher verteilter Systemplattformen
ist eine technische Heterogenitat, die sichprimar durch die von den Plattformen
angebotenen unterschiedlichen Dienstaufrufmechanismen ergibt. Im allgemeinen
sind derartige Kommunikationsmechanismen, wie beispielsweise die
RPC{Mechanismen von ANSA, CORBA oder DCE, nicht zueinander kompatibel,
so da eine gegenseitige Dienstnutzung ohne weiteres plattformubergreifend
nicht moglich ist. Ebenso zeigen sich Unterschiede hinsichtlich der Ausfuhrungssemantik
von Operationsaufrufen, die sich ineinem unterschiedlichen Verhalten
beim Operationsaufruf auswirken konnen. Beispielsweise konnen Operationsaufrufe
nur einmal (engl. at{most{once semantics [CDK94]) oder bei Fehlschlagen
auch mehrfach wiederholt werden. Weitere technische Problemstellungen ergeben
sich auch aufgrund unterschiedlicher Adressierungsverfahren, mit denen
Diensterbringer angesprochen werden konnen.
Zur Uberwindungtechnischer Heterogenitatsgrenzen mussen zusatzlicheSystemtechniken
angeboten werden, die eine Abbildung der verschiedenartigen technischen
Aspekte der verteilten Systemplattformen untereinander erlauben. Hierdurch
wird es moglich, eine domanenubergreifende Dienstnutzung zu realisieren
und somit eine technische Interoperabilitat zu gewahrleisten.
Administrative Heterogenitat Zusatzlich zu den technischen Heterogenitatsgrenzen
sind au erdem administrative Heterogenitatsprobleme zuberuck-

3.1 Grundlegende Problemstellungen 49
sichtigen, die in engem Zusammenhang mit den im vorherigen Kapitel beschriebenen
Interoperabilitatsaspekten bei der Beschreibung von Diensten stehen. Die
Gewahrleistung der Interoperabilitat von Dienstnehmern und Diensterbringer in
o enen verteilten Dienstemarkten ist eine der Hauptaufgabenstellungen der Verarbeitungsebene.
Vollstandige Interoperabilitat la t sich hierbei nur durch Standardisierung
von Diensttypen erreichen, so da sowohl deren Syntax als auch
Semantik auf eindeutige Art und Weise von vornherein festgelegt ist. Aufgrund
der Dynamik o ener verteilter Dienstemarkte mit standig neu hinzukommenden
und sich andernden Diensttypen ist eine derartige globale Standardisierung jedoch
nur zum Teil fur bestimmte grundlegende Systemdienste oder bestimmte
Anwendungsbereiche sinnvoll durchfuhrbar. Generell ist deshalb davon auszugehen,
da vor der Nutzung von Diensten anderer Verwaltungsdomanen eine
Uberprufung erforderlich ist, mit der die Ubereinstimmung des vom Dienstnehmer
gewunschten und des von Diensterbringerseite angebotenen Diensttyps
durchgefuhrt wird. Als Grundlage hierfur dienen die Dienstbeschreibungen, die
mit den jeweiligen Beschreibungsmitteln der Realisierungsplattformen formuliert
sind. Bei der Uberprufung mussen gegebenfalls die unterschiedlichen Dienstbeschreibungen
aufeinander abgebildet werden. Aufgrund der in Abschnitt 2.4.5
beschriebenen Einschrankungen der Ausdrucksmachtigkeit von Dienstbeschreibungen
mussen sichautomatisierteVerfahren jedochauf die Untersuchung struktureller
Eigenschaften, insbesondere der Schnittstellensignaturen, beschranken,
da die semantische Ubereinstimmung von Diensten mit den heute verfugbaren
Methoden nicht uberpruft werden kann.
3.1.2 Dienstzugangsphasen
Bevor im folgenden die in der Abbildung 3.2 bereits angedeuteten Systemtechniken
zur Uberwindung der technischen und administrativen Heterogenitat genauer
vorgestelltwerden, ist die Unterscheidungverschiedener Dienstzugangsphasen
sinnvoll:
1. Diensttyp ndung,
2. Dienstauswahl und
3. Dienstzugri .
Diese Aufteilung ermoglicht es, den verschiedenen Phasen jeweils bestimmte
Ansatze zuzuordnen, die eine adaquate Losung der dortigen spezi schen Anforderungen
versprechen.
3.1.2.1 Au nden von Diensttypen
Voraussetzung fur jegliche Art von Dienstnutzung ist das Vorhandensein einer
Vorstellung uber die Art des Dienstes, der in einem bestimmten Anwendungskontext
verwendet werden soll. Wie konkret diese Vorstellung ausgepragt ist,

50 Zugang zu Diensten in heterogenen Umgebungen
d.h. ob bereits ein bestimmter Diensttyp gefordert oder ein passender Diensttyp
erst gefunden werden mu , hangt von der jeweiligen Anwendungssituation ab.
Ein insbesondere fur die vorliegende Arbeitinteressanter Anwendungsbereichist
der Entwurf und die Entwicklung verteilter Anwendungen, auf den in Kapitel
4noch genauer eingegangen wird. Initialer Schritt der Entwicklung verteilter
Anwendungen ist die Modularisierung der geplanten Anwendung inverschiedene
Problembereiche. Ziel dieser elementaren software{technischen Methodik [Par72]
ist, die vorhandene Komplexitat des Gesamtsystems derartig zu reduzieren, da
eine dedizierte Behandlung von Teilproblemen moglich ist.Fur diese Teilprobleme
konnen modulare Losungsansatze entworfen und entwickelt werden, die anschlie
end derartig miteinander kombiniert werden, da sie in Kooperation das
anwendungsspezi sche Gesamtproblem behandeln. Diese spezielle Sichtweise, die
von einigen Autoren auchalskomponentenbasiert bezeichnet wird [ND95, Ber95],
ndet sich auch indem in dieser Arbeit gewahlten Ansatz der Dienstmodellierung.
Die im vorherigen Kapitel vorgestellte objektbasierte Modellierung bietet
hierfur bereits diewesentlichen Voraussetzungen, um einemodul{ bzw. komponentenbasierte
Entwicklung verteilter Anwendungen durchfuhren zu konnen. So
konnen Dienste bzw. Diensttypen auch als Module oder Komponenten verstanden
werden, die zu neuen verteilten Anwendungen kombiniert werden konnen.
Dabei bestimmtder jeweilige Diensttyp bzw. die Dienstbeschreibung die Art und
Weise, wie ein Dienst dieses Diensttyps genutzt werden kann. Ein Hauptziel der
Entwicklung verteilter Anwendungen ist es, moglichst die in o enen verteilten
Dienstemarkten vorhandenen Diensttypen wiederzuverwenden, die bereits wesentliche
zur Realisierung der Gesamtanwendung nutzbare Teillosungsansatze
zur Verfugung stellen. Durch diesen dienstorientierten Ansatz kann eine hohe
E zienz bei der Softwareentwicklung erreicht werden. Idealvorstellung ist, die
Entwicklung und Realisierung von verteilten Anwendungen ausschlie lich unter
Nutzung extern angebotener Dienste durchzufuhren (siehe Abschnitt 4.1.1). Als
Konsequenz hieraus ergibt sich, da nicht mehr primar der Entwurf und die
Entwicklung neuer, anwendungsspezi scher Dienste imVordergrund der Anwendungsentwicklung
steht, sondern in zunehmenden Ma e die Koordination bestehender,
unter Umstanden standardisierter Anwendungsdienste inden Kern der
Betrachtungen ruckt.
Ein derartig dienstorientiertes Vorgehen erfordert die Unterstutzung durch systemtechnischeMechanismen,
sogenannte Diensttypmanager,dieinAbschnitt 3.2
vorgestellt werden. Ihre Funktion umfa t unter anderem auch die Unterstutzung
des Anwendungsentwicklers beim Au nden und der Auswahl der fur sein Anwendungsproblem
am besten geeigneten Diensttypen. Zur Abgrenzung zur anschlie
enden Phase der Dienstauswahl bzw. Dienstvermittlung (engl. trading), in
der konkrete diensttypkonforme Diensterbringer ermittelt werden, wird die Phase
der Diensttyp ndung deshalb auch als sogenanntes Meta{Trading [PB96] oder
Service Mediation [MML94a] bezeichnet. Kennzeichnend fur diese Phase ist vor
allem die interaktive Form der Dienstsuche, die in diesem Zusammenhang auch
oft als " Blattern\ (engl. browsing) bezeichnet wird.

3.1 Grundlegende Problemstellungen 51
3.1.2.2 Dienstauswahl
Nachdem ein geeigneter Diensttyp wahrend der Entwicklungssphase einer verteilten
Anwendung gefunden wurde, stellt sich die Frage nach Diensterbringern,
die einen entsprechenden Dienst zum Ausfuhrungszeitpunkt einer verteilten Anwendung
anbieten. Durch die Moglichkeiten der Konformitat von Diensttypen
konnen auch die Dienste mitberucksichtigt werden, die einem zum angegebenen
Diensttyp konformen Diensttyp besitzen. Da in o enen verteilten Dienstemarkten
unter Umstanden eine gro e Anzahl moglicher diensttypkonformer Diensterbringer
existieren kann, reicht der Diensttyp als alleiniges Suchkriterium im
allgemeinen nicht aus, um eineangemessene Dienstauswahl tre en zu konnen.
Erganzende Suchkriterien sind hierbei beispielsweise die statischen Dienstattribute,
deren Spezi kation Bestandteil des Diensttypkonzeptes ist. Mit ihnen lassen
sich die Diensterbringer nach ihren jeweiligen Eigenschaften unterscheiden,
beispielsweise in den Kosten pro Seite bei Druckdiensterbringern, so da die
Dienstauswahl durchAngabe gewunschter Dienstattributwertedurchden Dienstnehmer
naher eingegrenzt werden kann. Sie stellen jedochnur einen ersten Schritt
dar, um eineAuswahl des " am besten geeigneten\ Diensterbringers tre en zu
konnen. So wird beispielsweise nicht berucksichtigt, ob der Diensterbringer auch
tatsachlich verfugbar ist oder die momentane Auslastung eineAuswahl uberhaupt
sinnvoll erscheinen la t. Weitere Probleme bei der Dienstauswahl ergeben
sich auchaufgrundder moglichen Gro e verteilter Dienstemarkte, die zusatzliche
Strukturierungsmoglichkeiten zur Eingrenzungdes Suchraums erfordern. Eine integrierte
Behandlung dieser Problemstellungen ndet in Abschnitt 3.3 statt, wo
verschiedene Ansatze zur Dienstvermittlung in o enen verteilten Dienstemarkten
ausfuhrlich dargestellt werden.
3.1.2.3 Dienstzugri
Nachdem der Dienstnehmer Kenntnis uber einen geeigneten diensttypkonformen
Diensterbringer erhalten hat, mu vor dem eigentlichen Aufruf einer gewunschten
Operation eine Bindung zum Diensterbringer erfolgen, welche die kommunikationstechnischeVerknupfung
zwischen ihnen aufbaut. Diese Art von Bindung wird
in diesem Zusammenhangauch als spate Bindung bezeichnet, da sie erst zur Laufzeit
hergestellt wird und nicht beim Entwurf der Anwendung bereitsvorgegeben
ist. Bedingt durch diespate Bindung ergeben sich jedoch unter Umstanden Probleme
hinsichtlich der Interoperabilitat. So kann es beispielsweise durch Fehler
beim Dienstauswahlproze vorkommen, da eine Bindungzueinem Diensterbringer
eingegangen wird, der nicht diensttypkonform ist. Generell solltedeshalbauch
hier eine Uberprufung der Konformitat des vom Dienstnehmer gewunschten und
des vom Diensterbringer realisierten Diensttyps durchgefuhrt werden, um die
Typsicherheit der Interaktion zu gewahrleisten.
In heutigen verteilten Systemplattformen ndet in den meisten Fallen nur eine
einfache Uberprufung der Konformitat von Dienstnehmer und Diensterbringer
zum Bindungszeitpunkt statt. Zum Beispiel im Fall von DCE beschrankt
sich die Uberprufung auf die einfache Namensaquivalenz von Schnittstellentyp-

52 Zugang zu Diensten in heterogenen Umgebungen
namen, die jedoch | wie bereits imvorherigen Kapitel verdeutlicht wurde |
kein hinreichendes Kriterium fur die Interoperabilitat von Dienstnehmer und
Diensterbringer bieten, da wesentliche strukturelle Eigenschaften, beispielsweise
die Signaturen der Operationen, nicht berucksichtigt werden.
Nachdem alle obigen Vorbereitungsphasen abgeschlossen sind, kann die eigentliche
Nutzung der Dienstfunktionalitat an der operationalen Schnittstelle des
Diensterbringers statt nden. Dabei sollten bei jedem Operationsaufruf die Werte
fur die Eingabe{ und Ruckgabeparameter der entsprechenden Schnittstellenoperation
uberpruft werden, umeine Ubereinstimmungder Wertezuminder Dienstbeschreibung
de nierten Typ zu gewahrleisten. Je nach Typde nition kann beispielsweise
auch die Zugehorigkeit zu einem bestimmten Wertebereich nachgepruft
werden. Die Typ{ bzw. Wertuberprufung ist besonders dann interessant,
wenn der Operationsaufruf erst zur Laufzeit dynamisch erzeugt worden ist, wie
es beispielsweise durch Nutzung des sogenannten Dynamic Invocation Interface
(DII) von CORBA oder TRADE moglich ist. Hierbei eventuell auftretendeFehler
konnen ohne weitere Prufungen zur Laufzeit zumeist nur schwer entdeckt
werden und au ern sich zumeist in der fehlerhaften Ausfuhrung einer Operation.
Diese Aspekte gelten in eingeschranktem Ma e auch fur die RPC{basierten
Ansatze, die durch Generierung sogenannter Stubs Typfehler zumindest bei der
Anwendungsentwicklung eingrenzen. Wie derartige Typuberprufungen bei beiden
Varianten sowohl zum Zeitpunkt der Bindung als auch beim Operationsaufruf
durchgefuhrt werden konnen, wird in Abschnitt 3.2.2.7 genauer betrachtet.
Erfolgt der Dienstzugri dabei domanenubergreifend, so sind zusatzlich auch die
technischen und administrativen Heterogenitatsaspekte bei der Bindungunddem
Operationsaufruf zu berucksichtigen. Die hierfur notwendigen Unterstutzungsmechanismen,
die durch sogenannte Interzeptoren erbracht werden, betrachtet
Abschnitt 3.4.
3.2 Diensttypmanagement
Dienstbeschreibungen kommt eine bedeutende Rolle bei der Kooperation von
Dienstnehmern und Diensterbringern in verteilten Dienstemarkten zu. Sie bieten
die notwendigen Voraussetzungen, auf deren Grundlage Interoperabilitat und
somit auch Typsicherheit in den oben genannten Dienstzugangssphasen gewahrleistet
werden kann. Auf dem Hintergrund dieser elementaren Bedeutung von
Dienstbeschreibungen stellt sich die Frage nach geeigneten Systemtechniken,
welche eine adaquate Unterstutzung zur Verwaltung von Dienstbeschreibungen
bereitstellen. Die Verwaltung umfa t dabei verschiedene Aufgabenstellungen,
die von der strukturierten Speicherung von Dienstbeschreibungen, insbesondere
Diensttypbeschreibungen, bis hin zu Typvergleichen reichen, mit deren
Hilfe beispielsweise wahrend der Phase der Dienstauswahl diensttypkonforme
Diensterbringer gefunden werden konnen. In der Literatur wird diese Art von
Verwaltung imRahmen verteilter Systeme im allgemeinen als Typmanagement
[ODP95c, IBR93] bezeichnet. In Anwendung auf die in dieser Arbeit speziell betrachteten
Diensttypen wird im folgenden auch alternativ der Begri des Dienst-

3.2 Diensttypmanagement 53
typmanagements verwendet (siehe auch [CM95]). Konkrete Systemkomponenten
werden entsprechend als sogenannte Typmanager [CM95, IBR93] oder Typrepositories
[ODP95c, ISO95] genannt.
In der aktuellen Forschung ist die Thematik des Typmanagementsino enen verteilten
Systemen zumeist eng mit der Betrachtung von Dienstvermittlungskomponenten,
den Tradern, verknupft, die als wichtige Klienten eines Typmanagers
gesehen werden und einen wesentlichen Ein u auf die Entwicklung von Typmanagementkomponenten
ausuben. Diese Beein u ung zeigtsich insbesondere
in den in [IBR93] beschriebenen Ansatzen, in denen erste Vorschlage fur eine
mogliche Grundfunktionalitat einer Typmanagementkomponente untersucht
werden, wobei Typmanagement vor allem unter dem Gesichtspunkt der Unterstutzung
des ODP{Traders [ODP95a] untersucht wird. Die Ergebnisse der
dort durchgefuhrten Untersuchungen lassen sich jedoch auchunabhangig von der
spezi schen Betrachtung von Dienstvermittlungskomponenten zur Entwicklung
weitgehend generischer Typverwaltungsmechanismen fur verteilte Dienstemarkte
verwenden. Weitere Beispiele fur diese enge Betrachtung von Trading und
Typmanagement sindunter anderem in [BR92b] und [PB96] zu nden. Auch
in der internationalen Standardisierung imRahmen des ODP{Referenzmodells
wird Typmanagement zur Zeit noch primar im Zusammenhang mit der ODP{
Trading{Funktion [ODP95a] betrachtet. Erst vor kurzem sind dort neuere Arbeiten
begonnen worden, die Typmanagement als eigenstandiges Themengebiet
behandeln [ISO94, ISO95].
Im folgenden wird Typmanagement als eine anwendungsunabhangige, generische
Systemfunktion gesehen, die von zahlreichen in o enen verteilten Systemen
vorhandenen Komponenten genutzt und zur Losung deren spezi schen Problemstellungen
eingesetzt werden kann (siehe Abbildung 3.3).
Typmanager
Trader Browser Interzeptor Typmanager ...
Abbildung 3.3:Mogliche Klienten eines Typmanagers
So sind neben den genannten Tradern auch graphische Suchwerkzeuge (Browser)
potentielle Klienten eines Typmanagements, die im Rahmen von Software{
Entwicklungs{Frameworks bzw. CASE{Tools [Ber95] angeboten werden, um
beispielsweise den Programmierer in der Phase der Diensttyp ndung zuunterstutzen.
Ein anderes Beispiel sind die oben bereits genannten Interzeptoren,
die die Funktionen des Typmanagements als eine wesentliche Unterstutzungsfunktion
zur Uberwindung der Heterogenitat benotigen. Weitere wichtige Klienten
von Typmanagern sind auch andere Typmanager, die beispielsweise zur

54 Zugang zu Diensten in heterogenen Umgebungen
Unterstutzung einer domanenubergreifenden Dienstnutzung miteinander interagieren
mussen.
3.2.1 Typmanagement in heutigen verteilten Systemplattformen
Die Entwicklung dedizierter Managementkomponenten zur Verwaltung von
Dienstbeschreibungen in o enen verteilten Systemen be ndet sich gegenwartig
erst in ihren Anfangen. So verfugen die heutigen verteilten Systemplattformen
zumeist uber gar keine Systemkomponenten zur Unterstutzung von
Typmanagement, beispielsweise DCE und ILU, oder nur uber einfache Typverwaltungskonzepte,
wie beispielsweise das Schnittstellenrepository in CORBA
oder die namensbasierte Verwaltung von Diensttypen in ANSA. Beide werden
im folgenden kurz beschrieben.
3.2.1.1 Schnittstellenrepository in CORBA
Das Schnittstellenrepository (engl. interface repository) ist ein Basisdienst der
Common Object Request Broker Architecture (CORBA) [OMG91]. Es bietet
einen Ablagedienst (engl. repository) fur Schnittstellentypbeschreibungen, die
von den Anwendungsentwicklern mit Hilfe der CORBA{spezi schen Schnittstellenbescheibungssprache
dargestellt werden. Die Ablage erfolgt dabei durch fest
vorgegebene Strukturierungskriterien, die sich aus den syntaktischen Regeln der
Erstellung von Schnittstellentypbeschreibungen ergeben. So werden hier unter
anderem Module, Schnittstellen, Operationen, Attribute und Datentypen unterschieden.
Hierbei bildet das Repository die oberste Strukturierungseinheit, in
der unter anderem Datentypen und Schnittstellen sowie Module de niert werden
konnen. Die dort de nierten Module setzen sich selbst wiederum aus verschiedenen
Typde nitionen zusammen. Unterste Ebenebilden die Schnittstellen, die
auch die De nition von Operationen umfassen. Hierdurch bedingt ergibt sicheine
hierarchische Struktur, die die Sichtbarkeitsbereiche von Typde nitionen widerspiegelt.
Abbildung 3.4 verdeutlicht die Beziehungen der Strukturierungseinheiten
untereinander. Eine Einschrankungdes Schnittstellenrepositories ist, da sich
die in der CORBA{Spezi kation de nierte Zugri sschnittstelle ausschlie lich auf
Funktionen zum Lesen der dort gespeicherten Typinformationen beschrankt. Die
Art undWeise, wie die Schnittstellenbeschreibungen im Repository abgelegt werden,
wird den jeweiligen CORBA{Implementierungen uberlassen und wird nicht
weiter spezi ziert. Prinzipiell ergibt sich die Einordnung einer Typbeschreibung
durch den explizit vom Programmierer gewahlten Typnamen, der die Zuordnung
ineinen bestimmten durch Modul{ und Schnittstellende nitionen vorgegebenen
Typsichtbarkeitsbereich bestimmt. So kennzeichnet beispielsweise der Name
iwt module::trader interface::ServicePropertyOfInterestType einen
Datentyp ServicePropertyOfInterestType innerhalb des Schnittstellentyps
trader interface, der selbst innerhalb des Moduls iwt module de niert ist.
Der gesamte Name ist im Repository eindeutig, wobei es prinzipiell moglich ist,
Teile dieser Namen, beispielsweise trader interface,auchinanderen Modulen

3.2 Diensttypmanagement 55
Repository
ModuleDef
InterfaceDef
OperationDef
ExceptionDef ConstantDef
InterfaceDef TypedefDef
ConstantDef
TypedefDef
ExceptionDef ModuleDef
TypedefDef
ConstantDef
ExceptionDef
ParameterDef
AttributeDef
ExceptionDef
Abbildung 3.4: Hierarchie von Typde nitionen im CORBA{Schnittstellenrepository
wiederzuverwenden.
Eine der moglichen Aufgaben des Schnittstellenrepositories ist unter anderem
die Unterstutzung der dynamischen Dienstaufrufschnittstelle. Dieser als sogenannter
Dynamic Invocation Interface (DII) bezeichnete Mechanismus erlaubt
die Konstruktion von Operationsaufrufen zur Laufzeit, mit dem Anfragen (engl.
requests) durch Zusammenfugen von Operationsnamen, Operationsparametern
und Platzhaltern fur Ruckgabeparameter und Fehlermeldungen erzeugt und an
den Diensterbringer uber den Object Request Broker (ORB) geschickt werden
konnen. Hierbei kann dann der ORB die Lesefunktionen des Schnittstellenrepositories
nutzen, um die notwendigen Schnittstellentypinformationen zu erhalten,
die fur eine Uberprufung der Korrektheit des konstruierten Aufrufs notwendig
sind 2 . Die eigentliche Uberprufung erfolgt dann durch den ORB auf der Grundlage
der entsprechenden zum Aufruf gehorigen Operationssignatur.
Das CORBA{Schnittstellenrepository stellt einen ersten Ansatz fur Diensttypmanagement
inverteilten Systemen dar, wobei sich die Aufgaben hauptsachlich
auf die Speicherungsaspekte von Dienstbeschreibungen konzentrieren und ausschlie
lich Funktionen zum Lesenund zumNavigieren angeboten werden.
3.2.1.2 Typverwaltung in ANSA
Ein zum CORBA{Schnittstellenrepository ahnlicher Ansatz ndet sich in ANSA
[Mar91]inForm einer mit TrType bezeichneten Typmanagementschnittstelle, die
als eine von insgesamt vier Schnittstellen von dem dortigen Trader angeboten
wird. Diese Schnittstelle bietet hierbei unter anderem verschiedene Operationen
zum Einfugen, Loschen und Au isten von namensbasierten Diensttypbeschreibungen.
Die interne Verwaltung der Diensttypnamen erfolgt dabei als direkter
2 Die CORBA{Spezi kation [OMG91] legt den Gebrauch des Schnittstellenrepositories beim
DII jedoch nicht zwingend fest.

56 Zugang zu Diensten in heterogenen Umgebungen
Diensttypname
Diensttypname
Diensttypname
Diensttypname
Diensttypname
Abbildung 3.5: Namensbasierter Diensttypgraph in ANSA
azyklischer Graph, den Diensttypgraph (Abbildung 3.5), der die hierarchische
Subtypbeziehungen zwischen den Diensttypen widerspiegelt. Da deren Verwaltung
ausschlie lich auf der Grundlage von Namen durchgefuhrt wird, mu beim
Einfugen neuer Diensttypen die Menge aller Supertypen explizit angegeben werden.
Eine grundsatzliche Problematik ist hierbei, da die Korrektheit der vom
Programmierer spezi zierten Einordnungaufgrundder Einschrankungen von Namen
nicht uberpruft werden kann. So kann es unter Umstanden durch die Denition
fehlerhafter Typbeziehungen auch zur Mehrfachverwendung von Namen
kommen, sofern nicht vorab einfache Uberprufungsmechanismen durchgefuhrt
werden, die die Eindeutigkeit der vom Programmierer vorgegebenen Namen sicherstellen.
Ebenso wie bei CORBA basiert die Subtypbeziehung inANSAauf
dem Prinzip der in Abschnitt 2.3.2 dargestellten Schnittstellentypkonformitat,
wobei bei beiden sich die Konformitat auf das Hinzufugen von neuen Operationen
zu einer bestehenden Schnittstelle beschrankt und vorhandene Operationssignaturen
nicht nach den Ko{ bzw. Kontravarianzregeln verandert werden
durfen.
Anwendung ndet die TrType{Typmanagementschnittstelle hauptsachlich beim
Suchen nach konformen Diensttypen, die mit Hilfe der Operation zum Au isten
der Diensttyphierachie ermittelt werden konnen. Dabei erhalt der Suchende den
gesamten Subtypbaum zuruck, der dann selbstandig ausgewertet werden mu .
Wie beim CORBA{Schnittstellenrepository ubernimmtauch hier die Typmanagementfunktion
hauptsachlich dieAufgabe der strukturierten Speicherung von
Typinformationen, die hier jedoch nur aus einfachen Namen bestehen.
3.2.2 Aufgaben des Diensttypmanagements
Die obigen beiden Beispiele verdeutlichen die ersten Anforderungen an Typmanagement
inverteilten Systemen. So umfa t die Aufgabe des Typmanagements
zumindest die dort beschriebene, strukturierte Ablage von Dienstbeschreibungen
bzw. Diensttypbeschreibungen. Hierdurch ist es dann moglich, strukturiert
auf Typinformationen von vorhandenen Dienstbeschreibungen zuzugreifen, wobei
im obigen Fall nur CORBA den Zugri auf die Operationssignaturen der

3.2 Diensttypmanagement 57
Schnittstellentypen erlaubt, wahrend hingegen ANSA nur einfache Namen von
Diensttypen verwaltet. Ebenso sollten die Beziehungen zwischen Diensttypen
verwaltet werden konnen, wobei im Fall von ANSA ausschlie lich Subtypbeziehungen
berucksichtigt werden. Im CORBA{Schnittstellenrepository spiegeln
sich die Subtypbeziehungen im allgemeinen nicht durch die hierarchische Struktur
wider, da beispielsweise bei Schnittstellende nitionen auch auf De nitionen
von Schnittstellen in anderen Modulen verwiesen werden kann.
Einschrankungen beider Ansatze zeigen sichunter anderem beim Einfugen neuer
Diensttypen bzw. Dienstbeschreibungen. Wahrend bei CORBA diese Funktionalitat
zum gegenwartigen Zeitpunkt nicht spezi ziert ist, mu bei ANSA eine
explizite Einordnung des neuen Diensttyps in den vorhandenen Diensttypgraphen
vorgenommen werden, da bedingt durch die geringe Ausdrucksmachtigkeit
von Namen ein systemgesteuertes Einfugen nicht moglich ist. Eine weitere
wesentliche Einschrankung beider Ansatze ist auch, da Heterogenitatsaspekte,
die sich beispielsweise bei der Kooperation mit anderen Verwaltungsbereichen
ergeben, nicht ausreichend berucksichtigt werden. Zwar wird durch die Lese{
Schnittstelle des CORBA{Schnittstellenrepositories ein sogenanntes Container{
Objekt [OMG91] als Transferformat fur Schnittstellentypbeschreibungen de -
niert, so existieren jedoch keine weiteren Mechanismen, die einen Vergleich zweier
derartiger Dienstreprasentationen (siehe Abschnitt 2.1) erlauben. Im Fall von
ANSA ist der Austauschvon Typinformationen im Prinzip auch moglich, so sind
diese jedoch aufgrund der geringen Ausdrucksmachtigkeit von Namen nur eingeschrankt
nutzbar.
Auf dem Hintergrundder einfachen Typverwaltungsmechanismen von ANSA und
CORBA sollen im folgenden grundlegende Aufgaben des Typmanagements in
o enen verteilten Dienstemarkten herausgearbeitet werden, wobei insbesondere
die Verwaltung von Diensttypen im Vordergrund der Betrachtung steht.
3.2.2.1 Anforderungen an Dienstbeschreibungen
Die von einem Typmanager verwaltbaren Dienstbeschreibungen sollten zumindest
die Beschreibung der Schnittstellentypen mit ihren Operationssignaturen
umfassen, die die grundlegenden Informationen fur einetypsichere Dienstnutzung
darstellen. Zusatzlich zu diesen strukturellen Aspekten ist auch die Semantik eines
Dienstes genauer zu beschreiben, die Aufschlu uber die Art der erbrachten
Dienstleistung gibt. Welche Beschreibungsmittel konkret gewahlt werden, hangt
unter anderem davon ab, fur welche Zwecke die in der Dienstbeschreibung vorhandenen
Informationen verwendet werden sollen.
Wie bereits inder Bewertung verschiedener Ansatze von Dienstbeschreibungen
im vorherigen Kapitel deutlich wurde, ist ein wichtiger Aspekt der der Automatisierbarkeit
von Typuberprufungen und Typvergleichen. Automatisierbarkeit ist
insbesondere fur diejenigen verteilten Anwendungen von Wichtigkeit, bei denen
die Interaktionen zwischen den Dienstnehmern und den Diensterbringern hochgradig
autonom ablaufen, ohne da Eingri e eines Benutzers, beispielsweise bei
der Dienstauswahl, erforderlich sind. Hierbei mussen unter anderem Typverglei-

58 Zugang zu Diensten in heterogenen Umgebungen
[Diensttypname]
Diensttypbeschreibung
[Schnittstellentypname]
Operationsname Parametertyp Parametertyp
Operationsname Parametertyp Parametertyp
... ... ...
( + Beschreibung der Semantik jeder Operation)
( + Beschreibung der Semantik der Schnittstelle)
Attributname Attributtyp
Attributname Attributtyp
... ...
...
...
...
Abbildung 3.6: Bestandteile einer Diensttypbeschreibung
che und {uberprufungen in den Phasen der Dienstauswahl, der Bindung und des
Operationsaufrufs automatisch durch die Infrastruktur vorgenommen werden,
um die Interoperabilitat bzw. Typsicherheit von Dienstnehmer und Diensterbringer
gewahrleisten zu konnen. In diesen Phasen sind beispielsweise verhaltensbeschreibende
Dienstbeschreibungsformen, wie in Abschnitt 2.4.4 gezeigt wurde,
nicht oder nur sehr eingeschrankt fur derartig autonom ablaufende Systemmechanismen
zu verwenden.
Einen geeigneten Losungsansatz zur Erfullung der Anforderung nach Automatisierbarkeit
bieten zum gegenwartigen Zeitpunkt die Dienstattribute, mit denen
die charakteristischen Eigenschaften von Diensten auf einfache Art undWeise beschrieben
werden konnen. Sie stellen einen geeigneten Kompromi zwischen der
automatisierten Uberprufung und Vergleichbarkeit auf der einen und der eingeschrankten
Ausdrucksmachtigkeit auf der anderen Seite dar. Dieser Ansatz wird
deshalb auch inder vorliegenden Arbeit verfolgt. Im folgenden werden Dienstbeschreibungen
aus diesem GrundauchalsDiensttypbeschreibungen bezeichnet, um
explizit auf den Diensttypbegri Bezug zu nehmen, der in Abschnitt 2.3.1 de -
niert ist. Eine Diensttypbeschreibung besteht somit aus der Spezi kation der operationalen
Schnittstelle und der Dienstattribute. Sie kann erganzt werden durch
zusatzliche semantische Beschreibungen, beispielsweise informelle textuelle Anmerkungen
oder formale Verhaltenbeschreibungen in Form von Protokollspezi -
kationen, die jedoch bei automatischen Typvergleichen und Typuberprufungen
nicht weiter verwendet werden. Die Bestandteile einer Diensttypbeschreibung
sind inAbbildung 3.6 zusammenfassend dargestellt.
3.2.2.2 Arten von Typbeziehungen
Aus Grunden der Flexibilitat und Erweiterbarkeit sollte ein Typmanager die Verwaltung
beliebiger Arten von Beziehungen (engl. relations) erlauben. Hierdurch

3.2 Diensttypmanagement 59
lassen sich fur verschiedene Anwendungsbereiche jeweils spezielle Beziehungen
de nieren, die den dortigen Anforderungen am besten gerecht werden. Zum Beispiel
ist es bei der Software{Entwicklung oftmals sinnvoll, die Zusammengehorigkeit
verschiedener Diensttypen auszudrucken, die bezuglich ihrer Dienstsemantik
an sich nicht inBeziehung stehen. Eine solche Beziehung konnte beispielsweise
lauten: " Die DiensttypenAund Bstehen in Beziehung, da sie im selben
Software{Projekt verwendet werden\. In diesem Zusammenhangware auch eine
Beziehung sinnvoll, die Versionsbeziehungen zwischen verschiedenen Diensttypen
ausdruckt, um deren Weiterentwicklung beim Software{Entwicklungsproze zu
dokumentieren. Dabei mussen die Diensttypen nicht unbedingt in einer Konformitatsbeziehung
stehen.
Auch sollten Beziehungen, die zum Zeitpunkt der Entwicklungdes Typmanagers
noch nicht bekannt waren, nachtraglich de niert werden konnen. Grundsatzlich
sollte auch moglich sein, bereits vorhandene De nitionen von Beziehungen
zu verandern, um beispielsweise die dort beschriebenen Anforderungen zu
verscharfen, die festlegen, ob zwei Typen in Beziehung stehen oder nicht.
Generell lassen sich zwei Arten von Beziehungen unterscheiden:
1. Durch Instanzen de nierte Beziehungen:
Ein Beispiel hierfur ist die obige Beziehung bei der Software{Entwicklung.
Sie kennzeichnet eine " semantische\ Beziehung zwischen Diensttypen, fur
die im allgemeinen keine expliziten Regeln angegeben werden konnen, die
systemseitig fur ein automatisches Einfugen neuer Diensttypen genutzt
werden konnen. Dadurch ist es erforderlich, neue Diensttypen durch administrative
Tatigkeiten mit vorhandenen Diensttypen explizit in Beziehung
zu setzen.
Ein anderes Beispiel fur durch Instanzen de nierteBeziehungen ist auch die
oben dargestellte Subtypbeziehung in ANSA, die ebenfalls explizit durch
administrative Tatigkeiten verwaltet werden mu . Obwohl prinzipiell automatische
Verfahren fur die dort verwendete Beziehung existieren (siehe
beispielsweise die in [NS95] oder [AC91] beschriebenen Algorithmen), ist
dieses in ANSA nicht moglich, da dort ausschlie lich Diensttypnamen fur
die Beschreibung von Diensttypen verwendet werden.
2. Durch De nitionsregeln de nierte Beziehungen
Sie ermoglichen im Gegensatz zu den durch Instanzen de nierten Beziehungen
eine automatische, systemgesteuerte Vergleichbarkeit von Diensttypen.
Hierfur sind inder Beziehungsbeschreibung entsprechende De nitionsregeln
auzugeben, auf deren Grundlage der Typmanager automatisch
Typbeschreibungen einordnen, vergleichen und uberprufen kann.
Ein Beispiel hierfur sind die in der Konformitatsbeziehung de nierten Regeln,
die in Abschnitt 2.3.2 informell dargestellt wurden.
Formalisierung von Beziehungen Beziehungen konnen formal durch Beziehungstypen
beschrieben und somit in Analogie zu Diensten als Typen behandelt

60 Zugang zu Diensten in heterogenen Umgebungen
werden. Dieser Ansatz ndet sich unter anderem im ISO General Relationship
Model [ISO] und dem CORBA Object Relationship Service, der Bestandteil der
Common Object Services Speci cations (COSS) [Gro94] ist. Im folgenden soll
speziell eine in Anlehnung an [BIBY95] gewahlte Darstellung von Beziehungstypen
verwendet werden, die auf dem obigen Modell der ISO aufbaut und mit
Hilfe der objektorientierten Spezi kationssprache Z [Spi89] de niert wird. Einen
zusammenfassenden Uberblick uber Beziehungstypen zeigt Abbildung 3.7.
Beziehungstyp
Charakteristika
Definitionsregeln
Rolle
Name
Typ
...
Rolle
Kardinalität
gefordert erlaubt
Rolle
Homogener binärer Beziehungstyp
Charakteristika
Definitionsregeln
Rolle 1
DT-1
Typ-A
Rolle 2
DT-2
Typ-A
Abbildung 3.7: Struktureller Aufbau von Beziehungstypen
Beziehungen werden ebenso wie andere Typen als eine bestimmte Typart (engl.
type kind) [Car89] verstanden.
Type Defn
kind : TypeKind
TypeKind ::= Datatype | Operation | Interface
| Relationship | Service| ... (andere Typen)
Ein Beziehungstyp setzt sich aus einem syntaktischen und einem semantischen
Teil zusammen. Die syntaktischen Aspekte von Beziehungen werden durch sogenannte
Rollen ausgedruckt. Jede Rolle modelliert einen Beteiligten einer Beziehung
und hat einen Namen, einen Rollentyp und eine geforderte und erlaubte
Kardinalitat. Die erforderte Kardinalitat legt die minimale Anzahl anderer Teilnehmer
der Beziehung fest,wohingegen die erlaubte Kardinalitat die maximale
Teilnehmeranzahl einschrankt. Zusatzlich ist mit jeder Rolle eine semantische
Beschreibung verknupft, die hier jedoch nicht dargestellt ist.

3.2 Diensttypmanagement 61
RoleSignature
rolename : Name
roletype : TypeId
required_cardinality : N
permitted_cardinality : N
(N = Menge der natürlichen Zahlen)
Der semantische Teil eines Beziehungstyps setzt sich aus zwei Teilaspekten zusammen.
Er beinhaltet zum einen die Beschreibung der Charakteristika einer
Beziehung und zumzweiten die oben bereits genannten De nitionsregeln, mit
deren Hilfe die Zugehorigkeit zu einer Beziehung bestimmt werden kann. Charakteristika,diefur
samtliche Beziehungstypen anwendbar sind, umfassen unter
anderem die Art und Weise, wie Rollen aus einer Beziehung geloscht werden, ob
beispielsweise andere Rollen ebenfalls geloscht oder freigegeben werden mussen.
RelationshipSignature
TypeDefn
roles : F RoleSignature
delete_all_in_roles : RoleSignature --> F RoleSignature
release_all_in_roles : RoleSignature --> F RoleSignature
only_if_none_in_roles : RoleSignature --> F RoleSignature
kind = Relationship
#roles > 0
dom delete_all_in_roles roles ran delete_all_in_roles roles
dom release_all_in_roles roles ran release_all_in_roles roles
dom only_if_none_in_roles roles ran only_if_none_in_roles roles
Ein Spezialfall sind die nachfolgend gezeigten homogenen, binaren Beziehungen.
Sie sind dadurch gekennzeichnet, da sie aus genau zwei Rollen mit demselben
Rollentyp bestehen. Ihnen konnen zusatzliche Charakteristika zugeordnet
werden, die beispielsweise Aussagen uber die Re exivitat, Antisymmetrie oder
Transitivitat der Beziehung liefern. Ein Beispiel einer homogenen binaren Beziehung
ist die Konformitatsbeziehung, die jeweils Instanzen desselben Typs,
beispielsweise Dienstattribut{ und Operationstypen, in Beziehung setzt. Neben
den drei oben genannten Charakteristika ist ein weiteres Charakteristikumauch
der Hinweis darauf, da beim Einfugen eines Diensttyps in eine Konformitatsbeziehung
die Zugehorigkeit automatisch uberpruft werden kann (typematching
: B). Die Uberprufung durch den Typmanager erfolgt dabei auf der Grundlage
der mit der Beziehung assoziierten De nitionsregeln.

62 Zugang zu Diensten in heterogenen Umgebungen
BinaryRelationshipSignature
RelationshipSignature
R : Reflexivity ::= Reflexive | Irreflexive | Antireflexive
S : Symmetry ::= Symmetric | Asymmetric | Antisymmetric
T : Transitivity ::= Transitive | Intransitive | Antitransitive
type_matching : B
#roles = 2
r1, r2 . roles
r1 = r2 r1.roletype = r2.roletype
Generell sollten beim Einfugen neuer Typen in eine Beziehung die dort de -
nierten Charakteristika uberpruft werden. Kann diese Uberprufung jedoch, im
Gegensatz beispielsweise zur Konformitatsbeziehung, nicht automatisch durch
den Typmanager ausgefuhrt werden, ist es sinnvoll, die Entscheidung dem Administrator
zu ubergeben, der dann aufgrund der De nitionsregeln selbst eine
Beurteilung abgeben und die Beziehung der neuen Instanz explizit angeben mu .
Ein Beispiel fur eine derartige, durch Instanzen de nierte 3 Beziehung ist die in
Abschnitt 2.4.4.1 vorgestellte Interaktionskonformitat, die auf der Grundlage erweiterter
endlicher Transitionssystem de niert ist. Automatische Vergleiche von
Dienstbeschreibungen sind dort nur bei relativ einfachen Spezi kationen moglich,
so da bei komplexen Transitionssystemen im allgemeinen eine explizite administrative
Unterstutzung notwendig ist. Grundsatzlich sollten dem Benutzer geeignete
Werkzeuge, beispielsweise Browser, angeboten werden, die ihn in seinen
Entscheidungsprozessen e ektiv unterstutzen.
Zusammenfassend ergibt sich, da die Automatisierbarkeit beim Einfugen neuer
Dienstbeschreibungen zum einen von dem Beziehungstyp und zumanderen
von der Form der Dienstbeschreibung abhangt. Beziehungstyp und Dienstbeschreibung
mussen dabei derartig aufeinander abgestimmt sein, da die Dienstbeschreibungallewesentlichen
Beschreibungselementebeinhaltet, die fur die Anwendung
der im Beziehungstyp beschriebenen De nitionsregeln notwendig sind.
In Anwendungauf die Konformitatsregeln bedeutet dies, da die Dienstbeschreibung
zumindest die in Abbildung 3.6 dargestellten strukturellen Informationen
des Dienst{ und Schnittstellentyps umfassen mu . Einfache Namen, wie im Beispiel
von ANSA, sind hierfur nicht ausreichend.
3 Auch durch Instanzen de nierte Beziehungen konnen wie in diesem Fall De nitionsregeln
besitzen. Ausschlaggebend ist jedoch, ob diese fur ein vollstandig automatisches Uberprufungsverfahren
geeignet sind.

3.2 Diensttypmanagement 63
3.2.2.3 Ablage von Beziehungen und Typen
Durch die obige Betrachtungvon Dienst{ und Beziehungstypen wird eine orthogonale
Behandlung von Dienst{ und Beziehungsbeschreibungen im Typmanager
moglich. Insofern erscheint es sinnvoll, beide Typarten durch den Typmanager
integriert verwalten zu lassen. Zu diesem Zweck wird deshalb in [BIBY95]
eine separate Speicherungskomponente, das sogenannte Typrepository oder Typbeschreibungsrepository,
zur Ablage von Dienst{ und Beziehungstypen vorgeschlagen.
Zusatzlichund hiervon getrenntwerden in einer anderen Speicherungskomponente,
dem Beziehungsrepository (engl. relationship repository), konkrete
Instanzen von solchen Beziehungen zwischen Typen gespeichert. Abbildung 3.8
verdeutlicht die Zusammenhange zwischen beiden Arten von Repositories.
Typbezeichner1 Typbezeichner2
Instanzbezeichner
Typbeschreibung
Beziehungstypbeschreibung
Typbeschreibungs-Repository
Rolle
Beziehungsinstanz
Beziehungs-Repository
Abbildung 3.8:Verwaltung von Typen und Instanzen
Eine Beziehungsinstanz verweist auf ihre eigene Typbeschreibung, die im Typbeschreibungsrepository
verwaltet wird. Dies gilt auch fur alle an der Beziehung
beteiligten Rollen, die ebenfalls auf ihre jeweiligen Typbeschreibungen verweisen.
Typbeschreibungen konnen auchmehrfach referenziert werden, beispielsweise innerhalb
verschiedener Beziehungsinstanzen oder anderen Typbeschreibungen.
3.2.2.4 Typbezeichner und Aliasnamen
Jede Typbeschreibung imTypbeschreibungsrepository wird durch einen Typbezeichner
identi ziert, der innerhalb des Typbeschreibungsrepositories eindeutig
ist. In der Abbildung sind diese Verweise durch Pfeile gekennzeichnet. Analog
hierzu kennzeichnen entsprechende eindeutige Instanzbezeichner konkrete Beziehungsinstanzen
im Beziehungsrepository.
Um die Eindeutigkeit von Typbezeichnern sicherzustellen ist deren automatische
Generierung sinnvoll. Ein Beispiel sind die UUIDs (universial unique
identi er) in DCE, die bei der Untersuchung namensbasierter Dienstbeschreibungen
in Abschnitt 2.4.1 vorgestellt worden sind. Sie dienen innerhalb
von DCE unter anderem zur eindeutigen Benennung von Schnittstellentypen.
Sie werden durch ein spezielles Programmierwerkzeug uuid gen

64 Zugang zu Diensten in heterogenen Umgebungen
[OSF93a] als textuelle Reprasentation erzeugt. Ein Beispiel einer UUID ist
0081f128-a244-10b5-99d0-08005a921930.
Um den Umgang mitderartigen, fur den Programmierer unhandlichen und " bedeutungslosen\
Bezeichnern zu vereinfachen, ist zusatzlich dieVerwaltung von
Aliasnamen sinnvoll, die auf die UUIDs abgebildet werden. Hierdurch wird es
moglich, Typbezeichner exibel an bestimmteAnwendungsbereiche anzupassen,
um den Verwendungszweck eines Typs besser zu verdeutlichen. Ihre Eindeutigkeit
mu jedoch weiterhin sichergestellt werden.
Generell kann das Konzept der Aliasnamen alternativ auch als eine homogene,
binare, durch Instanzen de nierte Aquivalenzbeziehung angesehen werden, die jeweils
zwei unterschiedlich benannte Typen explizit in Beziehung stellt. Sie wird
in anderen Arbeiten deshalb auch als Renaming [LW93] bezeichnet. Aquivalenzbeziehungen
spielen insbesondere zur Erhohung der Flexibilitat beim Vergleich
von Typen eine wichtige Rolle. Mit ihnen konnen beispielsweise Diensttypen verglichen
werden, die sich nur in der Benennung der Operationen unterscheiden,
ansonsten aber syntaktisch und semantisch konform zueinander sind.
3.2.2.5 Typverwaltungsdomanen
Bedingt durch die gro e Anzahl von Typbezeichnern und Aliasnamen ist der Zugri
auf die im Typmanager abgelegten Informationen fur den Programmierer im
allgemeinen zu unubersichtlich. Aus diesem Grund ist die Einfuhrung lokaler Verwaltungsdomanen
ahnlich der am Anfang dieses Kapitels eingefuhrten sinnvoll,
die eine Strukturierung von Typinformationen nach organisatorischen Gesichtspunkten
erlauben. Beispielsweise konnteeine Domanesamtliche Diensttyp{ oder
Beziehungstypbeschreibungen eines bestimmten Software{Projektes umfassen,
so da von den Projektteilnehmern e zient auf die Typbeschreibungen zugegriffen
werden kann.
Einemogliche Realisierung eines derartigen Domanenkonzeptes sind die oben genannten
Module im CORBA{Schnittstellenrepository, die neben der Strukturierung
gleichzeitig auch Typsichtbarkeitsbereichede nieren, mit denen die jeweilige
Domanenachau en hin abgegrenzt wird. Inwieweit generell die Zugehorigkeit
eines Typbezeichners zu einer bestimmten Domane auch deren Sichtbarkeit einschranken
sollte, hangt von den beabsichtigten Zielstellungen eines Typmanagers
ab. Alternativ zu dem integrierten Ansatz von CORBA ist prinzipiell auch eine
vollstandige Trennung beider Aspekteinzwei separate Komponenten eines Typmanagers
denkbar. Eine Komponente konnte beispielsweise in Anlehnung an
das CORBA{Schnittstellenrepository die Verwaltung der Typde nitionen und
deren Verknupfungen untereinander sowie der jeweiligen Sichtbarkeitsbereiche
ubernehmen. Organisationelle Domanen werden dann in einer anderen Systemkomponente
verwaltet, mit der ubergreifend uber diese typverwaltungsspezi -
schen Einschrankungen eine separate Organisationsstruktur auf die im Typbeschreibungsrepository
vorhandenen Typbeschreibungen de niert werden kann.
Sie ermoglichen, da beispielsweise auch Typbeschreibungen, die in verschiedenen
Sichtbarkeitsbereichen de niert sind, gemeinsam verwaltet werden konnen.

3.2 Diensttypmanagement 65
Auf dem Domanenkonzept aufsetzend konnen des weiteren auch Sicherheitskonzepte
entwickelt werden, mit denen der Zugri auf Typbeschreibungen fur bestimmte
Nutzergruppen eingeschrankt werden kann.
3.2.2.6 Diensttyphierarchien
Im folgenden wird speziell auf die Verwaltung von Konformitatsbeziehungen eingegangen,
da ihnen innerhalb o ener verteilter Dienstemarkte eine wichtige Bedeutung
sowohl fur die Gewahrleistungder Interoperabilitat zwischen Dienstnehmer
und Diensterbringer als auch fur die Systemfortentwicklung und das Au nden
von Diensterbringern zukommt.
Grundlage fur die weitere Betrachtung ist die Modellierung der Konformitatsbeziehung
als homogener binarer Beziehungstyp. Die zwei beteiligten Rollen verweisen
jeweils auf Diensttypbeschreibungen, wie sie in Abbildung 3.6 dargestellt
sind. Die mit dem Konformitatsbeziehungstyp assoziierten De nitionsregeln entsprechen
den in Abschnitt 2.3.2 de nierten.
Mit Hilfe der einzelnen Instanzen derartiger Konformitatsbeziehungen, die jeweils
zwei Diensttypen miteinander in Beziehung stellen, lassen sich Diensttyphierarchien
aufbauen. Als geeignete Realisierungsform erweisen sich gerichtete
Graphen, die sich aus einer Menge von Knoten und Kanten zusammensetzen.
Knoten reprasentieren die Rollen einer Beziehungsinstanz, wahrend die Kanten
die Beziehung zwischen den Rollen verdeutlichen. Abbildung 3.9 zeigt das an
[IBR93] angelehnte Beispiel einer Hierarchie von Diensttypen, die jeweils verschiedene
Dienste zumUmgang mit Dateien (engl. le service) beschreiben.
Virtual Root
Other (virtual) service types
File transfer( NULL: Inttype,
cost: integer,
access control: enum,
transfer rate: range,
transfer mode: enum)
FTP(inttype-1: Inttype,
cost: integer,
access control: enum,
transfer rate: range,
transfer mode: enum)
File service( NULL: Inttype,
cost: integer,
access control: enum)
File access( NULL: Inttype,
cost: integer,
access control: enum,
response time: range,
access mode: enum)
FTAM( inttype-3: Inttype,
cost: integer,
access control: enum,
response time: range,
access mode: enum)
FTAM transfer( inttype-2: Inttype,
cost: integer,
access control: enum,
transfer rate: range,
transfer mode: enum)
File management
( NULL: Inttype,
cost: integer,
access control: enum)
NFS( inttype-4: Inttype,
cost: integer,
access control: enum,
response time: range,
access mode: enum)
Abbildung 3.9: Beispiel einer Diensttyphierarchie mit virtuellen Diensttypen

66 Zugang zu Diensten in heterogenen Umgebungen
Die Knoten im Baum bezeichnen die verschiedenen Diensttypen, die durch entsprechende
Pfeile zueinander in Beziehung gestellt sind. So sind beispielsweise
die Diensttypen NFS 4 und FTAM 5 File access konforme Diensttypen. Ein besonderes
Merkmal des Diensttyps File access ist dabei, da kein Schnittstellentyp
(NULL: Inttype)sondern nur eine Menge von Dienstattributtypen de niert
wird. Aus diesem Grund wird dieser Diensttyp auch als als sogenannter virtueller
Diensttyp [IBR93] bezeichnet, da eine Instanziierung des Diensttyps durch
konkrete Diensterbringer nicht moglich ist.
Ein wesentlicher Vorteil von virtuellen Diensttypen ist die Strukturierung von
Diensttyphierarchien. So konnen auch Diensttypen in Beziehung gestellt werden,
die aufgrund unterschiedlicher Schnittstellentypen ansonsten mit Hilfe der Konformitatsregeln
nicht vergleichbar waren. Erreicht wird dieses, indem gemeinsame
Diensteigenschaften bzw. Dienstattributtypen realer Diensttypen zu einem
virtuellen Diensttyp zusammengefa t werden, wie es beispielsweise bei NFS und
FTAM gezeigt ist. Verschiedene virtuelle Diensttypen konnen auch wiederum in
Konformitatsbeziehungzueinem anderen gemeinsamen virtuellen Diensttyp stehen.
Letztendlich fuhrt diese Hierarchiebildung zur De nition einer virtuellen
Wurzel (engl. virtual root), von der aus samtliche Diensttypde nitionen erreichbar
sind. Von dieser Wurzel aus kann ein Benutzer oder Programmierer bei der
Diensttypsuche inverschiedene Zweige der Diensttyphierarchie absteigen, um
die von ihm gesuchten Diensttypen zu nden. Dazu mu er sich bisauf die auf
unterster Ebene be ndlichen Blatter des Hierarchiebaumes navigieren, um reale
Diensttypen mit de nierten Schnittstellentypen zu erhalten. Die realen Diensttypen
bilden wiederum dieWurzel fur weitere, in Konformitatsbeziehung stehende
reale Diensttypen, wie in Abbildung 3.10 dargestellt ist.
FTAM( inttype-6: (read,write,extend),
cost: integer,
access control: enum,
response time: range,
access mode: enum)
FTAM( inttype-3: (read,write),
cost: integer,
access control: enum,
response time: range,
access mode: enum)
FTAM( inttype-7: (read,write,extend),
cost: integer,
access control: enum,
response time: range,
access mode: enum,
shared access: enum)
FTAM( inttype-5: (read,write),
cost: integer,
access control: enum,
response time: range,
access mode: enum,
shared access: enum)
Abbildung 3.10: Konformitatsbeziehungen zwischen realen Diensttypen
4 Das Network File System (NFS) von Sun isteinverteilter Dateidienst, der den Zugri auf
Dateien uber Rechnergrenzen hinweg ermoglicht [Sun90, Cor91].
5 Das File Transfer and Access Management (FTAM) ermoglicht ebenso wie NFS den Zugri
auf entfernt verwaltete Dateien. FTAM ist als sogenanntes Application Service Element auf
Schicht sieben des OSI{Referenzmodells [EF86] de niert.

3.2 Diensttypmanagement 67
Die dort am Beispiel des Diensttyps FTAM gezeigten Konformitatsbeziehungen
beruhen zum einen auf der Erweiterung eines Schnittstellentyps um eine zusatzliche
Operation extend und zumanderen auf dem Hinzufugen neuer Dienstattributtypen,
beispielsweise shared access.
Speicherstrategien Im Zusammenhang mit der Verwaltung von Typhierarchien
konnen zum einen speichere ziente und zumanderen zugri se ziente
Speicherstrategien unterschieden werden. Beide Varianten sind inAbbildung 3.11
zusammenfassend dargestellt.
Beziehungsinstanz
Diensttyp Diensttyp
A A
Diensttyp
B
Diensttyp Diensttyp
C
D
Speichereffiziente Ablage
Diensttyp Diensttyp
Diensttyp
C B
D
Diensttyp Diensttyp
C D
Zugriffseffiziente Ablage
Abbildung 3.11: Strategien bei der Speicherung von Diensttyphierarchien
Speichere ziente Strategien zeichnen sich dadurch aus, da mit Hilfe der in der
Konformitatsbeziehungde nierten Charakteristika das Duplizieren von Informationen
in der Diensttyphierarchie vermieden werden kann. Aufgrund der re exiven,
antisymmetrischen und transitiven Charakteristika von Konformitatsbeziehungen
konnen neu hinzugefugte Beziehungsinstanzen aus bereits vorhandenen
erschlossen werden. Besteht beispielsweise zwischen den Diensttypen A und B
sowie zwischen B und Ceine Konformitatsbeziehung, ist das Einfugen einer neuen
Beziehungsinstanz zwischen A und C in den Diensttypgraphen wegen der
Transitivitat der Beziehung uber ussig. Bezogen auf die Abbildung einer derartigen
Typhierarchie auf gerichtete Graphen bedeutet dies, da nur der den
Graphen aufspannende Baum gespeichert wird. Samtliche, nicht explizit gespeicherten
Beziehungsinstanzen mussen durch Berechnung der transitiven Hulle des
Diensttypgraphens ermittelt werden. Dies wurde beispielsweise bei einer Anfrage,
ob die obigen Diensttypen A und C in Konformitatsbeziehungstehen, der Fall
sein. Diese explizit durchgefuhrte Berechnung ist der wesentliche Unterschied
zur zugri se zienten Speicherung, die gerade die oben vermiedene Redundanz
von Beziehungsinstanzen explizit ausnutzt. Hierdurch kann beispielsweise beim
Suchen nach konformen Diensttypen auf die unter Umstanden aufwendige Berechnung
der transitiven Hulle verzichtet werden.

68 Zugang zu Diensten in heterogenen Umgebungen
3.2.2.7 Typuberprufungen und {vergleiche
Die im vorherigen Abschnitt beschriebenen Aspekte der strukturierten und persistenten
Ablage von Typbeschreibungen und Beziehungsinstanzen bilden die
Grundlage, auf derer Uberprufungen und Vergleiche von Typen und Beziehungen
durchgefuhrt werden konnen. Sie sind vor allem bei der Bindungsphase von
Dienstnehmer und Diensterbringer und den anschlie enden Operationsaufrufen
sinnvoll, um dieTypsicherheit der Interaktion zu gewahrleisten.
Uberprufung von Bindungen In der Bindungsphase ist zu untersuchen,
ob der vom Dienstnehmer angebotene Diensttyp mit dem vom Dienstnehmer
gewunschten ubereinstimmt. Ist dies nicht der Fall, kann keine Bindung zum
Diensterbringer eingegangen werden. Um einen Typvergleich durchfuhren zu
konnen, mussen vom Typmanager Operationen angeboten werden, mit deren Hilfe
zwei Diensttypbeschreibungen verglichen werden konnen. Dabei sind sowohl
die beiden zu vergleichenden Diensttypbeschreibungen als auch die Beziehungstypbeschreibung
anzugeben. Aufgrund der im Beziehungstyp de nierten Charakteristika
und De nitionsregeln wird die Vergleichsoperation gesteuert. Wie
bereits inAbschnitt 3.2.2.2 erlautert wurde, ist es unter Umstanden erforderlich,
da diese Entscheidung durch explizite administrativeTatigkeiten getro en werden
mu , falls die De nitionsregeln eine automatische Uberprufung durch den
Typmanager nicht zulassen.
Grundvoraussetzung fur Typuberprufungen und {vergleiche zumZeitpunkt der
spaten Bindung ist die Verfugbarkeit der Diensttypbeschreibungen der Kooperationspartner
und der mit der Bindung assoziierten Beziehungstypbeschreibung.
Vor Eingehen der Bindung werden diese Typbeschreibungen dem Typmanager
ubergeben, der die Zugehorigkeit beider Diensttypbeschreibungen in die durch
die Beziehungstypbeschreibung de nierte Beziehung uberpruft. Innerhalb o ener
verteilter Dienstemarkte sind als Beziehungstypen vor allem Aquivalenz{
und Konformitatsbeziehungen interessant, mit denen die Typsicherheit der Beteiligten
sichergestellt wird. Welche Art von Typbeziehung fur die aktuelle Bindung
jeweils von Interesse ist, mu vor Uberprufungder Bindung festgelegt werden.
Dies kann beispielsweise in der Dienstauswahlphase bestimmt werden und
hangt unter anderem auch davon ab, welche Beziehungen durch das Laufzeitsystem,
das die Infrastruktur fur Dienstaufrufe zur Verfugung stellt, unterstutzt
werden. In DCE oder CORBA beispielsweise sind nur einfache Konformitatsbeziehungen
erlaubt, mit denen Operationen zu bestehenden Schnittstellentypen
hinzugefugt werden konnen, wobei die Parameter der bestehenden Operationen
nicht verandert werden durfen. Um auch dort eine Konformitatsbeziehung zu
unterstutzen, sind zusatzliche Systemdienste erforderlich, die ein uber die vorhandenen
Plattformkonzepte hinausgehende Umsetzung und Anpassung der Parameterwerte
vornehmen. Diese Aufgabe kann durch sogenannte Interzeptoren
erfullt werden, die in Abschnitt 3.4 vorgestellt werden.
Eine einfache Artder Realisierung von Typuberprufungen und {vergleichen zum
Bindungszeitpunkt kann durch Verwendung der vom Typmanager vergebenen

3.2 Diensttypmanagement 69
Typbezeichner erreichtwerden. Diese Variante ist in Abbildung 3.12 verdeutlicht.
Dienstnehmer
TypeId
Typmanager
CheckRelationship
RelTypeId
Laufzeitsystem
TypeId
Diensterbringer
Abbildung 3.12: Typuberprufung zum Bindungszeitpunkt
Mit Hilfe der beiden Typbezeichner und des, indem dargestellten Fall vom Laufzeitsystem
bereitgestellten Beziehungstypbezeichners wird uberpruft, ob beide
Diensttypen in der gegebenen Beziehung stehen. Gegebenenfalls kann die neue
Beziehungsinstanz anschlie end auch im Beziehungsrepository des Typmanagers
abgelegt werden, falls sie dort noch nicht vorhanden war.
Variationen dieses einfachen Verfahrens ergeben sich, falls alternativ zu Typbezeichnern
Dienstreprasentationen verwendet werden, die samtliche Diensttypinformationen
beinhalten. Das kann unter anderem der Fall sein, falls ein Diensterbringer
einen Dienst eines neuartigen Diensttyps anbietet, der nochnichtimTypmanager
registriert und somit noch keinen Typbezeichner besitzt. Aus diesem
Grund werden derartige Dienste in dieser Arbeit auch als unklassi ziert bezeichnet.
Im Gegensatz hierzu stehen klassi zierte Dienste, deren Diensttypen registriert
und somit a{priori bekanntund durcheinen Typbezeichner identi zierbar
sind. Dieser Aspekt der Klassi kation von Diensten spielt insbesondere bei der
in diesem Kapitel betrachteten ODP{basierten Dienstvermittlung [ODP94b] eine
wichtige Rolle, bei der die Ubergabe von Diensttypbeschreibungen auf der
Basis von Typbezeichnern erfolgt (siehe Abschnitt 3.3.2.2).
Uberprufung von Operationsaufrufen Nachdem die Bindung erfolgreich
abgeschlossen und dieTypsicherheit sichergestellt ist, konnen die Operationen
des Diensterbringers von Seiten des Dienstnehmers aufgerufen werden. Beim
Operationsaufruf ist es sinnvoll, zusatzlich die Ubereinstimmung der Parameterwerte
mit den in den Operationssignaturen de nierten Datentypen zu uberprufen.
Ein einfaches Beispiel hierfur ist die falschliche Verwendung von reellen
Zahlen bei einem Parameter, der einen ganzzahligen Datentyp besitzt. Ob derartige
Fehler uberhaupt auftreten konnen, hangt vor allem davon ab, wie exibel
von Seiten des Dienstnehmers Operationen aufgerufen werden konnen.
Die exibelste Moglichkeit stellt eine dynamische Aufrufschnittstelle zur
Verfugung, wie sie bereits in ihrer Grundfunktion im Zusammenhang mit dem
CORBA{Schnittstellenrepository in Abschnitt 3.2.1.1 vorgestellt worden ist.

70 Zugang zu Diensten in heterogenen Umgebungen
Mit ihr konnen Operationsaufrufe zur Laufzeit aus den hierfur notwendigen
Bestandteilen erzeugt und anschlie endanden Diensterbringer gesendet werden.
In CORBA werden hierfur neben anderen die drei Operationen create request,
add arg und send angeboten. Mit create request wird das Grundgerust einer
Operation mit einem bestimmten Namen erzeugt, dem anschlie end mit add arg
Parameter und deren Werte sowie auch vorerst leere Ruckgabeparameter, die
erst bei Beendingung des Operationsaufrufs belegt werden, hinzugefugt werden
konnen. Das abschlie ende Versenden der Operation erfolgt mit send. Bei
komplexen Operationen kann es hier leicht zuFehlern im Aufbau der Operation
kommen, die im ungunstigsten Fall erst auf Diensterbringerseiteerkanntwerden.
Um dies zu vermeiden ist eine vorherige Uberprufung des Operationsaufbaus
durch den Typmanager notwendig. Abbildung 3.13 zeigt einen moglichen Ansatz
einer derartigen Uberprufung.
create_request
add_arg
...
send
Dienstnehmer
TypeId
Typmanager
CheckOperation
Operation( Name, List (Parameter), ...)
Laufzeitsystem
Diensterbringer
Abbildung 3.13: Typ{ undWertuberprufung beim dynamischen Operationsaufruf
Bevor die Operation an den Diensterbringer gesendet wird, ubergibt das Laufzeitsystem
dem Typmanager den Diensttypbezeichner, der auf die Diensttypbeschreibung
imTypbeschreibungsrepository verweist. Gleichzeitig wird auch das
komplette Operationsgerust einschlie lich der Werte der Parameter beigefugt,
so da der Typmanager sowohl dessen korrekten Aufbau als auch dieParameterwerte
bezuglich der geforderten Parametertypen uberprufen kann. Erst bei
Korrektheit der gemachten Angaben wird die Operation beim Diensterbringer
aufgerufen.
Das obige Prinzip der Typuberprufung dynamischer Operationsaufrufela t sich
auch auf statische Varianten ubertragen, wie sie durch das Prinzip der entfernten
Prozeduraufrufe (engl. remote procedure call { RPC) realisiert werden. Der
wesentliche Unterschied zum dynamischen Aufruf besteht dort in der Generierung
von sogenannten Stubs, die statischzum Dienstnehmer und Diensterbringer
hinzugebunden werden und alle zur Typuberprufung notwendigen Funktionen
bereitstellen. Grundlage fur deren Generierung bildet im allgemeinen, beispielsweise
auch bei DCE, ANSA und CORBA, die Schnittstellentypbeschreibung. Sie
wird einem Sprachubersetzer (engl. compiler) ubergeben, der die entsprechenden

3.2 Diensttypmanagement 71
Stubs erzeugt (siehe Abbildung 3.14).
Schnittstellentypbeschreibung
Stub-
Generator
Dienstnehmer
Stub
...
Operationsname
(Parameterliste)
CheckOperation
Laufzeitsystem
Diensterbringer
Abbildung 3.14: Typ{ und Wertuberprufung beim statischen, generierten Operationsaufruf
Fur den Programmierer des Dienstnehmers bedeutet dies, da er sich mit spezi
schen Details des internen Aufbaus von Operationen nicht auseinandersetzen
mu , sondern entfernte Operationen ahnlich wie Prozeduren in prozeduralen
Programmiersprachen aufrufen kann. Die Stubs verbergen hierbei samtlichekommunikationstechnischen
Details. Bedingt durch die automatische Generierungaus
der Schnittstellentypbeschreibung werden au erdem Fehler im Operationsaufbau
von vornherein vermieden und fehlerhafte Ubergaben von Parameterwerten bei
der Programmierungbereitserkannt. Ob die in der Abbildung dargestellte Operation
CheckOperation in den Stubs selbst oder wie im dynamischen Fall durch
einen separaten Typmanager realisiert wird, hangt unter anderem von den sich
gegenuberstehenden Anforderungen nach E zienz auf der einen und Generizitat
auf der anderen Seite ab.
3.2.3 Grundlagen eines verteilten Diensttypmanagements
Im vorherigen Abschnitt sind die grundlegenden Aufgaben des Typmanagementsvorgestelltworden,
die wohlde nierte Grundkonzeptefur den Umgangmit
Diensttypen und Beziehungstypen sowie von Beziehungsinstanzen bereitstellen.
Der Darstellung wurde dabei eine idealisierte Sichtweise von Typmanagement
zugrunde gelegt, bei der zunachst Verteilungs{ und Heterogenitatsaspekte unberucksichtigt
geblieben sind. Aufgrund der Autonomie der an o enen verteilten
Dienstemarkten beteiligten Verwaltungsdomanen, die sich vor allem bei der Gestaltunginterner
Verwaltungsstrukturen ausdruckt, ist in der Regel jedochdavon
auszugehen, da auch die Aspektedes Typmanagementsinder jeweiligen lokalen
Verantwortlichkeit der Domanen liegen. Eine der direkten Konsequenzen dieser
Autonomie ist das Vorhandensein verschiedener Typmanager, die jeweils die innerhalb
einer Verwaltungsdomane de nierten Beschreibungen von Diensttypen
und Beziehungstypen sowie konkreten Beziehungsinstanzen verwalten. Zur besonderen
Betonung der Autonomieaspekte wird in dieser Arbeit die Zusammenarbeit
von Typmanagern zweier Verwaltungsdomanen auch als Typmanagerfoderation
bezeichnet. Die Abbildung 3.15 zeigt einen verfeinerten Ausschnitt der zu
Beginn dieses Kapitels gezeigten Abbildung 3.2, in der die moglichen Hetero-

72 Zugang zu Diensten in heterogenen Umgebungen
Verwaltungsdomäne A
Verwaltungsdomäne B
Typmanager
Typmanager
A B
Typmanagerföderation
DienstDienstnehmer
Heterogenitätsgrenze
erbringer
Abbildung 3.15: Verteiltes Diensttypmanagement
genitatsgrenzen beim Zugang zu Diensten in o enen verteilten Dienstemarkten
verdeutlichtworden sind. Die Abbildung beschrankt sich hierbei zunachst auf die
Darstellung administrativer Heterogenitatsgrenzen. Bei der Typmanagerfoderation
uber technische Heterogenitatsgrenzen hinweg ware zusatzlich der Einsatz
eines Interzeptors erforderlich. Hierauf geht Abschnitt 3.4 noch genauer ein.
Im folgenden werden die grundlegenden Systemmechanismen vorgestellt, die fur
die Kooperation von Typmanagern zweier heterogener Verwaltungsdomanen notwendig
sind. Hierbei wird zum einen das Problem der bisher nur lokal gultigen
Typbezeichner erortert. Zum anderen wird der ebenfalls bisher nur lokal betrachtete
Aspekt der Bindungsuberprufung wieder aufgegri en und ein moglicher
Ansatz vorgestellt, der unter Berucksichtigungder Beteiligung mehrerer Typmanager
Typuberprufungen und {vergleiche ermoglicht. Dieser basiert im wesentlichen
auf dem Austauschvon Typbeschreibungen zwischen den Typmanagern. Die
hierfur vorgeschlagenen Konzepte der global eindeutigen Typbezeichner und des
Austauschs von Typbeschreibungen bilden gleichzeitig auch die systemtechnischen
Voraussetzungen fur die Realisierung von Trader{Kooperationsprotokollen, wie
sieinAbschnitt 3.3.3.3 detailliert betrachtet werden.
3.2.3.1 Global eindeutige Typbezeichner
Wie auch im lokalen Fall ist eine Grundvoraussetzung fur verteiltes Typmanagement
die eindeutige Bezeichnung von Typbeschreibungen und Beziehungsinstanzen.
Da bei der Typmanagerfoderation die Bezeichnung von Typen jeweils
in der Verantwortung des lokalen Typmanagers liegt, ist eine Erweitertung von
Typ{ und Instanzbezeichnern notwendig, so da weiterhin die globale Eindeutigkeit
der Bezeichner gewahrleistet ist. Die verwendeten eindeutigen Bezeichner
sollten dabei auch Informationen uber ihre Herkunft beinhalten, mit denen
der Bezug zum dazugehorigen Typmanager hergestellt wird. Wird beispielsweise
davon ausgegangen, da die Adresse eines Typmanagers weltweit eindeutig

3.2 Diensttypmanagement 73
ist, konnte einTypbezeichner das in Abbildung 3.16 gezeigte Format besitzen.
Die Typmanageradresse mu hierbei von jedem Teilnehmer in einem o enen
Typmanageradresse interner Bezeichner Bezeichnertyp
Abbildung 3.16: Format eines Typbezeichners
Dienstemarkt interpretiert werden konnen, um auf den Typmanager zuzugreifen.
Die Interpretation des zweiten Teils des globalen Typbezeichners hingegen
ist jedoch nur im Kontext des adressierten Typmanagers sinnvoll und sollte in
der Regel ansonsten nichtweiter interpretiert werden. Mit Hilfe der dritten Komponente,
dem Bezeichnertyp, lassen sich zusatzlich Aussagen uber die Art des
Bezeichners machen, beispielsweise ob es sich nur um einen lokal gultigen oder
um einen standardisierten, global gultigen Bezeichner handelt. Der letzte Fall
ist besonders im Kontext internationaler Standardisierung nutzbar, bei der fur
alle im o enen verteilten Dienstemarkt agierenden Teilnehmer eine verbindliche
Absprache uber Diensttypbezeichner und die damit verknupften Diensttypbeschreibungen
getro en wird. Beispielsweise kann so der in Abbildung 3.9 gezeigte
Diensttyp FTAM in seiner Syntax und Semantik standardisiert und mit einem
weltweit einheitlichen Diensttypbezeichner identi ziert werden. Standardisierte
Typbezeichner eignen sich insbesondere fur die einfache Realisierung einer verteilten
Dienstvermittlung, wie sichinAbschnitt 3.3.3.3 als einemoglicheVariante
eines Trader{Kooperationsprotokolles vorgestellt werden.
3.2.3.2 Austausch von Typbeschreibungen
Die oben vorgestellten global eindeutigen Bezeichner bieten die wesentliche
Grundvoraussetzung fur den domanenubergreifenden Zugri auf die Informationen
eines Typmanagers. Um diese Informationen zwischen den Typmanagern
austauschen zu konnen, mussen Mechanismen fur ihren Transport zur Verfugung
gestellt werden. Dabei sind insbesondere die Heterogenitatsaspekte zuberucksichtigen,
die sich aus der Autonomie der Verwaltungsdomanen ergeben und sich
beispielsweise konkret in der Wahl unterschiedlicher Typbeschreibungssprachen
au ern. In Abschnitt 2.1 wurde hierfur das Konzept der Dienstreprasentation
vorgestellt, welches ein Transferformat zur Reprasentation von Typinformationen
der Dienstbeschreibungsebene zur Verfugung stellt.
Auf dieser Grundlage kann unter anderem die bisher nur fur den lokalen Fall
betrachtete Bindungsuberprufung beim Dienstzugri uber administrative Heterogenitatsgrenzen
realisiert werden. Die Abbildung 3.17 zeigt hierzu eine Erweiterung
der in Abbildung 3.12 dargestellten Uberprufung einer Bindung, wobei
in diesem Fall die vom Laufzeitsystem benutzten globalen Typbezeichner auf
Typbeschreibungen in den lokalen Typmanagern der Verwaltungsdomanen verweisen.
Die Bindungsuberprufung (CheckRelationship) wird in der Domane
des Dienstnehmers vorgenommen, in der auch der Beziehungstypbezeichner
RelTypeId-TM-A gultig ist. Um an die zur Uberprufung notwendigen Typinformationen
zu gelangen, greift der dortige Typmanager A mit Hilfe der Opera-

74 Zugang zu Diensten in heterogenen Umgebungen
Dienstnehmer
Verwaltungsdomäne A
RelTypeId-TM-A
TypeId-TM-A
Typmanager A
CheckRelationship
Laufzeitsystem
Verwaltungsdomäne B
GetTypeDescr
(TypeId-TM-B)
TypeId-TM-B
Typmanager B
Diensterbringer
Abbildung 3.17: Austausch von Dienstbeschreibungen zum Bindungszeitpunkt
tion GetTypeDesc auf die Typbeschreibung des mit TypeId-TM-B referenzierten
Typbezeichners in Typmanager B zu. GetTypeDesc erfordert hierbei auch die
Angabe einer bestimmten Typbeschreibungssprache, mit der die Typbeschreibung
von Typmanager B ausgedruckt werden soll, damit die Typinformationen
von Typmanager A verstanden werden konnen. Nach Erhaltder Typbeschreibung
erfolgt die Bindungsuberprufung durch den Typmanager.
Der Austauschvon Typinformationen ist generell nicht nur auf den Informationsaustauschzwischen
Typmanagern beschrankt, sondern umfa t samtlicheInteraktionen
des Typmanagers mit seinen Klienten, beispielsweise mit Dienstvermittlungskomponenten
beim Diensttypvergleich oder Browsern zur Unterstutzung
der Diensttypsuche. Insbesondere im letzten Fall mussen unter Umstanden zahlreiche
Typmanager verschiedener Verwaltungsdomanen kontaktiert werden. Bei
jedem Zugri ist ebenso wie im obigen Fall der Bindungsuberprufung vorher die
gemeinsame Typbeschreibungssprache und Typreprasentation abzustimmen.
Weiterhin sind beim Austausch von Typinformationen von Seiten der Typmanager
auch Sicherheitsaspektezuberucksichtigen, die den Umgang mit den dort
abgelegten Typinformationen festlegen. Generelle Fragestellungen sind beispielsweise,
welche Typinformationen fur wen nach au en hin sichtbar sein sollen oder
welche Operationen durch einen Klienten genutzt werden durfen. Die Beantwortung
dieser Fragen hangt ma geblich von den lokalen Rahmenbedingungen ab,
die in der jeweiligen Verwaltungsdomane de niert sind. In der Literatur werden
diese Rahmenbedingungen generell auch als Verwaltungsvorschriften (engl.
policies) [ODP95c] bezeichnet, deren Festlegung beispielsweise durch den Typmanager
selbst oder domanenubergreifend getro en wird. Ein Beispiel fur eine
Verwaltungsvorschrift im Rahmen des Typmanagements ist die in [IBR93]vorgeschlagene
Unterscheidung von universellen, standardisierten und privaten Typbeschreibungen,
wobei der Zugri von au en nur auf die ersten beiden moglich
ist, wahrendprivateTypbeschreibungen nur im Sichtbarkeitsbereich der lokalen
Verwaltungsdomane zuganglich sind.

3.3 Vermittlung und Verwaltung von Dienstangeboten 75
3.3 Vermittlung und Verwaltung von Dienstangeboten
Angesichts der moglichen Vielfalt und Vielzahl von angebotenen Diensten in offenen
verteilten Dienstemarkten ergibt sich fur potentielle Dienstnehmer die Frage
nach geeigneten Unterstutzungsmechanismen, mit denen geeignete Diensterbringer
eines gewunschten Diensttyps gefunden werden konnen. Wie auch in
herkommlichen kommerziellen Warenmarkten sind hierbei vor allem diejenigen
Dienstangebote von Interesse, die fur den Dienstnehmer das in seinem spezi -
schen Anwendungskontext " am besten geeignete\ darstellen.
In diesem Abschnitt sollen Systemtechniken untersucht werden, die den Dienstnehmern
eine adaquate Unterstutzung fur die zweite wichtige Dienstnutzungsphase,
die Dienstauswahl, bereitstellen. Im Betrachtungsschwerpunkt steht das
sogenannte Trading, welches einen geeigneten Losungsansatz fur die Dienst{
bzw. Dienstangebotsvermittlung 6 sowohl in lokalen als auch inweltweit verteilten
Dienstemarkten bietet. Hierbei wird insbesondere auch auf aktuelle Arbeiten
eingegangen, die im Rahmen der internationalen Standardisierung des
ODP{Referenzmodells [ODP95b] unter dem Begri der ODP trading function
[ODP95a] durchgefuhrt worden sind. Hieruber hinausgehend werden auch noch
einmal verschiedene Heterogenitatsprobleme erortert, die sich aus der Autonomie
der in einem o enen verteilten Dienstemarkt kooperierenden Verwaltungsdomanen
ergeben und ma geblichen Ein u auf den Dienstvermittlungsproze
ausuben.
3.3.1 Mechanismen zur Dienstauswahl
Wesentliches Unterscheidungsmerkmal verschiedener Dienstauswahlmechanismen
sind die Moglichkeiten, die einem Dienstnehmer, d.h. Dienstnehmern im
systemtechnischen Sinne und menschlichen Endbenutzern, zur Unterstutzung
seiner Dienstauswahl zur Verfugung stehen. Generell lassen sich drei verschiedene
Dienstauswahlmechanismen unterscheiden, die im folgenden naher erlautert
werden:
1. Namens{ und attributbasierte Dienstauswahl
2. Browsing{basierte Dienstauswahl
3. Diensttypbasierte Dienstauswahl
3.3.1.1 Namens{ und attributbasierte Dienstauswahl
Die Aufgabe der Verwaltung von Ressourcen in o enen verteilten Systemumgebungen
wurde bisher zumeist durch Namensdienste [Sch92a] erbracht, die den
6 Die Begri e Dienst und Dienstangebot werden im folgenden im Kontext der hier betrachteten
Vermittlung und Auswahl von Dienstangeboten synonym verwendet.

76 Zugang zu Diensten in heterogenen Umgebungen
Dienstnehmern einfache Moglichkeiten zur Ablage und zumSuchen von Ressourcen
bereitstellen. Durch ihre Generizitat lassen sie sich somit auch fur die
Verwaltungvon Diensten bzw. Diensterbringern nutzen, die in diesem Sinne spezielle
Formen von Ressourcen darstellen. Die wesentliche Hauptaufgabe derartiger
Namensdienste liegt in der Verwaltung von Abbildungen zwischen logischen
Namen auf physikalische Adressen, die den konkreten Ort der Diensterbringung
darstellen. Bedingt durch diese Indirektionsstufe ergibt sich fur den Dienstnehmer
der Vorteil der Ortsabstraktion, da nur der logische Name, beispielsweise der
Dienstname PrintService, und nicht die unter Umstanden sich andernde physikalische
Adresse des Diensterbringers berucksichtigt werden mu . Neben dieser
reinen Abbildungsfunktionalitat unterstutzen Namensdienste zumTeil auch
attributbasierte Anfragen, so da eine Auswahl von Diensten uber Eigenschaften
der registrierten Dienste durchgefuhrt werden kann. Ein bekanntes Beispiel
hierfur ist der standardisierte globale Namensdienst X.500 [Neu89, Rad94], der
ahnlich zuden Dienstattributtypen im Diensttypkonzept zu jedem Namenseintrag
die Angabe von Attributen erlaubt. Diese konnen spater als Suchkriterien
fur eine Dienstauswahl benutzt werden, auf deren Grundlage der Namensdienst
passende Dienstangebote in seinem verwalteten Namensraum sucht.
Ein wesentliches Merkmal von Namensdiensten ist der Determinismus, mit dem
Suchanfragen beantwortet werden. So ist in der Regel davon auszugehen, da
eine bestimmte Anfrage immer mit denselben Resultaten beantwortet wird, so
da beispielsweise unter der Attributanfrage PrinterSpeed > 20 immer dieselben
Diensterbringer zuruckgeliefert werden. Begrundet liegt dieses darin, da die
Auswahlprozesse innerhalb von Namensdiensten ausschlie lich auf der Berucksichtigung
statischer Informationen beruhen, die unveranderlich mit den Namenseintragen
abgelegt sind. Hier ist auch der wesentliche Unterschied zum nachfolgend
dargestellten Trading zusehen, das durch Berucksichtigung zusatzlicher
Auswahlkriterien generell nichtdeterministische Resultate zuruckliefert. Dieses
wird insbesondere beim Vorgang der gesta elten Auswertung deutlich, der in
Abschnitt 3.3.2.3 beschrieben ist. Prinzipiell ist dort ebenfalls ein deterministisches
Verhalten erzielbar, sofern sich der Auswahlproze beim Trading ausschlie
lich auf statische Dienstangebotsinformationen beschrankt. Von einigen
Autoren werden Namensdienste in diesem Zusammenhangauch als Vorlaufer von
Trading{Diensten verstanden [AA91, Dud90, Kel93], was sich zumTeil auch in
der Wahl von Namensdiensten zur Dienstangebotsverwaltung inTradern widerspiegelt
(siehe beispielsweise in [BKS91, WB95]). Ein ahnlicher Ansatz ist auch
innerhalb von TRADE gewahlt worden, da Namensdienste zahlreiche Trading{
unterstutzende Funktionen bereits anbieten (siehe Abschnitt 5.2).
Ein anderer attributbasierter Dienstauswahlmechanismus ndet sich imCygnus{
System [CR91], in dem Dienstangebote durch eineunterliegende verteilte Datenbank
verwaltet werden. Dienstnehmer konnen sich unter Angabe von Attributlisten,
beispielsweise ((category, compile), (source, C), (target,
PowerPC)) zur Suche nach einem Programmubersetzungsdienst, Bindungsinformationen
von passenden Diensterbringern zuruckgeben lassen. Ebenso wie bei
den attributierten Namensdiensten werden auch hier jedoch nur die statischen
Eigenschaften der Diensterbringer berucksichtigt.

3.3 Vermittlung und Verwaltung von Dienstangeboten 77
3.3.1.2 Browsing{basierte Dienstauswahl
Als zweite Form von Dienstauswahlmechanismen existieren interaktive Verfahren,
wie sie bereits schon in Kapitel 2 bei der Darstellung verschiedener Moglichkeiten
von Dienstbeschreibungen angesprochen wurden:
Zum einen ist dieses der in Abschnitt 2.4.4.2 beschriebene Generische
Klient, der den interaktiven Systembenutzer bei der Diensttypsuche und
der Dienstauswahl unterstutzt. Da dort konzeptionell Diensterbringer und
Dienstbeschreibung eineindeutig miteinander verknupft sind [MML94a],
bietet der Generische Klient gleichzeitig die Moglichkeit, die am Bildschirm
des Benutzers visualierten Dienstbeschreibungselemente, die beispielsweise
Operationsaufrufe reprasentieren, zu aktivieren. Hierdurchkannder von
einem Diensterbringer bereitgestellte Dienst interaktiv getestet werden, um
beispielsweise dessen Semantik besser zu verstehen.
Ein anderer Ansatz sind die in Abschnitt 2.4.3.2 beschriebenen Konzeptgraphen.
Obwohl dort im Vergleich zum Generischen Klienten keine explizite
Verknupfung von Dienstbeschreibung und Diensterbringer vorgegeben
ist, lassen sich Konzeptgraphen auch zur Beschreibung der Dienste konkreter
Diensterbringer nutzen, so da dort zwischen Dienstbeschreibung
und Diensterbringer ebenfalls eine enge Beziehung herrscht. Anschlie end
konnen durch benutzerseitige Spezi kation eines Konzeptgraphens geeignete
Dienstbeschreibungen mit Hilfe eines auf einem Ahnlichkeitsma basierenden
Vergleichsverfahrens ermittelt werden.
Da beide Verfahren die Dienstzugangsphasen der Diensttyp ndung und der
Dienstauswahl verbinden, ist neben den eigentlichen Vergleichsmechanismen
zusatzlich auch der Zugri auf eine explizite Dienstangebotsverwaltung erforderlich,
die die Abbildungen von Dienstbeschreibungen auf konkrete Dienstangebote
mit den dort enthaltenen Bindungsinformationen der Diensterbringer verwaltet.
Im Fall der Konzeptgraphen kann dieses beispielsweise durch Integration mit
der nachfolgend beschriebenen ODP{Trading{Funktion erreicht werden, in dem
die dort vorhandene Dienstangebotsverwaltung implizit mit benutzt wird [PB96].
Beim Generischen Klienten wird hierfur ein erweitertes Dienstrepository vorgeschlagen
[Vol95], welches Dienstbeschreibungen|und somit gleichzeitig konkrete
Diensterbringer | verwaltet und eine uber Dienstbeschreibungselemente
gesteuerte Suche anbietet.
Beide Verfahren setzen au erdem eine hohe Interaktion des Benutzers beim
Dienstauswahlproze voraus, so da sie fur eine Anzahl verteilter Anwendungen,
wie beispielsweise den in dieser Arbeit speziell betrachteten Kooperationsanwendungen
(siehe Abschnitt 4.2.1), nicht geeignet sind, da dort in der Regel eine
automatisch ablaufende Dienstvermittlung gefordert wird.

78 Zugang zu Diensten in heterogenen Umgebungen
3.3.1.3 Diensttypbasierte Dienstauswahl
Im Gegensatz zu den obigen generischen Namensdiensten, die prinzipiell beliebige
Arten von Informationen verwalten konnen, stellt das Trading einen speziell
auf die Verwaltung und Vermittlung von Dienstangeboten spezialisierten Unterstutzungsdienst
dar. Herausragendes Merkmal des im folgenden speziell betrachteten
ODP{Tradings [ODP95a] ist der Diensttypbegri , der als ein Hauptkriterium
zur strukturierten Verwaltung von Dienstangeboten dient. Aus diesem
Grund wird Trading zur Abgrenzung zuherkommlichen Namensdiensten auch
explizit als diensttypbasiert gekennzeichnet, um den spezi schen, auf Diensttypen
basierenden formalistischen Ansatz der Dienstverwaltung und {vermittlung
zu betonen.
3.3.2 ODP{basiertes Trading
Der vorliegende Abschnitt stellt die ODP{Trading{Funktion vor, die zur Zeit
auf internationaler Ebene durch die International Standardization Organisation
(ISO) standardisiert wird. Grundlage fur die folgende Darstellung bildet das im
Juli 1994 vero entlichte Standarddokument [ODP94b]. Weitere erganzende Beschreibungen
des ODP{Tradings nden sich unter anderem im Tutorial des oben
genannten Standarddokuments und in [Bea95], [Pop95], [PSW96] und [SPM94],
wobei die drei letztgenannten auf einem alteren Standarddokument [ODP94a]
beruhen, wodurch sichUnterschiede vor allem bei der Darstellung der Kooperation
von Tradern, dem sogenannten Trader Interworking bzw. der Trader Federation,
und der Darstellung der operationalen Schnittstelle des ODP{Traders
ergeben 7 . Grundlegende Anmerkungen zum Trading nden sich auch inder verteilten
Systemarchitektur ANSA [ANS87, Her89], in der ursprunglich der Begri
des Tradings gepragt wurde.
An dieser Stelle ist anzumerken, da das Trader{StandarddokumenteinSchnittstellenstandard
darstellt, bei dem nur der Diensttyp des Traders mit seinem extern
sichtbaren Verhalten an der operationalen Schnittstelle de niert ist. Aspekte
konkreter Losungsansatze und Realisierungsvorschlage werden nur informell im
Anhang des Dokuments erortert. Sie betre en jedoch nur allgemeine Vorgehensweisen,
beispielsweise zur Durchfuhrung der Dienstauswahl.
3.3.2.1 Export und Import von Dienstangeboten
Zentrale Aufgabe eines Traders ist die VermittlungundVerwaltungvon Dienstangeboten.
Er bietet hierzu Mechanismen an, die eine Strukturierungder verschiedenartigen
Dienstangebote ermoglichen und den Dienstnehmer beim Au nden
geeigneter unterstutzen. Seine Funktionalitat la t sich am besten mit der eines
" Gelbe Seiten\{Dienstes vergleichen, der Dienste kategorisiert und eineSuche
uber Diensteigenschaften anbietet. Das formale Konzept fur die Kategorisierung
7 Eine endgultige Verabschiedung des ODP{Trader{Standards ist fur Mitte 1996 vorgesehen.

3.3 Vermittlung und Verwaltung von Dienstangeboten 79
von Diensten ist der in Kapitel 2 bereits eingefuhrte Diensttyp, der sich aus einem
Schnittstellentyp und den Dienstattributtypen zusammensetzt. Ein weiteres
Strukturierungsmittel des Traders sind sogenannte Kontexte, die die geordnete
Ablage von Dienstangeboten, beispielsweise in einer hierarchisch organisierten
Form, ermoglichen.
Die Interaktionen der zu verwaltenden Diensterbringer und der Dienstnehmer
mit dem Trader verdeutlicht Abbildung 3.18.
Trader
ImportOffer 2 3
1 ExportOffer
Dienst-
4
Dienstnehmer
Dienstaufruf erbringer
Abbildung 3.18: Der Trader und seine Nutzer
Ein Diensterbringer, der sogenannte Exporteur, registriert sein Dienstangebot
beim Trader (Schritt 1). Hierzu gibt er unter anderem den Diensttyp, die aktuellen
Werte der Dienstattribute und moglicherweise einen Kontext an, in den das
Dienstangebot exportiert werden soll. Ein Dienstnehmer, der sogenannte Importeur,
richtet seine Suchanfrage nach einen bestimmten Diensterbringer an den
Trader (Schritt 2). Sie setzt sich unter anderem aus dem gewunschten Diensttyp
und den gewunschten Diensteigenschaften zusammen. Zusatzlich konnen auch
bestimmte Suchvorschriften (engl. search policies) angegeben werden, mit denen
beispielsweise der Suchkontext genauer bestimmtund eingeschrankt werden
kann. Aufgrund dieser Suchkriterien ermitteltder Trader passende Dienstangebote,
wahlt gegebenfalls das am besten geeignete aus und ubermittelt dem Dienstnehmer
die fur die anschlie ende Interaktion mit dem Diensterbringer notwendigen
Bindungsinformationen (Schritt 3). Anschlie end kann der Dienstnehmer die
Operationen des Diensterbringers aufrufen (Schritt 4). Weiterhin kann ein Exporteur
auch sein Dienstangebot spater wieder zuruckzuziehen oder verandern.
Importeur und Exporteur nehmen bei der Interaktion mit dem Trader die Rolle
der Dienstnehmer ein, die in diesem Fall den vom Trader erbrachten Trading{
Dienst in Anspruch nehmen. Ebenso wie beim Diensttyp der Dienste der Exporteure
besitzt auch der Trader einen Diensttyp, der im Standarddokument
beschrieben ist. Dort spezi zierte Operationen sind einem sogenannten trading
service interface oder einem trading management interface zugeordnet, welche
die Schnittstellen zumeinen fur die Importeure und Exporteure undzumanderen
fur administrative Aufgaben de nieren. Erstere umfa t unter anderem die Operationen
exportOffer, importOffer, withdrawOffer und describeOffer,mit
denen auf die im Trader verwalteten Dienstangebote zugegri en werden kann.
Die zweiteSchnittstelle bietet Operationen fur das sogenannte Link{Management

80 Zugang zu Diensten in heterogenen Umgebungen
an, mit denen Trader{Kooperationen 8 verwaltet werden. Weiterhin werden auch
Operationen zur Verwaltung von Trader{Eigenschaften (engl. trader properties)
angeboten, mit denen spezi sche Charakteristika bzw. Verwaltungsvorschriften,
beispielsweise die Zugehorigkeit zu einem bestimmten Typmanager oder die maximale
Anzahl an einen Importeur zuruckgebbarer Dienstangebote, bestimmt
werden.
3.3.2.2 Verwaltung von Dienstangeboten
Grundlage fur die Dienstangebotsauswahl durch einen Trader ist die Verwaltung
der an ihn exportierten Dienstangebote. Zu diesem Zweck werden beim ODP{
Trading sogenannte Kontexte als mogliches Strukturierungsmittel de niert (siehe
auch [BR93]). Sie bezeichnen bestimmte Teilbereiche des von einem Trader verwalteten
Dienstangebotsraums (engl. service o er space), in die Dienstangebote
beim Exportieren eingeordnet werden konnen. Abbildung 3.19 zeigt ein Beispiel
einer Kontextstruktur, die auch als direkter azyklischer Graph reprasentiert werden
kann.
B
A
C
D
E
Abbildung 3.19: Trader{Kontexte
B
A
C E
A,B,C,D und E bezeichnen jeweils die Kontexteund die dort eingeordneten Dienstangebote.
D ist hierbei Subkontext von C und E. Kontexte konnen generell nach
den verschiedenartigsten Kriterien gebildet werden, die in der Regel vom beabsichtigten
Einsatzbereich eines Traders abhangen. Eine einfache und generischverwendbare
Moglichkeit ist beispielsweise die Bildung von Kontexten nach
Diensttypen. In diese konnen die Dienstangebote entsprechend ihrem jeweiligen
Diensttyp eingeordnet werden. Ein Dienstangebot eines Exporteurs setzt sich
dabei aus mehreren Einzelteilen zusammen, die in Abbildung 3.20 zusammenfassend
dargestellt sind. Im einzelnen werden dabei folgende Bestandteile unterschieden:
Diensttypbeschreibung zur Kategorisierungdes exportierten Dienstangebotes.
Sie umfa t die Beschreibung des Schnittstellentyps und der Dienstattributtypen.
8 Die Kooperation zweier Trader wird alternativ auch als Trader{Interworking [Vog94] bzw.
in alteren Trader{Standarddokumenten [ODP93, ODP94b, BR92a] als Trader{Foderation
bezeichnet.
D

3.3 Vermittlung und Verwaltung von Dienstangeboten 81
Dienstangebot
Dienstangebotseigenschaften
Dienstzugangs-
Schnittstelle
Dienstangebotsauswertungs-
Schnittstelle
Werte statischer
Dienstattribute
Diensttypbeschreibung
- Dienstattributtypen
- Schnittstellentyp
- Semantikbeschreibung
Abbildung 3.20: Bestandteile eines Dienstangebotes
Werte statischer Dienstattribute zur genaueren Charakterisierung des
Dienstangebots
Schnittstellenkennung der Dienstangebotsauswertungsschnittstelle (engl.
service o er evaluation interface { SOEI), uber die der Trader bei einer
spateren Dienstangebotssuche auf die aktuellen Werte der dynamischen
Dienstattribute zugreifen kann. Prinzipiell gilt dieses jedoch auch fur
statische Dienstattribute.
Schnittstellenkennung der operationalen Schnittstelle des Diensterbringers,
uber die ein spaterer Dienstzugri durchgefuhrt wird.
Attributwerte fur Dienstangebotseigenschaften (engl. service o er properties),
mit denen der im Trader verwaltete Dienstangebotseintrag naher
beschrieben wird, so da beispielweise das Entstehungsdatum oder auch
ein mogliches Ablaufdatum des Dienstangebots imTrader verwaltet werden
kann. Diese konnen zu statistischen Zwecken oder auch zur Steuerung
Trader{interner Verwaltungsvorgange genutzt werden.
Die genannten Dienstangebotsbestandteile bilden einschlie lich einer zusatzlichen
Exporteurskennung und einem Kontext, in den das Dienstangebot im
Dienstangebotsraum eingeordnet werden soll, die wesentlichen von der Export{
Operation geforderten Eingabeparameter.
Zur Reprasentation und Darstellung der Diensttypbeschreibung existieren prinzipiell
drei verschiedene Moglichkeiten, die auf dem in Abschnitt 3.2.2.4 vorgestellten
Konzept der Typbezeichner beruhen 9 :
9 Insofern stellt dieseForm von Diensttypreprasentation im Sinne des in Abschnitt 2.1vorgestellten
Begri s nur eine sehr einfache Moglichkeit zur Reprasentation von Typbeschreibungen
dar, da auf deren eigentliche Bestandteile nur verwiesen wird.

82 Zugang zu Diensten in heterogenen Umgebungen
1. Die einfachste Form ist die Angabe eines Diensttypbezeichners, der auf die
dazugehorige Diensttypbeschreibung imTypmanager verweist.
2. Die zweite Moglichkeit ist die Aufsplittung der Bestandteile eines Diensttyps
in einen Schnittstellentypbezeichner und eineMenge an Dienstattributtypbezeichnern.
3. EinedritteVarianteistdiedetaillierte Darstellungvon Diensttypen in Form
eines Signaturbezeichners und einer Menge von Dienstattributtypbezeichnern.
Der Signaturbezeichner verweist auf einen Eintrag im Typmanager,
der die Beschreibung der Operationssignaturen und gegebenfalls der semantischen
Beschreibung der Schnittstelle und der Operationen beinhaltet
(siehe zumVergleich auch Abbildung 3.6).
Insgesamt ergibt sich unter Berucksichtigung aller innerhalb eines Dienstangebotes
vorhandenen Informationen das in Abbildung 3.21 gezeigte Gesamtbild,
welches die in Abbildung 3.18 gezeigte Grundstruktur des Tradings weiter verfeinert.
Typmanager
SO
Trader
ImportOffer
Importeur
Dienstangebotsauswertung
ExportOffer
Dienstaufruf
S
O
E
I
Exporteur
Dienstaufruf-
Schnittstelle
Abbildung 3.21: Rolle des Dienstangebots beim Trading
Das Dienstangebot (SO) bzw. die dort enthaltenen Informationen verwaltet der
Trader in seiner Dienstangebotsverwaltung. Dort werden die Verweise auf die
Dienstaufrufschnittstelle und die Dienstangebotsauswertungsschnittstelle (SOEI)
gespeichert. In dem dargestellten Fall wird die Dienstangebotsauswertungsschnittstelle
vom Exporteur selbst realisiert. Sie kann alternativ aber auch durch
andere Komponenten, beispielsweise einem Attributmanagementsystem [Spr96],
bereitgestellt werden. Weiterhin werden in der Dienstangebotsverwaltung auch
die Diensttypinformationen gespeichert, die in einer der drei oben genannten Varianten
beschrieben sein konnen und imwesentlichen aus Typbezeichnern bestehen,
die auf die entsprechenden Typbeschreibungen im Typmanager verweisen.
Die operationale Schnittstelle des Typmanagers wird jedoch durch das Trader-

3.3 Vermittlung und Verwaltung von Dienstangeboten 83
standarddokument nicht festgelegt. 10 Dieses tri t auchauf die Art undWeise der
Benutzung der Dienstangebotsauswertungsschnittstelle, der Dienstangebotsverwaltungoder
des Typmanagers zu, die den jeweiligen Trader{Implementierungen
uberlassen ist.
3.3.2.3 Dienstangebotsauswahl
Mit dem Aufruf der ImportO er{Operation durch einen Importeur wird eine
Dienstanfrage (engl. service request) an den angesprochenen Trader gestellt (siehe
auch Abbildung 3.21). Die Dienstanfrage setzt sich aus den folgenden Einzelteilen
zusammen:
Importeurskennung (engl. client identi cation) fur Zwecke der Authentisierung
und Autorisierung
Ein oder mehrere Kontextnamen zur Einschrankung der Dienstangebotssuche
inder Dienstangebotsverwaltung des Traders
Diensttypbeschreibung zur Bezeichnung des gewunschten Diensttyps
Suchvorschriften (engl. importer policies) zur Steuerung des Dienstauswahlmechanismus
des Traders, beispielsweise zur Festlegung einer maximalen
Suchzeit oder einer bestimmten Suchstrategie
Geforderte Auswahlkriterien (engl. matching constraints), die in Form von
geschachtelten logischen Ausdrucken uber Werten von Dienstattributen,
beispielsweise costPerPage < 1.0 AND queueLength < 4 bei einer Anfrage
nach einem Druckdienstangebot, formuliert werden.
Bevorzugte Auswahlkriterien (engl. selection preferences), die hinausgehend
uber die geforderten Auswahlkriterien eine weitere Optimierung
der Dienstauswahl erlauben. Derartige Optimierungskriterien werden
ebenfalls in Form geschachtelter logischer Ausdrucke, beispielsweise
MAX(paperQuality) AND MIN(queueLength), ubergeben.
Gewunschte Dienstattribute (engl. service properties of interest), fur die
aktuelle Attributwerte zuruckgegeben werden sollen.
Gewunschte Dienstangebotseigenschaften (engl. service o er properties of
interest), fur die aktuelle Werte zuruckgegeben werden sollen.
Mit Hilfe dieser von einem Importeur gemachten Angaben ermittelt der Trader
passende Dienstangebote, wobei der Vorgang der Dienstangebotsauswahl durch
das Trader{Standarddokument nicht spezi ziert ist.
Eine mogliche, durch die Bestandteile eines Dienstangebots naheliegende Realisierungsvariante
ist die der gesta elten Auswertung [Kel93]. Grundlegende Idee
10 Zur Zeit be ndet sich dieStandardisierung einer Typrepository{Funktion [ODP95c, ISO95]
in Entwicklung, die auf den in Abschnitt 3.2 dargestellten Typverwaltungskonzepten basiert.

84 Zugang zu Diensten in heterogenen Umgebungen
dieses Auswertungsprinzips ist die Unterteilung des Dienstauswahlvorgangs in
verschiedene Auswertungsschritte. Ziel ist hierbei die Optimierung der Auswahl
des am besten\ geeigneten Dienstangebotes zu einer gegebenen Dienstanfrage.
"
Optimierungsaspekte sindvor allem die zeitliche Dauer der Auswahl und die
" Qualitat\ desgefundenen Dienstangebots, die sich anhand der Dienstattribute,
insbesondere der dynamischen, anwendungsspezi sch fur jeden Diensttyp festlegen
la t. Abbildung 3.22 verdeutlicht das Grundprinzip der gesta elten Auswertung.
Nicht dargestellt sinddie vom Importeur vorgebbaren Suchvorschriften,
die den Dienstauswahlproze in seiner Gesamtheit beein u en konnen.
Dienstanfrage
Diensttyp Kontexte
Suche
konformer
Diensttypen
Auswahl
diensttypkonformer
Dienstangebote
Geforderte
Auswahlkriterien
Auswertung
statischer
Dienstattribute
Auswertung
dynamischer
Dienstattribute
Abbildung 3.22: Prinzip der gesta elten Auswertung
Optimierungskriterien
Festlegung
einer qualitativen
Ordnung
In einem ersten Schritt wird mit Hilfe des dem Trader zugeordneten Typmanagers
die Menge aller diensttypkonformen Diensttypen ermittelt. Diese dienen anschlie
end zur Suche nach passenden Dienstangeboten im Dienstangebotsraum,
wobei die Suche durch die bei der Dienstanfrage angebbaren Kontexte eingeschrankt
werden kann. Anschlie end wertet der Trader die statischen und dynamischen
Dienstattributeder gefundenen Dienstangebotedanachaus, ob diese den
geforderten Auswahlkriterien entsprechen. Weiterhin werden abschlie end gegebenfalls
die Optimierungskriterien ausgewertet, die die nachgebliebenen Dienstangebote
nach den gewunschten Qualitatskriterien ordnen.
Durch die Berucksichtung dynamischer, sich hau g verandernder Dienstattribute,
beispielsweise der Warteschlangenlange bei einem Druckdienstanbieter, ist die
Dienstauswahl zu einer gegebenen Dienstanfrage nicht immer identisch, so da einem
Importeur zumeist unterschiedliche Dienstangebote vermittelt werden. Hier
ergibt sich auch der wesentliche Unterschied zu attributierten Namensdiensten,
die eine Dienstsucheausschlie lich aufgrundstatischer Kriterien durchfuhren und
somit immer dieselben Dienstangebote zuruckliefern. Der Unterschied von Tradern
zu Namensdiensten wird weiterhin auchdadurchdeutlich, da beim Trading
verschiedene Dienstauswahlstrategien zum Einsatz kommen konnen. Beispiele

3.3 Vermittlung und Verwaltung von Dienstangeboten 85
hierfur sind die in [TWW92, WT90] genannte zufallige Wahl, bei der aus einer
Menge geeigneter Dienstangebote ein einziges zufallig ausgewahlt wird,oder die
beste Wahl, bei der insbesondere die dynamischen Dienstattribute herangezogen
werden.
Ein grundsatzliches Problem der Nutzung dynamischer Dienstattribute ist die
Aktualitat der bei der Dienstauswahl genutzten Attributwerte. Da sie sich unter
Umstanden hau g andern konnen, ist die Aktualitat nur unter bestimmten einschrankenden
Kriterien, den sogenannten Aktualitatspradikaten [Kov92], gewahrleistet.
Ein Beispiel eines derartigen Aktualitatspradikates ist die sogenannte
Anderungsbedingung, die die obere Grenze nicht berucksichtigter Anderungen
eines Dienstattributes festlegt. Da ein Zugri auf dynamische Dienstattribute in
der Regel mit erhohtem Aufwand verbunden ist, kann hiermit die Anzahl notwendiger
Zugri e verringert werden, wobei jedoch der Verlust hochstmoglicher
Aktualitat ( " Beste{Moglichkeit{Bedingung\) akzeptiert werden mu . Welches
Aktualitatspradikat beim Tradingverwendet wird, hangt unter anderem von den
internen Verwaltungsvorschriften eines Traders undden vorhandenen systemtechnischen
Unterstutzungsmechanismen zum Zugri auf dynamische Dienstattribute
ab. Die oben genannte, vom ODP Trader{Standarddokument vorgeschlagene
Dienstangebotsauswertungsschnittstelle bietet hierfur eine Moglichkeit der Realisierung
einer standardisierten Zugri sschnittstelle. Eine konkrete Realisierung
unter Berucksichtigungeines auf Aktualitatspradikaten basierenden Attributmanagementsystems
[Spr96] zum Zugri auf Dienstattribute wird im Zusammenhang
mit dem TRADEr in Abschnitt 5.2.2.2 vorgestellt.
3.3.3 Verteilte Dienstangebotsvermittlung
Aufgrund der Gro e o ener, moglicherweise weltweit verteilter Dienstemarkte
ist die Annahme einer zentralisierten Dienstvermittlung aus Grunden der Skalierbarkeit
unrealistisch und auch angesichts der Existenz unterschiedlicher Verwaltungsdomanen
in dieser Form nicht durchfuhrbar. Ebenso wie das Diensttypmanagement
ist generell davon auszugehen, da auch die Dienstvermittlung
im allgemeinen in der lokalen Verantwortlichkeit einer bestimmten Verwaltungsdomane
liegt, so da jede Domane mindestens einen eigenen Trader zur Verwaltung
und Vermittlung der dort vorhandenen Dienstangebote besitzt, wie es
bereits amAnfang dieses Kapitels in Abbildung 3.2 angedeutet wurde.
Als Konsequenz der Autonomie der Verwaltungsdomanen ergibt sich ohneeine
domanenubergreifende Zusammenarbeit der Trader eine lokale Eingeschranktheit
der Dienstvermittlung, die sich darin au ert, da dort verwaltete Dienstangebote
nur innerhalb einer Domane zuganglich sind. Dieses betri t gleichermaen
die Importeure, die Dienstanfragen an den lokalen Trader stellen, und die
Exporteure, die ihre Dienste uber den lokalen Trader anbieten.Umauch Dienstangebote
anderer Verwaltungsdomanen nutzen bzw. dort anbieten zu konnen,
ergeben sich fur beide prinzipiell zwei Moglichkeiten.
Zum einen konnen sie sich explizit an Trader anderer Verwaltungsdomanen wenden,
wodurch sichdas primare Problem der Lokalisierung ergibt. Da dieses ein

86 Zugang zu Diensten in heterogenen Umgebungen
allgemeines Wissen uber das Vorhandensein und den genauen Ort anderer Tradern
erfordert, erscheint dieser Ansatz aus Grunden der Komplexitat und auch
aufgrund der Gro e verteilter Dienstemarkte und der dadurch zuerwartenden
Unubersichtlichkeit in der Regel jedoch als nicht praktikabel. Zusatzlich konnen
auch domaneninterne Verwaltungsvorschriften einen direkten Zugri externer
Importeure und Exporteure auf den dortigen Trader verhindern.
Als ein geeigneter Losungsansatz ergibt sich die Zusammenarbeit der in den Verwaltungsdomanen
vorhandenen Trader. In diesem Fall erfolgt der Zugri auf die
Dienstangebote der Trader anderer Domanen durch den lokalen Trader selbst,
so da der Vorgang der Dienstvermittlung weitgehend verborgen werden kann.
Fur den Importeur bedeutet dieses, da ihm nun trotz der ausschlie lichen Nutzung
des lokalen Traders auch Dienstangebotevon Tradern anderer Verwaltungsdomanen
vermittelt werden konnen, ohne da er uber die Kooperation Kenntnis
besitzen mu . Aus der Sicht eines Exporteurs bedeutet dies gleichzeitig eine Erweiterung
seiner Sichtbarkeit, so da nun auch Importeure anderer Domanen
sein Dienstangebot nutzen konnen.
3.3.3.1 Kooperationsformen von Tradern
Im folgenden werden als zwei Grundformen domanenubergreifender Trader{
Kooperationen die sogenannte indirekte und direkte Kooperation vorgestellt (siehe
zumVergleich auch [Mul96, MMaTT96]). Ausgangspunkt fur diese Unterscheidung
bildet die in Abbildung 3.23 dargestellte Struktur.
Typ-
Manager 1
Trader 1
Typ-
Manager 2
Trader 2
import(...,ServiceTypeId_Y,...) export(...,ServiceTypeId_X,...)
Importeur Exporteur
Abbildung 3.23: Komponenten einer Trader{Kooperation
Sie zeigt die potentiell an einer Trader{Kooperation beteiligten Systemkomponenten.
Im einzelnen sind dieses die Trader und dieihnen zugeordneten Dienstangebotsverwaltungen
und Typmanager. Die Dienstangebotsverwaltung ist hierbei
durch ein Symbol dargestellt, die je nach beabsichtigter Kooperationsform

3.3 Vermittlung und Verwaltung von Dienstangeboten 87
grundsatzlichsowohl durch die Trader selbst oder durcheine externeKomponente
bereitgestellt werden kann. Die gestrichelte Linie in der Mitte der Abbildung
verdeutlicht die bereits schon am Anfang dieses Kapitels beschriebene Heterogenitatsgrenze
zwischen den Verwaltungsdomanen. Hierbei werden im folgenden
vor allem die administrativen Fragestellungen der dort auftretenden Heterogenitatsproblemeerortert,
die das Verstandnis und den Austauschvon Typinformationen
zwischen den Tradern der kooperierenden Verwaltungsdomanen betre en.
Aus diesem Grund spielt insbesondere das in der Abbildung dargestellte Typmanagement
eine zur Unterstutzung von Trader{Kooperationen grundlegende
Komponente, mit deren Hilfe trotz der administrativen Heterogenitatsprobleme
zwischen zwei Verwaltungsdomanen die Interoperabilitat auf der Verarbeitungsebene
gewahrleistet werden kann (siehe Abschnitte 3.1.1 und 3.2). Dieses gilt
auch fur die Uberwindung der technischen Heterogenitatsprobleme, auf die Abschnitt
3.4 separat eingeht.
Eine hier bereits sichtbare Problematik der verteilten Dienstvermittlung ist die
Gultigkeit von Typbezeichnern, die bereits inAbschnitt 3.2.3.1 im Rahmen des
verteilten Typmangements angesprochen wurde. Da Typbezeichner nur jeweils
innerhalb einer Verwaltungsdomanefur einen bestimmten Typmanager eine Bedeutung
besitzen, mussen dementsprechend Vereinbarungen getro en werden,
auf deren Grundlage ein gemeinsames Typverstandnis erreicht wird. Fur die
weitere Darstellung wirddavon ausgegangen, da der durch ServiceTypeId X
bezeichnete Diensttyp konform zu dem durch ServiceTypeId Y bezeichneten
ist, so da als Resultat einer moglichen Kooperation beider Trader das vom Exporteur
bei Trader 2 registrierte Dienstangebot dem Importeur bei Trader 1
vermittelt werden kann.
Indirekte Kooperation Eine Variante einer Trader{Kooperation bildet die
in Abbildung 3.24 dargestellte indirekte Kooperation.
Trader 1
Typ-
Manager
Trader 2
import(...,ServiceTypeId_Y,...) export(...,ServiceTypeId_X,...)
Importeur Exporteur
Abbildung 3.24: Indirekte Trader{Kooperation

88 Zugang zu Diensten in heterogenen Umgebungen
Hauptkennzeichen dieser Kooperationsform ist die Nutzung gemeinsamer
Dienstangebotsraume, auf die von den beteiligten Tradern gleicherma en lesend
und schreibend zugegri en werden kann und uber die sie indirekt kooperieren.
Als direkte Konsequenz dieser Indirektion ergibt sich, da nur die Nutzung eines
standardisierten Ablageformats fur Dienstangebote vereinbart werden mu , so
da diese auf einheitliche Art und Weise im Dienstangebotsraum gelesen und
gespeichert werden konnen. Da keine direkte Interaktion zwischen den Tradern
selbst statt ndet, konnen diese in den sonstigen Aspekten der Implementierung
voneinander di erieren. So ist es nicht zwingend notwendig, sich bei der
Realisierung der nach au en angebotenen operationalen Schnittstellen an einen
gemeinsamen Schnittstellenstandard zu halten, wie er beispielsweise durch das
ODP{basierte Trading de niert wird.
Ein weiterer notwendiger Gegenstand der Standardisierung ist die Festlegung
eines einheitlichen Diensttypverstandnisses, da ansonsten die im gemeinsamen
Dienstangebotsraum abgelegten Dienstangebote nicht sinnvoll von den beteiligten
Tradern genutzt werden konnen. Ein moglicher Losungsansatz ist in der
Abbildung durch die Nutzung eines gemeinsamen Typmanagers dargestellt. Bezogen
auf die einleitend angefuhrte Problematik der Gultigkeit von Typbezeichnern
bedeutet dieses, da in diesem Fall alle Trader bzw. Importeure und Exporteure
dieselben Typbezeichner benutzen, wodurch implizit ein einheitliches
Typverstandnis gewahrleistet ist.
Aufgrund der beiden einschrankenden Voraussetzungen eignet sich der Ansatz
der indirekten Kooperation vor allem fur die Kooperation von Tradern innerhalb
einer Verwaltungsdomane. Hierdurch konnen beispielsweise aus Grunden
der Lastverteilung auf einfache Art und Weise neue Trader hinzugefugt werden,
ohne da weitgehende administrative Ma nahmen notwendig sind. Der Ansatz
ist jedochauchfur zwei verschiedeneVerwaltungsdomanen interessant, wenn von
vornherein die mogliche Anzahl von Diensttypen, zu denen konkrete Dienstangebote
vermittelbar sind, eingeschrankt ist. In diesem Fall ist der vorherige Austausch
der gemeinsam genutzten Typbezeichner sinnvoll, so da auf diese Weise
ein einheitliches Typverstandnis erreicht wird. In diesem Zusammenhangmussen
auch mogliche Sicherheitsfragen geklart werden, die beispielsweise die Speicherung
von Dienstangeboten in bestimmten Kontexten oder aber das Loschen von
Dienstangeboten betre en.
Ein moglicher Losungsansatz fur die gemeinsame Ablage von Dienstangeboten
sind die in Abschnitt 3.3.1.1 vorgestellten Namensdienste, die sich insbesondere
durch dieMoglichkeit der Verwaltung von Kontexten auszeichnen, in
denen Dienstangebote strukturiert verwaltet werden konnen. Vor allem X.500
[Rad94] bietet hierfur eine geeignete Verwaltungsinfrastruktur, die auch eine
globale Verteilung von Dienstangebotsinformationen und somit eine indirekte
Trader{Kooperation uber gro e Distanzen hinweg erlaubt. Architekturelle
Grundkonzepte fur X.500{basierteTrader{Kooperationen nden sich in [AA91],
[PM93], [RH95] und [WB95], wobei die letztgenannte Arbeitdas im Trader{
Standarddokument [ODP94b] festgelegte X.500{Speicherformatfur Dienstangebote
verwendet. Ein alternativer X.500{basierter Ansatz ndet sich auch indem

3.3 Vermittlung und Verwaltung von Dienstangeboten 89
in dieser Arbeit entwickelten und realisierten TRADEr, der in Abschnitt 5.2.2
beschrieben wird.
Alternativ zu globalen Namensdiensten eignet sich fur eher lokal zusammenhangende
Verwaltungsdomanen auch der Einsatz verteilter Datenbanken,
wie er beispielsweise in [CR91] beschrieben ist.
Direkte Kooperation Wesentlicher Unterschied zur indirekten, auf der Nutzung
gemeinsamer Dienstangebotsraume basierenden Kooperationsform ist die
direkte Interaktion der Trader untereinander. Damit diese Kooperation geordnet
ablaufen kann, ist die De nition eines standardisierten Kooperationsprotokolls
erforderlich, das sowohl die fur die Kooperation relevanten operationalen Aufrufschnittstellen
der Trader und ihrer Semantik als auch die Art und Weise festlegt,
wie der Kooperationsvorgang genau durchzufuhren ist.
Wird hierbei zunachst wie bei der oben vorgestellten indirekten Kooperationsform
von einem gemeinsamen Typverstandnis ausgegangen, ergibt sich die in
Abbildung 3.25 gezeigte Struktur, wobei beide Trader wiederum auf einen gemeinsamen
Typmanager zugreifen.
Trader 1
Typ-
Manager
Trader 2
import(...,ServiceTypeId_Y,...) export(...,ServiceTypeId_X,...)
Importeur Exporteur
Abbildung 3.25: Protokollgesteuerte, direkte Trader{Kooperation
Anstelle der Nutzungeines gemeinsamen Dienstangebotsraumes kooperieren Trader
1 und 2 unmittelbar miteinander, um Dienstangebote gegenseitig auszutauschen.
Als Konsequenz ergibt sich, da jeder Trader uber seine eigene Dienstangebotsverwaltung
verfugen kann und somit auch ein gemeinsames Ablageformat
fur Dienstangebote nicht mehr zwingend verwendet werden mu .
Wie der direkte Austausch von Dienstangebotsinformationen zwischen den kooperierenden
Tradern konkret ablauft, hangt von dem gewahlten Kooperationsprotokoll
ab. Generell kann hierbei eine Import{ oder eine Export{orientierte
Sichtweise zugrunde gelegtwerden. Im ersten Fall agiert der Trader 1 als Impor-

90 Zugang zu Diensten in heterogenen Umgebungen
teur des Traders 2, anden er die ursprunglich bei ihm gestellte Dienstanfrage
weitergibt. Im zweiten Fall exportiert Trader 2 die bei ihm registrierten Dienstangebote
automatisch bei Trader 1, der sie dort in seinen Dienstangebotsraum
einfugt und den Importeuren seiner Verwaltungsdomane zur Verfugung stellt.
Trader 1 kann nun seinerseits ebenfalls das Dienstangebot an andere ihm bekannte
Trader weitergeben. Dies gilt im Prinzip auch fur die Dienstanfrage im
Import{orientierten Fall. Ein sich aus der Export{orientierten Variante ergebender
Nachteil ist jedoch, da beim Zuruckziehen eines Dienstangebots wiederum
samtliche Trader kontaktiert werden mussen, welches angesichts einer moglichen
Vielzahl beteiligter Trader in der Regel recht aufwendig ist. Desweiteren
ist eine explizite Verwaltungsfunktion erforderlich, die Buch uber die an andere
Trader exportierten Dienstangebote fuhrt, damit diese spater ordnungsgema
zuruckgezogen werden konnen. Demgegenuber steht beider Import{orientierten
Vorgehensweise der Verwaltungsaufwand, der fur das spatere Einsammeln der
weitergereichten Dienstanfragen notwendig ist.
3.3.3.2 Aufbau direkter Trader{Kooperationen
Damit eine direkteTrader{Kooperation zwischen zwei Tradern statt nden kann,
mu vorher eine Verknupfung zwischen ihnen aufgebaut werden. Das ODP{
Standarddokument [ODP94b]de niert hierzu Links, die unidirektionale Verweise
auf andere Trader darstellen. Sie werden in jedem Trader in seinem Link{Raum
(engl. trader link space) lokal verwaltet und beinhalten unter anderem die Bindungsinformationen
zum verknupften Trader. Ein Link ist weiterhin beschrieben
durch sogenannte Link{Eigenschaften (engl. link properties), mit denen bestimmte
Informationen, beispielsweise uber den Typmanager des anderen Traders, abgelegt
werden konnen. KonkreteAuspragungen von Link{Eigenschaften sind zur
Zeit jedoch nicht explizit im Standardddokument festgelegt. Nach Aufbau eines
Links kann der damit bezeichnete Trader von Seiten des diesen Link verwaltenden
Traders im Rahmen einer Trader{Kooperation genutzt werden. Hierbei
tritt der initiierende Trader dem im Link bezeichneten Trader in der Rolle eines
Importeurs gegenuber, indem er dort die entsprechende Operation importOffer
aufruft. Diese Import{orientierte 11 Sichtweise ist in Abbildung 3.26verdeutlicht.
Der gestrichelte Pfeil bezeichnet einen von Trader A ausgehenden Link zu Trader
B. Uber diesen Link wird die vom Importeur an Trader A gestellte Dienstanfrage
zu Trader B weitergegeben. Anschlie end erhalt Trader A die gewunschten
Dienstangebote zuruck und ubergibt sie letztendlich unter Hinzufugen der von
ihm selbst in seinem Angebotsraum gefundenen Dienstangebote anden Importeur.
Bedingt durch die Dezentralisierung der Link{Verwaltung kann sich bei der Kooperation
mehrerer Trader ein vermaschtes Netz ergeben, wie es beispielsweise
in Abbildung 3.27 verdeutlicht ist. Das entstandene Netz wird auch als Trading{
Graph bezeichnet. Links kennzeichnen einen moglichen Weg im Trading{Graph,
11 Prinzipiell la t sich mit Links auch ein Export{orientierter Ansatz realisieren. Dieser ndet
im Trader{Standarddokument jedoch keine Erwahnung.

3.3 Vermittlung und Verwaltung von Dienstangeboten 91
Link
Trader A Trader B
ImportOffer
ImportOffer
Importeur
Abbildung 3.26: Verknupfung von Tradern durch Links
auf dem eine aneinen Trader gestellte Dienstanfrage an andere Trader weitergereicht
werden kann. Ob und auf welche Art und Weise Links bei der Dienstangebotsvermittlungdurch
einen Trader verwendet werden, hangt unter anderem von
den jeweiligen Verwaltungsvorschriften des Traders selbst und insbesondere auch
von den durch den Importeur vorgegebenen Suchvorschriften ab. Beispielsweise
kann hierdurch die moglicheSuchtiefe eingeschrankt werden, so da die in Abbildung
3.27durch fett gezeichnete Pfeile angedeutete Dienstanfrage bei Trader B
endet und nicht anTrader E weitergegeben wird. Ein derartiges Vorgehen ist im
Trader{Standarddokument jedoch nicht explizit spezi ziert, sondern den jeweiligen
Trader{Implementierungen uberlassen. Dieses betri t grundsatzlich auch
die Behandlung von moglicherweise vorhandenen Zyklen im Trading{Graphen.
Ebenso das Weiterreichen einer Dienstanfrage an mehrere Trader gleichzeitig
(beispielsweise von Trader C an A und E) und das spatere Zusammenfugen der
Teilergebnisse sind durch dieTrader{Implementierungen selbst zu losen.
ImportOffer
Trader B
ImportOffer
Trader A
Trader D
Trader C
Trader E
Abbildung 3.27: Weiterreichen einer Dienstanfrage

92 Zugang zu Diensten in heterogenen Umgebungen
3.3.3.3 Kooperationsprotokolle
Die Nutzung eines gemeinsamen Typmanagers, wie es in der obigen Abbildung
3.25 dargestellt wurde, ist in o enen verteilten Dienstemarkten aufgrund der administrativen
Heterogenitat der beteiligten Verwaltungsdomanen in der Regel
nicht realisierbar. Im allgemeinen ist deshalb von der in Abbildung 3.28 gezeigten
Struktur auszugehen, in der jede Verwaltungsdomane fur die Aspekte der
Dienstvermittlung, des Typmanagements und der Dienstangebotsverwaltung eigenstandig
und weitestgehend autonom verantwortlich ist.
Typ-
Manager 1
Trader 1
Typ-
Manager 2
Trader 2
import(...,ServiceTypeId_Y,...) export(...,ServiceTypeId_X,...)
Importeur Exporteur
Abbildung 3.28: Typmanager{unterstutzte Trader{Kooperation
Ein Exporteur registriert sein Dienstangebot beim Trader 2 mit dem durch den
Typbezeichner ServiceTypeId X bezeichneten Diensttyp ServiceType X, dessen
dazugehorige Diensttypbeschreibung inTypmanager 2 verwaltet wird. Anschlie
end stellt ein Dienstnutzer, der Importeur, eine Dienstanfrage an den Trader
1, wobei der gewunschte Diensttyp ServiceType Y durch ServiceTypeId Y
bezeichnet ist, welcher seinerseits auf die entsprechende Diensttypbeschreibung
in Typmanager 1 verweist. Dabei wird im folgenden davon ausgegangen, da
beide Diensttypen ServiceType X und ServiceType Y entweder aquivalentsind
oder ServiceType X konform zu ServiceType Y ist. Weiterhin besteht von Trader
1 zu Trader 2 ein unidirektionaler Link, wobei von einer Import{orientierten
Sichtausgegangenwird,inder Trader 1 wahrenddes Kooperationsvorganges vom
Importeur an ihn gerichtete Dienstanfragen an Trader 2 stellvertretend weitergibt.
Generell konnen in Anlehnung an [VBB95] mehrere verschiedene Moglichkeiten
zur Durchfuhrung einer derartigen Import{orientierten Trader{Kooperation unterschieden
werden, wobei die hier zuletzt vorgestellteeine Erweiterungder dort
beschriebenen Varianten darstellt (siehe zumVergleich auch [CM95]):

3.3 Vermittlung und Verwaltung von Dienstangeboten 93
Ignorante Vorgehensweise:
In diesem Fall ignoriert Trader 1 die Heterogenitatsgrenze und verwendet
bei der Dienstanfrage an Trader 2 den innerhalb seiner Verwaltungsdomane
gultigen Bezeichner ServiceTypeId Y. Damit Trader 2 diesen Bezeichner
innerhalb seiner eigenen Verwaltungsdomanenutzen kann, mu er diesen in
einen dort gultigen Bezeichner ServiceTypeId X umwandeln. Erst danach
kann er geeignete Dienstangebote ermitteln und gegebenfalls an Trader 1
zuruckgeben.
Bewu te Vorgehensweise:
Im Unterschied zum ersten Fall ist Trader 1 das Vorhandensein einer Heterogenitatsgrenze
bewu t, soda er vor dem Weiterreichen der Dienstanfrage
als erstes den innerhalb seiner Verwaltungsdomane gultigen Bezeichner
ServiceTypeId Y in einen innerhalb der Verwaltungsdomane von Trader
2 gultigen Bezeichner ServiceTypeId X umwandelt.
Standardisierte Vorgehensweise:
Ein dritte Moglichkeit ist die domanenubergreifendeStandardisierung von
Typbezeichnern und Diensttypbeschreibungssprachen bzw. {reprasentationen.
Standardisierte Typbezeichner besitzen hierbei uberall dieselbe Bedeutung,
so da sie unmittelbar weitergegeben werden konnen. Eine Alternative
zuden Typbezeichnern stellt die Verwendung einer einheitlichen
Diensttypbeschreibung dar (siehe auch Abschnitt 2.1), mit denen Diensttypen
auf einheitliche Art und Weise beschrieben werden konnen. Hierdurch
wirdesmoglich, Dienstbeschreibungen mit ihren samtlichen Beschreibungsbestandteilen
zu ubergeben, die anschlie end ohne weitere Umwandlungen
unmittelbar durchden domaneninternen Typmanager interpretiert
werden konnen.
Sowohl im ignoranten als auch im bewu ten Fall 12 mu der vom Importeur vorgegebene
Typbezeichner ServiceTypeId Y in einen vom Typmanager 2 interpretierbaren
umgewandelt werden. Dies geschieht generell in zwei Schritten:
Der erste Schritt besteht inder Au osung bzw.Umwandlung des Typbezeichners
ServiceTypeId Y in die dazugehorige Diensttypbeschreibung
ServiceTypeDesc Y. Dieser wird von Typmanager 1 durchgefuhrt.
Im zweiten Schritt dient diese dem Typmanager 2 zur Suche nach
einem in seiner Verwaltungsdomane konformen Diensttyp, in diesem
Fall ServiceType X, so da letztendlich der Diensttypbezeichner
ServiceTypeId X der entsprechenden Diensttypbeschreibung gefunden
wird.
In Abhangigkeit von den beteiligten Systemkomponenten kann dieser Umwandlungsvorgang
inzwei unterschiedlichen Varianten erfolgen:
12 Diese beiden Falle konnen im Englischen in Analogie zur Terminologie bei der Netzwerkkommunikation
pragnant auch als " Receiver makes it right\ bzw. " Sender makes it right\
bezeichnet werden.

94 Zugang zu Diensten in heterogenen Umgebungen
Trader{gesteuerte Kooperation:
In dieser Variante sind die Trader, im bewu ten Fall Trader 1 und
im ignoranten Fall Trader 2, fur die Steuerung des Umwandlungsvorganges
verantwortlich. Die Trader erhalten zunachst von Typmanager
1 die zum Typbezeichner ServiceTypeId Y zugehorige Typbeschreibung
ServiceTypeDesc Y, die anschlie end anTypmanager 2 ubergeben wird.
Typmanager{gesteuerte Kooperation:
Im Unterschied zur Trader{gesteuerten Variante ubernehmen hier die den
Tradern zugeordneten Typmanager die Steuerung des Umwandlungsvorganges.
In diesem Fall ist eine von der Trader{Kooperation unabhangige
Typmanager{Kooperation bzw. Typmanagerfoderation (siehe auch Abschnitt
3.2.3) notwendig.
In beiden Fallen mu eine Einigung auf eine gemeinsame Diensttypbeschreibung
erfolgen, damit die vom Typmanager 1 erzeugten Typinformationen vom Typmanager
2 interpretiert werden kann. Im zweiten Fall ist hierbei eine Absprache
zwischen den Typmanagern erforderlich, wahrend im ersten Fall sich Trader
und Typmanager verstandigen mussen. GrundlegendeVoraussetzungistauchdie
Nutzung global eindeutiger Typbezeichner, beispielsweise in der in Abschnitt
3.2.3.1 vorgeschlagenen Form, so da fur jeden Typbezeichner eine eindeutige
Zuordnung zudem diesen Bezeichner verwaltenden Typmanager gewahrleistet
ist.
Bei Kombination der oben beschriebenen Falle ergeben sich insgesamtsechs verschiedene
Varianten zur Realisierung domanenubergreifender, direkter Trader{
Kooperationen. Diese werden im folgenden genauer beschrieben und miteinander
verglichen, wobei auch die Operationen herausgestellt werden, die vom Typmanagement
zur Unterstutzungderartiger Trader{Kooperationen zur Verfugung zu
stellen sind.
Variante 1: Ignorante, Typmanager{gesteuerte Kooperation
Trader 1 (siehe Abbildung 3.29) ignoriert in diesem Fall das Vorhandensein der
Heterogenitatsgrenze und reicht die vom Importeur gestellte Dienstanfrage, die
unter anderem den geforderten, durch den Typbezeichner ServiceTypeId Y bezeichneten
Diensttyp enthalt, unverandert an Trader 2 weiter. Wahrenddes darau
olgenden Dienstauswahlproze es ubergibt Trader 2 diesen Typbezeichner an
den ihm lokal in seiner Verwaltungsdomane zugeordneten Typmanager 2, um
weitere konforme Diensttypen ermitteln zu lassen, die anschlie end zur Suche
nach geeigneten Dienstangeboten genutzt werden. Anhand der im globalen Typbezeichner
vorhandenen TypmanagerkennungerkenntTypmanager 2, da es sich
um einen von Typmanager 1 erzeugten Bezeichner handelt. Als erstes wendet er
sichdeshalb anTypmanager 1,um die von ihm unterstutzten Diensttypbeschreibungssprache
zuerfahren. Anschlie end wahlt ereineder von beiden Typmanagern
unterstutzten Beschreibungssprachen aus und fordert die zum Diensttypbezeichner
ServiceTypeId Y gehorige Diensttypbeschreibung ServiceTypeDesc Y

3.3 Vermittlung und Verwaltung von Dienstangeboten 95
Typmanager
1
Trader 1
4. GetTypeDescLanguages(...)
2.
1. import(...,ServiceTypeId_Y,...)
5. ServiceTypeDesc_Y=
GetTypeDesc(ServiceTypeId_Y,...)
import(...,ServiceTypeId_Y,...)
Typmanager
2
FindAllRelatedTypes
(ServiceTypeId_Y,...)
Trader 2
Importeur Exporteur
3.
export(...,ServiceTypeId_X,...)
Abbildung 3.29: Ignorante, Typmanager{gesteuerte Trader{Kooperation
an. Hiermit ermittelt der Typmanager 2 samtliche in seinem De nitionsbereich
vorhandenen konformen Diensttypen, unter denen einer ServiceType X
ist. Letztendlich wirddas Dienstangebot des in der Abbildung dargestellten Exporteurs
als ein Teilresultat der Dienstanfrage an Trader 1 zuruckgegeben, der
es seinerseits anden Importeur weitergibt.
Variante 2: Ignorante, Trader{gesteuerte Kooperation
Typ- Typmanager
1 manager 2
Trader 1 Trader 2
Importeur
4. GetTypeDescLanguages(...)
5. ServiceTypeDesc_Y =
GetTypeDesc(ServiceTypeId_Y,...)
2. import(...,ServiceTypeId_Y,...)
3. GetTypeDescLanguages(...)
6. FindAllRelatedTypes
(ServiceTypeDesc_Y,...)
1. import(...,ServiceTypeId_Y,...)
export(...,ServiceTypeId_X,...)
Exporteur
Abbildung 3.30: Ignorante, Trader{gesteuerte Trader{Kooperation

96 Zugang zu Diensten in heterogenen Umgebungen
In diesem Fall wird im Vergleich zur vorherigen Variante die Umwandlung
des von Trader 1 bei der Dienstanfrage verwendeten Typbezeichners
ServiceTypeId Y anstelle von Typmanager 2 durch Trader 2 selbst durchgefuhrt.
Hierzu ermittelt er die Dienstbeschreibungssprachen, die sowohl von
Typmanager 1 als auch von seinem eigenen Typmanager unterstutzt werden.
Anschlie end fordert er von Typmanager 1 die zu ServiceTypeId Y gehorende
Diensttypbeschreibung ServiceTypeDesc Y in einer der gefundenen Beschreibungssprachen
an. Diese ubergibt er Typmanager 2, der auf dieser Grundlage
konforme Diensttypen sucht. Der weitere Ablauf erfolgt analog zum obenbereits
beschriebenen.
Variante 3: Bewu te, Trader{gesteuerte Kooperation
Typ- Typ-
Manager 1
Manager 2
2. GetTypeDescLanguages(...)
3. GetTypeDescLanguages(...) 5. ServiceTypeId_X =
4. ServiceTypeDesc_Y =
GetTypeId(ServiceTypeDesc_Y,...)
GetTypeDesc(ServiceTypeId_Y,...)
1.
6. import(...,ServiceTypeId_X,...)
Trader 1 Trader 2
import(...,ServiceTypeId_Y,...)
export(...,ServiceTypeId_X,...)
Importeur Exporteur
Abbildung 3.31: Bewu te, Trader{gesteuerte Trader{Kooperation
Im Gegensatz zu den obigen ignoranten Varianten wird die Umwandlungdes vom
Importeur bei der Dienstanfrage verwendeten, nur in Verwaltungsdomane1gultigen
Typbezeichners ServiceTypeId Y von Trader 1 vor dem Weiterreichen der
Dienstanfrage an Trader 2 durchgefuhrt. Hierzu bestimmt er als erstes eine von
beiden Typmanagern unterstutzte Typbeschreibungssprache und la t sich von
Typmanager 1 die Diensttypbeschreibung ServiceTypeDesc Y zuruckgeben 13 .
Diese wird anschlie end dem Typmanager 2 weitergereicht, der aufgrund dieser
Typbeschreibung inseinem De nitionsbereich konforme Diensttypen sucht. Bei
erfolgreicher Suche wird ein dort gultiger Diensttypbezeichner, in diesem Fall
beispielsweise ServiceTypeId X, anTrader 1 zuruckgereicht, der nachfolgend
diesen Typbezeichner bei der Dienstanfrage an Trader 2 verwendet.
13 In systemtechnischer Betrachtung erfolgt die Ruckgabe der Diensttypbeschreibung mit
Hilfe einer geeigneten Diensttypreprasentation (siehe Abschnitt 2.1), die durch das Kooperationsprotokoll
vorab festgelegt ist.

3.3 Vermittlung und Verwaltung von Dienstangeboten 97
Der von Typmanager 2 als Resultat dieser Anfrage gelieferte Diensttyp
ServiceType X sollte hierbei generell mit dem geforderten Diensttyp moglichst
weitgehend ubereinstimmen, d.h. entweder aquivalent oder ein direkter Subtyp
in der Hierarchie der zu diesem Diensttyp konformen Diensttypen sein. Anderenfalls
wurde beider spateren Anfrage nach konformen Diensttypen von
Trader 2 an seinen Typmanager nur ein Teil der zum ursprunglich geforderten
Diensttyp ServiceType Y konformen Diensttypen gefunden werden. Dieses
konnte dann unter Umstanden bedeuten, da das Dienstangebot des in der
Abbildung dargestellten Exporteurs nicht vermittelt wird, falls ServiceType X
ein Supertyp des zuruckgegebenen Diensttyps ist.
Variante 4: Bewu te, Typmanager{gesteuerte Kooperation
Typ- 3. GetTypeDescLanguages(...)
Typ-
Manager 1
Manager 2
2. ServiceTypeId_X =
4. ServiceTypeId_X=
GetTypeID(ServiceTypeDesc_Y,...)
GetForeignTypeId(ServiceTypeId_Y,TM2,...)
5. import(...,ServiceTypeId_X,...)
Trader 1 Trader 2
1. import(...,ServiceTypeId_Y,...)
export(...,ServiceTypeId_X,...)
Importeur Exporteur
Abbildung 3.32: Bewu te, Typmanager{gesteuerte Trader{Kooperation
Im Vergleich zurbewuten, Trader{gesteuerten Variante ubernimmt hier der
Typmanager 1 die Steuerung des Umwandlungsproze es. Hierzu ubergibt
Trader 1 ihm zuerst den Diensttypbezeichner ServiceTypeId Y und die Schnittstellenkennung
von Typmanager 2. Nach Abstimmung einer gemeinsamen
Typbeschreibungssprache reicht erTypmanager 2 die Diensttypbeschreibung
ServiceTypeDesc Y weiter, der wie schon im Trader{gesteuerten Fall einen
Typbezeichner ServiceTypeId X eines zu dieser Typbeschreibung konformen
Dienststyps zuruckgibt. 14 Dieser wird anschlie end Trader 1 weitergereicht, der
ihn bei der Dienstanfrage an Trader 2 verwendet. Anschlie end wird dieser zur
Ermittlung konformer Diensttypen durch Typmanager 2 genutzt.
14 Alternativ konnte Typmanager 2 auch samtliche von ihm gefundene Diensttypbezeichner
zuruckreichen, wodurch sich die erneute Suche nach konformen Diensttypen durch Trader 2
nach Ubergabe der Dienstanfrage von Trader 1 vermeiden la t. Dieses gilt ebenfalls fur den
Trader{gesteuerten Fall.

98 Zugang zu Diensten in heterogenen Umgebungen
Variante 5:Standardisierte Diensttypbeschreibung
Typ- Typ-
Manager 1
Manager 2
2. CanonicalDesc_Y =
GetTypeDesc(ServiceTypeId_Y,
CanoncialTypeDescLanguage)
4. FindAllRelatedTypes
(CanonicalDesc_Y,...)
3. import(...,CanonicalDesc_Y,...)
Trader 1 Trader 2
1. import(...,ServiceTypeId_Y,...)
export(...,ServiceTypeId_X,...)
Importeur Exporteur
Abbildung 3.33: Trader{Kooperation basierend auf standardisierten Diensttypbeschreibungen
Bei dieser Variante unterstutzen alle beteiligten Typmanager und Trader eine
vorab festgelegte Typbeschreibungssprache. Diese wird von Trader 1 an Trader
2 zum Austausch von Diensttypbeschreibungen, in diesem Fall CanonicalDesc
Y, bei der Dienstanfrage genutzt, wodurch die Umwandlung von Diensttypbezeichner
beim Uberschreiten der Heterogenitatsgrenze beider Trader entfallt.
Innerhalbder Verwaltungsdomanen kann jedoch weiterhin von Seiten der Importeure
und Exporteure mit den dort gultigen Typbezeichner gearbeitet werden.
Im Vergleich zuden obigen ignoranten und bewu ten Varianten gestaltet sich
die Abwicklung einer auf standardisierten Diensttypbeschreibungen basierenden
Trader{Kooperation relativ einfach, da au er dem Weiterreichen der Dienstanfrage
von Trader 1 an Trader 2 keine weiteren domanenubergreifenden Interaktionen
zwischen den Typmanagern notwendig sind. Dieses tri t auchfur den Fall
zu, in dem ahnlich wie bei den bewu ten Kooperationsvarianten eine zusatzliche
dynamische Abstimmung der gemeinsamen Typbeschreibungssprache vorab
erfolgt. Konkret wurde dieses eine zusatzliche Anfrage von Trader 1 bei Typmanager
1 und 2verursachen, wobei anschlie end einevon beiden unterstutzte
Beschreibungssprache gewahlt werden wurde.
Variante 6:Standardisierte Diensttypbezeichner
Eine weitere Moglichkeit zur Durchfuhrung von Trader{Kooperationen ist die in
Abbildung 3.34 gezeigteVerwendungstandardisierter Diensttypbezeichner, die in
allen Verwaltungsdomanen dieselbe Bedeutung besitzen bzw. denselben Diensttyp
bezeichnen. Trader 1 kann in diesem Fall die vom Importeur ankommende
Dienstanfrage ohne weitere Umwandlungen des Diensttypbezeichners an Trader

3.3 Vermittlung und Verwaltung von Dienstangeboten 99
Typ- Typ-
Manager 1
Manager 2
Trader 1
1. import(...,CanonicalTypeId,...)
2. import(...,CanonicalTypeId,...)
3.
FindAllRelatedTypes
(CanonicalTypeId,...)
Trader 2
export(...,ServiceTypeId_X,...)
Importeur Exporteur
Abbildung 3.34: Trader{Kooperation basierend auf standardisierten Diensttypbezeichnern
2 weitergeben, wodurch sich wie beim obigen Fall der standardisierten Diensttypbeschreibung
diefur die Trader{Kooperation notwendigen Interaktionen auf
ein Minimum beschranken.
Die De nition der entsprechenden Diensttypbeschreibung und die Vergabe des
dazugehorigen Bezeichners mu fur die beteiligten Verwaltungsdomanen verbindlich
durcheine ubergeordneteAutoritat bestimmtwerden. Dabei sollten standardisierte
Bezeichner explizit kenntlich gemacht werden, um sie von den sonstigen
Typbezeichnern unterscheiden zu konnen. Beim Weiterreichen an einen Trader
oder Typmanager konnen diese hierdurch sofort erkannt werden. Ein hierfur geeigneter
Losungsansatz zur Identi zierung standardisierter Typbezeichner sind
dieinAbschnitt 3.2.3.1 beschriebenen global eindeutigen Typbezeichner, die
die Festlegung eines Bezeichnertyps erlauben. Da die Menge der zukunftig zu
standardisierenden Diensttypen bzw. der dazugehorigen Diensttypbezeichner von
vornherein nicht vorbestimmt ist, ist generell zu erwarten, da ein Typmanager
die zu einem standardisierten Typbezeichnern gehorende Diensttypbeschreibung
nicht kennt. Fur diesen Fall sollte ein durch die Standardisierungsautoritat
ein wohlbekannter Ablageort de niert werden, bei dem die zu standardisierten
Dienstttypbezeichnern gehorigen Typbeschreibungen abrufbar sind.
Berucksichtigung von Beziehungstypen
Bei der obigen Darstellung der sechs verschiedenen Trader{Kooperationsprotokolle
wurde insbesondere die Konformitatsbeziehung zwischen Diensttypen
implizit zugrundegelegt und davon ausgegangen, da diese in den an der
Trader{Kooperation beteiligten Verwaltungsdomanen uberall dieselbe Semantik

100 Zugang zu Diensten in heterogenen Umgebungen
besitzt 15 . Wird zusatzlichberucksichtigt, da Typmanager generell die De nition
beliebiger Beziehungstypen erlauben sollten, erscheint es bei einer Dienstanfrage
sinnvoll, neben der Diensttypbeschreibung auch eine Beziehungstypbeschreibung
anzugeben, die im weiteren Auswahlproze zur Suche nach | in Bezug
auf die De nition des Beziehungstyps | kompatiblen Diensttypen durch den
Typmanager verwendet wird. So konnen unter anderem auch eingeschranktere
Konformitatsbeziehungen, wie beispielsweise die von CORBA oder DCE, bei
der Dienstauswahl genutzt werden. Unter Berucksichtigung von Beziehungstypbezeichnern
ergibt sich die in Abbildung 3.35 dargestellte Struktur.
4. RelationId_B =TranslateRelation
(RelationId_A,TM2)
Typ- Typ-
Manager 1 5.
6.
Manager 2
GetTypeDescLanguages(...)
ServiceTypeDesc_Y =
GetTypeDesc(ServiceTypeId_Y,...)
Trader 1
2. import(...,ServiceTypeId_Y, Trader 2
1. import(...,ServiceTypeId_Y,RelationId_A,...)
RelationId_A,...)
3. FindAllRelatedTypes
(ServiceTypeId_Y,
RelationId_A,...)
export(...,ServiceTypeId_X,...)
Importeur Exporteur
Abbildung 3.35: Berucksichtigung von Beziehungstypen bei der Trader{
Kooperation
Die Abbildung zeigt eine um Beziehungsstypen erweiterte Darstellung der
ignoranten, Typmanager{gesteuerten Trader{Kooperation. Als zusatzlicher Parameter
der ursprunglichen Import{Operation gibt der Importeur gleichzeitig
auch den gewunschten Beziehungstyp in Form des Beziehungstypbezeichners
RelationId A an, der in dem gezeigten Fall zum Zugri auf die dazugehorige
in Typmanager 1 verwaltete Beziehungstypbeschreibung dient. Der
RelationId A entsprechende Beziehungstypbezeichner in Typmanager 2 ist hierbei
als RelationId B bezeichnet.
Wesentlicher Unterschied zur oben beschriebenen ignoranten, Typmanager{
gesteuerten Trader{Kooperation ist zum einen die explizite Ubergabe des Beziehungstypbezeichners
von Trader 2 an Typmanager 2. Da dieser RelationId A
als globalen Typbezeichner von Typmanager 1 erkennt, mu er diesen vor der
spateren Suche nach kompatiblen Diensttypen in einen in seinem De nitionsbe-
15 Hiervon wird beispielsweise auch bei der Standardisierung des ODP{Traders
[ODP94b] ausgegangen, wobei die dort zugrundeliegende Konformitatsbeziehung im ODP{
Referenzmodell [ODP95c] de niert ist (siehe auch Abschnitt 2.3.2).

3.4 Domanenubergreifender Dienstzugri 101
reichgultigen Beziehungstypbezeichner umwandeln. Dies geschieht prinzipiell auf
die gleiche Art und Weise wie bei den Diensttypbezeichnern, indem er von Typmanager
1 eine entsprechende Beziehungstypbeschreibung ineiner von ihm verstandenen
Beschreibungssprache anfordert und anschlie end einen aquivalenten
Beziehungstyp, beispielsweise den durch RelationId B bezeichneten, ermittelt.
In der Abbildung sind diese Einzelschritte inder Operation TranslateRelation
zusammengefa t.
Damit Beziehungstypbeschreibungen ausgetauschtwerden konnen, ist ebenso wie
bei den Diensttypbeschreibungen eine gemeinsame Beschreibungssprache erforderlich.
Hiermit sindunter anderem die beteiligten Rollen, deren Typen sowie die
Charakteristika und De nitionsregeln des Beziehungstyps zu beschreiben (siehe
Abschnitt 3.2.2.2).ImVergleich zu Diensttypbeschreibungen existieren zur Zeit
jedochnochkeine konkreten Vorschlage fur eine derartige Beschreibungssprache.
Erschwerendkommtau erdem hinzu, da fur eine durch Instanzen de nierte Beziehung
keine Beschreibung angebbar ist, die fur einen anschlie enden automatisierten
Typvergleich genutzt werden kann. Hierbei wird es notwendig, durch
administrativeMa nahmen Abbildungen zwischen den in den verschiedenen Verwaltungsdomanen
vorhandenen Beziehungstypen vorab explizit zu de nieren, wobei
die Korrektheit der Abbildungdurchden Administrator gewahrleistet werden
mu . Eine mogliche Erweiterung dieses Verfahrens stellen standardisierte Beziehungstypbezeichner
dar, die ahnlich wie die standardisierten Diensttypbezeichner
die Semantik von Beziehungstypen eindeutig festlegen.
3.4 Domanenubergreifender Dienstzugri
Die in den letzten beiden Abschnitten beschriebenen Funktionen des Diensttypmanagementsund
der darauf basierenden Dienstvermittlung bilden die Grundlage,
auf derer eine gemeinsame und wohlde nierte Nutzung der in o enen verteilten
Dienstmarkten vorhandenen Dienstangebote moglich ist. Hierdurch wird das
am Anfang dieses Kapitels geforderteZielder Umsetzung der auf Dienstmodell{
und Dienstbeschreibungsebene vorhandenen idealisierten Dienstabstraktion in
heterogene verteilte Systemumgebungen erreicht. Dabei spielt insbesondere das
(verteilte) Diensttypmanagement eine wichtige Rolle, da mit dessen Hilfe eine
einheitliche Behandlung von Diensttypen und Beziehungstypen trotz technischer
und administrativer Heterogenitatsprobleme zwischen Verwaltungsdomanen, die
diese Dienstemarkte inKooperation realisieren, ermoglicht wird.
Die Forderung nach Dienstabstraktion bedeutet somit gleichzeitig auch, da
die Existenz organisationeller Heterogenitatsgrenzen zwischen den kooperierenden
autonomen Verwaltungsdomanen weitgehend vor dem Dienstnehmer verborgen
werden soll. Bis zu welchem Grad diese, aus der Sicht der Dienstnehmer
wunschenswerte Abstraktion bei der anschlie enden Dienstbindung und dem
Dienstaufruf gewahrt werden soll und kann, hangt zum einen von den technischen
Heterogenitatsproblemen zwischen den Verwaltungsdomanen ab, die eine
vollstandige Abstraktion unter Umstanden verhindern. Zum anderen sind auch
die in der jeweiligen Domane vorhandenen lokalen Gegebenheiten und admini-

102 Zugang zu Diensten in heterogenen Umgebungen
strativen Verwaltungsvorschriften zu berucksichtigen. So kann es beispielsweise
aus Sicherheitsgrunden sinnvoll sein, die Dienstnutzung von au en bewu t einzuschranken,
so da in diesem Fall die Grenzen zwischen den Verwaltungsdomanen
explizit sichtbar werden. Diese administrativen Beschrankungen konnen prinzipiell
in allen Phasen des Dienstzugangs aufgestelltwerden, wobei|imVergleich
zu den Phasen der Diensttyp ndung und der Dienstauswahl | die Dienstbindungundder
Dienstaufruf letztlich die entscheidenen Hurden fur eine erfolgreiche
Dienstnutzung darstellen, da erst in diesen beiden Phasen eine explizite Kooperationsbeziehung
zwischen Dienstnehmer und Diensterbringer aufgebaut wird.
Schwerpunkt der Betrachtung sindindiesemAbschnitt deshalb vor allem diejenigen
Systemtechniken, die einen Dienstzugri , d.h. die Dienstbindung und
den Dienstaufruf, uber Domanengrenzen hinweg ermoglichen. Derartige Systemtechniken
werden in dieser Arbeit in Anlehnung andas ODP{Referenzmodell
[ODP95c] als sogenannte Interzeptoren bezeichnet. Der durch einen Interzeptor
geleistete Dienst wird entsprechend als Interzeption (engl. to intercept: ab{, auffangen)
bezeichnet und kennzeichnet die wesentliche allgemeine Eigenschaft des
Interzeptors, als Mittler zwischen Dienstnehmern und Diensterbringern zweier
Verwaltungsdomanen zu fungieren. Funktionell kann der Interzeptor als Erweiterungder
Laufzeitsystemeder zu verbindenden Verwaltungsdomanen verstanden
werden, wobei er durchseine Mittlerfunktionalitat konzeptionell fur jedeDomane
sowohl die Rolle eines Diensterbringers als auch die eines Dienstnehmers vereint
(siehe Abbildung 3.36).
Verwaltungsdomäne A
Dienstnehmer
Interzeptor
Laufzeitsystem A Laufzeitsystem B
Organisationelle Heterogenitätsgrenze
Verwaltungsdomäne B
Diensterbringer
Abbildung 3.36: Dienstzugri uber organisationelle Heterogenitatsgrenzen hinweg
3.4.1 Aufgaben von Interzeption
Ob und inwelcher Form ein Interzeptor zur Unterstutzung des Dienstzugri s
benotigt wird, hangt ma geblich von der Art der Kooperation von Verwaltungsdomanen
innerhalb o ener verteilter Dienstemarkte untereinander und den damit
verbundenen, am Anfang dieses Kapitels dargestellten organisationellen, d.h.
technischen und administrativen Heterogenitatsproblemen, ab. Prinzipiell las-

3.4 Domanenubergreifender Dienstzugri 103
sen sich vier wesentliche Aufgaben von Interzeption unterscheiden (siehe auch
[GML96]):
1. Uberwindung technischer Heterogenitatsgrenzen
2. Uberwachung und Kontrolle administrativer Heterogenitatsgrenzen
3. Erweiterung von Plattformkonzepten
4. Kompensation fehlender Domanenkonzepte
Bei dieser Unterscheidung wird im folgenden davon ausgegangen, da die Phasen
der Diensttyp ndung und der Dienstauswahl bereits abgeschlossen sind und die
Interoperabilitat zwischen Dienstnehmer und Diensterbringer sichergestellt ist.
Eine ahnliche Unterteilung der Aufgaben von Interzeption ndet sich auch in
[Hof96], wo die ersten beiden Aspekte berucksichtigt werden: " Interception is
the process which creates and inserts the appropriate gateways when a binding
between a client andaserver is created across domain boundaries. The inserted
gateways can perform the required transformations in case of technical di erences,
the checking andvetting in cases where administrative boundaries are
necessary, andthe monitoring where auditing isnecessary.\ Alternativ zu diesen
Gateways wird bei der primaren Betrachtung der technischen Heterogenitatsprobleme
von einigen Autoren alternativ auch der Begri der Bridge verwendet
[YV96, MZP96]. In dieser Arbeit soll jedochausschlie lichder Begri Interzeptor
benutzt werden, der alle oben genannten Aspekte ganzheitlich erfa t.
3.4.1.1 Uberwindung technischer Heterogenitatsgrenzen
Hauptursache fur die technische Heterogenitat ist die bereits am Anfang dieses
Kapitels beschriebene Existenz verschiedener verteilter Systemplattformen, die
in den jeweiligen Verwaltungsdomanen zur Realisierung und zumAblauf von
Diensterbringern genutzt werden. Diese besitzen in der Regel zueinander inkompatible
Systemmechanismen zur Bindung und zum Operationsaufruf, so da eine
technische Interoperabilitat nur durch gegenseitige Abbildung der verschiedenen
Verfahren untereinander erreicht werden kann.
Bindung Vor dem eigentlichen Dienstaufruf ist die Bindung zwischen Dienstnehmer
und Diensterbringer der beiden Verwaltungsdomanen notwendig, um die
Kooperationsbeziehung zwischen beiden aufzubauen. Wie schon bei den Aufgaben
des Diensttypmanagements beschrieben wurde, ist eine der Hauptaufgaben
der Bindungsphase, die Interoperabilitat beider Kooperationspartner zu uberprufen.
Im Fall eines plattformubergreifenden Dienstzugri s sind insbesondere
die Problemstellungen zu berucksichtigen, die sich aufgrund der Verteilung
des Diensttypmangements, d.h. dem Vorhandensein jeweils eigener Typmanager
in den Verwaltungsdomanen, ergeben und gegebenfalls Protokolle erfordern,
mit denen Diensttypbeschreibungen auf einheitliche Art und Weise ausgetauscht

104 Zugang zu Diensten in heterogenen Umgebungen
werden konnen. Auf moglicheLosungsansatze in Form von Diensttypreprasentationen
wurde beider Betrachtungeines verteilten DiensttypmanagementsinAbschnitt
3.2.3 eingegangen. Interzeptoren konnen als Konkretisierung des in Abbildung
3.17 abstrakt dargestellten Laufzeitsystems verstanden werden, das die
Uberprufungsfunktionen initiiert, mit denen die Interoperabilitat von Dienstnehmern
und Diensterbringern beim Dienstzugri uber technische Domanengrenzen
hinweg uberpruft werden kann. Dieses ist in Abbildung 3.37 dargestellt, wobei
der Interzeptor zwischen den beiden Verwaltungsdomanen auf der gemeinsamen
Domanengrenze lokalisiert ist.
Dienstnehmer
Typmanagerföderation
CheckRelationship
TypeId RelTypeId TypeId
Interzeptor
Organisationelle Heterogenitätsgrenze
Diensterbringer
Abbildung 3.37: Bindungsuberprufung durch einen Interzeptor
Die Typuberprufungen fuhrt er unter Zuhilfenahme des Diensttypmanagements
aus, welches in der Abbildung durch eineTypmanagerfoderation angedeutet ist.
Da auch innerhalb einer derartigen Typmanagerfoderation ein domanenubergreifender
Dienstzugri der Typmanager untereinander erforderlich ist (siehe Abbildung
3.17), sind dort ebenfalls entsprechende Interzeptionsmechanismen zur
Verfugung zustellen, so da in Verfeinerung wiederum das in Abbildung 3.36
dargestellte Grundmodell gilt.
Dienstaufruf Die Problematik des Dienstaufrufs uber technische Heterogenitatsgrenzen
hinweg ist eng verknupft mit den in den Plattformen vorhandenen
Mechanismen zur Typisierung von Diensten bzw. Operationen. Im einfachsten
Fall konnen hierbei einfache Datentypen, beispielsweise Integer und
Int, direkt wechselseitig aufeinander abgebildet werden. Komplizierter wird
diese Abbildung, falls sich Typkonzepte einer Systemplattform nicht direkt in
der anderen widerspiegeln lassen und stattdessen Umwandlungen durchgefuhrt
werden mussen. Abbildung 3.38verdeutlicht diese Problematik anhand einer
CORBA{ und einer DCE{Dienstbeschreibung, bei der eine inDCEIDLspe-

3.4 Domanenubergreifender Dienstzugri 105
zi zierte Zeigerliste ineine aquivalente CORBA IDL Deklaration einer Sequenz
umgewandelt wird. Eine umfangreiche Abbildung von DCE{ und CORBA{
Dienstbeschreibungen und der dabei auftretenden Problemstellungen ndet sich
in [CM95].
/* DCE IDL */ // CORBA IDL
typedef struct foo { struct foo_1 {
long value1� long value1�
long value2� long value2�
[ptr] struct foo *next� sequence next�
} foo� }�
Abbildung 3.38: Ausschnitt einer Abbildung einer DCE{ auf eine CORBA{
Dienstbeschreibung
Die Entscheidung, welche Konzepte zwischen Dienstbeschreibungen zweier verschiedener
Systemplattformen abbildbar sind, hangt ma geblich von dem gemeinsam
gewahlten Diensttypmodell ab, das unter anderem auch die Festlegung
einfacher und komplexer Datentypen umfa t. Bezogen auf die in Kapitel
2 vorgestellten Interoperabilitatsebenen wird durch diese Einigung die Interoperabilitat
auf Dienstbeschreibungsebene sichergestellt, so da hinsichtlich der
strukturellen bzw. syntaktischen Aspekte die Typsicherheit zwischen heterogenen
Dienstbeschreibungen auf dieser Ebene gewahrleistet ist. In der Regel lassen
sich hierbei nicht alle Konzepte der Systemplattformen untereinander abbilden,
so da meistens ein kanonisches Typmodell gewahlt wird, da zumindest eine
Schnittmenge der in den verschiedenen verteilten Systemplattformen vorhandenen
Typisierungskonzepte umfa t. Dieser Ansatz ndet sich auch inder in Teil
II vorgestellten TRADE{Systemarchitektur, bei der auf Grundlage des in Abschnitt
2.3 vorgestellten Diensttypmodells ein kanonisches Typmodell fur DCE{
und CORBA{basierte Diensterbringer entwickelt worden ist. Ein ahnlicher Abbildungsansatz
ist beispielsweise auch in CORBA [OMG91] oder ILU [JSS95]
durch sogenannte Sprachabbildungen (engl. language mappings) realisiert, bei
denen die Typsysteme verschiedener Programmiersprachen auf das kanonische
CORBA{ bzw. ILU{Typmodell abgebildet werden. Dadurch wird es anschlie end
moglich, Dienstnehmer und Diensterbringer in verschiedenen Programmiersprachen
zu entwickeln, die uber das gemeinsame Typverstandnis des kanonischen
Modells zueinander typkompatibel sind.
Neben der Abbildung der unterschiedlichen Typmodelle ist ein weiterer wichtiger
Gesichtspunkt beim Dienstaufruf auch die Umsetzung der in den Systemplattformen
verwendeten Dienstaufrufmechanismen. Ein Beispiel hierfur sind die
Systemplattformen DCE, ANSA, CORBA und ILU, die jeweils unterschiedliche,
zueinander inkompatible Verfahren zur Ausfuhrung von Operationsaufrufen besitzen.
So ist es beispielsweise nicht moglich, mittels eines DCE{RPCs die Ope-

106 Zugang zu Diensten in heterogenen Umgebungen
rationen eines ANSA{ oder CORBA{Diensterbringers aufzurufen. Ein moglicher
Losungsansatz hierfur ware die Einigung auf ein gemeinsames Transferformatfur
Operationsaufrufe bei der Netzwerkubertragung, wie es beispielsweise durch das
Internet interoperability protocol (IIOP) in CORBA 2.0 [OMG95] de niert ist.
Alternativ existieren auch Losungsansatze auf Anwendungsebene, wie sie auch
auch innerhalb von TRADE verwendet werden. Letztere Variante wird mit ihren
Vor{ und Nachteilen bei der Untersuchung verschiedener Implementierungsvarianten
von Interzeptoren in Abschnitt 3.4.2 noch genauer beschrieben.
Unmittelbare Aufgabe eines Interzeptors ist es nun, einen Dienstaufruf eines
Dienstnehmers der Domane A in einen aquivalenten Aufruf in der Domane B
umzuwandeln. Hierbei kann gleichzeitig auch eine Uberprufung des Operationsaufrufs
hinsichtlich der Korrekheit der Parameter{ und Resultatwerte durchgefuhrt
werden. Der prinzipielle Ablauf einer derartigen Interzeptor{basierten
Interaktion von Dienstnehmer und Diensterbringer ist in Abbildung 3.36durch
entsprechende Pfeileangedeutet, wobei im Interzeptor die verschiedenartigen
Typmodelle und Dienstaufrufmechanismen umgesetzt werden. Die speziell fur
die Typtransformation notwendigen Informationen erhalt der Interzeptor durch
das Diensttypmanagement schon wahrend der Bindungsphase, bei der diese Informationen
fur die dortigen Typvergleiche und {uberprufungen benotigt werden.
Der Interzeptor ubernimmt beim Interzeptionsvorgangsowohl die Rolle des
Diensterbringers als auch des Dienstnehmers. So ist er beispielsweise nach Umsetzung
des Dienstaufrufs stellvertretender Dienstnehmer des Diensterbringers
der Zieldomane.
3.4.1.2 Uberwachung und Kontrolle administrativer Heterogenitatsgrenzen
Unabhangig von den technischen Heterogenitatsproblemen zeichnen sich die kooperierenden
Verwaltungsdomanen aufgrund ihrer Autonomie durchverschiedenartige
administrative Vorgehensweisen aus, die durch die dort de nierten Verwaltungsvorschriften
(engl. policies) beein u t werden. Bei der Kooperation mit
anderen Verwaltungsdomanen sind vor allem Vorschriften hinsichtlich der Uberwachung
und Protokollierung von Interaktionen zwischen Dienstnehmern und
Diensterbringer von Interesse, mit denen den speziellen Sicherheitsanforderungen
der Verwaltungsdomanen Rechnung getragen wird. Ebenso lassen sich durch administrative
Grenzen auch Zugri sbeschrankungen auf bestimmte Dienste festlegen.
Diese Ma nahmen gehen einher mit den bereits beim Diensttypmanagement
und bei der Dienstvermittlung genannten Vorschriften, mit denen unter anderem
die Sichtbarkeit auf bestimmte Diensttypbeschreibungen bzw. Diensterbringer
eingeschrankt wird. Zusammengenommen kann der Interzeptionsdienst somit
auch als ein Kontrolldienst verstanden werden, mit denen der generelle Zugang
zu einer Verwaltungsdomane uberwacht und geregelt werden kann. Er ist in
dieser Funktion vergleichbar mit den Komponenten von sogenannten Fire Walls
[CZ96], die auf Netzwerkebeneden Zugri auf ein lokales Rechnernetz von au en
regeln. Prinzipiell konnen Interzeptoren auch innerhalbvon Verwaltungsdomanen
eingesetzt werden. Eine mogliche Anwendung ware beispielsweise die Uberwa-

3.4 Domanenubergreifender Dienstzugri 107
chung samtlicher Interaktionen zwischen Dienstnehmern und Diensterbringern in
einer Domane, wobei alle Dienstzugri e uber einen domaneninternen Interzeptor
abgewickelt werden mussen.
3.4.1.3 Erweiterung von Plattformkonzepten
Aufgrund der " Mittler\{Funktionalitat konnen Interzeptoren im allgemeinen
auch fur Aufgaben herangezogen werden, die uber die oben genannten Aufgaben
der Uberwindungtechnischer Heterogenitatsproblemeund der Uberwachung
hinausgehen. Eine mogliche Erweiterung ist die Gewahrleistung zuverlassiger
Dienstaufrufe zwischen Dienstnehmern und Diensterbringern einer bzw. zwischen
zwei verschiedenen Verwaltungsdomanen. Ein Beispiel hierfur ist der sogenannte
Logger im Cygnus{System [CR91], der moglicheAufru ehler beim Diensterbringer
vor dem Dienstnehmer verbirgt und gegebenfalls einen Aufruf bei einem
anderen Diensterbringer initiiert.
Generell konnen Interzeptoren somit auch als Moglichkeit zur Erweiterung von
Plattformkonzepten genutzt werden, indem zusatzliche Systemfunktionen beim
Dienstaufruf ausgefuhrt werden. Eine interessante Anwendung ist im Zusammenhang
mit den Typisierungskonzepten verteilter Systemplattformen die Unterstutzung
erweiterter und exibler Beziehungstypen. So lie en sich beispielsweise
die in CORBA und DCE vorhandenen Subtypisierungskonzepte, die bisher
nur das Hinzufugen neuer Operationen zu einem bestehenden Schnittstellentyp
erlauben, durch die in Abschnitt 2.3.2 de nierte Konformitatsbeziehung
ersetzen, so da auch Diensterbringer mit veranderten Parameter{ und Resultattypen
aufrufbar waren. Da dieses durch die Laufzeitsysteme der beiden Systemplattformen
nicht unterstutzt wird, mu te der Interzeptor die Dienstaufrufe
entgegennehmen und mitentsprechenden Typumwandlungen an den diensttypkonformen
Diensterbringer weitersenden. Derartige Typumwandlungen konnten
auch zur Anpassung von beliebigen Diensten genutzt werden, die nicht in
expliziter Konformitatsbeziehung stehen. In [Kon93] ist dies beispielsweise anhand
zweier Diensterbringer veranschaulicht, die einen semantisch aquivalenten
Dienst erbringen, sich jedoch inden an der Schnittstelle angebotenen Operationen
unterscheiden. Abbildung 3.39 zeigt das dort angefuhrte Beispiel eines
Fensterkontrolldienstes (engl. window manager), wobei die sogenannten Membrane
eine technische und administrative Heterogenitatsgrenze bilden. CooL und
Hybrid bezeichnen jeweils verschiedene Programmiersprachsysteme, in denen die
Schnittstellentypen spezi ziert sind. Interzeption wird in dem dortigen Zusammenhang
als sogenanntes Object Mapping bezeichnet, bei dem die Operationen
der Schnittstellentypen durch De nitionsregeln aufeinander abgebildet werden.
Dieses ist vom unterliegenden Konzept her vergleichbar mit den durch Instanzen
de nierten Beziehungstypen, die in Abschnitt 3.2.2.2 beim Diensttypmanagementeingefuhrt
wurden. Um die Interzeption durchfuhren zu konnen, wird systemseitig
durcheinen Object Mapper ein windowServer Inter-Object erzeugt,
welches zur Laufzeit die notwendigen Zuordnungen der Operationen aufeinander
vornimmt.

108 Zugang zu Diensten in heterogenen Umgebungen
newWindow
newSquareWin
refreshDisplay
readCoordinates
windowSelected
Hybrid Cell CooL Cell
windowServer
Inter-Object
Membrane
Membrane
Abbildung 3.39: Object Mapping
3.4.1.4 Kompensation fehlender Domanenkonzepte
create_win
redisplay_all
get_Position
select_Window
Ebenso wie bei den erstgenannten Moglichkeiten der Erweiterung des Aufgabenspektrums
von Interzeptoren bzgl. Plattformkonzepten konnen diese auch
dazu eingesetzt werden, fehlende Konzepte inder Zieldomane zukompensieren.
Ein Beispiel, auf das innerhalb von TRADE noch genauer eingegangen wird,
ist das Einfuhren des Diensttypkonzeptes in eine auf CORBA basierende Verwaltungsdomane,
der originar nur das Schnittstellentypkonzept unterliegt. Der
in TRADE entwickelte Interzeptor ubernimmt in diesem Zusammenhang unter
anderem gewisse Trading{Funktionalitat, indem den CORBA{Diensterbringern
der Zieldomane bestimmte Diensttypen zugeordnet werden, die anschlie end
fur eine Dienstvermittlung benutzt werden konnen. Er kompensiert damit die
dort zur Zeit fehlende Trader{Komponente. Hierdurch wird es in der Ausgangsdomane
moglich, auf der Grundlage des dort verwendeten Diensttypkonzeptes
auf Diensterbringer der Zieldomane zuzugreifen, die ursprunglich unabhangig
von diesem Konzept entwickelt worden sind (siehe auch [GML96]).
3.4.2 Entwurfsvarianten von Interzeptoren
Zur Realisierung von Interzeptoren sind verschiedenartige Entwurfsvarianten
moglich, die im folgenden naher beschrieben werden sollen. Generell lassen sich
statische und dynamische Ansatze unterscheiden.
3.4.2.1 Statische Interzeption
Bei dieser Art von Interzeption ist die Abbildung bestimmter Dienstaufrufe zwischen
den verschiedenen Verwaltungsdomanen fest im Interzeptor integriert. Statisch
bedeutet in diesem Zusammenhang, da die im Interzeptor realisierten
Abbildungsprozesse wahrend seiner Lebenszeit nicht veranderlich sind. Dieses

3.4 Domanenubergreifender Dienstzugri 109
betri t insbesondere die Festlegung auf bestimmte, zwischen den Verwaltungsdomanen
aufeinander abzubildenen Schnittstellen{ bzw. Diensttypen. Prinzipiell
ergibt sich die in Abbildung 3.40 gezeigte Grundstruktur bei der Instanziierung
eines statischen Interzeptors.
Dienstnehmer
S
T
U B
Interzeptor-
Generator
Abbildungskomponente
Verwaltungsdomäne A Verwaltungsdomäne B
Heterogenitätsgrenze
Abbildung 3.40: Statischer, generierter Interzeptor
S
T
U B
Dienst-
erbringer
Der Interzeptor wird durch einen Generator erzeugt, wobei die entsprechenden
Stubs fur die Dienstnehmer{ und Diensterbringerseite und die zur Abbildung
zwischen den Operationsaufrufen notwendige Abbildungskomponente inden Interzeptor
statischintegriert werden. Die Stub{Generierung erfolgt aus den in den
beiden Verwaltungsdomanen jeweils verwendeten Dienstbeschreibungen, wie es
bereits inAbbildung 3.14dargestellt wurde. Hierbei ist es unter Umstanden
aufgrund technischer Heterogenitatsgrenzen notwendig, da die unterschiedlichen
Dienstbeschreibungen der beiden Verwaltungsdomanen aufeinander abgebildet
werden mussen. Dieses bedeutet auch, da jeweils die domanenspezi -
schen Dienstaufrufmechanismen in den Interzeptor integriert werden mussen, so
da beispielsweise auf Dienstnehmerseite ein Diensterbringer{Stub mittels DCE
RPC und auf Diensterbringerseite ein Dienstnehmer{Stub mittels des CORBA
RPCs (des sogenannten Skeletons [OMG91]) genutzt werden mu . Neben der
Umwandlungvon Operationsaufrufen kann die Abbildungskomponenteauchweitere
Aufgaben ubernehmen, die unter anderem die oben genannte Erweiterung
von Plattformkonzepten oder die Kompensation fehlender Domanenkonzeptebetre
en.
Der Vorgang der Generierung von Interzeptoren kann prinzipiell zu zwei verschiedenen
Zeitpunkten statt nden. Zum einen kann der Interzeptor bei der Instanziierung
eines Diensterbringers gleichzeitig mit generiert werden, so da jedem
Diensterbringer jeweils ein Interzeptor zugeordnet ist. Als Alternativekann
auch nur ein Interzeptor fur eine Mehrzahl diensttypaquivalenter Diensterbringer
erzeugt werden. 16 Zum anderen kann eine Interzeptor auch erst zur Laufzeit
zu dem Zeitpunkt erzeugt werden, wenn ein domanenubergreifender Dienstzu-
16 In [Hof96] wird die erste Variante auch als privat, die zweite alstypspezi sch bezeichnet.

110 Zugang zu Diensten in heterogenen Umgebungen
gri erwunscht ist. Auf welche Art die Generierung bei beiden Varianten durchgefuhrt
wird, beispielsweise manuell durch den Administrator der Diensterbringerdomaneoder
automatischdurch das Laufzeitsystem (sogenannte On{demand
bridge [YV96]), hangt von den jeweiligen Implementierungsvarianten und auch
Verwaltungsvorschriften der Domanen ab.
3.4.2.2 Dynamische Interzeption
Wesentliche Eigenschaft dynamischer Interzeptoren ist der hohe GradanTypunabhangigkeit.
ImVergleich zumstatischen Ansatz mit jeweils fest vorgegebener
Typbeziehung zwischen Dienstnehmer und Diensterbringer ist ein dynamischer
Interzeptor unabhangig von einem bestimmten Dienst{ bzw. Schnittstellentyp,
wodurchverschiedenartigste Dienstaufrufe an Diensterbringer mit beliebigen
Diensttypen ubermittelt werden konnen.
Um eine derartige Generizitat zu erreichen, ist von Seiten des Interzeptors zum
einen eine dynamische Dienstschnittstelle zur Verfugung zustellen, die eine Entgegennahme
und Interpretation beliebiger Dienstaufrufe von Dienstnehmern erlaubt.
In der Abbildung 3.41 ist diese als sogenanntes Dynamic Service Interface
(DSI) bezeichnet. 17
Dienstnehmer
D SI
Generische
Abbildungskomponente
Verwaltungsdomäne A Verwaltungsdomäne B
Heterogenitätsgrenze
Abbildung 3.41: Dynamischer Interzeptor
D II
Diensterbringer
Das DSI stellt das Komplement zur dynamischen Aufrufschnittstelle (engl. Dynamic
Invocation Interface {DII)dar. Das DSI ermoglicht es, eingehende Operationsaufrufe
beliebiger Art in ihre Einzelbestandteile zu zerlegen. Diese Informationen
nutzt anschlie end der Interzeptor fur die weitere Umwandlungs{ und
Abbildungsschritte, so da letztendlichder Operationsaufruf an den Diensterbringer
der Zieldomane weitergeleitet werden kann. Hierfur wird das DII verwendet,
welches das dynamische Kreieren von Operationsaufrufen ermoglicht(siehe auch
Abbildung 3.13).
3.4.3 Ubermittlung von Fremdkonzepten
Eine grundsatzliche Problematik bei der Interzeption zwischen verschiedenen
Verwaltungsdomanen ist die Ubermittlung von Fremdkonzepten. Fremdkonzepte
17 in Anlehnung an das in CORBA 2.0 [OMG95] de nierte DSI

3.4 Domanenubergreifender Dienstzugri 111
bezeichnen Informationen, die nur innerhalb einer Verwaltungsdomane eine Bedeutung
besitzen und somit in anderen Domanen nicht interpretierbar sind. Ein
insbesondere fur den Dienstzugri wichtiges Beispiel eines derartigen Fremdkonzeptes
sind Bindungsinformationen, mitdenen Diensterbringer innerhalb bestimmter
verteilter Systemplattformen eindeutig adressiert werden konnen. Sie
stellen in einer anderen verteilten Systemplattform opake Informationen dar, die
mit den dort vorhandenen, originaren Werkzeugen nicht weiter interpretierbar
und somit verarbeitbar sind. Ein konkretes Beispiel einer Bindungsinformation
(engl. interface references) ist ein im DCE Cell Directory Service (CDS)
[OSF92] de nierter Kontextname, der einen Verweis auf DCE{spezi sche Binding
Handles darstellt, mit denen die DCE{Diensterbringer adressiert werden
konnen. Beispielsweise kennzeichnet der Name /.:/trade/services/TRADEr
einen Trading{Dienst, wie er im Rahmen der TRADE{Systemarchitektur implementiert
worden ist. In einer CORBA{ oder ANSA{basierten Systemumgebung
kann dieser Namejedoch nicht sinnvoll interpretiert werden, da dieseselbst
andere Adressierungsverfahren verwenden.
Eine Situation, bei der Bindungsinformationen als Fremdkonzepte ubertragen
werden, ist die in Abschnitt 3.3.3 vorgestellte verteilte Dienstvermittlung, bei
der Dienstangebotsinformationen zwischen den kooperierenden Tradern ausgetauscht
werden. Da diese Trader aufgrund der Autonomie der ihnen zugeordneten
Verwaltungsdomanen moglicherweise auf verschiedenen verteilten Systemplattformen
ablaufen, beinhalten die zuruckgelieferten Dienstangebote jeweils die
plattformspezi schen Bindungsinformationen der in ihrer Domane verwalteten
Diensterbringer, wodurch sichdas obige Interpretationsproblem in der anderen
Domane ergibt. Diese Situation ist in Abbildung 3.42noch einmal verdeutlicht.
Trader 1
I
n
t
e
r
Trader 2
import(...) ==> InterfaceId_B
z
e
p
t
export(...,InterfaceId_B,...)
Importeur ? o
r
Exporteur
Verwaltungsdomäne A Verwaltungsdomäne B
Abbildung 3.42: Ubertragung von Fremdkonzepten
Die Abbildung zeigt die Kooperation zweier Trader uber eine technische Heterogenitatsgrenze
hinweg. Die von dem Dienstnehmer in der Domane A initiierte
Dienstanfrage wird uber den Interzeptor zum kooperierenden Trader B der anderen
Domane propagiert. Dieser gibt anschlie end die Informationen eines in seinem
Verwaltungsbereich vorhandenen Dienstangebots anden Trader A zuruck.

112 Zugang zu Diensten in heterogenen Umgebungen
Letztendlich erhalt der Dienstnehmer die enthaltenen Bindungsinformationen,
die fur ihn in seiner lokalen Verwaltungsdomane jedoch nicht weiter verwendet
werden konnen, da siedorteinFremdkonzept darstellen.
Generell konnen zwei verschiedeneStrategien zur Behandlung von Fremdkonzepten
beim Ubergang zwischen zwei Verwaltungsdomanen unterschieden werden:
1. Keine Ubermittlung von Fremdkonzepten:
Aufgrund der Autonomie von Verwaltungsdomanen ist oftmals das
Einfuhren von Fremdkonzepten nicht moglich oder beispielsweise aus
Grunden der Sicherheit nicht erwunscht. Hierdurch bedingt sind beider
Interzeption Ma nahmen durchzufuhren, die eine vorherige Umwandlung
der zu ubermittelnden Fremdkonzepte in Konzepte der Zieldomane
ermoglichen. Innerhalb der Domanen werden somit ausschlie lich die
dort bereits vorhandenen, originaren Konzepte zugelassen, ohne da
Anderungen der unterliegenden Systemtechniken notwendig sind.
Ein moglicher, in dieser Arbeit vorgeschlagener Losungsansatz ist die Generierung
sogenannter Stellvertreter (engl. proxies), die in der Zieldomane
instanziiert werden. Dabei sind sie eng mit dem originalen Diensterbringer
der Ausgangsdomane verknupft, dessen Stellvertretung sieubernommen
haben.
2. Kennzeichnung von Fremdkonzepten bei der Ubermittlung:
Bei diesem Verfahren werden bei der Interzeption die Fremdkonzepte vor
ihrer eigentlichen Ubertragung ineineandere Domane besonders gekennzeichnet,
so da diese innerhalbder Zieldomane explizit als Fremdkonzepte
erkanntwerden konnen. In diesem Fall ist es anschlie end notwendig, eine
weitere Verarbeitung und Interpretation der domanenfremden Informationen
vorzunehmen, um auf die Originalinformationen zugreifen zu konnen.
Beide Ansatze erfordern, da Fremdinformationen bei der Interaktion zwischen
kooperierenden Partnern zweier Verwaltungsdomanen durch einen Interzeptor
erkannt bzw. ihm im voraus explizit bekannt gegeben werden. Da derartige
Fremdinformation neben den oben genannten, plattformspezi schen Bindungsinformationen
prinzipiell beliebiger, anwendungsspezi scher Art sein konnen, ist
Interzeption hierbei jeweils auf die spezi schen Bedurfnisse bestimmter Anwendungsfelder
abzustimmen.
3.5 Zusammenfassung
Zielstellung des vorliegenden Kapitels war die Identi zierung und Beschreibung
von Techniken, die eine adaquateUnterstutzungdes Zugangs zu Diensten in o enen
verteilten Dienstemarkten erlauben. Hierbei wurden insbesondere die Heterogenitatsprobleme
erortert, die sich aus der Kooperation verschiedener Verwaltungsdomanen
innerhalb von verteilten Dienstemarkten ergeben und die den Zugangeines
Dienstnehmers zu den Dienstangeboten anderer Verwaltungsdomanen

3.5 Zusammenfassung 113
ma geblich erschweren. Als geeignete Losungsansatze wurden das Diensttypmanagement,dieDienstvermittlung{
und verwaltung (Trading) und die Interzeption
in ihren wesentlichen Konzepten vorgestellt. Diese ermoglichen in gegenseitiger
Kooperation einen weitestgehenduneingeschrankten Dienstzugangunter Berucksichtigung
der in o enen verteilten Dienstemarkten vorhandenen Heterogenitatsprobleme.
Zusammenfassend ergibt sich somit das in Abbildung 3.43dargestellte Gesamtbild,
welches die verschiedenen, in diesem Kapitel genauer betrachteten Kooperationsbeziehungen
zwischen Typmanagern, Tradern und Interzeptoren schematisch
wiedergibt.
Typ-
Manager 1
Trader 1
I
n terze
p tor
Typ-
Manager 2
Trader 2
Importeur Exporteur
Abbildung 3.43: Kooperationsbeziehungen beim Dienstzugang
Unter der Voraussetzung technischer und administrativer Heterogenitatsgrenzen
zwischen den Verwaltungsdomanen kommtdem Interzeptor eine zentrale Bedeutung
beim Dienstzugri zu, danur uber ihn domanenubergreifende Dienstaufrufe
ablaufen konnen. Dieses gilt auch fur die in diesem Kapitel betrachteten Typmanager
und Trader, die den Dienst eines Interzeptors als notwendige Voraussetzung
fur eine domanenubergreifende Kooperation benotigen. Zur Uberwindung
der Heterogenitat nutzt der Interzeptor seinerseits die Dienste des Typmanagements,
um die beim domanenubergreifenden Dienstzugri notwendigen Abbildungen
bzw. Umwandlungen der Typisierungs{ und Kommunikationskonzepte
der Ausgangsdomaneindieder Zieldomane vorzunehmen. Auf Grundlage dieser
Interzeptionvorgange ist die Realisierung einer verteilten, domanenubergreifenden
Dienstvermittlung moglich, die potentiellen Dienstnutzern adaquate Dienstauswahlmechanismen
zum Au nden von " am besten geeigneten Dienstangeboten\
bietet. Dieses geschieht inenger Kooperation mit dem Typmanagement,
welches die Suchenachzueinem bestimmten Beziehungstyp kompatiblen Diensttypen
unterstutzt und somit die Anzahl potentieller Dienstangebote erhoht. Auerdem
behandelt das Typmanagement die aus der Autonomie der Verwaltungs-

114 Zugang zu Diensten in heterogenen Umgebungen
domanen resultierenden Unterschiededer jeweils verwendeten Diensttypbeschreibungssprachen
und Typbezeichnerkonzepte, so da trotzdem auch einVergleich
von Dienstangeboten heterogener Verwaltungsdomanen moglich ist.
Durch das kooperative Zusammenspiel aller drei Systemkomponenten ergibt sich
somit fur Dienstnehmer ein | ohne Berucksichtigung von domanenspezi schen
Restriktionen | weitestgehenduneingeschrankter Zugang zu Diensten in o enen
heterogenen verteilten Dienstemarkten.

Kapitel 4
Koordination von Diensten
Die im vorherigen Kapitel beschriebenen Systemtechniken ermoglichen den Aufbau
einer Dienstinfrastruktur, die einen weitgehend uneingeschrankten Zugang
zu den in o enen verteilten Dienstemarkten vorhandenen Dienstangeboten zur
Verfugung stellt. Mit ihr ero net sich fur einen Dienstnehmer die Moglichkeit,
aus einer gro en Menge verschiedenartigster Dienstangebotezuwahlen, um diese
anschlie end zumErreichen seiner beabsichtigten Anwendungsziele zu nutzen.
Durch die Unterstutzung domanenubergreifender Typmanagement{, Trading{
und Interzeptions{Mechanismen konnen die Dienstangebote sogar auf der Basis
unterschiedlicher verteilter Systemplattformen mit unterschiedlichen Typmodellen
und Dienstaufrufmechanismen realisiert werden, ohne da diese Aspekte der
Heterogenitat von Seiten des Dienstnehmers im besonderen Ma e berucksichtigt
werden mussen. Fur den Dienstnehmer bzw. den Anwendungsentwickler ergibt
sich hierdurch eineeinheitliche und abstrakte Sicht auf die in o enen verteilten
Dienstemarkten vorhandenen Dienstangebote. Um diese nun e ektiv nutzen zu
konnen, sind jedochzusatzlich zuden oben genannten Systemtechniken weitere
Unterstutzungsmechanismen erforderlich. Dieses betri t vor allem geeignete
Ausdrucksmittel, mit denen die Nutzung von Diensten im Rahmen verteilter
Anwendungen beschrieben werden kann. Auf dieser Grundlage konnen dann
Steuerungsmechanismen entwickeltwerden, die die Kontrolle der anschlie enden
Anwendungsausfuhrung realisieren.
In einem ersten Schritt stellt dieses Kapitel zunachst verschiedene Arten verteilter
Anwendungen vor, die sich durch ihren ausgepragten dienstnutzungsorientierten
Charakter auszeichnen. Aus ihrer Betrachtung ergeben sich generelle
Anforderungen an Beschreibungskonzepte, die zur Beschreibung koordinierter
Dienstnutzung in o enen verteilten Dienstemarkten notwendig sind. Vor dem
Hintergrund der gestellten Anforderungen wird anschlie end der im Rahmen
dieser Arbeit entwickelte Beschreibungsansatz vorgestellt. Er bietet eine vorgangsorientierte
Sicht auf die koordinierte Nutzung von Diensten in o enen verteilten
Dienstemarkten. Formale Grundlage bildet ein erweitertes Petri{Netz, das
eine integrierte Darstellung sowohl der strukturellen als auch der verhaltensbezogenen
Aspekte koordinierter Dienstnutzung erlaubt. Hierdurch bedingt eignet
sich dieser Ansatz nicht nur zur Beschreibung von Anwendungsvorgangen, son-

116 Koordination von Diensten
dern bietet gleichzeitig auch die Grundlage fur ihre Ausfuhrung. Desweiteren
ermoglicht ereineweitgehend direkte Umsetzung ineinekonkrete Programmiersprache
und eineSteuerungskomponente zur Ausfuhrung von Anwendungsvorgangen.
Dieses ist am Beispiel der Koordinationssprache PAMELA und des
sogenannten Koordinationsmanagers verdeutlicht, die bei der Darstellung der
TRADE{Systemumgebung inTeilIIvorgestellt werden.
4.1 Dienstnutzung inverteilten Anwendungen
Verteilte Anwendungen konnen prinzipiell vielfaltigste Formen annehmen, die
von der vergleichsweise einfachen interaktiven Nutzung einzelner Dienste bis hin
zu komplexen Anwendungssystemen reichen, die sich aus der Kombination einer
gro en Menge kooperierender Dienste zusammensetzen (siehe auch Abschnitt
1.2). Ein insbesondere sich aus dem zweiten Fall ergebender interessanter Gesichtspunkt
betri t die Entwicklung neuer verteilter Anwendungen. Hier la t
sich durch dieWiederverwendung [Ber95] bereits vorhandener Dienste einehohe
E zienz erreichen. Wesentliche Voraussetzung hierfur ist jedoch ein gro es
und vielfaltiges Angebot von Diensten, die sowohl generischverwendbare Diensttypen
als auch individuelle, anwendungsspezi sche Diensttypen realisieren. Ein
o ener verteilter Dienstemarkt kann dann als eine Art Systembaukasten verstanden
werden, dessen Bausteine, die Dienstangebote, beliebig im Rahmen verteilter
Anwendungen kombiniert werden konnen [MML95d, MML95e].
4.1.1 Ubergang zur weitestgehenden Nutzung externer Dienste
Generell ist diese Sichtweise der Kombination von Teildiensten zu einer neuen
Gesamtanwendungauch auf andere Anwendungsbereiche ubertragbar. Insbesondere
in Hinblick auf kommerzielle Gesichtspunkte in Dienstemarkten sind sogenannte
Mehrwertdienste [Mer96, Pop95] von zunehmenden Interesse. Mehrwertdienste
zeichnen sich dadurch aus, da sie bereits vorhandene Dienstleistungen
derartig kombinieren, da sich aus der koordinierten Zusammenfuhrungder Einzeldienste
und einer hierauf aufsetzenden Anwendungslogik eine neue Art von
Dienst ergibt. Ein einfaches Beispiel hierfur sind Reisevermittlungsdienste, die
die Dienstangebote einzelner Reiseanbieter gesammelt anbieten und zusatzlich
eigene Sonderleistungen anbieten, indem beispielsweise die Suche und Auswahl
geeigneter Reisen unterstutzt wird. Hierbei trittder Kunde nur indirekt mit dem
eigentlichen Reiseanbieter uber den Vermittler in Kontakt.
Wahrend Mehrwertdienste wiederum herkommliche Dienste miteinem neuem
Diensttyp darstellen, sind auch lose gekoppelteFormen von Dienstnutzung denkbar.
Ein in letzter Zeit aktuelles Schlagwort sind sogenannte Intelligente Agenten
bzw. Mobile Agenten [Way94, MML96, MLML96], die eigenstandig von einem
Dienstangebot zum anderen wandern und die dortigen Dienstleistungen nutzen.
Ein oftmals angefuhrtes Beispiel fur die Verwendungvon Agenten sindBuchungsanwendungen,
die aus einer Anzahl von Einzelbuchungen, beispielsweise zur Bestellung
von Theaterkarten oder Blumen, bestehen. Hierbei ist es nicht mehr

4.1 Dienstnutzung inverteilten Anwendungen 117
erforderlich, da der Initiator des Agenten warten mu , bis das Ergebnis eintri
t. Vielmehr wird hierbei von einem asynchronen Ablauf ausgegangen, bei
dem der Agent nach Erfullung seiner Aufgabe, die unter Umstanden recht lange
dauern kann, dem Initiator eine Mitteilung zusendet. Die Art undWeise sowie die
Reihenfolge der Dienstnutzung durcheinen Agenten ist vorabdurch seine Aufgabenbeschreibung
festgelegt. Hierfur werden oftmals sogenannte Skriptsprachen,
beispielsweise Telescript [Whi94], verwendet, mit denen eine einfache Beschreibung
von Ablaufen moglich ist.
AgentenbasierteAnwendungen sindvom Ansatz der Dienstnutzungher vergleichbar
mit der ebenfalls in der letzten Zeit intensiv untersuchten Klasse der sogenannten
Work ow Management{Anwendungen [Jab95, Rei93],beidenen ebenfalls
die Art und Weise der Dienstnutzung durch vorde nierte Proze beschreibungen
von vornherein festgelegt ist. Sie dienen zur Unterstutzung und Optimierung
von unternehmensinternen Arbeitsablaufen, mit dem globalen Ziel, die
Wirtschaftlichkeit eines Unternehmens zu erhohen. Diese wird in der Regel durch
die Automatisierung von Arbeitsablaufen erreicht, die durch das Work ow{
Management{System koordiniert und uberwachtwerden. Bei der Ausfuhrungder
Arbeitsablaufe werden auch Dienste in Anspruch genommen, die durch menschliche
Tatigkeiten erbrachtwerden, um bestimmtezumeist nicht automatisierbare
Aufgaben, wie beispielsweise die Genehmigung oder Ablehnung eines Bankdarlehens,
zu ubernehmen. Konzeptionell werden derartige Diensteaber von sonstigen
Diensten, beispielsweise autonom ablaufenden Datenbank- oder Druckdiensten,
nicht unterschieden.
Trotz der anwendungsspezi schen Unterschiede der oben genannten verteilten
Anwendungen ist deren gemeinsames Hauptmerkmal die weitgehende Verwendung
von externen Dienstleistungen, um diese zur Realisierung der Gesamtanwendung
derartig einzusetzen, da sie auf koordinierte Art und Weise das beabsichtigte
Anwendungsziel erreichen. Wird sich auf diesen Aspekt der Dienstnutzung
konzentriert, lassen sich derartige dienstnutzungsorientierte verteilte Anwendungen
weiter nach dem Grad ihrer Dienstnutzung unterscheiden:
1. Partielle Dienstnutzung, d.h. im Verlaufe der Anwendungwerden gelegentlich
externe Dienste in Anspruch genommen, um gewisse Teilfunktionen
erfullen zu lassen. Die eigentliche Hauptverarbeitung ndet jedoch inder
Klientenanwendung statt, die den Anwendungsablauf steuert. Ein Beispiel
hierfur ist eine Reisebuchungsanwendung, bei der auf verschiedene Datenbankdienste
zur Buchung von Flugen und Hotels zugegri en wird, die Berechnungdes
Gesamtpreises und der Ausdruckder Kundenrechnungjedoch
durch die lokale Klientenanwendung durchgefuhrt wird. Sie ubernimmt
auch die Uberwachung der Ausfuhrung der Dienstzugri e und die Steuerung
der Kooperation der sequentiell oder nebenlau g genutzten Dienste.
2. Weitestgehende Dienstnutzung, d.h. die anwendungsspezi sche Verarbeitung
ndet weitestgehendoder sogar vollstandig in den genutzten Diensten
bzw. Diensterbringern statt. In der Gesamtanwendung zu erbringende Teilaufgaben
und deren Verarbeitung sinddabei so weit wie moglich aus der

118 Koordination von Diensten
Klientenanwendung in externe Dienste ausgelagert. In Ubertragungauf die
Reisebuchungsanwendung bedeutet dieses, da auch die Preisberechnung
und der Belegausdruck durch extern genutzte Dienste erbracht wird.
DurchdieseExternalisierungvon Berechnungsfunktionalitat verandert sich
die Rolle und Aufgabe der Klientenanwendung, die bei einer partiellen
Dienstnutzung selbst noch zusatzlich zur Steuerungder Dienstnutzung wesentliche
Verarbeitungsaufgaben ubernommen hat. In diesem Fall spielen
die Verarbeitungsaspekte inder Klientenanwendung nur noch eineuntergeordnete
Rolle, wahrend hingegen die Steuerung und Koordination der
genutzten Dienste inden Vordergrund ruckt.
Beide Arten von Dienstnutzung sindinAbbildung 4.1 veranschaulicht, wobei
die Kastchen die Ausfuhrung bestimmter Anwendungsfunktionen verdeutlichen,
die entweder durch die Klientenanwendung selbst oder durch externe Dienste
realisiert werden. Die Kanten zwischen den Kastchen deuten den Kontroll u
innerhalb der Klientenanwendungen an.
Klientenanwendung Dienste Klientenanwendung Dienste
Partielle Dienstnutzung Weitestgehende Dienstnutzung
Abbildung 4.1: Grad der Dienstnutzung
Die oben dargestellteTrennungvon partieller und weitestgehender Dienstnutzung
zeigt gleichzeitig auch einen moglichen Weg auf, wie zukunftig verteilte Anwendungen
entworfen und realisiert werden konnen. Die ausschlie liche Dienstnutzung
kann generell als ein Idealziel verstanden werden, da jedoch angesichts
der zu erwartenden Vielfalt und Vielzahl verschiedenster Dienstangebote gerade
bei der Anwendungsentwicklung in o enen verteilten Dienstemarkten zunehmend
realistischer wird. Jedoch auch unabhangig von dem Vorhandensein nutzbarer
Dienstangebote in o enen verteilten Dienstemarkten la t sich das Prinzip weitestgehender
Dienstnutzung allgemeingultig bei der Anwendungsentwicklungverwenden.
Ziel ist es dann, schon in der Entwurfsphase neue verteilteAnwendungen
derartig modular zu entwerfen, da eine spatere Realisierung der Einzelmodule
durch eigenstandige, wiederverwendbare und funktional abgeschlossene Dienste
erfolgen kann. Hierbei sollte jedochvor allem die Wiederverwendung bereitsvor-

4.1 Dienstnutzung inverteilten Anwendungen 119
handener, unter Umstanden generischer Anwendungsdienste angestrebt werden,
so da letztendlich nur in Ausnahmefallen die Neuentwicklung modulspezi scher
Dienste notwendig ist.
4.1.2 Benotigte Beschreibungs{ und Modellierungskonzepte
Bei dieser Art des Anwendungsentwurfs wird ersichtlich, da sichmitdem Ubergang
zur weitestgehenden Dienstnutzung eineWandlung imStil der Realisierung
verteilter Anwendungen vollzieht, bei der zukunftig vor allem die Aspekte der
Koordination von Diensten adaquat berucksichtigt werden mussen. Dieses bedeutet
insbesondere, da ausdrucksmachtige Modellierungs{ und Beschreibungsmittel
zur Verfugung stehen mussen, mit denen unter anderem der eigentliche
Dienstzugri sowie sequentielle und nebenlau ge Dienstnutzungsfolgen ausgedruckt
werden konnen.
Die Moglichkeit der Beschreibung der Koordination von Diensten ist jedoch nur
eine Anforderung, die an die Ausdrucksmachtigkeit einer Beschreibungssprache
gestellt wird. Insgesamtsollten die folgenden Beschreibungskonzepteunterstutzt
werden:
Datenkonzept: Zur Darstellung der in verteilten Anwendungen vorhandenen,
in der Regel komplex strukturierten Daten mussen geeignete Typkonzepte
unterstutzt werden. Das Datentypkonzept steht hierbei im engen Zusammenhang
mitdem gewahlten Diensttypkonzept, mit dem die strukturellen
Aspekte der in den Dienstnutzungsfolgen genutzten Dienste beschrieben
werden.
Dienstorientiertes Aktionskonzept: Die beabsichtigte Nutzung von externen
Diensten, die in o enen verteilten Dienstemarkten angeboten werden,
erfordert Beschreibungsmittel, mit denen die Dienstauswahl und der
Dienstzugri ausgedruckt werden kann. Hierzu ist die Unterstutzung des
Diensttypkonzeptes erforderlich, das die wesentliche Grundlage fur den
Dienstzugang darstellt (siehe hierzu auch die ausfuhrlichen Erlauterungen
im vorherigen Kapitel).
Kontroll u konzept: Zur Beschreibung des Ablaufs verteilter Anwendungen
ist die Bereitstellung eines Kontroll u konzeptes erforderlich, mit dem eine
zustandsabhangige Steuerung ihrer Ausfuhrung moglich ist. Dabei sollten
die in Programmiersprachen ublichen Kontroll u konstrukte wie beispielsweise
Verzweigungen, bedingte Auswahl und Schleifen zur Verfugung stehen.
Nebenlau gkeitskonzept: Verteilte Systeme ermoglichen durch ihre inharenten
Eigenschaften die nebenlau ge Ausfuhrung von Diensten. Um dieses
optimal ausnutzen zu konnen, ist die Beschreibung von Nebenlau gkeitsaspekten
erforderlich, mit denen sowohl sequentielle als auch nebenlau ge
Dienstnutzungsfolgen ausgedruckt werden konnen. Hierbei sind zusatzlich

120 Koordination von Diensten
auch Synchronisationsaspekte zuberucksichtigen, um beispielsweise einen
konsistenten Zugri auf gemeinsam genutzte Ressourcen sicherzustellen.
Transaktionskonzept: Bei der sequentiellen und nebenlau gen Nutzung von
Diensten ist es oftmals notwendig, ihre logische Zusammengehorigkeit und
gegenseitigen Abhangigkeiten in Form von Transaktionen beschreiben zu
konnen. Hiermit lassen sich dann bestimmte Anforderungen verknupfen,
die die Nutzung einzelner oder auch aller Dienste betre en. Ein in diesem
Zusammenhang oft verwendetes Konzept ist das der bekannten ACID{
Transaktionen [GR93], mit dem die Eigenschaften der Atomaritat, Konsistenz,
Isolation undDauerhaftigkeit bei der sequentiellen undnebenlau gen
Ausfuhrung von Teilschritten einer Gesamttransaktion sicherstellt werden.
Fehlerbehandlungskonzept: Die Nutzung von Diensten, die prinzipiell beliebig
raumlich verteilt sein konnen, erfordert die Berucksichtigung spezieller
Fehlerfalle, die bei einer ausschlie lich lokalen Ausfuhrung nicht auftreten.
Dieses sind insbesondere Fehler, die sich aus der Abhangigkeit von
der Kommunikationsinfrastruktur ergeben und sichgegebenfalls direkt bis
auf die Anwendungsebene auswirken und sogar zum Abbruch der gesamten
Anwendung fuhren konnen. Des weiteren mussen auch Fehler bei der
der Dienstauswahl berucksichtigt werden, so da beispielsweise beim Nichtvorhandensein
eines geeigneten Dienstangebotes geeigneteFehlererholungsma
nahmen initiiert werden konnen.
Interaktionskonzept: Je nach beabsichtigter Zielstellung einer verteilten
Anwendung mussen Interaktionen von Benutzern bei der Anwendungsausfuhrung
berucksichtigt werden. Im einfachsten Fall kann ein Benutzer
hierbei als ein Dienst aufgefa t werden, der uber einen Diensttyp formal
de niert ist. Somit werden die Leistungen eines Benutzers und die
der sonstigen, automatisiert ablaufenden Diensterbringer homogen und
orthogonal behandelbar (siehe auch [MML95d, MML95d]). Zusatzlich ist
jedoch auch die umgekehrte Situation zu berucksichtigen, da externe
Benutzereingaben unabhangig vom konkreten Ausfuhrungszustand der
Anwendung getatigt werden konnen. Hierfur mussen explizite Zugangspunkte
de nierbar sein, an denen die Interaktion statt nden kann. Diese
konnen prinzipiell auch anderen Anwendungen als Interaktionsschnittstelle
dienen.
Strukturierungskonzept: Initialer Schritt der Entwicklung jeder geplanten
verteilten Anwendung sollte darin bestehen, die vorhandene Komplexitat
des Gesamtanwendungsproblems zu reduzieren, so da eine dedizierte
Behandlung von Teilproblemen moglich ist. Hierfur ist ein Strukturierungskonzept
anzubieten, welches neben der Modularisierung der verteilten
Anwendung auch die anschlie ende Kombination der Einzelmodule
unterstutzt. Begleitend zu diesem strukturierten Entwurf verteilter
Anwendungen ist auch die Unterstutzung durch analytische Verfahren
wunschenswert. Hiermit la t sich der voraussichtliche Anwendungsablauf
unter Umstanden bereits vor der eigentlichen Realisierung auf bestimmte

4.2 Beschreibung und Modellierung koordinierter Dienstnutzung 121
Eigenschaften, beispielsweise seine Lebendigkeit oder Verklemmungsfreiheit
bei der nebenlau gen Nutzung von Diensten, untersuchen. In diesem
Zusammenhang ist auch der Einsatz simulativer Methoden [Pag91] sinnvoll,
mit denen eine praxisnahe Erprobung vorhandener Entwurfs{ und
Realisierungsergebnisse moglich ist.
4.2 Beschreibung und Modellierung koordinierter
Dienstnutzung
Auf dem Hintergrund der im vorherigen Abschnitt geforderten Beschreibungs{
und Modellierungskonzepte stellt dieser Abschnitt einen Ansatz vor, der eine
abstrakte Sicht auf koordinierte Nutzung von Diensten in o enen verteilten
Dienstemarkten ermoglicht. Zuvor werden jedoch zuerst grundlegende Begriffe
de niert, die eine durchgangige und einheitliche Darstellung des Ansatzes
ermoglichen. Des weiteren wird auch die Wahl von Petri{Netzen motiviert, die
dem Beschreibungsansatz als formale Grundlage dienen.
4.2.1 Kooperationsanwendungen und Anwendungsvorgange
Zur besonderen Betonung der spezi schen Eigenschaft der koordinierten Nutzung
von Diensten, die im Rahmen einer Anwendungsausfuhrung miteinander
kooperieren, werden die hier betrachteten verteilten Anwendungen im folgenden
als Kooperationsanwendungen bezeichnet. Kooperationsanwendungen unterstreichen
den in Abschnitt 4.1.1 beschriebenen Ubergang zur weitestgehenden Verwendung
extern angebotener Dienste. Sie sind vergleichbar mit den in [Tsc94]
vorgestellten kooperativen Anwendungen, die als " (:::)permanenteoder zeitweilige
Zusammenschlusse von Benutzern und Komponenten zumZweckkoordinierter,
zielgerichteter Aktivitaten (:::)\ de niert sind.
De nition 4.1 (Kooperationsanwendungen) Kooperationsanwendungen
bezeichnen eine Klasse verteilter Anwendungen, die durch ihren ausgepragten
dienstnutzungsorientierten Charakter gekennzeichnet sind. Dieser au ert sich
darin, da bei ihrer Ausfuhrung ausschlie lich externe Dienste verwendet
werden, auf die im Rahmen von Anwendungsvorgangen zugegri en wird.
De nition 4.2 (Anwendungsvorgang) Ein Anwendungsvorgang beschreibt
die Handlungen, die ausgefuhrt werden mussen, um das beabsichtigte Anwendungsziel
zu erreichen. Er ist identi ziert durch einen Namen und besteht aus
einer Folge sequentiell oder parallel ausgefuhrter Aktivitaten, die partiell geordnet
sind.
De nition 4.3 (Aktivitat) Eine Aktivitat beschreibt einen Block von Aktionen,
die gemeinsam ausgefuhrt werden. Sie wird identi ziert durch einen Namen
und besteht aus einer Aktionsbeschreibung sowie einer einschrankenden Bedingung,
die spezi ziert, wann sie ausgefuhrt werden kann. Die Aktionsbeschreibung

122 Koordination von Diensten
besteht entweder aus einer elementaren Aktion oder einer Menge elementarer
Aktionen, die sequentiell oder parallel ausgefuhrt werden.
De nition 4.4 (Aktion) Eine elementare Aktion entspricht dem Aufruf einer
einzelnen Operation an der Schnittstelle eines Diensterbringers. Der genutzte
Dienst wird beschrieben durch seinen Diensttyp und ihn eingrenzende Dienstattribute,
die die gewunschten Eigenschaften des Dienstes festlegen.
Insgesamt ergibt sich somit eine hochgradig nebenlau ge Ausfuhrung von Kooperationsanwendungen.
Dieses ist in Abbildung 4.2 schematisch verdeutlicht.
Aktivitität
Anwendungsvorgang
Aktivitität
Aktivitität
Aktion
Aktivitität
Aktion
Aktion
Dienst
Aktion
Abbildung 4.2:Nebenlau gkeit von Aktivitaten und Aktionen
Je nach betrachtetem Anwendungsbereich nden sichinder Literatur eine Anzahl
alternativer Benennungen fur Kooperationsanwendungen bzw. von Anwendungsvorgangen,
die je nach betrachtetem Anwendungsumfeld beispielsweise als geregelte
arbeitsteilige Anwendungssysteme [Rei93], Auftragssysteme [JV87] bzw.als
Work ows [LA94, Jab95] oder ConTracts [WR91] bezeichnet werden. Entsprechend
wirddieSteuerung von Anwendungsvorgangen unter anderem als Worow
Management, Activity Management [Jab93] und Ablaufsteuerung [Win93]
bezeichnet. In dieser Arbeit wird hierfur zusammenfassendauch der Begri Koordinationsmanagement
verwendet.
4.2.2 Petri{Netze als Beschreibungsgrundlage
Petri{Netze [Pet62] sind ein in den sechziger Jahren von C.A. Petri entwickeltes
Beschreibungskonzept, mit dem eine naturliche und ausdrucksstarkeDarstellung
von Informations- und Kontroll ussen in Systemen mit asynchronen und
nebenlau gen Prozessen ermoglicht wird. Petri{Netze besitzen eine wohlde -
nierte mathematische Basis, auf derer eine formale Analyse statischer und dynamischer
Netzeigenschaften moglich ist (siehe beispielsweise [Pet81, Rei86]).
Durch diese Eigenschaft und auch durch ihre anschauliche Darstellungsweise
in Form einer graphischen Netzdarstellung haben Petri{Netze mittlerweile
in zahlreichen Anwendungsbereichen Verwendung gefunden. Dieses betri t
unter anderem auch Entwicklungsprojekte im Bereich verteilter Anwendungen,

4.2 Beschreibung und Modellierung koordinierter Dienstnutzung 123
wo Petri{Netze vor allem wegen ihrer Analysemethoden hinsichtlich der Verikation
komplexer Anwendungsablaufe eingesetzt werden (siehe beispielsweise
in [Ric83, SV89,Mur89]). Die breite Basis ihrer Verwendung hat auch dazu
gefuhrt, da dem Anwendungsentwickler mittlerweile verschiedene Hilfsmittel
zur Verfugungstehen. Beispiele hierfur sindunter anderem Laufzeit{Simulatoren
wie Design/CPN [Met93] oder LOOPN [Lak92], das eine sprachorientierte Umsetzung
der graphischen Petri{Netz{Darstellung realisiert. Diese unterstutzen in
der Regel nichtnur die Spezi kation von sequentiellen und nebenlau gen Anwendungssystemen,
sondern erlauben zumeist schon wahrendder Spezi kationsphase
Teilanalysen und auch simulative Tests.
Ausschlaggebender Grund fur die Verwendung von Petri{Netzen als formale
Grundlage fur den hier vorgeschlagenen Ansatz zur Beschreibung verteilter Anwendungsausfuhrung
ist insbesondere ihre Eigenschaft, sowohl die Struktur von
Anwendungsvorgangen als auch ihreAusfuhrung ineinem integrierten und mathematisch
fundierten Ansatz beschreiben zu konnen. Hierdurch erleichtert sich
auch die spatere Realisierung einer konkreten Ausfuhrungsumgebung fur Anwendungsvorgange,
da mitder Petri{Netz{basierten Beschreibung eines Anwendungsvorgangs
gleichzeitig auch seine Ausfuhrungssemantik eindeutig festgelegt
ist.
Grundlage fur die weitere Darstellung bilden die Stellen{/Transitionsnetze, die
eine wesentliche Grundform von Petri{Netzen darstellen. Aus graphentheoretischer
Sicht sind sie als bipartiter, gerichteter Graph mit Stellen und Transitionen
als Knoten darstellbar, wobei die Knoten uber gewichtete Kanten miteinander
verbunden sind. Durch die Richtung der Kanten sind die Stellen entweder als
Eingangs{ oder Ausgangsstellen von Transitionen de niert. Der Zustand eines
Netzes bzw. des damit beschriebenen Systems wird durch eine Markierung beschrieben,
die jeder Stelle eine Anzahl von Marken zuordnet. Eine formale Beschreibung
gibt die folgende De nition:
De nition 4.5 (Stellen-/Transitionsnetz) Ein Stellen{/Transitionsnetz ist
ein 6{Tupel N =(S� T� F� K� W�m 0) mit:
einer Menge von Stellen S = fS 1�S 2�:::�Sng,
einer dazu disjunkten nichtleeren Menge von Transitionen T =
fT 1�T 2�:::�Tmg,
einer Flu relation F (S T ) [ (T S),
einer Kapazitatsfunktion K : S ! IN [f1g,
einer Kantengewichtung W :(S T ) [ (T S) ! IN mit W (x� y) =0
genau dann, wenn (x� y) =2 F ,
einer Anfangsmarkierung m 0 : S ! IN mit m 0(s) K(s) fur s 2 S.
Wie oben bereitsangedeutet wurde, eignen sichPetri{Netze sowohl zur Beschreibung
statischer als auch dynamischer Eigenschaften. Wahrend sich die statischen

124 Koordination von Diensten
Eigenschaften in der Netzstruktur widerspiegeln, resultiert die Dynamik eine
Netzes aus seiner Ausfuhrung, bei der Marken durch das Schalten der Transitionen
durch das Netz bewegt werden. Das Schalten einer Transition setzt deren
Aktivierung voraus. Eine Transition hei t aktiviert,wenn samtlicheEingangsstellen
der Transition mit einer der Kantengewichtung entsprechenden Anzahl von
Marken belegt sind. Ein aktivierteTransition kann anschlie end schalten, indem
sie der Kantengewichtung entsprechend viele Marken von allen ihren Eingangsstellen
entferntund gema der Kantengewichtungentsprechend viele Marken auf
ihren Ausgangsstellen ablegt. Hierdurch entsteht eineneue Markierung, die wiederum
Grundlage fur die Aktivierung und das Schalten weiterer Transitionen
bildet. Das Schalten mehrerer Transitionen kann gleichzeitig erfolgen, wie auch
eine Transition gleichzeitig zu sich selbst schalten kann. Der Schaltvorgang geschieht
unmittelbar und zeitverzugslos. Die Menge aller moglichen Schaltfolgen
eines Petri{Netzes legt seinen Erreichbarkeitsgraph fest, der die Gesamtheit der
im Netz einnehmbaren Zustande umfa t.
Ausgehend von diesem einfachen Modell der Stellen{/Transitionsnetze sind ersteMoglichkeiten
fur ihre Nutzung zur Beschreibung von Anwendungsvorgangen
bereits o ensichtlich. So bietet sichunmittelbar eine Zuordnungder Transitionen
zu den Aktivitaten eines Anwendungsvorganges an, wobei die Kanten des Netzes
einen moglichen Aktivitats u verdeutlichen, der durch den Erreichbarkeitsgraphen
des Petri{Netzes bestimmt wird.
4.2.3 Beschreibungskonzepte
Im folgenden werden die Konzepte des hier vorgeschlagenen Ansatzes zur Beschreibung
von Anwendungsvorgangen in ihren Details vorgestellt. Die Darstellung
orientiert sich hierbei an den in Abschnitt gestellten 4.1.2 Beschreibungsanforderungen.
Um diese Anforderungen erfullen zu konnen, sind Erweiterungen
der grundlegenden Stellen{/Transitionsnetze vorzunehmen. Generelle Zielstellung
ist hierbei die Verwendung bereits aus der Petri{Netz{Theorie stammender
Vorschlage. Hierdurch wird eineweitgehendnahtlose Integration undVertraglichkeit
mit den vorhandenen Grundkonzepten von Stellen{/Transitionsnetzen sichergestellt.
So kann auch auf bereits vorhandene Analysewerkzeuge zugegri en
werden, die grundsatzlich auch fur die Analyse von Anwendungsvorgangen verwendbar
sind.
4.2.3.1 Datenkonzept
Zur Darstellung von komplex strukturierten Daten, die in der Regel bei der
Ausfuhrung von Anwendungsvorgangen zwischen den Aktivitaten ausgetauscht
werden, ist eine Erweiterungdes Markenkonzeptes der Stellen{/Transitionsnetze
notwendig, da dort die Marken aufgrund ihrer Uniformitat keine innere Struktur
und Identitat besitzen.
Unterstutzungfur ein derartiges Datenkonzept bieten sogenannte Gefarbte Petri{

4.2 Beschreibung und Modellierung koordinierter Dienstnutzung 125
Netze [JR91, Jen92], die zur Klasse der hoheren Petri{Netze gehoren. 1 Hier besitzen
die Marken eine Identitat, die sie eindeutig unterscheidbar zu anderen
macht, und eine Typisierung, mit der eine Darstellung komplex strukturierter
Daten moglich wird. Beide Eigenschaften spiegeln sich inder folgenden De nition
[JR91] wider:
De nition 4.6 (Gefarbtes Petri{Netz) Ein gefarbtes Petri{Netz ist ein
Stellen/Transitionsnetz (S,T,F,K,Mo) mit den zusatzlichen Eigenschaften
( ,C,G,E):
=fC 1�C 2�:::�Cpg ist eine endliche Menge von Typen, genannt Farbenmengen.
Jede Farbenmenge Cn ist endlich und nicht leer.
C : S ! ist eine Farbenfunktion, die jeder Stelle eine Farbenmenge
zuordnet.
G : T ! BoolExpr ist eine logische Schaltbedingung ( " Guard\), die
jeder Transition einen logischen Ausdruck (BoolExpr) zuordnet, der zu
wahr oder falsch evaluiert und der das Schaltverhalten der Transition einschrankende
Bedingungen spezi ziert.
E : F ! Expr ist eine Kantenausdrucksfunktion, die selektiert, welche
Markenfarben beim Schalten der Transition von den Eingangsplatzen entfernt
und welche auf den Ausgangsplatzen abgelegt werden. Sie wird durch
einen logischen Ausdruck (Expr) beschrieben, der zu einer Multimenge 2
von Farben evaluiert. Die Variablen des Ausdrucks sind aus der Farbenmenge,
die durch die Farbenfunktion C der mit der Kante verbundenen
Stelle zugeordnet ist.
Die Anfangsmarkierung ist fur gefarbte Petri{Netze de niert als M 0 : S !
fc j c 2 g�
Mit der Typsierung der Marken la t sich | in Analogie zur Typisierung von
Diensten (siehe Abschnitt 2.3) | die interne Struktur einer Marke auf wohde -
nierte Art und Weise festlegen. Die Typisierung der Marken wirkt sich auch auf
den Schaltvorgangaus, der in Abhangigkeit von der Auswertungder Kantenausdruckeunddurchdieeiner
Transition zugeordneten logischen Schaltbedingungen
ausgefuhrt wird.
Die Wahl eines bestimmten Datentypmodells wird durch die De nition nicht
festgelegt, sondern kann in Hinblickauf das beabsichtigteAnwendungsumfeld bestimmtwerden.
Im Modellierungswerkzeug Design/CPN [Met93] wird beispielsweise
das Typmodell der Sprache ML [Mil84] unterstutzt. Bei der Beschreibung
von Anwendungsvorgangen wird sich die Wahl eines konkreten Datentypmodells
1 Die Bezeichnung Gefarbtes Petri{Netz erklart sich aus seiner graphischen Darstellungsweise,
in der die unterschiedlichen Marken ursprunglich durch farbige Punkte unterschieden
wurden.
2 Eine Multimenge kann ein Element mehrfach enthalten.

126 Koordination von Diensten
in der Regel in Abhangigkeit vom Diensttypmodell ergeben, welches fur die abstrakteBeschreibungder
Diensteund ihrer Schnittstellen verwendet wird. Dieses
ist beispielsweise auch beider in Teil II dieser Arbeit vorgestellten Koordinationssprache
PAMELA der Fall, der das Typsystem von CORBA zugrunde liegt.
4.2.3.2 Kontroll u konzept
Die Schaltbedingungen und Kantenausdrucke gefarbter Petri{Netze ermoglichen
eine Darstellung zustandsgesteuerter Kontroll usse, wie es in Abschnitt 4.1.2 gefordert
wurde. Mit ihnen konnen die aus Programmiersprachen bekannten Konzepte
wie die bedingteVerzweigung, Auswahl und Schleife dargestelltwerden, die
fur die Steuerung komplizierter Anwendungsvorgange erforderlich sind. Hierfur
ist eine Erweiterung der Kernkonzepte gefarbter Petri{Netze nicht notwendig.
Abbildung 4.3 verdeutlicht verschiedene Kontroll u konstrukte, wobei die Kantenbedingungen
durch informelle logische Ausdrucke reprasentiert sind.
a
a=1 / a=1
Bedingte Verzweigung
a+1
a
a

4.2 Beschreibung und Modellierung koordinierter Dienstnutzung 127
denen Informationen undMaterialien verarbeitet werden, wodurchsich beispielsweise
die Arbeit eines Sachbearbeiters oder einer Maschine beschreiben la t. Da
Instanzen uber die Kanale interagieren, sind unter anderem Informations{ und
Material usse in einem System darstellbar. Diese Sichtweise auf Petri{Netze
ermoglicht die Betrachtung von Transitionen als Funktionsseinheiten [Val87],
die Zustandsanderungen im AnwendungsvorgangdurchdieAusfuhrungvon Operationen
bewirken und sichkonkret in Anderungen der Markierung des Petri{
Netzes zeigen.
In Anwendung auf die Beschreibung von Anwendungsvorgangen liegt es deshalb
nahe, die Transitionen mit externen Diensten zu verknupfen, die mittels von
Operationsaufrufen zuganglich sindund die Verarbeitungder in den Marken vorhandenen
Informationen ubernehmen. Das Transitionskonzept von Petri{Netzen
erganzt sich hierdurch umeine externe Interaktion, bei der die Dienste externer
Dienstnehmer bei der Ausfuhrung einer Transitionen in Anspruch genommen
werden (Abbildung 4.4).
Externer Dienst
Abbildung 4.4:Anbindung von Diensten an Transitionen
Die Verknupfung von Transition und Diensterbringer wird uber den Diensttyp
erreicht, der die Beschreibung der geforderten Dienstattributeund der Aufrufparameter
der Operation umfa t. Die konkreten Parameterwerte ergeben sich aus
den Marken, die von der Transition von den Eingangsstellen entfernt werden.
Die Weitergabe der vom Diensterbringer zuruckgelieferten Ergebnisse erfolgt anschlie
end durch Erzeugung entsprechender Marken auf den Ausgangsstellen der
Transition.
Formal lassen sich derartige, um Dienstaufrufe erweiterten Petri{Netze auf zeitbehaftete
Petri{Netze (engl. timed petri nets) [Jen95]abbilden. Mit ihnen konnen
im Unterschied zu herkommlichen Stellen{/Transitionsnetzen, bei denen das
Schalten einer Transition zeitverzugslos geschieht, Verweilzeiten in den Transitionen
ausgedruckt werden. Der Schaltvorgang einer Transition untergliedert
sich dann in mehrere Schaltphasen [Mar89]:
1. In der Startphase (engl. start ring phase) werden die Marken von den
Eingangsstellen entfernt�
2. In der Schaltphase (engl. ring in progress phase) be nden sich die Marken
" in\ der Transition�

128 Koordination von Diensten
3. In der Endphase (engl. end ringphase) werden die Marken auf den Ausgangsstellen
abgelegt.
Die Darstellung des Zeitverbrauchs in der Schaltphase geschieht hierbei mittels
stochastischer Verfahren, die anschlie end auch imRahmen weiterer Netzanalysen
genutzt werden konnen (siehe beispielsweise [Mar89]).
4.2.3.4 Nebenlau gkeitskonzept
Bedingt durch ihre formale De nition stellen Petri{Netze bereits die wesentlichen
Beschreibungsmittel zur Verfugung, die zur Wiedergabe der Dynamik
nebenlau ger Aktivitaten notwendig sind. Aus Sicht von Kooperationsanwendungen
und den dort ausgefuhrten Anwendungsvorgangen ist insbesondere die
Beschreibung der Inter{ und Intravorgangsnebenlau gkeit von Interesse. Erstere
bezeichnet die Nebenlau gkeit, die in einer Kooperationsanwendung durch
die gleichzeitige Abwicklung mehrerer identischer Anwendungsvorgange auftritt.
Die Intravorgangsnebenlau gkeit tritt dann auf, wenn innerhalb eines einzelnen
Anwendungsvorgangs mehrere verschiedene Aktivitaten gleichzeitig ausgefuhrt
werden. Abbildung 4.5verdeutlicht beideVarianten.
Abbildung 4.5: Inter- und Intravorgangsnebenlau gkeit
Wahrend sich die Intravorgangsnebenlau gkeit durch gleichzeitiges Schalten
mehrerer Transitionen darstellen la t, druckt sich die Intervorgangsnebenlau gkeit
in Form von Transitionen aus, die zu sichselbst nebenlau g schalten. Hierbei
werden die in der Abbildung gezeigten zwei Marken, die jeweils einem Anwendungsvorgang
zugeordnet sind, durch die Transition konzeptuell gleichzeitig und
unabhangig voneinander verarbeitet. Aufgrund der Unterscheidbarkeit der Marken
in gefarbten Petri{Netzen la t sich hierdurch die unabhangige Bearbeitung
mehrerer Anwendungsvorgange in einem Petri{Netz beschreiben.
Im Zusammenhangmitdem nebenlau gen Schalten der Transitionen sind zusatzlich
auch Konsistenzaspektezuberucksichtigen, die beim Zugri auf gemeinsam
genutzte Ressourcen auftreten. Klassische Beispiele derartiger Synchronisationsproblemesinddas
in [JV87, HH89]ausfuhrlich dargestellte Leser/Schreiber{ und
das 5{Philosophen{Problem, an denen sich exemplarischzahlreiche Algorithmen
fur die Analyse von Petri{Netzen, beispielsweise fur die Uberprufungder Lebendigkeit
eines Netzes, zeigen lassen. Ein genereller Losungsansatz hierfur, der von

4.2 Beschreibung und Modellierung koordinierter Dienstnutzung 129
seinem Grundprinzip her auchfur andere Koordinationsprobleme(siehe beispielsweise
auch [MC94]) anwendbar ist, ist die De nition von sogenannten kritischen
Abschnitten (Abbildung 4.6).
Abbildung 4.6: Wechselseitiger Ausschlu im kritischen Abschnitt
Die Realisierung des in der Abbildung grau unterlegten kritischen Abschnitts
erfolgt mittels einer Synchronisationsstelle, die vergleichbar zum aus dem Betriebssystembereich
bekannten Semaphor [PS85] ist. Der kritische Abschnitt
darf von den nebenlau gen Prozessen nur im wechselseitigen Ausschlu betreten
werden, was sich konkret im Petri{Netz darin ausdruckt, da nur ein
Proze die Marke aus der Synchronisationstelle entnehmen kann. Die dargestellte
Losung berucksichtigt hierbei nicht das Fairness{Prinzip, da dort durch das
nicht{deterministischeSchalten des Netzes prinzipiell immer derselbe Proze den
kritischen Abschnitt betreten kann. Eine Losung dieses Problems ndet sich in
[JV87].
4.2.3.5 Strukturierungskonzept
Die Beschreibung komplexer Kooperationsanwendungen erfordert die Unterstutzung
durch Strukturierungskonzepte, mit denen eine Modularisierung auf
der Ebene der Anwendungsvorgange moglich ist. Grundlage hierfur bildet die
Aufteilung der Gesamtanwendung in beschreibare Teilvorgange, fur die jeweils
dedizierte Losungsansatze entwickelt werden konnen. Des weiteren mussen
eindeutige Schnittstellen zwischen den Teilvorgangen de nierbar sein, damit
diese anschlie end auf wohlde nierte Art und Weise miteinander verbunden
werden konnen.
Petri{Netze bieten als Strukturierungsmittel in der Regel eine Hierarchisierung
an, die auf dem Prinzip transitionsberandeter oder stellenberandeter Teilnetze
[Jen92] beruht. Hierbei werden entweder Transitionen oder Stellen zusammengefa
t, so da sie auf einer hoheren Abstraktionsebene als eine Transition oder
Stelle erscheinen. Bei einer spateren Netzanalyse werden die Teilnetze durch
Expansion wieder bis auf die Ebene einzelner Stellen und Transitionen aufgelost.
Obwohl dem Anwendungsentwickler durch die Hierarchisierung zahlreiche
Abstraktionsmoglichkeiten gegeben sind, besteht ihr wesentlicher Nachteil
jedoch darin, da das Verhalten der Teilnetze immer im Zusammenhang mit
dem Gesamtnetz betrachtet werden mu und somit eine getrennteAnalyse nicht

130 Koordination von Diensten
moglich ist [SB93]. Fur die Darstellungvon Anwendungsvorgangen mittels Petri{
Netzen erscheint es sinnvoller, eine losere Kopplung von Teilnetzen anzustreben,
die einen hohen Grad an Unabhangigkeit der verknupften Teilnetze ermoglicht.
Einen Ansatz hierfur bieten sogenannte Klienten/Server{Netze [SB93], die eine
Unterscheidung inKlienten{ und einServer{Netze vornehmen (Abbildung 4.7).
Klienten-Netz
Server-Netz
Abbildung 4.7: Strukturierung durch Klienten/Server{Netze
In dieser Sichtweise verfugen die Server-Netze uber von au en zugreifbare Stellen,
auf die Marken von Seiten der Transitionen des Klienten{Netzes abgelegt
werden konnen. Die Marken konnen als Auftrage betrachtet werden, die durch
das Server{Netz verarbeitet werden. Die Verbindungsstelle ist als unidirektionaler
Kanal de niert, der beide Netze insofern lose koppelt, als da von Klienten{
Seite der aktuelle Zustand des Server{Netzes nicht berucksichtigt werden mu .
Hierdurch la t sich zumeinen eine unabhangige Betrachtungder Teilnetze erreichen,
die im Fall komplexer Anwendungsvorgange zur Beschreibung von Teilvorgangen
dienen konnen. Zum anderen ermoglicht sie die problemlose Verknupfung
der Teilnetze zu einem ausfuhrbaren Gesamtnetz. Ein hiermit verbundener
Vorteil ist dann auch die Wiederverwendbarkeit von Teilvorgangen,
die uber Verbindungsstellen zu neuen Anwendungsvorgangen miteinander kombiniert
werden konnen.
4.2.3.6 Fehlerbehandlungskonzept
Nachder De nition von Petri{Netzen geschiehtder Schaltvorganggenerell fehlerlos,
da dort eine Abgeschlossenheit des Gesamtnetzes zugrunde gelegt wird, die
eine Beein u ungder Ausfuhrungdes Petri{Netzes durch externe Ereignisse verhindert.
Diese Grundannahme gilt jedoch nicht mehr fur die oben vorgeschlagene
Erweiterung von Petri{Netzen zur Beschreibung von Anwendungsvorgangen,
die sich gerade dadurch auszeichnet, da wahrend der Ausfuhrung einer Transition
ein oder mehrere externe Dienste in Anspruch genommen werden. Hier
ist grundsatzlich von Fehlern bei der Dienstnutzung auszugehen, die einerseits
aufgrund fehlerhafter Kommunikation, beispielsweise dem Abbruch einer Netzwerkverbindung,
und andererseits auch von den unterstutzenden Systemdiensten
hervorgerufen werden konnen. Insbesondere fur den letzten Fall sind Fehlerfalle
zu beachten, die sich bei der Dienstauswahl ergeben konnen, beispielsweise falls
keine geeigneten Dienstangebote zur Ausfuhrung einer Aktion gefunden werden

4.2 Beschreibung und Modellierung koordinierter Dienstnutzung 131
konnen. Ebenfalls anzunehmen sind auch Fehler hinsichtlich der Verfugbarkeit
von Systemdiensten selbst, beispielsweise falls das fur die Dienstauswahl notwendige
Typmanagement kurzfristig nicht zur Verfugung steht. Fur derartige
systemtechnische Fehler sind entsprechende Fehlerbehandlungsma nahmen, d.h.
sowohl Fehlererkennungs{ als auch Fehlererholungsmechanismen, anzubieten. Zu
welchen Grad die Fehlerbehandlung aus der Ausfuhrungsumgebung von Petri{
Netzen bis auf die Beschreibungsebene der Anwendungsvorgange hochgereicht
werden soll, hangt von den dort geforderten Beschreibungsabstraktionen ab. Ist
beispielsweise ein hohes Abstraktionsniveau gefordert, mussen von Seiten der Systemumgebung
automatische Fehlererholungsma nahmen durchgefuhrt werden,
die auftretende systemtechnischeFehlerfalle moglichst vollstandig nach obenhin
verbergen. Im Fall einer erfolglosen Dienstauswahl konnte beispielsweise eine
erneute Dienstanfrage an einen Trader mit abgeschwachten Suchkriterien und
exibleren Suchvorschriften gestellt werden.
Eine Moglichkeit zur Integration des geforderten Fehlerbehandlungskonzeptes in
Petri{Netze besteht inder Erweiterung der Transitionskonzeptes. Hierfur werden
fur jede Transition zwei verschiedene Mengen von Ausgangsstellen de niert.
Die ersteMenge berucksichtigt den fehlerfreien Fall, bei dem keine systemtechnischen
Fehler auftreten. Im fehlerbehafteten Fall wird hingegen die zweite Menge
von Stellen berucksichtigt. Auf diese werden systemseitig Marken abgelegt, aus
denen die Art und der Grund des Fehlers ersichtlich wird, so da anschlie end
eine geeignete Fehlerbehandlung imAnwendungsvorgang durchgefuhrt werden
kann. 3 Hierfur sind bereits bei der Petri{Netz{Beschreibung entsprechende anwendungsspezi
sche Fehlerbehandlungsma nahmen festzulegen. Dies kann beispielsweise
in Form eines expliziten Fehlerbehandlungsdienstes geschehen, wie er
in Abbildung 4.8 dargestellt ist.
Dienst
Fehler
Fehlerbehandlungsdienst
Abbildung 4.8:Auslosung einer Fehlerbehandlung
Fehlerbehandelnde
Transition
Der Fehlerbehandlungsdienst kann sowohl automatische Aktionen initiieren, die
beispielsweise das erneute Starten einer Operation oder das Auslosen einer kompensierenden
Aktivitat ubernehmen, als auch Benachrichtigungen an den Benutzer
erzeugen, um ihn zu expliziten administrativen Ma nahmen aufzufordern.
3 Die Vertraglichkeit dieser Erweiterung ist in [Bri95] mittels der Abbildung des Fehlerbehandlungskonzeptes
auf ein aquivalentes, nichtdeterministisches Stellen{/Transitionsnetzes
gezeigt.

132 Koordination von Diensten
Hierdurch wird eine allgemeine benutzerorientierte Fehlerbehandlung [EN93]
ermoglicht.
4.2.3.7 Interaktionskonzept
Die Abwicklung von Anwendungsvorgangen erfordert in der Regel zahlreiche Interaktionen
auch mit externen Benutzern, von denen entweder Eingaben explizit
vom Anwendungsvorgang angefordert oder auch selbstandig und unaufgefordert
Daten an einen laufenden Anwendungsvorgang ubergeben werden konnen.
Die erste Art der Benutzerinteraktion ist generell orthogonal zum externen
Dienstaufruf bei der Ausfuhrung einer Transition behandelbar. In diesem Fall
versteht sich die Tatigkeit eines Benutzers als Dienstleistung, die dem Anwendungsvorgang
uber einen auf der Systemebene be ndlichen Dienst zuganglich
gemacht wird. Im Unterschied zu automatisch ablaufenden Diensten ist jedoch
eine explizite Interaktion mit dem Benutzer erforderlich, der die Eingabe der geforderten
Daten vornimmt. Die Au orderung des Benutzers kann beispielsweise
mittels einer Arbeitsliste [LR94] geschehen, aus der der Benutzer vom Anwendungsvorgang
geforderte Tatigkeiten entnehmen kann.
Bei der zweiten Art, bei der die Benutzer unaufgefordert Daten an den Anwendungvorgang
ubergeben konnen, lassen sich generell die unidirektionale und die
bidirektionale Benutzerinteraktion unterscheiden [Bri95]. Im ersten Fall erwartet
der Benutzer nach der Eingabe der Daten keine Antwort, so da die Interaktion
nach der Annahme der Eingabe sofort beendet wird. Mit dieser Variante lassen
sich auf einfache Art und Weise Benachrichtigungen, beispielsweise Steuerungsanweisungen,
realisieren, die in der Regel keiner Ruckantwort bedurfen.
Im Gegensatz hierzu wird bei der bidirektionalen Interaktion davon ausgegangen,
da der Benutzer eine explizite Antwort erwartet. Hiermit sind insbesondere
Benutzeranfragen realisierbar, die in der Ruckgabe einer Menge von Ergebnissen
resultieren.
Obwohl aufgrund der Abgeschlossenheit von Petri{Netzen eine Unterstutzung
derartiger Benutzerinteraktionen explizit nicht vorgesehen ist, la t sich die unidirektionale
Interaktion in ahnlicher Weise wie die in Abschnitt 4.2.3.5 vorgestellten
Klienten/Server{Netze beschreiben (Abbildung 4.9).
Externer Benutzer
Verbindungsstelle
Abbildung 4.9: Unidirektionale Benutzerinteraktion

4.2 Beschreibung und Modellierung koordinierter Dienstnutzung 133
Konzeptuell werden die Benutzer als Klienten{Netze angesehen, die auf den von
den Server{Netzen nachau en zur Verfugunggestellten Verbindungsstellen asynchron
Marken ablegen konnen. Die Marken werden anschlie end imServer{Netz
vorgangsspezi sch verarbeitet.
Im Gegensatz zur unidirektionalen Interaktion gestaltet sich die Beschreibung
einer bidirektionalen Interaktion vergleichsweise aufwendig. Wesentliche Ursache
hierfur ist die enge logische Verknupfung, die zwischen dem Eingabe{ und dem
Ausgabeschrittnotwendig ist. In Abbildung 4.10 ist dieses am Beispiel von zwei
miteinander verbundenen Transitionen dargestellt.
Benutzer
Eingabe
Ausgabe
Abbildung 4.10: Bidirektionale Benutzerinteraktion mittels zwei Transitionen
In diesem Fall realisiert die erste die Entgegennahme der Daten, wahrend die
zweite spater eine Antwortnachricht anden Benutzer zuruckschickt. Voraussetzung
hierfur ist, da beide Transitionen nur in dieser festgelegten Reihenfolge
schalten, da ansonsten Konsistenzprobleme auftreten konnen. Die Erfullung
dieser Eigenschaft ist in Petri{Netzen im allgemeinen jedoch nur schwer nachzuweisen
[SB94]. Eine Moglichkeit zur Umgehung dieser Problematik ist die
Einfuhrung einer besonderen Transition, die sich aus der in der Abbildung bereits
angedeuteten Verschmelzung der beiden einzelnen Transitionen ergibt. Mit
dieser Verschmelzung istgleichzeitig auch eine Anderung des Schaltverhaltens
der neuen Transition verbunden, die in Abbildung 4.11 durch eineentsprechende
Numerierungverdeutlichtist.Beidem Schaltvorgang erfolgt eine Umkehrungdes
ublichen Schaltverhaltens, die sichinder vertauschten Reihenfolge des Entfernens
undAblegens von Marken auf den Ein- undAusgangsstellen ausdruckt. Die Transition
schaltet wie auch eineunidirektional angesto ene Transition, ohne jedoch
Marken von ihren netzinternen Eingangsstellen zu entfernen. Im Unterschied
zum unidirektionalen Fall geht die Transition stattdessen in einen Wartezustand
uber, indem sie auf die Belegung ihrer Eingangsstellen wartet. Sobald dieses geschehen
ist, wird die bis zu diesem Zeitpunkt suspendierte Benutzerinteraktion
durch Ruckgabe einer Antwortnachricht beendet. Die Benachrichtigung erfolgt
ebenso wie die Eingabe uber eine eigene Verbindungsstelle, so da der Benutzer
konzeptuell einem Server{Netz entspricht. 4
4 Zur tiefergehenden Diskussion der Vertraglichkeit dieser konzeptuellen Erweiterung von

134 Koordination von Diensten
Benutzer
Eingabe
Ausgabe
Abbildung 4.11: Bidirektionale Benutzerinteraktion durch Transitionsverschmelzung
4.2.3.8 Transaktionskonzept
Wie in Abschnitt 4.2.3.6 bereits verdeutlicht wurde, sind bei der Ausfuhrung
von Anwendungsvorgangen zahlreiche Fehlerfalle zu berucksichtigen, die unter
Umstanden sogar einen Abbruch der Kooperationsanwendung zur Folge haben
konnen. Um trotz dieser Fehler eine konsistente Ausfuhrung der Anwendungsvorgange
sicherstellen zu konnen, ist die Einfuhrungeines Konzeptes erforderlich,
mit dem einzelne Aktivitaten bzw. Aktionen als eine logisch zusammengehorende
Ausfuhrungseinheit behandelt werden konnen.
Ein hierfur geeignetes und hau g verwendetes Kontrollkonzept sind die ACID{
Transaktionen [Gra81, GR93], die sich durch die folgenden grundlegenden Eigenschaften
auszeichnen:
Atomaritat: Innerhalb einer Transaktion werden entweder alle Handlungen
ausgefuhrt oder keine ( " Alles oder Nichts\{Prinzip)�
Konsistenz: EineTransaktion uberfuhrt ein System von einem konsistenten
in einen anderen. Hierbei ist der Begri der Konsistenz anwendungsspezisch
zude nieren.
Isolation: Die Operationen einer Transaktion werden vor der Beein u -
ung durch dieAusfuhrung nebenlau g ausgefuhrter Operationen anderer
Transaktionen geschutzt.
Dauerhaftigkeit: Nach Beendigung einer Transaktion sind ihre Wirkungen
dauerhaft und konnen nur durch explizite Gegentransaktionen modi ziert
werden.
Um Transaktionen in Petri{Netzen darstellen zu konnen, ist eine Erweiterung
des Transitionskonzeptes notwendig. Abbildung 4.12 zeigt einen moglichen Integrationsansatz.
Transaktionale Transitionen werden im folgenden mit einem (T)
gekennzeichnet.
Transitionen siehe insbesondere die Arbeiten von [Bri95] und [SB94].
1.
4.
2.
3.

4.2 Beschreibung und Modellierung koordinierter Dienstnutzung 135
Transaktionaler Dienst
Transaktionaler Dienst
Gesamttransaktion
T
Commit
Abbruch
Abbildung 4.12: Commit{ und Abort{Ausgangsstellen zur Transaktionsbehandlung
Die Sicherstellung der Atomaritats{ und Isolationseigenschaften erfolgt in ahnlicher
Weise wie beim Fehlerbehandlungskonzept durch die Einfuhrung spezieller
Ausgangsstellen, auf die je nach erfolgloser (Abbruch) oder erfolgreicher
(Commit)Beendigung entsprechend Marken abgelegt werden. Die Nutzung mehrerer
transaktionaler Dienste 5 ist hierbei innerhalb der Transition gekapselt, so
da Zwischenzustandenach au en fur andere Transitionen nur uber diese beiden
Stellen sichtbar werden. Die dort abgelegten Marken konnen anschlie end durch
Schalten nachfolgender Transitionen entfernt werden, um anwendungsspezi -
sche Folgeaktivitaten zu initiieren. Hierbei kann es unter Umstanden auch sinnvoll
sein, Aktionen fruherer, bereits abgeschlossener Transaktionen ruckgangig
zu machen. Dies kann beispielsweise in Form von kompensierenden Aktionen
[GMGK + 91, KLS90] geschehen, die ebenfalls durch transaktionale Dienste ausgefuhrt
werden.
Ein alternativer Vorschlag fur die Zusammenfassung von Operationen innerhalb
von Transaktionen ndet sich imConTract{Modell [WR90, Sch93c], dem ebenfalls
ein Petri{Netz{basierter Ansatz in Form von Pradikats{/Transitionsnetzen
unterliegt, die vom Konzept her ahnlich zuden hier gewahlten gefarbten Petri{
Netzen sind. In diesem Beschreibungsansatz erfolgt die Transaktionsklammerung
nicht innerhalb der Transitionen, sondern auf der Ebene der Petri{Netze, indem
Transitionen beliebig transaktional miteinander kombiniert werden konnen. Ein
mit diesem Ansatz verbundene Problemstellung ist jedoch das Auftreten von
Kon iktsituationen im Kontroll u einer Transaktion, da generell nicht zugesichert
werden kann, da die eine Transaktionsausfuhrung beendende Transition
auch tatsachlich jemals schaltet (siehe hierzu [Sch93c]). Diese Situation konnte
beispielsweise dann auftreten, wenn eine nicht ander Transaktion beteiligte
Transition Marken von Stellen entfernt, die fur die Beendigung der Transaktion
erforderlich sind. Dieses Problem hangt eng mit die Sichtbarkeit von Zwischenzustanden
in den die Transitionen verbindenden Stellen zusammen, die prinzipi-
5 Bei dieser transaktionalen Zusammenfuhrung konnen jedoch nur Dienste mit bestimmten
transaktionsunterstutzenden Eigenschaften berucksichtigt werden. Dieses betri t insbesondere
die Unterstutzung eines gemeinsamen Ausfuhrungsprotokolls, beispielsweise dem 2{Phasen{
Kommit{Protokoll [GR93], mit dem eine Transaktionsteuerung und {sicherung auch ineiner
verteilten Systemumgebung durchfuhrbar ist.

136 Koordination von Diensten
ell fur andere Transitionen zuganglich sind. Insbesondere bei der Beschreibung
komplexer Anwendungsvorgange mit einem hieraus resultierenden, in der Regel
gro en und unubersichtlichen Netz la t sich dieses prinzipiell nicht ausschlieen.
Aus diesem Grund erscheint der hier gewahlte Ansatz, der Transaktionen
nur innerhalb von Transitionen zula t, fur die Beschreibung von Anwendungsvorgangen
geeigneter.
4.3 Bewertung und erganzende Bemerkungen
Die Bereitstellung einer aus Typmanagement{, Trading{ und Interzeptions{
Mechanismen bestehenden Dienstinfrastruktur, die einen weitgehend uneingeschrankten
Zugang zuden in o enen verteilten Dienstemarkten vorhandenen
Dienstangeboten zur Verfugung stellt, ermoglicht einen neuen Stil der Realisierung
verteilter Anwendungen. Dieser zeichnet sich imwesentlichen dadurch
aus, da die Anwendungsentwicklung weitestgehend oder sogar ausschlie lich
in Form von Diensten geschieht, die im Rahmen von Anwendungsvorgangen
kombiniert genutzt werden. Diese Dienste werden entweder innerhalb verteilter
Dienstemarkte von externen Dienstanbietern bereits angeboten oder im Rahmen
der Anwendungsentwicklungneu realisiert. Die weitestgehendeVerwendung
von Diensten kann somit auch als ein allgemeingultiges Prinzip zur Realisierung
zukunftiger verteilter Anwendungen verwendet werden.
Bei dieser Art der Anwendungsentwicklung wird ersichtlich, da zukunftig die
Aspekte der Koordination von Diensten adaquat berucksichtigt werden mussen.
Dieses bedeutet insbesondere, da ausdrucksmachtige Beschreibungsmittel zur
Verfugungstehen mussen, die den ausgepragten dienstorientierten Charakter verteilter
Anwendungen auszudrucken vermogen. Hierzu wurde in diesem Kapitel
die Abstraktion von Anwendungsvorgangen vorgestellt, die eine Konzentration
auf die Koordinationsaspekte von Dienstnutzung ermoglicht.
Die Darstellung von Anwendungsvorgangen geschieht hierbei auf der Grundlage
eines erweiterten Petri{Netzes. Ausschlaggebender Grund fur die Verwendung
von Petri{Netzen in dieser Arbeit ist insbesondere ihre Eigenschaft, sowohl die
Struktur von Anwendungsvorgangen als auch ihre Ausfuhrungineinem integrierten
und mathematisch fundierten Ansatz beschreiben zu konnen. Dieses erlaubt
einen weitestgehend nahtlosen und direkten Ubergang von der Beschreibung in
die Ausfuhrung von Anwendungsvorgangen, da mit der Struktur eines Petri{
Netz gleichzeitig auch seineAusfuhrungssemantik eindeutig festgelegt wird. Dieser
Vorteil zeigt sich auch bei der im Rahmen der TRADE{Systemumgebung
realisierten konkreten Ausfuhrungsumgebung fur Anwendungsvorgange.
Insgesamt zeigt sich, da die durch Petri{Netze inharent gegebenen Darstellungsmittel
von Nebenlau gkeit und Synchronisation eine geeignete Grundlage
fur die Beschreibung von Anwendungsvorgangen bilden. Mit ihnen sind die
oben genannteIntra{ und Intervorgangsnebenlau gkeit und die gegebenfalls notwendigen
Synchronisationslosungen auf intuitive und einfache Art und Weise in
einem Petri{Netz darstellbar. Durch diese Integration in einer Beschreibungs-

4.3 Bewertung und erganzende Bemerkungen 137
form la t sich der konzeptuelle Bruchvermeiden, der sich im allgemeinen bei der
Einfuhrungvon Nebenlau gkeits{ und Synchronisationskonzepten in herkommlichen
sequentiellen Beschreibungsansatzen, beispielsweise der Nutzung der DCE{
Thread{Bibliothek [OSF93b] inder Systemprogrammiersprache C [KR88], zeigen.
Hierdurch la t sich auch ein hohes Abstraktionsniveau fur den Anwendungsentwickler
bei der Beschreibung von Anwendungsvorgangen erreichen. Unterstutzt
wird dieses unter anderem auch dadurch, da mit der gewahlten Petri{
Netz{Darstellung von Anwendungsvorgangen eine vollstandige Trennung der koordinativen
von den verarbeitungsbezogenen Aspekten bereitgestellt wird. Das
Petri{Netz beschreibt hierbei ausschlie lich die Koordination, wahrend die Beschreibung
der eigentlichen anwendungsspezi schen Berechnungsfunktionalitat
in den Diensten verborgen ist und prinzipiell in einer beliebigen Programmiersprache
erfolgen kann. In diesem Zusammenhang wird der hier vorgeschlagene
Beschreibungsansatz als Koordinationstechnologie [SV89] aufgefa t, der sich generell
zur Entwicklung einer Koordinationssprache [GC92] eignet.
Bei dem Ubergang zueiner konkret nutzbaren Koordinationssprache zur Programmierung
von Anwendungsvorgangen ist als nachster Schritt insbesondere
das Diensttypmodell des Beschreibungsansatzes zu konkretisieren. Erst hierduch
wird eine Verknupfung zueiner realen Dienstinfrastruktur gescha en. Dieser
Schritt wirdkonkret im nachfolgenden zweiten Teil dieser Arbeit vollzogen,
in dem unter anderem die Koordinationssprache PAMELA der TRADE{
Systemumgebung vorgestellt wird, die eine programmiersprachliche Umsetzung
des in diesem Kapitel beschriebenen Beschreibungsansatzes ermoglicht. Hierbei
zeigt sich dann auch der Vorteil der Wahl von Petri{Netzen als Beschreibungsgrundlage,
da mit ihnen gleichzeitig auch die Semantik der Ausfuhrung der mit
PAMELA beschriebenen Anwendungvorgange de niert ist. Diese Ausfuhrungssemantik,
die im Petri{Netz durch das Schaltverhalten der Transitionen reprasentiert
wird, bildet auch eine geeignete Grundlage fur die Realisierung einer Steuerungskomponente,
wie sie in Form des Koordinationsmanagers in TRADE realisiert
worden ist.
In dem vorgeschlagenen Beschreibungsansatz wurden eineReiheinder Forschung
entwickelter Petri{Netz{Erweiterungen kombiniert, um den besonderen Anforderungen,
vor allem nach Unterstutzung eines Aktions{, Nebenlau gkeits{ und
Interaktionskonzeptes, bei der Beschreibungkoordinierter Dienstnutzung gerecht
zu werden. Ihre Vertraglichkeit wurdeanden jeweiligen Stellen erortert, wobei jedoch
auf die Darstellung einer formalen Beweisfuhrungverzichtet wurde. Hierfur
sei insbesondere auf die in der Literatur vorhandenen, umfangreichen Arbeiten,
beispielsweise [Mar89] fur das Schaltverhalten von Transitionen beim dienstorientierten
Aktionskonzept und [SB93,SB94]fur die Strukurierungstechnik der
Klienten/Server{Netze, verwiesen. Fur die Weiterverfolgungdes Beschreibungsansatzes
ist jedoch zukunftig eine vollstandige formale Spezi kation der Netzsemantik
unter Berucksichtigung der hier vorgestellten Erweiterungen anzustreben.
Einen Anhalt fur eine derartige Formalisierung konnte die Darstellung der
FUNSOFT{Netze in [Gru91, DGSZ94] bieten.
Der gewahlte Beschreibungsansatz beschrankt sich auf die Erfullung der in Ab-

138 Koordination von Diensten
schnitt 4.1.2 gestellten Anforderungen, die zur Beschreibung von Anwendungsvorgangen
erfullt werden mussen. Er ist jedoch weiter ausbaubar, indem er
prinzipiell die Formulierung weitergehender Anforderung an die Beschreibung
von Anwendungsvorgangen zula t, was insbesondere auch durch die Erweiterungsfahigkeit
von Petri{Netzen unterstutzt wird. So ware erganzend beispielsweise
ein Rollenkonzept [Tsc94] sinnvoll, mit dem unter anderem eine organisationelle
Zuordnung von Benutzern zu den Aktivitaten bzw. Aktionen eines
Anwendungsvorganges moglich ist. Hierdurch konnen dann bestimmte Anwendungsbereiche,
beispielsweise die Optimierung von Arbeitsablaufen in Unternehmen
(engl. work ow management, process management) [Jab95, CKO92], spezi
scher unterstutzt werden. Weitere Uberlegungen konnten beispielsweise auch
hinsichtlich der Ersetzung des hier verwendeten ACID{Transaktionskonzeptes
angestellt werden. Gerade in Hinblick auf die Beschreibung langlebiger Aktivitaten
[DHL90], deren Ausfuhrung sich uber einen langen Zeitraum erstreckt,
sind dieACID{Forderungen oftmals zu streng. Hier wird in der Regel ein gelockertes
Transaktionskonzept gefordert (siehe unter anderem [Elm91] fur eine
Ubersicht verschiedener erweiterter Transaktionskonzepte). Diese besitzen dann
jedoch auch eineandere Ausfuhrungssemantik, zu deren Darstellung zumTeil
andere Ausdrucksmittel zur Verfugung stehen mussen.

Teil II
TRADE: Eine verteilte
Systemumgebung zur
Vermittlung und Koordination
von Diensten

TRADE{Uberblick 141
Der vorliegende Teil stellt das Service Trading and Coordination Environment
(TRADE) vor, welches im Rahmen dieser Arbeit entwickelt wurde und einen
integrierten Losungsansatz zur Unterstutzung koordinierter Dienstnutzung in
o enen verteilten Dienstemarkten vorschlagt und konkret implementiert. Die
Konzeption der TRADE{Systemumgebung setzt hierbei unmittelbar auf dem
vorherigen Teil I auf, indem sie eine prototypische Umsetzung der dort zunachst
abstrakt beschriebenen Mechanismen in eine konkreteverteilte Systemumgebung
realisiert.
Die entwickelte TRADE{Systemumgebung setzt sich grundsatzlich aus einer
Entwicklungs{ und einer Ausfuhrungsumgebung zusammen (Abbildung 4.13):
Beschreibung koordinierter Dienstnutzung
(Koordinationssprache PAMELA)
Dienstzugang
Diensttypbasierte
Dienstbeschreibung
Diensttypmanagement
Dienstvermittlung
Dienstzugriff (Interzeption)
DCE-basierte
Verwaltungsdomäne
Dienst-
Koordination
Entwicklungsumgebung
Koordinationsmanagement
CORBA-basierte
Verwaltungsdomäne
Ausführungsumgebung
Abbildung 4.13: Entwicklungs{ und Ausfuhrungsumgebung inTRADE
Die Entwicklungsumgebung stellt abstrakte Mittel und Werkzeuge zur
Verfugung, die zur Beschreibung von Diensten (Kapitel 2) und verteilten
Anwendungen bzw. Anwendungsvorgangen (Kapitel 4) notwendig sind.
Sie umfa t zum einen eine diensttypbasierte Dienstbeschreibung, mit der
die in den unterliegenden Verwaltungsdomanen angebotenen Dienste auf
einheitliche Artund Weise beschrieben werden konnen. Diese Dienstbeschreibungen
konnen anschlie end auch bei der Spezi kation von Anwen-

142 TRADE{Uberblick
dungsvorgangen mittels der Koordinationssprache PAMELA weiterverwendet
werden.
Die Ausfuhrungsumgebung realisiert die Laufzeitmechanismen, die eine
Ausfuhrung der in der Entwicklungsumgebung abstrakt beschriebenen koordinierten
Dienstnutzung unterstutzen. Sie beinhaltet unter anderem die
in Kapitel 3 identi zierten Unterstutzungsmechanismen des Diensttypmanagements,
der Dienstvermittlung und der Interzeption, mit denen sich ein
weitgehend uneingeschrankter Zugang zuden in o enen heterogenen verteilten
Dienstemarkten angebotenen Diensten erreichen la t.
Weiterhin umfa t die Ausfuhrungsumgebung Steuerungs{ und Koordinationsmechanismen,
die zur Ausfuhrung von Kooperationsanwendungen bzw.
Anwendungsvorgangen benotigt werden.
Als Grundlage fur die prototypische Realisierung der Entwicklungs{ und
Ausfuhrungsumgebung wurden die verteilten Systemplattformen DCE und
CORBA verwendet, mit denen die vorhandene technische Heterogenitat der an
o enen verteilten Dienstemarkten beteiligten Verwaltungsdomanen beispielhaft
widergebbar ist. Sie bilden au erdem eine geeignete Basis, die im Rahmen
dieser Arbeit entwickelten Losungsansatze, auf die zum Teil bereits in den
vorangegangenen Kapiteln eingegangen wurde, praktisch zu evaluieren und
auf ihre Anwendbarkeit hin zu uberprufen. Dabei sind die erzielten Losungen
jedoch weitestgehend generisch, so da sie prinzipiell auch auf andere verteilte
Systemplattformen ubertragbar sind.
Die folgende Darstellung unterteilt sichinzwei Abschnitte. Zunachst geht Kapitel
5 auf die in TRADE entwickelten Systemmechanismen ein, die einen weitestgehend
uneingeschrankten Zugang zu in DCE{ und CORBA{basierten Verwaltungsdomanen
angebotenen Dienste bereitstellen. Hierzu werden insbesondere
der Typmanager [CMML96], der TRADEr [MJM94, MML94b, MML95f,
GGL + 95, LMM95, MMaTT96] und der Interzeptor [GML96] vorgestellt und ihre
Kooperationsbeziehungen beschrieben.
Hierauf aufsetzend stellt Kapitel 6 die Koordinationssprache PAMELA und den
Koordinationsmanager vor [MML95d, MML95e], mit denen zum einen die koordinierte
Nutzung der nun potentiell verfugbaren Dienste beschreibbar und
zum anderen diese Beschreibung auch unmittelbar in einer DCE{ und CORBA{
basierten Systemumgebungausfuhrbar ist. Die Darstellungvon PAMELA knupft
hierbei an das vorherige Kapitel 4 an, indem sie eine programmiersprachliche
Umsetzung des dort entwickelten Petri{Netz{basierten Konzeptes fur die
Beschreibung von Kooperationsanwendungen bzw. Anwendungsvorgangen zur
Verfugung stellt. Diese Darstellung mundet in der Beschreibung von zwei Anwendungsbeispielen,
an denen unter anderem auch das Zusammenspiel des Koordinationsmanagers
mit dem Typmanager, TRADEr und Interzeptor erlautert
wird. Beide Beispiele verdeutlichen die durch TRADE gegebenen Moglichkeiten
zur Systemunterstutzungeiner weitgehend uneingeschrankten und koordinierten
Nutzung von beliebigen Diensten in o enen verteilten Dienstemarkten.

Kapitel 5
Systemunterstutzung fur den
Dienstzugang in o enen
verteilten Umgebungen
Wie schon in den Abschnitten 2.1 und 3.1 ausfuhrlich dargestellt wurde, stehen
dem Dienstnutzer in o enen verteilten Dienstemarkten zahlreiche Heterogenitatsprobleme
gegenuber, die aus der Autonomie der an derartigen Dienstemarkten
beteiligten Verwaltungsdomanen resultieren. Diese Autonomie au ert sichvor
allem in administrativen und technischen Problemstellungen, die den Dienstzugang
ma geblich erschweren oder sogar | wie im Falle technischer Heterogenitatsgrenzen
| grundsatzlich verhindern. Um trotz dieser Heterogenitatsprobleme
eine domanenubergreifende Dienstnutzung und {koordination zu ermoglichen,
ist eine Erweiterung heutiger verteilter Systemplattformen notwendig. In
Kapitel 3 wurden hierfur insbesondere das Diensttypmanagement, die Dienstvermittlung
(Trading) und die Interzeption als geeignete Systemmechanismen
herausgearbeitet und ihren grundlegenden Aufgaben und Konzepten vorgestellt.
Hierbei wurde deutlich, da fur eine uneingeschrankte Dienstnutzung ino enen
verteilten Dienstemarkten eine enge Kooperation dieser Systemmechanismen untereinander
erforderlich ist (siehe auch Abbildung 3.43).
Das vorliegende Kapitel beschreibt im folgenden den im Rahmen des Service
Trading and Coordination Environment (TRADE) durchgefuhrten Entwurf und
die Realisierung dieser bisher nur abstrakt betrachteten Systemmechanismen.
Betrachtungs{ und Realisierungsgrundlage von TRADE bilden die beiden verteilten
Systemplattformen DCE und CORBA. 1 Mit ihnen la t sich die in o enen
verteilten Dienstemarkten anzutre ende technische Heterogenitat beispielhaft
wiedergeben. Gleichzeitig dienen sie auch als konkrete Testumgebung, in
der die im Rahmen dieser Arbeit entwickelten Losungsansatze auf ihre Anwend-
1 Fur eine ausfuhrliche Beschreibung beider Plattformen sei an dieser Stelle beispielsweise
auf [OMG91, OPR96, Bet95, OSF92, Paw91, Sch93b, RKF93] sowie auf vergleichende
Darstellungen wie [BKR93, BIBY95] verwiesen. Gegenuberstellungen und Bewertungen beider
Plattformen im Rahmen der in dieser Arbeit dargestellten Aktivititaten nden sich in
[MML95f, CMML96, GML96, CM95, CM96, Gri96, Oh96].

144 Systemunterstutzung fur den Dienstzugang
barkeit hin auswertet und beurteilt werden konnen. Weiterhin ermoglicht dieses
Vorgehen eine Analyse der genutzten verteilten Systemplattformen, so da unter
anderem auch ihre momentan vorhandenen De zite | erstekonkreteAnmerkungen
nden sich unter anderem in den Abschnitten 2.4.1 und 3.2.1.1 | aufgezeigt
werden konnen.
Analog zum Kapitel 3 wird zunachst der Entwurf und die Realisierung des
Diensttypmanagers in TRADE vorgestellt. Im Anschlu folgt die Beschreibung
der TRADE{Dienstvermittlungskomponente, dem TRADEr, wobei als ein
Schwerpunkt auf den Aufbau von Trader{Kooperationen eingegangen wird. Abschlie
end wird der Interzeptor beschrieben, der einen Losungsansatz fur das eingangs
angefuhrte Problem technischer Heterogenitatsgrenzen zwischen auf DCE
und CORBA basierenden Verwaltungsdomanen bietet.
5.1 Diensttypmanagement in TRADE
Wie in Kapitel 3 ausfuhrlich beschrieben wurde, spielt das Diensttypmanagement
eine wichtige Rolle beim Zugang zu Diensten in o enen verteilten Dienstemarkten.
Hierbei wurden im einzelnen die folgenden Teilaufgaben des Diensttypmanagements
herausgearbeitet:
strukturierte, domanenspezi sche Ablage von Diensttyp- und Beziehungstypbeschreibungen
mit Bereitstellung von Grundfunktionen zum Einfugen,
Loschen, Modi zieren, Suchen und Browsen von Typbeschreibungen�
Verwaltungvon Beziehungsinstanzen, d.h. von in Beziehung stehenden Typen,
wobei innerhalb von TRADE vor allem Beziehungen zwischen Diensttypen
von Interesse sind�
Austausch von Diensttyp- und Beziehungstypbeschreibungen, unter anderem
im Rahmen von Trader{Kooperationen und plattformubergreifenden,
Interzeptor{basierten Dienstzugri en und
Durchfuhrung von Typvergleichen und {uberprufungen wahrend der einzelnen
Dienstzugangsphasen, d.h. der Diensttyp ndung, der Dienstvermittlung,
der Bindung und dem Operationsaufruf.
Die Erfullung dieserAufgaben erfolgt innerhalb von TRADE in Form des prototypisch
realisierten Diensttypmanagers bzw. Typmanagers. Mit seinen oben
beschriebenen Aufgaben ubernimmt ereine wichtige Funktion sowohl innerhalb
der Entwicklungs{ als auch inder Ausfuhrungsumgebung von TRADE. Zum
einen wird der Typmanager von den anderen in dieser Arbeit entwickelten und
realisierten Systemkomponenten, insbesondere dem TRADEr und dem Interzeptor
(siehe Abschnitte 5.2und 5.3), zur Durchfuhrung ihrer spezi schen Aufgaben
bei der Realisierung des Dienstzugangs in TRADE genutzt. Zum anderen
unterstutzt er auch dieAnwendungsentwickler | neben der generellen Moglichkeit
zur Verwaltung von Typbeschreibungen | beim Au nden von geeigneten

5.1 Diensttypmanagement in TRADE 145
Diensttypbeschreibungen, um diese anschlie end beispielsweise bei der Entwicklung
von Kooperationsanwendungen mittels der Koordinationssprache PAMELA
(siehe Abschnitt 6.1.2) verwenden zu konnen. Auf die Aspekte der Anwendungsentwicklung
in TRADE geht Kapitel 6 noch detailliert ein.
Die nachfolgenden Abschnitte beschreiben zunachst die Grundkonzepte des
TRADE{Typmanagers. Die Darstellung schlie t mit der Beschreibung wichtiger
Entwurfs{ sowie Implementationsentscheidungen in Abschnitt 5.1.4 ab.
5.1.1 Beschreibung von Diensten
Grundlage fur die Nutzungvon Diensten in TRADE bilden die Diensttypbeschreibungen,
die sich imwesentlichen aus der Beschreibung eines Schnittstellentyps
undder Dienstattributtypen zusammensetzen. Wie in Abschnitt 2.4.5 ausfuhrlich
diskutiert wurde, stellt das in Kapitel2eingefuhrte Konzept der Diensttypen
zum gegenwartigen Zeitpunkt eine geeignete Kompromi losung zur Beschreibung
von Diensten dar, das einerseits einen hohen Grad an Automatisierbarkeit
von Diensttypvergleichen und{uberprufungen erlaubt undanderseitsausreichend
ausdrucksmachtig ist, um die grundlegenden Eigenschaften der Dienste beschreibenzukonnen.
Die fur den zweiten Aspekt bereitgestellten Dienstattributeerweisen
sich unabhangig hiervon auch beider diensttypbasierten Dienstvermittlung
durch den TRADEr als geeignete Grundlage zum automatisierten Au nden geeigneter
Dienstangebote. Hier kommtzusatzlichauchder Vorteil von Diensttypen
zum Tragen, da Vergleiche zwischen ihnen, insbesondere der hier speziell betrachteten
" Konformitats{\Beziehungstypen, in den meisten Fallen 2 weitgehend
automatisch erfolgen konnen. Dieses ist eine wesentliche Grundvoraussetzungfur
die von vielen Anwendungen | vor allem auch von den hier speziell betrachteten
Kooperationsanwendungen | geforderte automatische Dienstvermittlung.
Abbildung 5.1 zeigt ein einfaches Beispiel einer Diensttypbeschreibung in TRA-
DE. Die gezeigte Diensttypbeschreibung setzt sich aus zwei Teilen zusammen:
1. Zum einen besteht sie aus der Beschreibung des Schnittstellentyps mit seinem
Namen und den darin de nierten Operationssignaturen. Die syntaktische
Darstellung und der angebotene Beschreibungsumfang lehnen sich an
die CORBA{Schnittstellenbeschreibungssprache (CORBA{IDL) [OMG91]
an. So stehen zur Beschreibungder Parameter{und Resultatwerteder Operationen
samtlicheeinfache und komplexe Datentypen zur Verfugung. Weiterhin
wird auch das durch die RAISE{Anweisung zur Verfugung gestellte
Fehlerbehandlungskonzept der CORBA{IDL unterstutzt, so da Fehlerfalle
explizit beschrieben werden konnen.
2. Ein zweiter wesentlicher Bestandteil der Diensttypbeschreibung ist der
Diensttypnameund die Beschreibung der Dienstattribute. Deren Beschreibung
geschieht mittels einer syntaktischen und semantischen Erweiterung
2 Zur Problematik strukturell aquivalenter jedoch semantisch unterschiedlicher Diensttypen
sei auf das in Abschnitt 2.1.2 und 2.4.5 beschriebene Beispiel der Diensttypen Stack und Queue
verwiesen.

146 Systemunterstutzung fur den Dienstzugang
// TRADE service type description
// A fundamental print service
//@service type PrintService�
//@category "print","druck","hardcopy"�
//@property static float costPerPage�
//@property dynamic long queueLength
interface Print {
void PrintJob (in string Data, out long JobNumber)�
}�
Abbildung 5.1: Beispiel einer TRADE{Diensttypbeschreibung
der Kommentaranweisung (//) der CORBA{IDL. Hierdurch wird eine
hohe Integration in die bestehende CORBA{Umgebung erreicht, da derartig
erweiterte Dienstbeschreibungen weiterhin auch mit den originaren
CORBA{Mechanismen, beispielsweise dem dortigen IDL{Sprachubersetzer
(engl. IDL compiler), verarbeitet werden konnen. Hierbei konnen die
erweiterten Beschreibungsbestandteile jedoch nicht erkannt werden, sondern
werden als herkommliche Kommentare behandelt. 3
Die Angabe des Diensttypnamens erfolgt mittels der Anweisung
//@service type. Er dient vor allem zur besseren Charakterisierung
der Semantik des ansonsten nur strukturell und abstrakt beschriebenen
Diensttyps und sollte dementsprechend einen sinnvollen Namen besitzen.
In der Diensttypbeschreibung wirdau erdem ein uber das Diensttypkonzept
hinausgehendes Kategorisierungskonzept //@category unterstutzt.
Dieses wird vor allem als Grundlage fur eine erweiterteSuchfunktionalitat
im Typmanager verwendet, um zusatzlich zuden vorhandenen Dienstattributen,
die bei der De nition von virtuellen Diensttypen (siehe Abschnitt
3.2.2.6) genutzt werden konnen, eine ubergeordnete Strukturierung von
Diensttypen zu ermoglichen. Sie sind konzeptuell vergleichbar mit den
Schlusselwortern beim Information Retrieval [SM83].
Die Beschreibung der Dienstattribute unterscheidet zwei Arten von
Dienstattributen. //@property static float costPerPage� beispielsweise
beschreibt ein statisches Dienstattribut, das den Preis pro
Druckseite charakterisiert. Alternativ kann ein Dienstattribut jedoch
auch alsdynamic spezi ziert werden, um seinespatere Modi zierbarkeit
zu kennzeichnen. Die Unterscheidung von statischen und dynamischen
Attributen wirkt sich insbesondere auf den Vorgang der Dienstauswahl
3 Hinsichtlich des Diensttypnamens und der Dienstattribute existiert eine alternative Darstellung
(siehe Abschnitt 6.1.2.3), die auf der semantischen Uberladung von CORBA{IDL{
Anweisungen beruht.

5.1 Diensttypmanagement in TRADE 147
durch den TRADEr aus, bei dem die beiden Attributarten in einem
gesta elten Auswertungsvorgang jeweils unterschiedlich behandelt werden.
Die speziell fur die CORBA{IDL aufgefuhrten diensttypspezi schen Erganzungen
sind auch fur die ebenfalls in TRADE relevante DCE{IDL vorgenommen
worden (siehe[CM95, CM96]). Die Erweiterung erfolgt in ahnlicher Weise mittels
der in der DCE{IDL vorhandenen Kommentaranweisung, so da auchinDCEeine
nahtlose Integration mit den originaren Typisierungskonzepten und Werkzeugen
erreicht wird. Durch diese orthogonal fur beide Schnittstellenbeschreibungssprachen
durchgefuhrten Erweiterungen wird ein einheitliches Dienstverstandnis
bzw. Dienstmodell in beiden verteilten Systemplattformen zur Verfugunggestellt.
Dieses stellteine erste Grundvoraussetzungdar, um die in Abschnitt 2.1 beschriebene
Interoperabilitat auf Dienstbeschreibungsebene zu erreichen und somiteine
wechselseitige Dienstnutzung zwischen beiden verteilten Systemplattformen zu
ermoglichen.
5.1.1.1 Ein kanonisches Diensttypmodell
Die zweite fur Interoperabilitat auf Beschreibungsebene notwendige Grundvoraussetzung
ist die De nition einer wechselseitigen Abbildung zwischen der DCE{
IDL und der CORBA{IDL. Ziel dieses Abbildungsvorganges ist die De nition
eines kanonischen Diensttypmodells, das eine verbindliche und gemeinsame Beschreibungsgrundlage
bildet, auf die spater auchandere Diensttypbeschreibungssprachen
abgebildet werden konnen. Hierdurch wird ein gemeinsames Verstandnis
uber den Inhalt der ansonsten syntaktisch verschiedenen Dienstbeschreibungen
erreicht. Es bildet somit die Grundvoraussetzung fur den wohlde nierten
Austausch von Typbeschreibungen zwischen den Verwaltungsdomanen, wie
er beispielsweise bei der Abwicklung der in Abschnitt 3.3.3.3 beschriebenen
Trader{Kooperationsprotokolle notwendig ist. Ein ahnlicher Abbildungsansatz
ist beispielsweise auch in CORBA [OMG91] oder ILU [JSS95] durch sogenannte
Sprachabbildungen (engl. language mappings) realisiert, bei denen die Typsysteme
verschiedener Programmiersprachen auf das kanonische CORBA{ bzw. ILU{
Typmodell abgebildet werden. Dadurch wird es anschlie endmoglich, Dienstnehmer
und Diensterbringer in verschiedenen Programmiersprachen zu entwickeln,
die uber das gemeinsame Typverstandnis des kanonischen Modells zueinander
typkompatibel sind.
Bei der in TRADE speziell untersuchten Abbildung von DCE{ und CORBA{
Diensttypbeschreibung zeigtsich insgesamt, da eine wechselseitige Abbildung
von samtlichen in beiden IDLs vorhandenen Beschreibungskonzepten generell
nicht sinnvoll ist bzw. zum Teil, wie beispielsweise bei den Kontextinformationen,
auch nicht durchfuhrbar ist. Wesentliches Kriterium fur die Entwicklung
eines kanonischen Diensttypmodells war die Auswahl derjenigen Beschreibungskonzepte,
die ein hohes Ma an Unabhangigkeit von Spezi kas der DCE{ und
CORBA{Plattformen erlauben. Resultat dieses Auswahlprozesses, der ausfuhrlich
in [CM95, Oh96] beschrieben ist, ist die De nition einer maximalen Schnittmenge
der in beiden Diensttypbeschreibungssprachen vorhandenen Beschrei-

148 Systemunterstutzung fur den Dienstzugang
bungskonzepte. Diese Schnittmenge bildet das kanonische Diensttypmodell. Es
versteht sich hierbei nicht als universelles Modell, da esimhohem Ma e in
Hinblick auf die Unterstutzung des Dienstzugangs in DCE{ und CORBA{
Systemumgebungen angepa t ist.
Erleichtert wird die Abbildungdadurch, da CORBA{ und DCE{basierte Diensttypbeschreibungen
eine gewisse Ahnlichkeit besitzen. Dieses zeigt sich beispielsweise
bei der Abbildung des Schnittstellentypkonzeptes, das in beiden verteilten
Systemplattformen ahnlich ausgedruckt wird.
Aufwendiger gestaltet sich die Abbildung von Konzepten, fur die keine aquivalenten
Beschreibungsmoglichkeiten existieren. Ein insbesondere zu berucksichtigendes
Problem ist die Nutzung von sogenannten Zeigern (engl. pointers) in der
DCE{IDL. Sie nden unter anderem Verwendung bei der Beschreibung von komplexen
Strukturen, wie beispielsweise verketteten Listen. Da in der CORBA{IDL
Zeiger nicht unterstutzt werden, wird eine Abbildung auf den dort vorhandenen
sequence{Konstruktur vorgenommen. Ein Beispiel hierfur wurde bereitsinAbbildung
3.38 in Abschnitt 3.4.1.1 gezeigt.
Ein weiteres Problem stellt auch die Abbildungvon Beschreibungskonzepten dar,
die nur exklusiv in einer der beiden IDLs de niert sind. Dieses betri t beispielsweise
das in der CORBA{IDL vorhandene Darstellung von Fehlerfallen mittels
der RAISE{Anweisung, die in dieser Form nicht durch die DCE{IDL unterstutzt
wird. Ein anderes Beispiel sind die sogenannten Kontextinformationen (engl.
context handles) in der DCE{IDL, die zur Beschreibung zustandsbasierter Interaktionsverbindungen
zwischen Dienstnehmer und Diensterbringer verwendet
werden. Hierfur existiert in der CORBA{IDL kein semantisch vergleichbares
Konzept.
5.1.2 Beschreibung und Verwaltung von Beziehungstypen und
{instanzen
Eine der Hauptaufgaben des Typmanagers ist zum einen die Verwaltung von
Beziehungstypen. Zum anderen verwaltet er Beziehungsinstanzen, die konkret
in Beziehung stehende Typen des kanonischen Diensttypmodells kennzeichnen.
Grundlage hierfur bildet das in Abschnitt 3.2.2.2 dargestellte rollenbasierte Beziehungstypkonzept.
Bei diesem werden sogenannte Rollen, die prinzipiell verschiedenartigsten
Typs sein konnen, uber Charakteristika und De nitionsregeln
sowie unter Umstanden auch durch eine informelle Beschreibung inBeziehung
gesetzt. In Hinblick auf die Unterstutzung des Dienstzugangs in o enen verteilten
Dienstemarkten interessieren hierbei vor allem die homogenen, binaren
Beziehungstypen, die zwei Diensttypen | d.h. Rollen dieses spezi schen Typs
| zueinander in Beziehung stellen. Beispiele hierfur sind die im Abschnitt 5.1.2
speziell betrachteten Konformitats{ bzw. Subtypbeziehungen, die innerhalb von
DCE und CORBA sowie dem ODP{Referenzmodell Verwendung nden. Generell
werden durchden realisierten Typmanager jedoch beliebige Beziehungstypen
unterstutzt, bei denen die Rollen nichtnur homogenen, sondern auchheterogenen
Typs sein konnen. Die vom Typmanager hierfur zur Verfugung gestellten Typen

5.1 Diensttypmanagement in TRADE 149
fur die Rollen orientieren sich andem oben genannten kanonischen Diensttypmodell.
5.1.2.1 Unterstutzung von Konformitatsbeziehungen
Ein besonderer Gesichtspunkt in der momentanen Realisierung des Typmanagers
ist dabei die spezielle Unterstutzung verschiedener Varianten von Konformitatsbeziehungen
zwischen Diensttypen. Wesentlicher Grund hierfur ist die Existenz
zahlreicher De nitionen, die zur Zeit von den etablierten verteilten Systemplattformen
angeboten werden und die beim konkreten, plattformubergreifenden
Dienstzugang berucksichtigt werden mussen. Das durch den Typmanager bereitgestellte
Unterstutzungskonzept ist dabei derartig allgemein entworfen, da im
Prinzip verschiedenste Arten von Konformitatsbeziehungen de niert und verarbeitet
werden konnen. Dieses umfa t auch die in Abschnitt 2.3.2 ausfuhrlich beschriebene
ODP{basierte Konformitatsbeziehung. Der hierfur gewahlte allgemeine
De nitionsansatz, der auch in [CMML96] und [CM96] ausfuhrlichbeschrieben
ist, basiert auf einem aus [ZW95] stammenden formalen Konzept von Beziehungen
zwischen (Software{)Modulen und Funktionen. Hierbei wird davon ausgegangen,
da jede Beziehung einer hoheren Granularitatsebene auf Beziehungen
unterliegender Granularitatsebenen aufbaut. So setzen sich im dort betrachtetem
Fall die Software{Module aus ein oder mehreren Funktionen zusammen.
Dieser generelle Ansatz der Unterscheidung unterschiedlicher Granularitatsebenen
eignet sich auch fur die hier speziell betrachteten Diensttypen, die sich ebenfalls
in mehrere Granularitatsebenen einteilen lassen. Hierzu wurdeder originare
Ansatz derartig geandert und erweitert, da entsprechend der De nition des in
TRADE verwendeten kanonischen Diensttypmodells insgesamt vier verschiedene
Granularitatsebenen unterschieden werden: Die Ebene der Datentypen, der
Operationstypen, der Schnittstellentypen und der Diensttypen. Die Verknupfung
der Ebenen innerhalb eines Beziehungstyps wird mit Hilfe sogenannter De nitionsregelmuster
(engl. de nition rule templates) [ZW95] ausgedruckt. Hierbei
referenziert ein auf hoherer Granularitatsebene de niertes De nitionsregelmuster
eine beliebige Anzahl von auf unterliegenden Granularitatsebenen be ndlichen
Beziehungen. Jedes De nitionsregelmuster besteht hierbei zusatzlichaus einer
Menge von speziellen De nitionsregeln, den sogenannten " Lockerungsregeln\
(engl. relaxations) [ZW95]. Diese ermoglichen eine Erhohung der Flexibilitat bei
der bei Konformitatsbeziehungstypen ansonsten ublicherweise sehr strikten und
statischen Festlegung von Identitaten auf einer bestimmten Granularitatsebene.
So kann es beispielsweise unter Umstanden sinnvoll sein, da bei einer Beziehung
zwischen zwei Diensttypen die Namen der Operationen unterschiedlich sein
konnen. Zusammenfassend werden vom Typmanager folgende De nitionsregelmuster
zur Verfugunggestellt, mit denen Konformitats{ bzw. Subtypbeziehungen
auf den vier verschiedenen Granularitatsebenen de niert werden konnen:
De nition 5.1 (De nitionsregelmuster fur Datentypen)
(Lockerungs{)Regeln:

150 Systemunterstutzung fur den Dienstzugang
1. Die Namen der Datentypen zwischen Sub{ und Supertyp durfen unterschiedlich
sein (engl. type variable renaming [ZW95, LW93]).
2. Typanpassungen (engl. coercion) [CW85] zwischen einfachen Datentypen
sind moglich, beispielsweise kann ein Ganzzahlwert auch bei Erwartung
eines reellen Wertes verwendet werden.
3. Subtypen von Tupel{Typen, beispielsweise Strukturen, durfen die Signatur
des Supertypen erweitern, wahrend Subtypen von Auswahltypen (engl. option
types) nur eine Teilmenge der Teilkomponenten des Supertypen haben
durfen [Car89].
4. Jeder Datentyp ist Subtyp von einem Typ top (Parametrischer Polymorphismus
[CW85]), beispielsweise any in der CORBA{IDL, und bottom ist
der Subtyp aller Datentypen [ODP95c].
De nition 5.2 (De nitionsregelmuster fur Operationstypen)
Referenz: Beziehung zwischen Datentypen
Regeln: 4
1. Operationsnamen durfen unterschiedlich sein.
2. Die Namen der Operationsparameter durfen di erieren.
3. Eine unterschiedliche Reihenfolge der Operationsparameter ist moglich
(engl. reordering [ZW95]).
4. Subtypen durfen zusatzliche Operationsparameter hinzufugen.
De nition 5.3 (De nitionsregelmuster fur Schnittstellentypen)
Referenz: Beziehung zwischen Operationstypen
Regeln:
1. Schnittstellennamen durfen unterschiedlich sein.
2. Eine Anderung der Reihenfolge der Operationstypen ist moglich.
3. Subtypen durfen neue Operationstypen hinzufugen.
De nition 5.4 (De nitionsregelmuster fur Diensttypen)
Referenz: Beziehung zwischen Datentypen (zur Darstellung von Dienstattributen)
Referenz: Beziehung zwischen Schnittstellentypen
Regeln:
1. Die Namen der Dienstattribute durfen unterschiedlich sein.
4 Die Subtypisierung von Operationsparametern basiert grundsatzlich auf dem Prinzip kovarianter
Argumente und kontravarianter Resultate [Car89, ODP95c] (siehe auch De nition
2.1 in Abschnitt 2.3.2).

5.1 Diensttypmanagement in TRADE 151
2. Die Diensttypnamen durfen di erieren.
3. Subtypen durfen neue Dienstattributtypen hinzufugen.
Mit Hilfe dieser De nitionsregelmuster konnen unter anderem die in den oben genannten
verteilten Systemplattformen de nierten Konformitatsbeziehungen zwischen
Schnittstellentypen ausgedruckt werden. Tabelle 5.1 gibt einen Uberblick
uber die Konformitatsbeziehungen des ODP{Referenzmodells, der Object Management
Architecture (OMA) [OMG92] und der verteilten Systemplattformen
DCE, CORBA und ANSA.
Datentypen Operationstypen Schnittst.
1 2 3 4 1 2 3 4 1 2 3
ODP x x x x x x
OMA x x x
CORBA, DCE, ANSA x x
Tabelle 5.1: Darstellbarkeit verschiedener Konformitatsbeziehungen mittels Denitionsregelmustern
Weiterhin sind jedochauch andere Variationen von Konformitatsbeziehungen
zwischen Diensttypen mit Hilfe der obigen De nitionsregelmuster de nierbar.
Bei der De nition von Konformitatsbeziehungen wird der Anwendungsentwickler
durch eine graphische Benutzerschnittstelle unterstutzt. Diese nutzt die Funktionen
des in dieser Arbeit entwickelten Typmanagers, der im Rahmen von TRADE
prototypisch realisiert ist. Der Typmanager ubernimmt hierbei die eingangs von
Abschnitt 5.1 beschriebenen Aufgaben des Typmanagements ino enen verteilten
Dienstemarkten. Seine Funktionen bietet er den Klienten in Form mehrerer
funktional getrennter Schnittstellen an (siehe Abschnitt 5.1.4). Die graphische
Benutzerschnittstelle als eine wichtige Klientenanwendung ermoglicht dem Anwendungsprogrammierer
einen intuitiven und einfachen Zugang zuder Funktionalitat
des Typmanagers und verbirgt hierbei die Komplexitat der hierfur notwendigen,
in der Regel komplexen Operationsaufrufe an den Typmanagerschnittstellen.
Dabei unterstutzt sie sowohl das interaktive Einfugen neuer Diensttyp{
und Beziehungstypbeschreibungen als auch das Browsing und die strukturierte
Suche nach Diensttypbeschreibungen, die beispielsweise im Rahmen der Entwicklung
von Kooperationsanwendungen und deren Anwendungsvorgangen genutzt
werden mochten. Das Einfugen neuer Beziehungstypen auf der Grundlage
der obigen De nitionsregelmuster verdeutlicht Abbildung 5.2. Die Optionen der
Eingabemaske orientieren sich anden De nitionsregeln, die fur jede Granularitatsebene
im De nitionsregelmuster de niert sind. Grundlage fur die in der
Abbildung gezeigte Ebeneder Schnittstellentypen bildet dementsprechend das
De nitionsregelmuster 5.3), in dem insgesamt drei De nitionsregeln festgelegt
sind. Der im De nitionsregelmuster geforderte Bezug zur bereits vorhandenen
Beziehungstypde nition auf Operationstypebene wird mit Hilfe eines eindeutigen
Namens erreicht, welcher im gezeigten Eingabefeld Relationship between
operations angegeben wird.

152 Systemunterstutzung fur den Dienstzugang
Abbildung 5.2:Einfugen neuer Konformitatsbeziehungstypen auf der Granularitatsebene
der Schnittstellentypen
Au er der De nition von Konformitatsbeziehungen unterstutzt der Typmanager
auch die De nition beliebiger anderer Beziehungen, die zwischen Typen auf den
unterschiedlichen Granularitatsebenen ausgedruckt werden sollen. Im Gegensatz
zu den auf De nitionsregelmustern aufsetzenden Konformitatsbeziehungen, die
speziell durch den Typmanager unterstutzt werden, existiert hierbei momentan
jedoch nochkeine Moglichkeit, De nitionsregeln formal angeben zu konnen. Ihre
Beschreibung erfolgt informell durch textuelle Beschreibung der Charakteristika
der Beziehung und ihrer Semantik. Neue Beziehungsinstanzen mussen deshalb
spater manuell durch den Anwendungsprogrammierer eingefugt werden, da eine
automatisierteVerwaltungderartiger Beziehungen nichtmoglich ist. Ein Beispiel
ist die De nition einer " semantischen\ Beziehung, die Diensttypen mit einem
bestimmten Anwendungsentwicklungsprojekt verknupft, so da eine projektbezogene
Gruppierung von Diensttypbeschreibungen moglich ist.
5.1.2.2 Automatisierter Aufbau von Diensttyphierarchien
Nachdem mit Hilfe der De nitionsregelmuster neue Konformitatsbeziehungen
de niert wurden, lassen sich durch Einfugen neuer Diensttypbeschreibungen automatisch
Diensttyphierarchien durchden Typmanager aufbauen. Der Aufbauerfolgt
unter Nutzungder fur jede Granularitatsebeneeiner Diensttypbeschreibung
de nierten De nitionsregeln. Hierzu ist ein Traversieren der Diensttyphierarchie
notwendig, bei dem Vergleiche zwischen dem einzufugenden und den bereits vorhandenen
Diensttypen durchgefuhrt werden mussen. Die Vergleiche nden auf
der Basis der strukturellen Bestandteile der Diensttypbeschreibungen und der in

5.1 Diensttypmanagement in TRADE 153
Abbildung 5.3: Graphische Visualisierung einer Diensttyphierarchie
den De nitionsregeln des Beziehungstyps festgelegten Vergleichskriterien statt.
Das Resultat des Einfugevorganges kann dem Anwendungsentwickler wiederum
mittels der graphischen Benutzerschnittstelle des Typmanagers angezeigt
werden (Abbildung 5.3). Durch diese Eigenschaft des Typmanagers, Diensttypbeschreibungen
automatisch in Konformitatsbeziehungen einfugen zu konnen,
wird die unter anderem in Abschnitt 2.4.5 gestellte Forderung nach einer weitgehenden
Automatisierbarkeit der Verarbeitung von Diensttypbeschreibungen und
ihrer Beziehungen erfullt. Hierdurch la t sich die zukunftig in o enen verteilten
Dienstemarkten zu erwartende Vielzahl standig neu hinzukommender Diensttypbeschreibungen
adaquat behandeln. Manuelle Losungsansatze sind hierfur aufgrund
des Verwaltungsaufwandes nicht geeignet und auch hinsichtlich Anderungen
zu wenig exibel. Hieraus ergibt sich auch der wesentliche Kritikpunkt an
den zur Zeit etablierten verteilten Systemplattformen, die im Vergleich zum hier
entwickelten Typmanager in der Regel nur relative einfacheTypverwaltungs{ und
Typvergleichsmechanismen zur Verfugung stellen. So bieten beispielsweise DCE
und ANSA nur namensbasierte Ansatze an, die fur eine automatisierte Verwaltung
von Diensttypen nicht ausreichendsind. Zudem sind sieauf die Behandlung
eines spezi schen Beziehungstyps beschrankt, so da auf dieser Grundlage Vergleiche
zwischen Diensttypbeschreibungen anderer Plattformen | sofern dieses
uberhaupt angestrebt wird | nur hinsichtlich ihrer Identitat erfolgen konnen.
5.1.2.3 Suche nach konformen Diensttypen
Im engen Zusammenhang mit dem automatisierten Aufbau von Diensttyphierarchien
stehen auch dieFahigkeiten des Typmanagers, automatisierte Typuberprufungen
und {vergleiche anbieten zu konnen. So eignen sich die implizit
beim Einfugen von Diensttypbeschreibungen verwendeten Vergleichsmechanismen
auch dazu, sie direkt an der Schnittstelle des Typmanagers verfugbar zu
machen. Diese konnen dann, wie es beispielsweise konkret beim TRADEr im

154 Systemunterstutzung fur den Dienstzugang
Rahmen der von ihm durchgefuhrten gesta elten Auswertung realisiert wird,
zum automatischen Au nden in Konformitatsbeziehung stehender Diensttypen
verwendet werden. Hierbei wird ausgenutzt, da die Diensttypen in einer hierarchischen
Struktur angeordnet sind, so da die Diensttypvergleiche nur bis zum
Au nden eines aquivalenten Diensttyps oder eines Subtyps durchgefuhrt werden
mussen. Alle anderen Subtypen sind dann in den unterliegenden Teilhierarchien
ohne weitere Vergleiche direkt zugreifbar.
5.1.3 Austausch und Verarbeitung von Typbeschreibungen
Bei der Darstellung inden vorherigen Abschnitten wurde bereits implizit die
Annahme getro en, da eine systemtechnische Reprasentation von Diensttyp{
und Beziehungstypbeschreibungen im Typmanager existiert, auf der unter anderem
die erwahnten Typvergleiche beim Einfugen neuer Diensttypbeschreibungen
in eine Typhierarchie durchfuhrbar sind. Eine derartige Typreprasentation
ermoglicht die Reprasentation der in den Typbeschreibungen zunachst abstrakt
vorhandenen Informationen, um sie einer weiteren systemtechnischen Verarbeitung
zuganglich zumachen. 5 Sie stellt gleichzeitig fur den Typmanager aucheine
Moglichkeit dar, um Typbeschreibungen mit seinen externen Nutzer austauschen
zu konnen. Grundsatzlich sind insgesamt drei unterschiedliche Austauschvarianten
an der Schnittstelle des Typmanagers moglich:
1. Verwendung von bereits vom Typmanager vergebenen Typbezeichnern:
In diesem Fall ist die Typbeschreibung bereitszueinem fruheren Zeitpunkt
eingefugt worden, so da zu ihrer Referenzierung der vom Typmanager erzeugte
eindeutige Typbezeichner verwendet werden kann. Bei seinem Austausch,
insbesondere mit Klienten anderer Verwaltungsdomanen, wird er
in global eindeutiger Form angeboten (siehe Abschnitt 3.2.3.1), so da er
domanenubergreifendeindeutig dem erzeugenden Typmanager zugeordnet
werden kann. Mit ihm kann dann beispielsweise ein anderer Typmanager
im Rahmen einer Typmanager{gesteuerten Trader{Kooperation die dem
Typbezeichner hinterliegende Diensttypbeschreibung ineiner ihm bekannten
Diensttypbeschreibungssprache anfordern (siehe Abschnitt 3.3.3.3).
2. Ubergabe der Typbeschreibung als einfache, uninterpretierteZeichenkette:
Diese Moglichkeit des Austausches von Typbeschreibungen, insbesondere
Diensttypbeschreibungen, in textueller Form stellt die einfachste Moglichkeit
einer Typreprasentation dar. Sie setzt voraus, da der Anfragende uber
geeignete Interpretationsmechanismen, beispielsweise entsprechende Parser,
verfugt, die ihm einen Zugang zuden Informationen der Typbeschreibung
ermoglichen. In dem entwickelten Typmanager wird diese Funktionalitat
durch sogenannte Abbildungskomponenten erbracht, die eine ineiner
bestimmten Beschreibungssprache verfa te Diensttypbeschreibung indie
intern im Typmanager verwendete, selbstbeschreibende Typreprasentation
uberfuhren (siehe auch Abbildung 5.4).
5 siehe hierzu vor allem auch die Abschnitte 2.1.3 und 3.2.3.2

5.1 Diensttypmanagement in TRADE 155
3. Kodierung der Typbeschreibung inForm einer sich selbstbeschreibenden
Datenstruktur:
Die eingangs erwahnte Typreprasentation ermoglicht durch ihren selbstbeschreibenden
Charakter eine Vorstrukturierung der Informationen einer
Diensttypbeschreibung. In ihr liegen die Informationen in eindeutig kodierter
Form vor, so da bei entsprechender Kenntnis dieses Formates eine
direkter Zugri auf Teilinformationen moglich ist. Diese Darstellungsweise
bildet eine geeignete Grundlage zur systemtechnischen Verarbeitung im
Typmanager, auf der unter anderem die beim Einfugen neuer Diensttypbeschreibungen
in eine Konformitatsbeziehung notwendigen Typvergleichsmechanismen
e zient realisiert werden konnen.
Eine bildliche Darstellung der beiden letztgenannten Ubergabevarianten ndet
sich inAbschnitt 2.1.3 in Abbildung 2.1.
Die nachfolgende Beschreibung gibt einen konkreten Einblick in die vom
TRADE{Typmanager zum Austausch von Typbeschreibungen (Diensttypen
und Beziehungstypen) genutzte Typrepasentation. 6
/* Dienstattributtypen */
struct Property {
Identifier propertyName�
TypeId propertyType�
boolean dynamic�
}�
typedef sequence PropertyList�
/* Diensttypen */
struct ServiceType {
Identifier name�
string uuid�
string originalImplementationMiddleware�
TypeId interfaceType� // Verweis auf Typbezeichner
PropertyList properties�
IdentifierList semantics�
IdentifierList categories�
}�
union Type switch (KindOfType) {
case DATA_TYPE: TypeCode dt�
case CONST_TYPE: Const cnst�
case TYPEDEF_TYPE: Typedef tdef�
case EXCEPTION_TYPE: Exception exc�
case ATTRIBUTE_TYPE: Attribute attr�
case OPERATION_TYPE: Operation op�
case INTERFACE_TYPE: Interface intf�
case SERVICE_TYPE: ServiceType svc�
case RELATIONSHIP_TYPE: Relationship rel�
}�
6 Diese Typreprasentation wird auch bei der Realisierung des in dieser Arbeit entwickelten
TRADErs (Abschnitt 5.2) und des Interzeptors (Abschnitt 5.3) verwendet.

156 Systemunterstutzung fur den Dienstzugang
Sie zeigt einen kleinen Ausschnitt aus der in der CORBA{IDL beschriebenen
Schnittstelle des Typmanagers, deren vollstandige Schnittstellenbeschreibung
sichinden Anhangen B undCbe ndet. Die entsprechende in DCE{IDL beschriebeneTypmanagerschnittstelle
ndet sich in [CM96]. Die dargestellteDatenstruktur
Type bildet die zentrale Basis der Typreprasentation. Neben der Wiedergabe
von Beziehungstypbeschreibungen (RELATIONSHIP Type) ermoglicht sie vor allem
die Reprasentation der Bestandteile einer auf dem kanonischen Diensttypmodell
basierenden Diensttypbeschreibung. So verzweigt sich beispielsweise ein
Diensttyp (case SERVICE TYPE) in seine weiteren Einzelbestandteile, die durch
den Datentypen ServiceType de niert sind, der selbst wiederum unter anderem
auf eine Listevon Dienstattributtypen (PropertyList)und einen Schnittstellentyp
verweist. Die Verknupfung der sich auf unterschiedlicher Granularitatsebene
be ndlichen Typen, wie in diesem Fall beispielsweise Diensttypen und Schnittstellentypen,
geschieht hierbei in Form von Typbezeichnern (TypeId), die fur
jeden de nierten Typ eindeutig vom Typmanager vergeben werden.
5.1.4 Aufbau des Typmanagers
Dieser Abschnitt beschreibt ausgewahlte Aspekte der Realisierung des Typmanagers.
Als Realisierungsplattformen standen zum einen stellvertretend fur eine
CORBA{Umgebung eine aktuelle Orbix{Implementation von IONA Technologies
Ltd. [ION94] und zumanderen die aktuelle DCE{Version von IBM zur
Verfugung, so da der Typmanager derzeitig auf beiden Plattformen verfugbar
ist.
Generelle Grundlage fur die Realisierung des Typmanagers bildet die oben genannte
Typreprasentation, die in Form einer C++{basierten Klassenbibliothek 7
zur Verfugung steht. Diese Klassenbibliothek erlaubt einen einfachen Umgang
mit den zum Teil komplexen Datenstrukturen, die bei der Reprasentation von
Diensttypen und Beziehungstypen aufzubauen und zuverarbeiten sind. Sie kann
auch fur die Entwicklung von Anwendungen genutzt werden, die auf die Funktionalitat
des Typmanagers zugreifen. Eine wesentliche Eigenschaft der Klassenbibliothek
ist die Moglichkeit zur persistenten Speicherung [Sou94], so da
im Typmanager verarbeitete Typreprasentationen auf einem stabilen Speicher
gesichert und spater auch wieder gelesen werden konnen. Weiterhin bietet die
Bibliothek Methoden zum Erzeugen, Kopieren, Ausdrucken und zumVergleichen
an. Insbesondere die Vergleichsmethoden werden intensiv genutzt, um unter anderem
die auf De nitionsregelmustern basierenden Konformitatsbeziehungen zu
verwalten.
In der Gesamtkonzeption des Typmanagers spielt die Klassenbibliothek eine zentrale
Rolle. So setzen samtliche Einzelkomponenten des Typmanagerkerns auf ihrer
Funktionalitat auf (sieheAbbildung 5.4). Weiterhin bildet sie durchihrePersistenzeigenschaft
auch die Grundlage fur die Realisierung eines Typbeschreibungs{
und eines Beziehungsrepositories.
7 Diese nutzt selbst wiederum eineandere generische objektorientierte Klassenbibliothek,
die auf einem musterbasierten (engl. pattern{based) Ansatz [GHJV94] beruht.

5.1 Diensttypmanagement in TRADE 157
Typ-
Manager
TRADEr
Generisches Repository
Typbeschreibungsrepository Beziehungsrepository
Beziehungstypbeschreibung
Typbeschreibung
Graphenrepository
Homogene binäre Beziehungen
Beziehungsinstanz
Graphischer
Browser
Föderation Anfragen Administration
Browsing
Abbildungskomponenten
DCE CORBA
5.1.4.1 Typmanagerkern
Typmanagerkern
Klassenbibliothek (Typrepräsentation)
Abbildung 5.4: Komponenten des Typmanagers
Der Typmanagerkern stellt die au eren Schnittstellen zur Verfugung, die von
seinen potentiellen Klienten | beispielsweise anderen Typmanagern, dem TRA-
DEr oder der in den Abbildungen 5.2 und 5.3 gezeigten graphischen Benutzerschnittstelle
| genutzt werden konnen. Hierzu bietet er unter anderem Funktionen
zum Einfugen, Loschen, Vergleichen und Browsen von Typbeschreibungen
und Beziehungsinstanzen an. Der Typmanagerkern realisiert hierbei auch die
Durchfuhrung von Vergleichsmechanismen, die im Zusammenhang mitder Verwaltung
von Konformitatsbeziehungen bzw. Diensttyphierarchien benotigt werden.
5.1.4.2 Repositories
Die Verwaltung der Typbeschreibungen und Beziehungsinstanzen geschieht mit
Hilfe der in der Abbildung gezeigten Typbeschreibungs{ und Beziehungsrepositories
und eines sogenannten Graphenrepositories.
Die Realisierung der beiden erstgenannten Repositories, deren grundlegende
Konzeption in Abschnitt 3.2.2.3 beschrieben wurde, ist auf Basis der persistenten
Klassenbibliothek durchgefuhrt worden. Sie sind zur Zeit fester Bestandteil
des Typmanagers, wobei ihre Funktionalitat jedoch uber die Schnittstelle des
in der Abbildung gezeigten Generischen Repositories eindeutig abgrenzbar ist.
Dadurch konnen auch alternative Repositories uber diese Schnittstelle verwendet
werden, wie beispielsweise das in Abschnitt 3.2.1.1 vorgestellte CORBA{

158 Systemunterstutzung fur den Dienstzugang
Schnittstellenrepository.
Aufsetzend auf der Schnittstelle des Generischen Repositories realisiert das sogenannte
Graphenrepository eine spezielle Verwaltung von homogenen binaren
Beziehungen, insbesondere von Konformitatsbeziehungen. Die Verwaltung geschieht
inForm von gerichteten Graphen, die eine e ziente Realisierung von
Einfuge{, Vergleichs und Anderungsfunktionen ermoglichen. Diese E zienz kann
in der Regel durch das unterliegende Typbeschreibungs{ bzw. Beziehungsrepository
aufgrund seines unstrukturierten Charakters indieserForm nicht gewahrleistet
werden.
5.1.4.3 Abbildungskomponenten
Eine weitere Aufgabe des Typmanagerkerns ist die Anbindung von Abbildungskomponenten,
dieeinedynamische Integration neuer Dienstbeschreibungssprachen
in den Typmanager erlauben. Sie realisieren jeweils eine wechselseitige Abbildung
von einer textuellen Diensttypbeschreibung in die kanonische Diensttypreprasentation,
die Bestandteil der Typmanager{internen Typreprasentation
ist. Hierdurch ist eine dynamische Erweiterbarkeit des Typmanagers gegeben, so
da zukunftig auch diejenigen Anfragen externer Klienten beantwortet werden
konnen, die eine Ruckgabe einer Diensttypbeschreibungineiner bestimmten, zur
Zeit noch nichtunterstutzten Beschreibungssprache erfordern. Diese Eigenschaft
ist vor allem wichtig fur die plattformubergreifende Dienstnutzung anderer als
der zur Zeit in TRADE unterstutzten verteilten Systemplattformen DCE und
CORBA.
5.1.4.4 Graphische Benutzerschnittstelle
Eine wichtige Rolle beim Zugri auf den Typmanager kommt der in den vorherigen
Abschnitten gezeigten graphischen Benutzerschnittstelle zu, welche dem
Anwendungsentwickler und Endbenutzer einen interaktiven Zugangzuseinen angebotenen
Funktionen ermoglicht. Neben den oben erlauterten administrativen
Tatigkeiten des Einfugens, Loschens und Modi zierens von Typbeschreibungen
besteht ihre Hauptaufgabe vor allem in der Unterstutzung des Benutzers beim
Au nden von fur ihn geeigneten Diensttypen. So bilden die im Typmanager
verwalteten Diensttypbeschreibungen eine geeignete Basis, um sie beispielsweise
bei der Entwicklung von Kooperationsanwendungen zu verwenden oder als Ausgangsbasis
fur die anschlie ende Suche nach geeigneten Dienstangeboten zu nutzen.
Hierfur bietet die graphische Benutzerschnittstelle umfangreicheMoglichkeiten,
unter anderem zum Browsen in Diensttyphierachien (siehe Abbildung 5.3)
oder zum Ansehen von Diensttypbeschreibungen. Um diesen Proze der Wiederverwendung
von Diensttypbeschreibungen [CMML96] in o enen verteilten
Dienstemarkten optimal zu unterstutzen, wurde ihre Realisierung auf Grundlage
der Java{Programmiersprache inForm von Java{Applets [Fla96] durchgefuhrt
(siehe [CM96, CMML96]). Diese stellen eine Moglichkeit zur Entwicklung graphischer
Endanwendungen dar, die zur Zeit im Rahmen des World{Wide{Web

5.1 Diensttypmanagement in TRADE 159
zunehmende Verwendung ndet. Die Nutzung der im Netz verschickbaren Java{
Applets geschieht hierbei mittels Web/Java{Browsern, beispielsweise Netscape
Navigator, die fur jede Plattform zur Verfugung stehen und einen transparenten
Zugri auf die Dienste des CORBA{ bzw. DCE{basierten Typmanagers uber
die gezeigte graphische Schnittstelle ermoglichen.
5.1.5 Bewertung und erganzende Anmerkungen
Der in TRADE entwickelteTypmanager stellt exible Mechanismen fur die Verwaltungvon
Diensttyp{ und Beziehungstypbeschreibungen zur Verfugung. Insbesondere
erlaubt er im Rahmen von Konformitatsbeziehungen die Durchfuhrung
automatischer Typvergleiche. Hierdurch wird eine der wesentlichen Grundvoraussetzungen
erfullt, um die von vielen Anwendungen | vor allem auch von
den in TRADE speziell betrachteten Kooperationsanwendungen | geforderte
selbstandige und automatische Dienstvermittlung zuunterstutzen, so da derartige
Anwendungen hochgradig autonom und unabhangig von externen Benutzereingri
en ablaufen konnen.
Mit Hilfe der automatischen Typvergleiche kann auchdas Einfugen neuer Diensttypbeschreibungen
in vorhandene Konformitatbeziehungen automatisch erfolgen,
wodurch sichvor allem die Administration der zukunftig in o enen verteilten
Dienstemarkten zu erwartenden Vielfalt neuer Diensttypen ma geblich erleichtert.
Unterstutzt wird dieses au erdem durch die entwickelte graphische Benutzerschnittstelle,
die nicht nur das Einfugen, Loschen und Modi zieren von
neuen Diensttypbeschreibungen sowie das Browsen vorhandener Typbeschreibungen
ermoglicht, sondern auch die exible De nition neuer Beziehungstypbeschreibungen
ermoglicht. Sie unterstutzt insbesondere die De nition von Konformitatsbeziehungstypen,
die in o enen verteilten Dienstemarkten wahrscheinlich
am hau gsten anzutre en sein werden. Diese konnen auf einfache Art und Weise
mittels der De nitionsregelmustern aus bestehenden Beziehungstypbeschreibungen
zusammengesetzt werden. Bisherige Erfahrungen im Umgang mitder graphischen
Benutzerschnittstellen zeigen auch, da vor allem die Moglichkeit zum
Browsen von Diensttypbeschreibungen recht hilfreich zumAu nden gesuchter
Diensttypen ist. Dieses kann insbesondere fur die Entwicklung von Kooperationsanwendungen
genutzt werden, bei denen sich die dort de nierten Anwendungsvorgange
aus einer Vielzahl genutzter Dienste zusammensetzten.
Weiterhin bietet der Typmanager die fur die Abwicklung von Trader{
Kooperationen notwendigen Unterstutzungsfunktionen, indem er eine kanonische
Typreprasentation zur Verfugung stellt. Diese wird fur den Austausch
von Diensttyp{ und Beziehungstypbeschreibungen im Rahmen des
Projektes Interworking of Traders zur Realisierung der verschiedenen Trader{
Koooperationsprotokolle genutzt (siehe hierzu Abschnitt 5.2.4). In diesem
Zusammenhangistfur eine allgemeine Anwendbarkeit zu untersuchen, ob der in
TRADE zunachst fur DCE und CORBA speziell angepa te und ausreichende
Ansatz ausdrucksmachtig genug ist, um auch andere, eventuell heute noch
nicht entwickelte Dienstbeschreibungssprachen reprasentieren zu konnen. Einen

160 Systemunterstutzung fur den Dienstzugang
moglichen Ansatz hierfur bieten die zur Zeit statt ndenden internationalen
Standardisierungsarbeiten zur De nition eines ODP{Type{Repositories
[ISO94, ISO95].
5.2 Dienstvermittlung und {verwaltung durch den
TRADEr
Der im vorherigen Abschnitt vorgestellte TRADE{Typmanager ermoglicht die
strukturierteVerwaltung von Diensttyp{ und Beziehungstypbeschreibungen und
Beziehungsinstanzen. Er stellt hierdurch die Grundlage zur Verfugung, auf der eine
Vermittlung und {verwaltungvon konkreten Dienstangeboten aufsetzen kann.
Die Realisierung dieserfur den Dienstzugang grundlegenden Dienstangebotsvermittlung
erfolgt in TRADE durch den TRADEr [MJM94, MML94b, MML95f,
GGL + 95, LMM95, MMaTT96]. Seine generelle Konzeption orientiert sich an
der im Rahmen internationaler Standardisierung durchgefuhrten De nition einer
ODP{Trading{Funktion [ODP95a], in der die elementare Funktionalitat eines
Traders und seineexternen Schnittstellen festgelegt wird (siehe auch Abschnitt
3.3.2). Der TRADEr verstehtsich in diesem Zusammenhang als Konkretisierung
der dort nur abstrakt beschriebenen Dienstvermittlungsfunktionalitat
und bietet eine adaquate Umsetzung innerhalb einer realen Systemumgebung
an. Ma geblich beein u t wurde sein Entwurf und seine Realisierung au erdem
durch die im Rahmen des internationalen Projektes Interworking of Traders
[Vog94, VBB95, MMaTT96] durchgefuhrten Arbeiten. In diesem Projekt
standen primar Fragen der Kooperation von Tradern heterogener Verwaltungsdomanen
im Vordergrund der Betrachtung. Auf einen Teil der dort erzielten
Forschungsergebnisse wurde bereits inAbschnitt 3.3.3.3 bei der Darstellung verschiedener
Trader{Kooperationsprotokolle eingegangen. Die Beschreibung der
konkreten Realisierung derartiger Trader{Kooperationen bildet einen der Hauptschwerpunkte
des vorliegenden Abschnitts. Zuvor wird der TRADEr jedoch in
seinem generellen Aufbau beschrieben und die zugrundeliegenden Entwurfsentscheidungen
diskutiert.
5.2.1 Komponenten des TRADErs
In diesem Abschnittwerden anhanddes innerhalbder TRADE{Systemumgebung
prototypisch realisierten TRADErs die wesentlichen Komponenten eines Traders
vorgestellt, die fur die Realisierung einer adaquaten Dienstangebotsvermittlung
in o enen verteilten Dienstemarkten notwendig sind. Hauptaugenmerk beider
Konzeption und Realisierung des TRADErs ist insbesondere das Erreichen eines
hochgradig modularen Aufbaus, der eine dedizierte und somit optimale Unterstutzung
der einzelnen Aufgaben bei der Dienstverwaltung und {vermittlung
erlaubt. Hierdurch bietet sich insbesondere die Moglichkeit zur Verwendung bereits
vorhandener elementarer Systemdienste, wie sie derzeit von gangigen verteilten
Systemplattformen angeboten werden. Diese Art von Wiederverwendung
wird beispielsweise bei der Dienstangebotsverwaltungdes TRADErs deutlich, bei

5.2 Dienstvermittlung und {verwaltung durch den TRADEr 161
deren Entwurf und Realisierung externe Namensdienste verwendet werden. Die
folgende Abbildung 5.5 zeigt den groben architekturellen Aufbau des TRADErs.
TRADEr
Typprüfung
und
-suche
Schnittstelle
Typmanager
Zugriffskontrolle
Importeur Exporteur
Dienstvermittlungsschnittstelle
Dienstangebotsauswertung
Dienstangebotsverwaltung
Schnittstelle Schnittstelle
Schnittstelle
Sicherheitsdienst
Attributmanager
Namensdienst
Abbildung 5.5: Komponenten des TRADErs
Trader-
Kooperationskontrolle
Schnittstelle
Andere
Trader
Der TRADEr unterscheidet insgesamtfunf verschiedene Einzelkomponenten, die
jeweils spezi scheTeilaufgaben bei der Dienstverwaltungund {vermittlung ubernehmen
und zwischen denen ein enges Zusammenspiel statt ndet. Diese Komponenten
sind interner Bestandteil des TRADErs, der in der Abbildung durch
eine Grauschattierung hervorgehoben ist. Samtliche Einzelkomponenten setzen
ihrerseits auf anderen Systemkomponenten auf, die extern zur Verfugung stehen.
Hierdurch wird ein hoher Grad an Modularitat und auch Vereinfachung im
TRADEr{Aufbau erreicht. So nutzt beispielsweise die Dienstangebotsverwaltung
die Funktionen eines Namensdienstes. Systemtechnisch erfolgt die Anbindung
durch generische Adapter, die aus Sicht des TRADErs eine abstrakte Zugri sschichtauf
die extern genutzten Dienste bereitstellen. Hierdurch wird die vorhandene
Heterogenitat anzubindender Dienste im TRADEr verborgen und ein hoher
Grad an Flexibilitat beim Austausch einzelner Unterstutzungsdienste erreicht.
Im Fall der genannten Dienstangebotsverwaltung wird hierfur eine standardisierte
Programmierschnittstelle zum Zugri auf verschiedene DCE{Namensdienste
verwendet (siehe Abschnitt 5.2.2.1).
5.2.2 Dienstangebotsverwaltung und {vermittlung
Zum Zugri auf die Dienstvermittlungs{ und Dienstverwaltungsfunktionen des
TRADErs steht den Klienten eine operationale Schnittstelle zur Verfugung,
die im wesentlichen aus den Operationen exportOffer, importOffer und
withdrawOffer besteht. 8 Diese konnen entsprechend zum Exportieren, Importieren
und Loschen von Dienstangeboten genutzt werden. Samtliche Zugrie
8 Die detaillierte Beschreibung dieser Operationen und ihrer Argumente ndet sich unter
anderem in Abschnitt 3.3.2.3 und in Anhang D.

162 Systemunterstutzung fur den Dienstzugang
der Klienten werden hierbei mit Hilfe der Zugri skontrolle auf ihre Berechtigung
hin uberpruft [Mul95]. Hierzu nutzt der TRADEr den in der DCE{
Implementationsumgebung bereits vorhandenen, auf dem Kerberos{System basierenden
Security Service [OSF93a]. Hierdurch lassen sich insbesondere die Aufgaben
der Benutzerverwaltungund{autorisierungaus dem TRADEr ausgliedern,
wodurch sichseinEntwurf und seine Realisierung ma geblich vereinfachen.
Um den Anforderungen nach einer exiblen und e zienten Dienstangebotsvermittlung
nachzukommen, realisiert der TRADEr ein dreigeteiltes Konzept zur
Ablage und zum Zugri auf Dienstangebote:
1. Ablage statischer Dienstangebotsinformationen unter Nutzung attributbasierter
Namensdienste
2. Verwaltung dynamischer Dienstangebotsinformationen in einem Attributmanagementsystem
3. Zugri auf Dienstangebote anderer Trader im Rahmen von direkten
Trader{Kooperationen
Die beiden erstgenannten Punkte betre en ausschlie lich diejenigen Mechanismen
des TRADErs, die unmittelbar unter seiner eigenen Kontrolle stehen.
Der dritte Punkt erweitert diese lokale Dienstvermittlungssicht, in dem er die
Einbeziehung externer und ebenfalls autonomer Trader erlaubt. Durch diese
domanenubergreifende Zusammenarbeit ergibt sich eineSteigerung der Dienstvermittlungsfahigkeiten
des TRADErs. Hierbei sind jedochseine direkten Einu
moglichkeiten auf die Vermittlungsprozesse der anderen Trader begrenzt. Abschnitt
5.2.3 geht auf diese Aspekte von Trader{Kooperationen und des sogenannten
Link{Managements noch genauer ein.
5.2.2.1 Verwendung attributbasierter Namensdienste
Grundlage fur die Verwaltung statischer Dienstangebotsinformationen bilden attributbasierte
Namensdienste, wie sie in der DCE{Implementierungsumgebung
durch das Cell Directory Service (CDS) und den X.500{konformen Global Directory
Service (GDS) zur Verfugung stehen [OSF93a]. Beide ermoglichen eine
hierarchische Ablage von Namenseintragen, wobei diese Eintrage zusatzlich mit
weiteren Attributeintragen versehen werden konnen.
Grundlegende Strukturierungseinheit des Namensraums sind sogenannte
Namenskontexte, in die Eintrage unter Angabe eines eindeutigen Namens,
beispielsweise unter dem GDS{Namen /.../c=DE/o=Universitat
Hamburg/ou=Informatik/cn=Druckdienst,abgelegt werden konnen. In diesem
Fall stellt Informatik ein Unterkontext von Universitat Hamburg dar, welcher
selbst wiederum Unterkontext von DE ist. Diese Fahigkeit zur hierarchischen
Strukturierung la t sich in geeigneter Weise fur die Verwaltung von Dienstangeboten
nach unterschiedlichsten Organisationskriterien einsetzen. Hierdurch
vereinfacht sichvor allem die Dienstauswahl, da sichder beabsichtigte Dienstangebotssuchraum
zumindest lokal einschranken la t. Des weiteren bilden

5.2 Dienstvermittlung und {verwaltung durch den TRADEr 163
Kontexteauch einemogliche Grundlage zur De nition von Zugri sbeschrankungen,
die beispielsweise bestimmten Importeuren bzw. Exporteuren den Zugri
auf geschutzte Namenskontexte verwahren.
Zu jedem Namenseintrag im CDS und GDS konnen zusatzliche Namensattribute
abgelegt werden, die den Eintrag naher charakterisieren. Der TRADEr nutzt diese
Namensattribute, um diezueinem Dienstangebot gehorenden Informationen
abzulegen [Gre95, MML95f, MML94b]. Die Informationen umfassen unter anderem
den angebotenen Diensttypbezeichner, die aktuelle Belegung der statischen
Dienstattribute und die Schnittstellenreferenzen (engl. interface references), die
zumeindeutigen Zugri auf die Dienstzugangs{ und Dienstangebotsauswertungsschnittstelle
des Diensterbringers erforderlich ist. Der TRADEr erhalt die Dienstangebotsinformationen
von den Exporteuren uber die exportOffer{Operation,
die er an seiner Schnittstelle fur die Registration von Dienstangeboten anbietet
(siehe auch Anhang D).
Um von den spezi schen Eigenschaften eines konkreten Namensdienstes abstrahieren
zu konnen, wurde beim Entwurf des TRADErs zunachst eine generische
Schnittstelle fur die Dienstangebotsverwaltung de niert [Gre95]. Ihre Realisierung
erfolgtehierbeiweitgehendauf Basis der standardisierten XDS{ und XOM{
Programmierschnittstellen 9 [OSF93a] (Abbildung 5.6). Beide Schnittstellen abstrahieren
bei der Programmierungvon den unterliegend genutzten Namensdiensten
und ermoglichen so eine von der vorhandenen Heterogenitat unabhangige
und einheitliche Anwendungsprogrammierung.
DCE-RPC-
Klient
rpc_ns_binding_import(
"/.:/printer")
Gruppen-
Eintrag
RPC-
Eintrag
NSI
/.:/service_offers
CDS
/.:/printer_if_0
importOffer()
RPC-Schnittstellenreferenz
DCE-
Importeur
TRADEr
/.:/printer
/.:/printer_svc_[UUID]
Diensttyp
Dienstattributwerte
•••
/.:/printer_if_1
RPC-Schnittstellenreferenz
•••
DCE-
Exporteur
exportOffer
( ..., DCE-Schnittstellenreferenz,
Diensttyp,
"/.:/printer",
Dienstattributwerte, ...)
XDS/XOM
GDS (X .500)
Abbildung 5.6: XDS/XOM{basierter Zugri auf Namensdienste im TRADEr
9 X/Open Directory Service und X/Open OSI{Abstract{Data Manipulation

164 Systemunterstutzung fur den Dienstzugang
Eine Besonderheit der in der Abbildung dargestellten TRADEr{Realisierung
ist die Moglichkeit, da vorhandene DCE{Dienstnehmer auch direkt uber die
DCE{RPC{spezi sche NSI{Schnittstelle [OSF93a] auf vom TRADEr im CDS{
Namensraumabgelegte Dienstangebote zugreifen konnen (sieheauch [MML95f]).
Hierdurch ergibt sich der Vorteil, da neue Versionen vorhandener Diensterbringer
die exibleren Moglichkeiten der Dienstvermittlung des TRADErs nutzen
konnen, ohne da die bisherigen Dienstnehmer, die weiterhin auf Nutzung des
CDS beruhen, geandert werden mussen. Aus diesem Grund werden in den CDS{
Namensraum exportierten Dienstangebote mittels der NSI{Schnittstelle abgelegt
und anschlie end uber die XDS{ und XOM{Schnittstellen um die dazugehorigen
Dienstattribute erganzt.
Insgesamt bietet die Dienstangebotsverwaltung Funktionen zum Einfugen, Lesen,
Loschen, Andern und Loschen von Dienstangeboten [Gre95]. Ebenso werden
attributbasierteSuchanfragen unterstutzt, die vom TRADEr bei der gesta elten
Dienstauswahl (siehe Abschnitt 3.3.2.3) alternativ zu den vom Attributmanagementsystem
angebotenen Suchanfragen verwendet werden konnen. Hierbei kann
ausgenutzt werden, da die Werte der statischen Dienstattribute bereitsfruhzeitig
wahrend des Dienstauswahlprozesses, d.h. bei der Suche von diensttypkonformen
Dienstangeboten im Namensraum, zur Verfugung stehen.
5.2.2.2 Das Attributmanagementsystem
Die fur die Dienstangebotsverwaltung im TRADEr eingesetzten Namensdienste
sind inder Regel nur fur die Ablage statischer, sich kaum verandernder Eintrage
geeignet. Um nun jedoch auch dynamische Dienstangebotsinformationen verwalten
zu konnen, ist in der TRADE{Systemumgebung ein eigenstandiges Attributmanagementsystem
realisiert [Spr96]. Dieses arbeitet eng mit dem TRADEr
zusammen und unterstutzt seine Dienstauswahl, bei der nun auch dieWerte der
dynamischen Dienstattribute und der operationale Zustand der Dienstanbieter
im Rahmen der gesta elten Dienstauswahl berucksichtigt werden konnen.
Abbildung 5.7 stellt das Zusammenspiel zwischen dem TRADEr und dem Attributmanagementsystem
genauer dar. Sie zeigt gleichzeitig auch eine Konkretisierung
der beim ODP{Trading inAbschnitt 3.3.2.2 gezeigten Abbildung 3.21,
in der unter anderem die Dienstangebotsauswertungsschnittstelle (engl. service
o er evaluation interface | SOEI) eingefuhrt wurde. Diese wird vom TRADEr
zum einheitlichen Zugri auf die Werte der Dienstattribute verwendet, wobei im
Gegensatz zur Darstellung inAbbildung 3.21 die Realisierung nicht von Seiten
der Dienstanbieter, sondern zentral durch den Attributmanager des Attributmanagementsystems
erfolgt. Die Attributverwaltung ist integraler Bestandteil eines
jeden Exporteurs und bindet ihn an das Attributmanagementsystem an. Uber
ihre interne Zugri sschnittstelle bietet sie den Exporteuren die folgende Funktionalitat:
Verwaltung der Werte statischer und dynamischer Dienstattribute:
Die Werte der Dienstattribute konnen vom Dienstanbieter jederzeit nach

5.2 Dienstvermittlung und {verwaltung durch den TRADEr 165
TRADEr
Dienstangebotsauswahl
Attributanfragen,
Zustandsüberprüfung
Dienstangebotsauswertungsschnittstelle
(SOEI)
Attributmanager
Ereignismeldungen
Export
Attributanfragen
Registration, Zustandsmeldungen
DCE- Exporteur
Attributverwaltung
Schnittstelle
Zustandsabfragen
Registration,
Zustandsmeldungen
Attributagent
Abbildung 5.7: Komponenten und Informations usse des Attributmanagementsystems
Bedarf geandert werden, wobei die Anderungen automatischandas Managementsystem
weitergereicht werden. Der konkrete Ablauf im Attributmanagementsystem,
d.h. die Interaktion mit dem Attributmanager und dem
Attributagenten, bleibt vor dem Exporteur verborgen.
Verwaltung von Aktualitatspradikaten:
Zu jedem von der Attributverwaltung verwalteten Dienstattribut ist die
Angabe von Aktualitatspradikaten moglich. Mit ihnen lassen sich Aussagen
uber das Aktualisierungsverhalten bei Attributanderungen tre en. So
werden derzeit unter anderem das Verzogerungs{, das Anderungs{ und das
" Beste{Moglichkeit\{Pradikat unterstutzt [Spr96]. Beispielsweise kann mit
dem Anderungspradikat bestimmtwerden, nach wievielen Wertanderungen
eine Mitteilung anden Attributmanager erfolgen soll. Es eignet sich insbesondere
zur Verwaltung sichpermanent andernder Dienstattribute, beispielsweise
der Lange einer Druckwarteschlange, bei denen die Propagierung
jeder einzelnen Anderung mit einem erheblichen Aufwand verbunden
ware. Fur die Dienstauswahl im TRADEr ist zudem eine hochstmogliche
Aktualitat von dynamischen Attributwerten oftmals auch nicht erforderlich.
Verwaltung des operativen Zustandes:
Neben den Werten der Dienstattribute konnen die Dienstanbieter dem Attributmanagementsystem
mitteilen, ob sie derzeit verfugbar oder, beispielsweise
fur kurzfristige Wartungsarbeiten, inaktiv sind. Sofern es vom Importeur
bei der Dienstanfrage mittels der Angabe von Suchvorschriften gefordert
wird (siehe Abschnitt 5.2.2.3), kann diese Information anschlie end
bei der Dienstauwahl des TRADErs entsprechend berucksichtigt werden.
Der Attributagent dient zur Unterstutzung des Attributmanagers bei der Verwaltung
der operativen Zustande der Dienstanbieter. Hierzu uberwacht er die

166 Systemunterstutzung fur den Dienstzugang
Dienstanbieter auf Fehlerfalle, in dem er periodisch ihre Verfugbarkeit uberpruft.
Sollte ein Dienstanbieter ausgefallen sein, so wird dieses dem Attributmanager
mitgeteilt, der einen entsprechenden Vermerk vornimmt.
Eine weitere Kernkomponente des Attributmanagementsystems ist der Attributmanager.
Er realisiert die Dienstangebotsauswertungsschnittstelle (SOEI) fur
alle beim TRADEr registrierten Dienstangebote. Hierzu bietet er dem TRA-
DEr unter anderem die Operation ServicePropertyValueEnquiry an. Sie unterstutzt
die Auswertungder vom Importeur gestellten Attributanfragen, in dem
sie den Zugri auf die aktuellen Werte der statischen und dynamischen Attribute
der Dienstanbieter ermoglicht. Bei diesem Vorgang wird auf die dem Dienstanbieter
zugeordneteAttributverwaltung zugegri en. Zur Optimierung dieser unter
Umstanden zeitaufwendigen Zugri e bietet der Attributmanager zusatzlicheinen
Attributzwischenspeicher (engl. attribute cache), der die Attributwerteder beim
TRADEr registrierten Dienstanbieter vorhalt. Die Aktualisierung dieser Werte
geschiehtentsprechendder vom Dienstanbieter spezi zierten Aktualitatspradikate,
die ebenfalls im Attributzwischenspeicher gehalten werden. Weiterhin verwaltet
der Attributmanager auch die aktuellen operativen Zustandeder Dienstanbieter.
Diese konnen vom TRADEr im Rahmen der gesta elten Auswertung mittels
der ServiceOfferEvaluate{Operation abgefragt werden.
5.2.2.3 Ablauf einer domanenbegrenzten Dienstangebotsvermittlung
Im folgenden sollen anhand eines Beispiels die Ein u moglichkeiten eines Importeurs
auf den Ablauf einer vom TRADErs durchgefuhrten Dienstvermittlung
verdeutlicht werden. Hierbei wird zunachst von einer lokal begrenzten Dienstauswahl
ausgegangen, bei deren Ablauf ausschlie lich das dem TRADEr lokal
zugeordnete Attributmanagementsystem bzw. die beiden DCE{Namensdienste
genutzt werden. Der Abschnitt 5.2.3 beschreibt anschlie end die erweiterten
Dienstvermittlungsfahigkeiten des TRADErs, die durch die Kooperation mit anderen
Tradern in einem globalen Dienstvermittlungsverbund erreicht werden.
Konzeptionell orientiert sich die lokale Dienstauswahl an dem Prinzip der in
Abschnitt 3.3.2.3 vorgestellten gesta elten Auswertung. Eine Beein ussung des
Auswertungsvorganges kann der Importeur mittels der Eingabeparameter der
importOffer{Operation vornehmen. Die hierbei moglichen Optionen sindinAbbildung
5.8 anhand einer graphischen Benutzerschnittstelle zum Browsen von
im TRADEr verwalteten Dienstangeboten verdeutlicht. Die Abbildung zeigt
die Anfrage nach Dienstangeboten zum Drucken von Dokumenten. Zunachst
wird die Dienstangebotssuche auf den Suchkontext /.../c=de/o=universitaet
hamburg/ou=services eingeschrankt. Der gesuchte Diensttyp ist durch den
Diensttypbezeichner PrintService gekennzeichnet, der auf eine DiensttypbeschreibungimTypmanager
zeigt undimRahmen der gesta elten Auswertung zur
Suche nach konformen Diensttypen verwendet wird. Die Diensttypbeschreibung
beinhaltet unter anderem die Beschreibung der Dienstattribute costperpage,
location und queuelenght,wobei letzteres ein dynamisches Dienstattribut ist.
Uber die Attribute konnen nun prinzipiell beliebig verschachtelte Anfragen ge-

5.2 Dienstvermittlung und {verwaltung durch den TRADEr 167
Abbildung 5.8: Optionen bei der domanenbegrenzten Dienstauswahl
stellt werden. In dem gezeigten Fall werden beispielsweise Druckdienstangebote
gesucht, deren Kosten pro Druckseite geringer als 30 Pfennige sind(costperpage
< 0.3). Hierzu sucht der TRADEr zunachst in dem angegebenen Suchkontext
bzw. allen unterliegenden Suchkontexten nach geeigneten Dienstangeboten, die
den spezi zierten Diensttyp bzw. einen seiner Subtypen realisieren. Anschlieend
wertet der TRADEr mit Hilfe des Attributmanagementsystems die Attributanfrage
aus. Die Auswertung kann durch Vorschriften CheckAvailability
und IgnoreDynamicAttributes beein u t werden, die in der graphischen Benutzerschnittstelle
durchKnopfe aktiviert werden. Mit der ersten Vorschrift wird
bestimmt, ob der aktuelle operationale Zustandeines Dienstanbieters mit berucksichtigt
werden soll. Mit der zweiten kann der Zugri auf die Werte dynamischer
Dienstattributeverhindert werden, um so beispielsweise die Geschwindigkeit des
Dienstauswahlvorganges zu erhohen.
Weiterhin wird in dem gezeigten Beispiel spezi ziert, da die Ruckgabe von
geeigneten Dienstangeboten entsprechend der aktuellen Warteschlangenlangen
geordnet sein soll. Dieses geschieht mit Hilfe des mit Min bezeichneten Knopfes
und des Dienstattributes queuelength. Zusatzlich wirdauch gefordert, da
zu jedem gefundenen Dienstangebot die Attribute queuelength und location
vom TRADEr zuruckgegeben werden sollen. Das Ergebnis der Dienstauswahl ist
im unteren Ausgabefenster gezeigt, wobei die drei gefundenen Dienstangebote
aufsteigend nach der Warteschlangenlange geordnet sind.
5.2.3 Aufbau von Trader{Kooperationen
Die oben gezeigten, auf Namensdiensten und einem Attributmanagementsystem
basierenden TRADEr{Dienstauswahlmechanismen bilden eine geeignete Grundlage
fur die Dienstvermittlung in lokal abgegrenzten Verwaltungsdomanen. Um

168 Systemunterstutzung fur den Dienstzugang
nun jedochauch auf Dienstangebote anderer Verwaltungsdomanen zugreifen zu
konnen, ist die Zusammenarbeit mit den dort vorhandenen Tradern erforderlich.
Hierdurch la t sich der zunachst lokal beschrankte Suchraum des TRADErs um
die Dienstangebote der anderen Trader erweitern. Somit wird gleichzeitig eine
der wichtigen Grundvoraussetzungen fur die domanenubergreifendeNutzungvon
in o enen verteilten Dienstemarkten angebotenen Diensten gescha en.
In Abschnitt 3.3.3 wurden fur den Aufbauderartiger Trader{Kooperationen (engl.
trader interworking) verschiedene Varianten diskutiert, die sich zunachst in indirekte
und direkte Kooperationsformen unterschieden. Die Umsetzung der ersten
Variante ergibt sich beim TRADEr bereits implizit durch die Wahl von globalen
Namensdiensten als Grundlage fur seine Dienstangebotsverwaltung. Insbesondere
der auf dem X.500{Standard basierende Global Directory Service bietet
durch seine derzeitige weite Verbreitung einen geeigneten Ablagedienst, um die
in o enen verteilten Dienstemarkten angebotenen Dienstangebote einem gro en
Nutzerkreis zur Verfugung zustellen. Ein bedeutender Nachteil fur die Anwendbarkeit
dieses Ansatzes ist jedoch die Einschrankungder Automie der an o enen
verteilten Dienstemarkten beteiligten Verwaltungsdomanen [MMaTT96]. Dieses
begrundet sich vor allem darin, da fur die Ablage von Dienstangeboten vorab
eine Standardisierung der Semantik von Diensttypen erforderlich ist,da ansonsten
eine Vermittlung von Dienstangeboten anderer Verwaltungsdomanen nicht
sinnvoll durchfuhrbar ist. Diese Voraussetzung ist jedoch angesichts der Heterogenitat,
insbesondere in den Aspekten der Semantik von Diensten und ihrer
Beschreibung (siehe Kapitel 2), in dieser strikt standardisierten Form in o enen
verteilten Dienstemarkten nicht haltbar.
Aus diesem Grund wurde bei der Realisierung des TRADErs die direkte Kooperation
von Tradern bevorzugt. Beein u t wurde diese Entscheidung auch durch
die Forschungsarbeiten im Rahmen des Projektes Interworking of Traders 10
[Vog94, VBB95, MMaTT96], bei dem aufgrund der weltweiten Verteilung der
Projektteilnehmer auf zwingende Weise von einer Heterogenitat der Verwaltungsdomanen
ausgegangen werden mu te. Zielstellung dieses Projektes war die
Verknupfung der jeweiligen von den Projektpartnern unabhangig entwickelten
Trader{Implementierungen, damit diese anschlie end in direkten Kooperationen
einen domanenubergreifenden Dienstvermittlungsverbund realisieren konnen.
Begleitet wurden diese Arbeiten durch die im Rahmen der ODP{Trading{
Standardisierungdurchgefuhrten Normungsarbeiten, wobei fur das IWT{Projekt
vor allem die Festlegung der importOffer{Operation und der zur Verwaltung
von Links (siehe Abschnitt 3.3.3.2) notwendigen Link Management{Schnittstelle
von Bedeutung waren. In diesem Zusammenhang ergab sichauch die Anforderungandas
Projekt, nichtnur die Durchfuhrbarkeit von standardisierten Trader{
Kooperationen aufzuzeigen, sondern gleichzeitig die erzielten Ergebnisse und Erfahrungen
mit in den Standardisierungsproze ein ie en zu lassen. Einige dieser
Ergebnisse wurden bereits inAbschnitt 3.3.3.3 in Form der dort erlauterten
Trader{Kooperationsprotokolle aufgezeigt. Erganzende Bemerkungen bzw. weitere
Bewertungen zu diesen Kooperationsprotokollen sindau erdem in Abschnitt
10 Das Projekt wird im folgenden auch kurz als IWT{Projekt bezeichnet.

5.2 Dienstvermittlung und {verwaltung durch den TRADEr 169
5.2.4 angefuhrt.
Im folgenden soll die Verknupfung zweier Trader exemplarischanhanddes TRA-
DErs und des am australischen Forschungszentrum DSTC entworfenen Traders
[BB94] beschrieben werden. Erganzende Beschreibungen, insbesondere von Implementationsentscheidungen,
nden sich in[Mul96].
5.2.3.1 IWT{Testszenario
Als gemeinsame Interaktionsplattform fur das in Abbildung 5.9 gezeigte IWT{
Testszenario dient das eingangs dieses Kapitels und im Zusammenhang mit der
TRADEr{Realsisierung erwahnte Distributed Computing Environment (DCE).
Sowohl in Brisbane, Australien, als auch in Hamburg existieren jeweils autonome
Verwaltungsdomanen, die durch sogenannte DCE{Zellen voneinander abgegrenzt
werden. Beide Zellen sind uber das Internet mit Hilfe des auf dem Domain Name
Service basierenden Global Directory Service von DCE miteinander verbunden,
so da die in den jeweiligen Zellen angebotenen Dienste von beiden Seiten uber
RPC{Mechanismen aufgerufen werden konnen.
Link-
Konfigurations-
DCE-Zelle (Hamburg)
Taxi-Server
manager
Taxi-Klient
Link-Management-
Schnittstelle
Dienstangebotsverwaltung
Typprüfung
und -suche
DSTC-Trader TRADEr
DCE-Zelle (Brisbane)
Link-Management-
Schnittstelle
Traderkooperationskontrolle
Svc 1
Zugriffskontrolle
Trading-Schnittstelle
Dienstangebotsauswertung
Typmanager
Abbildung 5.9: Die Testumgebung des Projektes Interworking of Traders
In beiden Verwaltungsdomanen existiert jeweils ein lokaler Trader, die fur den
externen Zugri im Rahmen des IWT{Szenarios mindestens die importOffer{
Operation und die Operationen der Link{Management{Schnittstelle 11 anbieten
mussen. Weiterhin stehen zu Testzwecken in beiden DCE{Zellen jeweils
identische Dienstanbieter in Form eines Taxibuchungsdienstes zur Verfugung
11 Die vollstandige Beschreibung der Link{Management{Schnittstelle ist in Anhang D.2 mit-
tels der DCE{IDL dargestellt.

170 Systemunterstutzung fur den Dienstzugang
(siehe auch Abbildung 5.11), die in jeder Verwaltungsdomane lokal im dortigen
Trader verwaltet werden. Diese sind zunachst durch die Isolation der beiden
Trader nur von den lokalen Importeuren nutzbar. Um nun jedochauch
die Vermittlung dieser Dienstangebote inder anderen Verwaltungsdomane zu
ermoglichen, wird mit Hilfe des im TRADE/IWT{Projektrahmen entwickelten
Link{Kon gurationsmanagers (engl. Link Con guration Manager) [MMaTT96,
Mul96] eine Kooperationsbeziehung zwischen den Tradern aufgebaut.
5.2.3.2 Link{Kon gurationsmanager
Grundlage fur den Link{Kon gurationsmanager bilden die in Abschnitt 3.3.3.2
eingefuhrten unidirektionalen Links, mit denen die Kooperationsbeziehung zwischen
zwei Tradern ausgedruckt wird. Neben den zum Aufbau einer Kooperationsbeziehung
notwendigen Bindungsinformationen enthalten sie Informationen
uber die Typisierungsmechanismen der Zieldomane, anhand derer die in der
Rolle des Importeurs auftretenden Trader erkennen konnen, ob gegebenenfalls
ein Typmanager in die Interaktion eingeschaltet werden mu . Dieses ist in der
Regel dann notwendig, wenn aufgrund administrativer und technischer Heterogenitatgrenzen
Unterschiede inder Typisierung bzw. in der Beschreibung von
Diensten bestehen (siehe auch Abschnitt 3.1.1). Weiterhin ermoglichen Links
durch die Verwaltung statistischer Informationen Aussagen uber die Qualitat einer
genutzten Kooperationsbeziehung, um diese anschlie end beispielsweise als
Grundlage fur eine Auswahl der am besten geeigneten Kooperationspartner zu
nutzen. Die Aktualisierung dieser Informationen geschieht jeweils nach Benutzung
eines Links.
Grundsatzlich la t sich das mit Hilfe des Link{Kon gurationsmanagers
durchfuhrbare Link{Management in drei Abschnitte unterteilen:
1. Strategische Phase:
Im Rahmen der strategischen Phase werden die Links zwischen den verschiedenen
kooperierenden Tradern eingerichtet. Diese Einrichtung erfolgt
uber eine standardisierte Schnittstelle der Trader, die sogenannte Link{
Management{Schnittstelle, mit deren Hilfe die Links in den durch dieTrader
verwalteten Linkraum (engl. link space) abgelegt werden. Links sind
unidirektional, wobei jedoch durch Einrichtung eines Links in entgegengesetzter
Richtung bidirektionale Verbindungen aufgebaut werden konnen.
2. Taktische Phase:
In der taktischen Phase wahlt ein Trader unter den in seiem Linkraum bekannten
Links die fur die jeweilige Anfrage geeignetesten aus. Die Auswahl
la t sich hierbei mit Hilfe von Verwaltungsvorschriften (engl. policies) beein
ussen. Hiermit kann der Dienstnehmer unter anderem festlegen, ob die
Anfrage sich auch uber Domanengrenzen hinweg erstrecken soll, oder ob
sie synchron oder asynchron an verbundene Trader weitergereicht werden
soll (siehe auch Abbildung 5.11).

5.2 Dienstvermittlung und {verwaltung durch den TRADEr 171
3. Operationale Phase:
In der abschlie enden operationalen Phase ruft der Trader die in den
ausgewahlten Links referenzierten Trader uber deren importOffer{
Schnittstelle auf, um die durch sie verwalteten Dienstangebote zu erfragen.
Wurden von den Kooperationspartnern Resultate geliefert, so werden diese
zusammen mit den lokalen Ergebnissen gebundelt an den anfragenden
Importeur zuruckgeliefert. Die Herkunft der Dienstangebote ist dabei
fur ihn nicht ersichtlich. Abschlie end erfolgt eine Aktualisierung der
statistischen Informationen eines Links.
Abbildung 5.10 zeigt einen Teilausschnitt der graphischen Benutzerschnittstelle
des Link{Kon gurationsmanagers, uber die der Zugri auf alle Operationen
der Link{Management{Schnittstelle und die importOffer{Operation der Trader
gesteuert wird.
Abbildung 5.10: Der Dienstangebotsmodus des Link{Kon gurationsmanagers
Um einen Link zwischen zwei Tradern einzurichten, mu zunachst das
Dienstangebot des beabsichtigten Kooperationspartners in Erfahrung gebracht
werden. Hierzu wird im sogenannten Dienstangebotsmodus des Link{
Kon gurationsmanagers eine Dienstanfrage an einen Trader gestellt, um dessen
eigenes Dienstangebot zu ermitteln. Grundlage fur diese Dienstanfrage bildet
der Diensttyp TradingService, der im IWT{Projekt hierfur projektintern
standardisiert wurde. Die zu diesem Diensttyp gehorende Diensttypbeschreibung
umfa t im wesentlichen die Beschreibung der oben bereits genannten
Operationen exportOffer, importOffer und withdrawOffer sowie samtliche
Operationen der Link{Management{Schnittstelle. Dieser Diensttyp wird von
jedem Trader benutzt, um seinen Trading{Dienst anderen Tradern im Rah-

172 Systemunterstutzung fur den Dienstzugang
men des Link{Managements zur Verfugung zu stellen. Die Abbildung zeigt
das Resultat einer derartigen Dienstanfrage, wobei auch die zum Diensttyp
gehorigen Dienstattribute ausgegeben werden. So existiert beispielsweise das
Attribut typemanager identifier, welches die Bindungsinformationen des
dem Trader zugeordneten Typmanagers beinhaltet. Andere Attribute, wie
beispielsweise search method und search strategy geben Auskunft uber vom
Trader angebotenen Suchmethoden und {strategien.
Nachdem ein derartiges Angebot eines Trading{Dienstes gefunden wurde, wird
im sogenannten Link{Modus des Link{Kon gurationsmanagers eine Verbindung
zur Link{Management{Schnittstelle des lokalen Traders hergestellt. Anschlieend
kann das ermittelte Dienstangebot als Link abgelegt werden. Durch die
Bindung an die Link{Management{Schnittstelle lassen sich auch spater die
gespeicherten Links und ihre statistischen Informationen mit Hilfe des Link{
Kon gurationsmanagers uberwachen.
5.2.3.3 Verwaltung und Nutzung von Links im TRADEr
Zur Realisierung der Link{Management{Schnittstelle im TRADEr und auch
im DSTC{Trader war zunachst eine Modi kation der bereits vorhandenen
Dienstvermittlungsschnittstellen beider Trader notwendig. Im Vergleich zur originaren
Spezi kation der importOffer{Operation, die sich ursprunglich ander
im Trader{Standarddokument [ODP95a] de nierten orientiert, verfugt die neue
importOffer{Operation uber folgende Erweiterungen:
Dienstanfragen werden nicht langer anonym behandelt, sondern mit eindeutigen
Dienstanfragekennungen versehen. Diese werden wahrend der gesamten
Lebenszeit einer Dienstanfrage beibehalten und bleiben auch bei
der Weitergabe an kooperierende Trader bestehen. Samtliche Kennungen
werden durch den Trader gespeichert und ermoglichen so die Identi kation
bereits beantworteter Dienstanfragen. Hiermit kann auch das zyklische
Weiterreichen von Dienstanfragen vermieden werden.
Anfragen konnen an Kooperationspartner weitergegeben werden. Dabei
verhalt sichder initierende Trader gegenuber seinem Kooperationspartner
wie ein normaler Importeur.
Spezielle Suchvorschriften (engl. search policies) konnen zur Beein ussung
der Behandlung einer verteilt ablaufenden Dienstanfrage durch den Trader
| beispielsweise in Bezug auf die Einbeziehung einoder mehrerer Kooperationspartner
oder eventuellen Optimierungskriterien | mit ubergeben
werden.
Die von den kooperierenden Tradern zuruckkommenden Ergebnisse werden
gebundelt und gemeinsam an den Importeur zuruckgegeben. Die ursprungliche
Herkunft der einzelnen Dienstangebote bleibt dabei verborgen.
Abbildung 5.11 zeigt am Beispiel einer Taxibuchungsanwendung die erweiterten
Moglichkeiten der Dienstauswahl. Im Unterschied zu der in Abbildung 5.8

5.2 Dienstvermittlung und {verwaltung durch den TRADEr 173
Abbildung 5.11: Angabe von Suchstrategien am Beispiel eines Taxi{Klienten
gezeigten generischen Benutzerschnittstelle, die eine domanenbegrenzte Dienstauswahl
unter unmittelbarer Nutzung der originaren importOffer{Operation
unterstutzt, kann mit der hier gezeigten Benutzerschnittstelle beispielsweise
bestimmt werden, ob Anfragen nur lokal oder auch imRahmen von Trader{
Kooperationen verschickt werden sollen.
Auf systemtechnischer Ebene werden derartige Dienstanfragen an die erweiterte
importOffer{Operation gerichtet. Sie wird an der Schnittstelle des TRADErs
zur Verfugung gestellt und realisiert unter anderem die Behandlung der vom Importeur
spezi zierten Suchvorschriften und die Zusammenfassung der im Rahmen
der Trader{Kooperationen gefundenen Dienstangebote. Hierzu nimmt sie die
Funktionen der Trader{Kooperationskontrolle in Anspruch. Abbildung 5.12 skizziert
den prinzipiellen Ablauf einer Dienstanfrage unter Nutzungexterner Trader.
Der Importeur, im obigen Fall die vom Benutzer gesteuerte graphische Eingabeschnittstelle,
wendet sich hierbei an die erweiterte importOffer{Operation.
Dort ndet als erstes eine Auswertung der Suchvorschriften der Dienstanfrage
statt, wobei als Resultat beispielsweise entweder zunachst nur der lokale Trader
genutzt wird 12 oder auch andere Trader bei der Dienstangebotssuche mit genutzt
werden. In dem in der Abbildung gezeigten Fall werden als erstes die lokal
vorhandenen Dienstangebote des TRADErs erfragt und anschlie end durch die
Trader{Kooperationskontrolle uber Links erreichbare Trader mit in die Dienstangebotsvermittlung
einbezogen. Der genaue Ablauf wird durch einen speziellen
Algorithmus gesteuert, der in Abbildung 5.13 dargestelltist.Detaillierte Erlauterungen
hierzu nden sich in[Mul96].
12 Dieses entspricht dann einer sonst ublichen domanenbegrenzten Dienstanfrage (siehe Ab-
schnitt 5.2.2.3).

174 Systemunterstutzung fur den Dienstzugang
TRADEr
Importeur
1
Standard-
Dienstvermittlungsschnittstelle
Erweiterte
Dienstvermittlungsschnittstelle
2
importOffer (erweitert)
importOffer
TRADEr-Module
- Typprüfung und -suche
- Dienstangebotsauswertung
- Dienstangebotsverwaltung
- Zugriffskontrolle
3
useTraderLinks
Entfernter
Trader
4
importOffer
(erweitert)
Trader-Kooperationskontrolle
- Link-Verwaltung
- Verwaltung von Anfragekennungen
Link-Management-
Schnittstelle
Abbildung 5.12: Ablauf einer Dienstanfrage im TRADEr im Rahmen einer
Trader{Kooperation
Angebotskennung
vorhanden ?
Nein
Angebotskennung (AK)
erstellen
Läßt sich AK
registrieren ?
Ja
Suchmethode
spezifiziert ?
Ja
Suchmethode
vermerken
Suchvorschrift
spezifiziert ?
Ja
Suchvorschrift
vermerken
Ja
Nein
Nein
Suchmethode auf
Defaultwert setzen
Nein
Suchvorschrift auf
Defaultwert setzen
Abbruch
Anfrage
nur lokal ?
Synchrone Anfrage ?
Ja
Lokale Anfrage
zuerst ?
Ja
lokale
Dienstanfrage
Hole relevante
Links
Stelle Dienstanfrage
an Kooperationspartner
Ergebnisse kombinieren
und Resultatrückgabe
Nein
Nein
Ja
lokale
Dienstanfrage
Hole relevante
Links
Threads erstellen für
Links & lokale Anfrage
Anfragen stellen und
warten bis terminiert
Hole relevante
Links
Stelle Dienstanfrage
an Kooperationspartner
lokale
Dienstanfrage
Abbildung 5.13: Algorithmus fur die Abwicklung einer Trader{Kooperation im
TRADEr

5.2 Dienstvermittlung und {verwaltung durch den TRADEr 175
5.2.4 Bewertung und erganzende Anmerkungen
In Hinblick auf die Gesamtentwicklung von TRADE bildet der TRADEr einen
zentralen Integrationspunkt fur das in dieser Arbeit verfolgte Zielder Unterstutzung
der Vermittlung und Koordination von Diensten in o enen verteilten
Dienstemarkten. Ausgehend von einer Sichtweise, die sich zunachst auf
die Grundfunktionen von Tradern in verteilten und technisch homogenen Verwaltungsdomanen
konzentrierte [MJM94, MML94b, MML95f], sind imVerlaufe
dieser Arbeit bereits fruhzeitig Erfahrungen gesammelt worden, die fur den
modularen Entwurf und dieEntwicklung des TRADErs genutzt werden konnten.
Hierbei erweist es sich als gunstig, da zu diesem Zeitpunkt erste stabile
Versionen verteilter Systemplattformen, wie beispielsweise das in dieser Arbeit
verwendete Distributed Computing Environment, zur Verfugung standen,
die bereits fur die Entwicklung und Ausfuhrung verteilter Anwendungen wesentliche
Systemmechanismen anbieten. Eine in diesem Zusammenhangwichtige
Fragestellung fur die Realisierung koordinierter Dienstnutzung in o enen heterogenen
verteilten Dienstemarkten betri t die Integration von Dienstvermittlungsmechanismen,
insbesondere der hier speziell betrachteten ODP{basierten
Trading{Ansatze [ODP95a], in derartige bestehende verteilte Systemplattformen.
Eine der Hauptaufgaben besteht deshalb inder konkreten systemtechnischen
Umsetzung der dort nur abstrakt de nierten Dienstvermittlungsschnittstelle
mit ihren Operationen exportOffer, importOffer und withdrawOffer.
Erst hierdurch lassen sich fundierte Aussagen uber die Praktikabilitat von
ODP{Trading{basierten Dienstvermittlungsmechanismen in realen Systemumgebungen
tre en. Im Gegensatz zu anderen Arbeiten, wie beispielsweise die in
[WT90, PZTT91, WT93, TWW92, Tsc94] beschriebenen, in denen kommerzielle
verteilte Systemplattformen noch nicht zur Verfugung standen und somit
zunachst grundlegende Verteilungsmechanismen erst entwickelt werden mu ten,
konnte beim Entwurf undder Entwicklungdes TRADErs auf eine Anzahl bereits
vorhandener Basisdienste zuruckgegri en werden. Somit waren zunachst geeignete
Basisdienste zuidenti zieren, die die Grundlage fur eine diensttypbasierte
Dienstvermittlung bereitstellen. Zielstellung des TRADEr{Entwurfs war hierbei
das Erreichen eines hohen Grades an Modularitat, so da die speziell auf DCE
bezogenen Erfahrungen verhaltnisma ig einfach auch fur den Entwurf und die
Entwicklung eines Traders auf anderen verteilten Systemplattformen, beispielsweise
der ebenfalls in dieser Arbeit betrachteten CORBA{Plattform, ubertragen
werden konnen.
Im einzelnen sind folgende Basiskomponenten einer Trading{Komponente zur
Unterstutzung der Dienstverwaltung und {vermittlung in o enen verteilten
Dienstemarkten identi ziert (siehe auch Abbildung 5.5) und imRahmen der prototypischen
Realisierung des TRADErs in ihrer praktischen Nutzbarkeit verdeutlicht
worden.

176 Systemunterstutzung fur den Dienstzugang
Dienstangebotsverwaltung
Eine geeignete Basisfur die Verwaltung von Dienstangeboten sind insbesondere
attributbasierteNamensdienste, wie sie in DCE in Form des Cell Directory Service
und des X.500{konformen Global Directory Service angeboten werden. Ihre
Fahigkeit zur hierarchischen Ablage von Eintragen beliebiger Art in Namenskontexten
la t sich in geeigneter Weise fur die Verwaltungvon Dienstangeboten nach
unterschiedlichsten Organisationskriterien einsetzen. Weiterhin bilden Kontexte
auch einemogliche Grundlage zur De nition von Zugri sbeschrankungen. Fur
den TRADEr konnte au erdem ausgenutzt werden, da zu jedem Eintrag beliebig
viele Attribute ablegbar sind, die fur die nahere Charakterisierung eines
Dienstangebotes, beispielsweise des Diensttyps und von Bindungsinformationen,
benotigt werden. Hierbei konnte au erdem durch Hinzufugen DCE{spezi scher
Attribute, die fur die Kopplung des RPC mit dem Cell Directory Service notwendig
sind, eine weitgehend nahtlose Integration des TRADErs in DCE erreicht
werden (siehe Abschnitt 5.2.2 und [MML94b, MML95f]). Mit der Nutzung
des X.500{konformen Global Directory Service ergab sich bereits fruhzeitig
auch ein einfacher Ansatz hinsichtlich der Unterstutzung indirekter Trader{
Kooperationen. Insbesondere in homogenen, auf eine Verwaltungsdomane beschrankteSystemumgebungen
lassen sich Trader{Kooperationen durch Nutzung
standardisierter Namensdiensteauf verhaltnisma ig einfache Artund Weise aufbauen,
ohneda umfangreicheAbsprachen in Form von Kooperationsprotokollen,
die bei der direkten Trader{Kooperation zu vereinbaren sind, getro en werden
mussen. Um diesen Namensdienst{basierten Kooperationsansatz auch inheterogenen
Umgebungen zu etablieren, sind jedoch zusatzliche Anstrengungen hinsichtlichder
Standardisierungvon Ablageformaten fur Dienstangebote zu tre en.
Hinweise hierzu nden sich unter anderem in [AA91, PM93, RH95, WB95].
Dienstangebotsauswertung
Durch die im Trader{Standarddokument de nierte Dienstangebotsauswertungsschnittstelle
(engl. service o er evaluation interface | SOEI) steht einestandardisierte
Schnittstelle fur den einheitlichen Zugri auf die Werte der Dienstattribute
von Dienstangeboten zur Verfugung. Da nur eine abstrakte Beschreibung
dieser Schnittstelle angeboten wird, konnen prinzipiell verschiedenartigste Varianten
des Attributmanagements realisiert werden. Ein moglicher Ansatz bietet
der fur den TRADEr gewahlte Ansatz, bei dem das Attributmanagementsystem
nicht nur die Werteder statischen und dynamischen Dienstattributeverwaltet,
sondern gleichzeitig auch die operationalen Zustande der Dienstanbieter mit
berucksichtigt. Hierdurch la t sich eine exible Unterstutzung der gesta elten
Dienstangebotsauswertung des TRADErs erreichen. Eine der zukunftigen Verallgemeinerungen
der Verwaltung statischer und dynamischer Dienstangebotsinformationen
besteht darin, dieses Attributmanagementsystem, das in TRADE
speziell fur DCE entwickelt wurde und somit eine proprietare Losung darstellt,
durch eineo ene, standardisierte Losung zu ersetzen. Einen moglichen Ansatzpunkt
hierfur bilden Ergebnisse aus dem Bereich der Entwicklung standardi-

5.2 Dienstvermittlung und {verwaltung durch den TRADEr 177
sierter Managementsysteme fur verteilte Systemumgebungen [HA93]. Die dort
entwickelten, standardisierten Interaktionsprotokolle zum Zugri auf Statusinformationen
von Netzkomponenten eignen sich beispielsweise dazu, die derzeit
im TRADE{Attributmanagementsystem verwendeten DCE{Aufrufen zu ersetzen
und soeinen standardisierten Zugri auf die Dienstattribute der Dienstanbieter
zu ermoglichen. In diesem Fall konntedas derzeitige Attributmanagementsystem
moglicherweise sogar vollstandig ersetzt werden und somit ein weiterer
Schritt inRichtung der Wiederverwendung bereits vorhandener generischer Systemmechanismen
erreicht werden.
Zugri skontrolle
Obwohl Sicherheitsaspekte beim Entwurf von TRADE und insbesondere des
TRADErs und der anderen Systemkomponenten nicht imVordergrund der Betrachtung
standen, konnten Autorisierungsmechanismen durch die Nutzung des
Security Service von DCE verhaltnisma ig einfach inden TRADEr integriert
werden. Hierbei wurde ausgenutzt, da samtliche Nutzer von DCE sich vorab
authentisieren mussen. Auf dieser Grundlage lassen sich dann fur jeden in
DCE angebotenen Anwendungs{ und Systemdienst dedizierte Zugri skontrolllisten
verwalten, mit denen der Zugri von Klienten auf die jeweiligen Dienste
bzw. Operationen der Diensterbringer gesteuert werden kann. In diesem Zusammenhangergabsich
als interessanteFragestellung, ob bereitsdurchden TRADEr
uberpruft werden sollte, ob ein Importeur uber entsprechende Zugri srechtezum
Zugri auf bestimmte Dienstangebote verfugt. Diese Kenntnis konnte dann beispielsweise
bereits bei der Dienstangebotsauswahl mit berucksichtigt werden.
Typuberprufung und {suche
In den ersten Versionen des TRADErs wurde zunachst nur ein namensbasierter
Typmanagementmechanismus benotigt. Dieser war fur die Integration des
TRADErs in DCE ausreichend, da DCE selbst nur uber rudimentare, auf den
Vergleich von Schnittstellentypnamen basierende Typuberprufungsmechanismen
zum Zeitpunkt der Bindung und des Operationsaufrufes verfugt. Aus diesem
Grund bot das fur den TRADEr entwickelteTypmanagementnur einfacheFunktionen
zum Einfugen, Suchen und Loschen von Diensttypnamen, Schnittstellentypnamen
sowie Aliasnamen in Typhierarchien an [MML94b, MML95f]. Diese
einfache Art des Typmanagements erwies sich jedoch bei der Entwicklung von
Trader{Kooperationen, insbesondere im Rahmen des in Abschnitt 5.2.3 beschriebenen
IWT{Projektes, zunehmend als un exibel, da aufgrund der Heterogenitat
der beteiligten Verwaltungsdomanen die Absprache von Diensttypnamen in der
Regel zu Mi verstandnissen bei der wohlde nierten, semantisch korrekten Nutzung
von Diensten fuhrt. Aus diesem Grund wurde bereits fruhzeitig parallel
ein struktureller Ansatz fur den Austausch von Dienstbeschreibungen verfolgt,
der letztendlich zumEntwurf und der Entwicklung des in Abschnitt 5.1.1.1 beschriebenen
kanonischen Typmodells fuhrte. Erst hierdurch konnten machtige

178 Systemunterstutzung fur den Dienstzugang
Typmanagementfunktionen realisiert werden, wie sie derzeitig vom TRADE{
Typmanager angeboten werden.
Trader{Kooperationskontrolle
Aufsetzend auf den Erfahrungen beim Entwurf und der Realisierung des ausschlie
lich innerhalb einer Verwaltungsdomane agierenden TRADErs ergab sich
die Moglichkeit, erweiterte Formen der Dienstangebotsvermittlung zuuntersuchen
und erste Erfahrungen und Ergebnisse hinsichtlichdes Aufbaus von Trader{
Kooperationen im Rahmen des Projektes Interworking of Traders [Vog94,
VBB95, MMaTT96] zu sammeln.
Zielstellung dieses Projektes (siehe auch Abschnitt 5.2.3) war die systemtechnische
Verknupfung der von den Projektpartnern unabhangig entwickelten
Trader{Implementierungen uber ein gemeinsames DCE{basiertes Testszenario.
Begleitet wurden diese Arbeiten durch die im Rahmen der ODP{Trading{
Standardisierungdurchgefuhrten Normungsarbeiten, wobei im IWT{Projekt vor
allem die importOffer{Operation und die Link{Management{Schnittstelle von
Interesse waren. In diesem Zusammenhang sollte nicht nur die Durchfuhrbarkeit
von standardisierten Trader{Kooperationen aufgezeigt werden, sondern gleichzeitig
die erzielten Ergebnisse und Erfahrungen mit in den Standardisierungsproze
ein ie en. Bei der konkreten Durchfuhrung des Projektes wurde von einem
mehrstu gen Plan ausgegangen, wobei in der derzeit abgeschlossenen Phase
zunachst nur zwei DCE{basierte Trader miteinander kooperieren konnen. Anschlie
endsolltedas Szenario auf heterogene Systemplattformen ausgeweitet werden,
so da auch Trader{Kooperationen, beispielsweise zwischen einem DCE{
und einem CORBA{Trader, moglich sein sollten. Hierfur mu ten dann zusatzlich
Trader{spezi zische Interzeptionsmechanismen entwickelt werden. Zur Vereinfachung
des DCE{Testszenarios wurde weiterhin von einem homogenen Typverstandnis
ausgegangen, so da die Einbeziehung von Typmanagern bei der
Trader{Kooperation auf einen spateren Zeitpunkt verschoben werden konnte.
Die Verknupfung von zwei DCE{basierten Tradern zwischen zwei getrennten
Verwaltungsdomanen konnte am Beispiel des TRADErs mit dem DSTC{Trader
und dem an der Universitat Stuttgart entwickelten Trader [BKS91, KW94]
praktisch demonstriert werden. Wesentliche Resultate dieserTests waren zum
einen die in Abschnitt 5.2.3.3 beschriebene Erweiterung der importOffer{
Operation und zum anderen der Entwurf und die Entwicklung des Link{
Kon gurationsmanagers. Dieser erlaubt die administrativeVerwaltungvon Links
und stellt somit die Grundlage fur den Aufbau von Trader{Kooperationen
dar. Hierbei zeigt sich, da die vom ODP{Trader{Standarddokument de nierte
Link{Management{Schnittstelle fur derartige Aufgaben ausreichend machtig
ist. Die von ihr angebotenen Operationen addLink, removeLink, modifyLink,
describeLink und listLinks (siehe auch Anhang D.2) wurden intensiv vom
Link{Kon gurationsmanager verwendet und ermoglichen neben dem Einrichten,
Loschen und Modi zieren von Links auch die Verwaltungstatistischer Informationen
uber die Links. Diese Informationen konnen beispielsweise fur administrative

5.2 Dienstvermittlung und {verwaltung durch den TRADEr 179
Entscheidungen beim Aufbauvon Trader{Kooperationen oder aber auchvon den
Tradern selbst zur Auswahl geeigneter Koooperationspartner genutzt werden.
Die ersten praktischen Erfahrungen im Umgang mit Kooperationen von Tradern
zweier getrennter Verwaltungsdomanen zeigen, da zum gegenwartigen Zeitpunkt,
insbesondere aufgrund der weiten Entfernung zwischen Hamburg und
Brisbane uber das Internet, mit hohen Wartezeiten bei der Kooperation zwischen
dem TRADEr und dem DSTC{Trader gerechnet werden mu . Generell
sind Laufzeiten von uber zehn Minuten fur einen einfachen RPC{Aufruf der
importOffer{Operation keine Seltenheit, wobei jedoch der zusatzliche Aufwand
berucksichtigt werden mu , der durch Nutzung des Cell Directory Service zur
Lokalisierung der Trader entsteht. Diese Laufzeiten sind fur einen Einsatz in der
alltaglichen Routine nicht tolerabel, so da zukunftig vor allem Optimierungen
des Zeitverhaltens vorgenommen werden mussen. Dieses ist vor allem hinsichtlich
der Realisierung mehrstu ger Trader{Kooperationen, bei denen mehrere Trader
hintereinandergeschaltet sind, notwendig.
Ein weiteres im Rahmen des IWT{Projektes erzieltes Ergebnis ist die Untersuchung
verschiedener Kooperationsprotokolle, wie sie ausfuhrlich inAbschnitt
3.3.3.3 beschrieben sind. Sie bieten die konzeptionelle Grundlage fur die Entwicklung
verschiedener Kooperationsszenarien zwischen Tradern. Mit ihnen lassen
sichkonkrete Realisierungen von exiblen Trader{Kooperationen entwickeln,
die dann beispielsweise hinsichlich ihrer E zienz evaluiert werden konnen. Um
trotz der oben genannten Performanzprobleme die Durchfuhrbarkeit der verschiedenen
Trader{Kooperationsprotokolle zeigen zu konnen, wurde neben dem
oben beschriebenen Testszenario ein weiteres Szenario aufgebaut, das nur innerhalb
einer Verwaltungsdomane bzw. DCE{Zelle in Hamburg ablief und auf ein
lokales Netzwerk beschrankt war. Hierzu wurden zwei TRADEr gestartet und
mit jeweils einem eigenen TRADE{Typmanager verknupft. Der Aufbau der Kooperationsbeziehungzwischen
den beiden TRADErn erfolgte mit Hilfe des Link{
Kon gurationsmanagers. Als gemeinsame Basis fur den Austausch von Dienstbeschreibungen
diente die vom Typmanager bereitgestellte kanonische Typreprasentation,
die sich in diesem Zusammenhang als geeignete Transportstruktur
von Dienstbeschreibungen erwies. Weiterhin wurde die in DCE de nierte Subtypbeziehung
als gemeinsame Grundlage fur beide Typmanager vereinbart. Als
vergleichsweise einfach zeigtesich die Realisierung der beiden standardisierten
Kooperationsprotokolle, da hier nur Interaktionen zwischen den jeweils zusammengehorenden
TRADEr und Typmanager statt nden und der Typmanager der
anderen Verwaltungsdomane nicht kontaktiert werden mu . Weiterhin wurden
beide ignoranten Varianten und die bewu te, Trader{gesteuerte Koooperationsform
realisiert. Die bewu te, Typmanager{gesteuerteKoooperationsformkonnte
aufgrundder zur Zeit nicht implementierten Operation GetForeignTypeId (siehe
auch Abbildung 3.32) noch nicht realisiert werden.
Mit dieser praktischen Realisierung der verschiedenen Kooperationsprotokolle
konnte zumeinen ihre Durchfuhrbarkeit praktisch demonstriert werden. Zum
anderen ergaben sich Ruckschlusse auf den Software{technischen Entwurf von
Tradern. So vereinfachtsich beispielsweise bei den Typmanager{gesteuerten Ko-

180 Systemunterstutzung fur den Dienstzugang
operationsformen der Entwurf des TRADErs ma geblich, da im TRADEr selbst
keine weitere Behandlung von Typinformationen mehr notwendig ist, sondern
samtliche hiermit verbundenen Aufgaben von den kooperierenden Typmanagern
ubernommen werden.
Im ubergeordneten IWT{Projekt stehen als nachstes vor allem Schritte fur die
oben erwahnteAusweitungdes Testszenarios auf heterogeneverteilte Systemumgebungen
unter Nutzung von Interzeptoren an. Voraussetzung hierfur ist, da
IWT{konforme Trader{Implementierungen auch auf anderen verteilten Systemplattformen
als auf DCE zur Verfugung stehen. Erst dieses ermoglicht die Analyse
der verschiedenen Trader{Kooperationsprotokolle unter gro tmoglichen Heterogenitatsbedingungen,
wobei insbesondere auf dem Hintergrund der bisherigen
praktischen Erfahrungen des IWT{Projektes auch auf Performanzaspekte
vordringlich geachtet werden sollte. In diesem Zusammenhang istauch der fur
den plattformubergreifenden Dienstzugang notwendige Interzeptor detailliert zu
untersuchen. Erste Anmerkungen zur Performanz eines derartigen Interzeptors
nden sich inden Abschnitten 5.3.3.2 und 5.3.4, wo auf verschiedene Realisierungsaspekte
des in TRADE fur DCE und CORBA entwickelten Interzeptors
eingegangen wird.
Vorschriften
Insgesamt zeigt sichbeider Realisierungvon Tradern undTrader{Kooperationen
die Behandlung von Verwaltungsvorschriften (engl. policies) als eine wichtige
ubergreifende Fragestellung. Sie kann in verteilten Systemplattformen generisch
behandelt werden, da sie nicht nur ein Trading{spezi sches Problem ist, sondern
generell auch inanderen System{ und Anwendungsdiensten zur dynamischen
Steuerung benotigt wird. Da hierfur zur Zeit erst grundlegende Ansatze in der
Entwicklung sind(siehe beispielsweise [Mof94, Bur95, MK95]), wurden fur den
TRADEr | und ebenso fur den Typmanager, den Interzeptor und den Koordinationsmanager
| bestimmte Verwaltungsvorschriften vorde niert. Beispiele
hierfur nden sich fur den TRADEr in den Abschnitten 5.2.2.3 und 5.2.3.3, wo
Vorschriften zur Steuerungder importOffer{Operation dienen. Eineder zukunftigen
Aufgabenstellungen wird es in diesem Zusammenhang sein, diese statischen
Ansatze durch einen generischen und dynamischen Steuerungsmechanismus zu
ersetzen, so da eine exible De nition, Ausfuhrung und Kontrolle von Vorschriften
durchfuhrbar ist. Dieser Mechanismus konnte beispielsweise als eigener
Systemdienst etabliert werden, wodurch eineweiterer Schritt der auch in TRA-
DE verfolgten Zielstellung hinsichtlich der Entwicklung generischer Basisdienste
erreicht werden wurde.
5.3 Domanenubergreifender Dienstzugri
Das rasche Voranschreiten der Entwicklung globaler verteilter Dienstemarkte
ermoglicht neue Formen der Entwicklung und Ausfuhrung von verteilten Anwendungen,
die sich insbesondere durch ein kooperatives Zusammenspiel unter-

5.3 Domanenubergreifender Dienstzugri 181
schiedlicher, oft auf heterogenen Einzelsystemen verteilt angebotenen Diensten
auszeichnet. Die Realisierung derartiger fast ausschlie lich aus der Nutzung externer
Dienste bestehender Kooperationsanwendungen (siehe Abschnitt 4.2) wird
vor allem durch die Bereitstellung weitreichender Systemfunktionen unterstutzt,
die durch verteilte Systemplattformen bzw. sogenannte Middleware [Ber93] erbrachtwerden.
Diese, beispielsweise auch die in TRADE speziell betrachteDCE{
und die CORBA{Plattform, bieten dem Programmierer machtige und auf hohem
Abstraktionsniveau be ndliche systemtechnische Funktionen und Schnittstellen
an und ermoglichen so eine e ziente Software{Entwicklung, ohne ihn mit tieferliegenden
system{ und netzwerktechnischen Details zu konfrontieren. Allerdings
ermoglichen sie die Uberwindung der Grenzen heterogener Einzelsysteme im
allgemeinen nur innerhalb ihrer eigenen homogenen Realisierungsumgebungen,
so da sich zwischen zwei verschiedenen verteilten Systemplattformen zunachst
unuberwindbare Heterogenitatsgrenzen ergeben. Um nun trotz dieser Heterogenitatsproblemeeine
domanenubergreifende Dienstnutzung und {koordination zu
ermoglichen, ist eine Erweiterung heutiger verteilter Systemplattformen um die
in Abschnitt 3.4vorgestellten Interzeptionsmechanismen notwendig, die einen
Ubergang uber die technische Heterogenitatsgrenze ermoglichen und somit eine
systemtechnische Interoperabilitat der unterliegenden Middleware{Architekturen
realisieren. Mit ihnen la t sichdann das in TRADE verfolgte Ziel nacheinem uneingeschrankten
Dienstzugang in o enen heterogenen verteilten Dienstemarkten
erreichen.
Der vorliegende Abschnittstellt imfolgenden den in TRADE entwickelten Interzeptor
[GML96, Gri96]vor. Zum einen werden seine unterliegenden verallgemeinerbaren
Konzepte fur den oben beschriebenen Ubergang technischer Heterogenitatsgrenzen
dargestellt und zumanderen ihre Umsetzung konkret am Beispiel
von DCE und CORBA demonstriert. Hierbei wird auch das Zusammenspiel des
Interzeptors mit den in den beiden vorherigen Abschnitten beschriebenen Typmanager
unddem TRADEr deutlich, das in Teil I bisher nur in seiner Konzeption
erlautert wurde.
5.3.1 Voraussetzungen fur die Interzeption
Als Grundvoraussetzung fur die Wirksamkeit des hier beschriebenen Interzeptionskonzeptes
wird zunachst eine Ahnlichkeit der zu integrierenden verteilten
Systemplattformen in der Unterstutzung der genannten Ebenen gefordert. Ahnlichkeit
hei t in diesem Zusammenhang die Gewahrleistung einer grundsatzlichen
Kommunikationsfahigkeit, einer Abbildbarkeit von Modellierungskonzepten
und die Absicht, verwandte Anwendungsklassen zu unterstutzen. Interoperabilitat
wird in diesem Beitrag ausdrucklichnur zwischen in diesem Sinne ahnlichen
Plattformen untersucht, welches im Sinne einer Anwendungsunterstutzung keine
wesentliche Einschrankung darstellt, da sichfur gangige praxisrelevante Systemplattformen,
insbesondere auch fur DCE und CORBA, eine solche Ahnlichkeit
identi zieren la t [YV96, BKR93]. Dieses wurde inAbschnitt 5.1.1 konkret
auch bei der Abbildung der von beiden Plattformen angebotenen Schnittstellenbeschreibungssprachen
deutlich. Beide Plattformen nutzen zudem den Objekt-

182 Systemunterstutzung fur den Dienstzugang
begri zur Charakterisierung ihrer eigenen Basiskonzepte. Ein Objekt versteht
sich dabei im Sinne der in Abschnitt 2.2 vorgestellten Begri sbildung als eine
durch ihre Schnittstelle von der Umgebung abgegrenzte Einheit, deren Verhalten
durch inder Schnittstelle spezi zierten Operationen beschrieben wird. Je nach
Entstehungsgeschichte der beiden Plattformen spiegelt sich diese Objektsicht
mehr oder weniger ausgepragt in ihren jeweiligen Programmiermodellen wider:
Wahrend beispielsweise der Schwerpunkt von DCE eher in der Uberwindung
heterogener Transportprotokolle mittels RPC und der Bereitstellung kommerziell
wichtiger Mechanismen der Sicherheit und eines hierarischen Namensdienstes
liegt, zielt CORBA eher auf die Bereitstellung einheitlicher objektorientierter Methoden
und Schnittstellen fur die Programmierung verteilter Systeme ab. Unter
anderem schon wegen dieser unterschiedlichen konzeptionellen Herangehensweise
werden auch zukunftig noch beide Plattformen nebeneinander existieren, welches
Programmierern o ener verteilter Anwendungen ihre Arbeit zunachst erschwert.
Dennoch bleibt ihr gemeinsamer Einsatz fur eine Vielzahl verteilter Anwendungen
wunschenswert und ist bei einer stufenweisen Migration, beispielsweise von
DCE nach CORBA, sogar unvermeidlich.
5.3.2 Entwurfsziele fur eine Interzeptor{Komponente
Wichtige Zielstellungen fur den Entwurf einer Interzeptor{Komponente zur
Uberwindung der in o enen verteilten Systemumgebungen vorhandenen Heterogenitat
sind:
die Erleichterung des Zugangs zu einer Vielzahl verschiedener Dienstangebote
heterogener Herkunft zur Erstellung verteilter Anwendungen, insbesondere
der in TRADE speziell zu unterstutzenden, auf Koordinationssprachen
und {steuerungsmechanismen basierenden Kooperationsanwendungen
(Abschnitt 4.2),
die Zusammenarbeit der Interzeptionsmechanismen mit den Diensttypisierungs{
und Dienstvermittlungsmechanismen, wie sie in TRADE durch
den Typmanager und TRADEr zur Verfugung gestellt werden und
eine weitgehende programmiertechnische Integration mit den in den verteilten
Systemplattformen vorhandenen Programmierungskonzepten, wobei
die explizite Nutzung eines Interzeptors beim plattformubergreifenden
Dienstzugri moglichst verborgen bleiben soll. Dieses bedeutet vor allem,
da keine explizite Bindung zumInterzeptor aufgebaut werden mu , sondern
der Interzeptionsvorgang automatisch und weitgehend unsichtbar fur
Dienstnehmer und Diensterbringer durchgefuhrt wird.
Insbesondere durch die Erfullung der letztgenannten Anforderung la t sich eine
hohe Akzeptanz des in TRADE entwickelten Interzeptors innerhalb bestehender
Systemumgebungen erreichen, da der Programmierer von einzelnen Anwendungsdiensten
weiterhin in seiner gewohnten Systemumgebung realisieren kann,
seine Dienstangebote nun jedoch mit verhaltnisma ig geringem Aufwand mit

5.3 Domanenubergreifender Dienstzugri 183
Hilfe der vom Interzeptor bereitgestellten Funktionen auch inanderen Verwaltungsdomanen
sichtbar werden und somit fur Anwendungsprogrammierer anderer
Domanen nutzbar werden.
Um die obigen Anforderungen zu erfullen, ist zum einen eine Methode und eine
Entwurfsumgebung fur die Diensterstellung (im Sinne eines " programming in
the small\) und zumanderen eine Methode und eineEntwurfsumgebung fur die
Systemerstellung ( " programming inthe large\) erforderlich. Sowohl die Dienst{
als auch die Systemerstellung, d.h. die Erstellung neuer Koooperationsanwendungen
mit ihren Anwendungsvorgangen, wird in TRADE durch ein spezielles
Framework unterstutzt. Dieser Programmier{Framework, das unter anderem
auch die Koordinationssprache PAMELA beinhaltet, wird in nachfolgenden Kapitel
6 in seinen Details vorgestellt. Es ermoglicht eine einfache Nutzung der
Interzeptionsmechanismen und bietet gleichzeitig auch dieFunktionen, mit denen
eine domanenubergreifendeSteuerungund Koordination der in Anwendungsvorgangen
genutzten Dienste durchfuhrbar ist. Hierbei werden bei der Diensterstellung
die originaren Konzepte der genutzten DCE{ und CORBA{Plattform
weitgehend beibehalten, 13 umden benotigten Lern{ und Umstellungsaufwand
fur den Programmierer so gering wie moglich zuhalten.
5.3.3 Der Interzeptionsmechanismus
Der Interzeptor realisiert die wesentlichen Funktionen zur Bindung und Interaktion
von Dienstnehmern und Diensterbringern uber Domanengrenzen hinweg.
Den dazu notwendigen Vergleich und die Transformation von Schnittstellentypen
fuhrt er mit Hilfe des in Abschnitt 5.1 beschriebenen Typmanagers aus.
Daruberhinaus stellt der Interzeptor auch einen Integrationspunkt fur in Abschnitt
3.4.1 identi zierten Kontroll{, Uberwachungs{ und Informationsfunktionen
dar, da sich mit ihm die entsprechenden Ubergangsmoglichkeiten der einzelnen
Verwaltungsdomanen auf ubersichtlicheWeise in einer Komponenten einheitlich
zusammenfassen lassen. Hierdurch unterscheidet er sich auch von den insbesondere
in [YV96] und [MZP96] vorgeschlagenen Bridge{Mechanismen, die sich
hauptsachlich auf Transformationsaspekte beim plattformubergreifenden Dienstzugri
beschranken.
5.3.3.1 Prinzipielle Funktionsweise
Der Interzeptor mu auf einer Systemplattform lokalisiert sein, die den Zugang
zu den beiden beteiligten und technisch unterschiedlichen Verwaltungsdomanen
erlaubt. Seine Basisfunktionalitat umfa t im einzelnen die folgenden Arbeitsschritte
(siehe auch [Gri96]):
Eingehen einer Bindung mit einem Dienstnehmer einer der beteiligten Verwaltungsdomanen,
13 Dieser Trend zur moglichst weitgehenden Integration wurde auch bei der Nutzung von
DCE{Namensdiensten zur TRADEr{Dienstangebotsverwaltung inAbschnitt 5.2.2deutlich.

184 Systemunterstutzung fur den Dienstzugang
Ermittlung des vom Dienstnehmer gewunschten Diensttyps,
Au nden eines diensttypkonformen Diensterbringers in der anderen
Domane,
Bindung an diesen Diensterbringer,
Entgegennahme eines Operationsaufrufes vom Dienstnehmer,
Transformation der Operationsparameter und ihrer Werte gema dem dort
vorhandenen Typsystem,
Aufruf einer zur gewunschten Operation typkonformen Operation beim
Diensterbringer der anderen Domane,
Entgegennahme der Operationsergebnisse und Transformation der Ausgabeparameter
und ihrer Werte ineinefur die Domane des Dienstnehmers
geeignete Form und
Ubergabe der so erhaltenen Ergebnisse an den Dienstnehmer.
GrundlegendeIdee, um die in Abschnitt 5.3.2 geforderteAbstraktion bei der Nutzung
des Interzeptionskonzeptes zur erfullen, sind sogenannte Proxies (Stellvertreter)
[GML96, Gri96]. Sie stellen fur jede ineiner Verwaltungsdomanevorhandenen
Dienstanbieter entsprechendeStellvertreter in der jeweils anderen Domane
dar, in der diese dann mit den dort bekannten Techniken genutzt und verwaltet
werden konnen.
Initiiert wird die Generierung von Proxies wahrendder Registration vorhandener
Dienstanbieter beim Interzeptor, der anschlie end die Interaktion zwischen der
tatsachlichen und der stellvertretenden Komponente abwickelt und uberwacht.
Bedingt durch die Generierungvon Proxies innerhalbder Zieldomanewirddamit
gleichzeitig auch verhindert, da Fremdkonzepte aus der initiierenden Domane,
die entweder semantischoder technischinder Zieldomane nicht fa bar sind, von
au en hereingetragen werden konnen (siehe auch Abschnitt 3.4.3). Ein Beispiel
hierfur sind Bindungsinformationen, die nur bezuglich einer bestimmten Verwaltungsdomane
einesinnvolle Bedeutung besitzen. In diesem speziellen Fall la t
sich dieses Problem jedoch auf elegante Weise durch Registrierung der erzeugten
Proxies bei der jeweils vorhandenen Dienstvermittlungskomponenteder Zieldomane
erreichen. In konkreter Anwendung auf die in TRADE konkret betrachtete
Verknupfung einer DCE{ und einer CORBA{Domane ndet entsprechend
eine Zusammenarbeit des Interzeptors mit dem CORBA{Broker und dem DCE{
basierten TRADEr statt. Hierdurch wird eine hochgradige Abstraktion vom Interzeptorkonzept
in der Zieldomane erreicht, da dort die bereits verfugbaren
Systemmechanismen, wie in diesem speziellen Fall die Dienstvermittlungskomponenten,
eingesetzt werden konnen. Aus Sicht des Dienstnehmers erscheint der
hierbei generierte Proxy wie ein normaler Diensterbringer der eigenen Verwaltungsdomane.
Grob umfa t das Interoperabilitatskonzept die folgende Vorgehensweise. Zur
Verfugung stehende Dienstanbieter registrieren sich lokal ( " domanenintern\) bei

5.3 Domanenubergreifender Dienstzugri 185
dem TRADEr bzw. CORBA{Broker und global ( " domanenubergreifend\) bei
dem Interzeptor. Dieser registriert wechselseitig Stellvertreter fur die ihm bekannten
Komponenten in der jeweils anderen Domane. Anschlie end konnen
Kooperationsanwendungen durch Komposition beliebiger vorhandener Dienstangebote
erstellt werden, bei deren Ablauf wahrend der Nutzung von Stellvertreterkomponenten
der Interzeptor entsprechende Dienstzugri e beim originaren
Dienstanbieter veranla t. Abbildung 5.14 skizziert diesen generellen Mechanismus
am Beispiel der Nutzung eines DCE{Dienstes durch einen CORBA{
Dienstnehmer.
Broker Interzeptor TRADEr
Register Create
Transform
6
5
1
2
Return Lookup
Typ-
Export
Manager
CORBA-
Klient
4
Bind & Call
7
DCE-
Proxy
3
Interception
8
DCE-
Server
Abbildung 5.14: Nutzung eines DCE{Dienstes durch einen CORBA{
Dienstnehmer
Der Interzeptionsvorgang der Nutzung eines CORBA{Dienstes in einer DCE{
Domane verhalt sichentsprechend spiegelverkehrt (Abbildung 5.15). Wahrend
dieser Interzeptionsvorgange werden Informationen uber registrierte Dienstanbieter,
ihre Bindungen und samtliche Interaktionsversuche protokolliert. Eine
Ein u nahme auf die Sichtbarkeit von Diensterbringern in Fremddomanen ist
durch die Steuerungsmoglichkeit der Proxy{Generierungmoglich. Sie kann auch
durch eine Regelung der Suchtiefen in den verteilten Umgebungen gesteuert wer-
Broker Interzeptor
1
Register
CORBA-
Server
Transform
2
Typ-
Manager
3 4
Create Register
CORBA-
Proxy
Interception Bind & Call
8
7
Return
TRADEr
6
DCE-
Klient
5
Lookup
Abbildung 5.15: Nutzung eines CORBA{Dienstes durch einen DCE{
Dienstnehmer

186 Systemunterstutzung fur den Dienstzugang
den. Weiterhin konnen Sicherheitsaspekte die Nutzung von Komponenten einschranken,
indem Zugri srechte vergeben werden [Gri96].
5.3.3.2 Entwurfsvarianten
Die genauere Betrachtung der vorab beschriebenen Interzeptionsfunktionen la t
unterschiedliche Variationsmoglichkeiten fur den Entwurf einer konkreten Interzeptorkomponente
zu(siehe auch erganzend [Gri96]):
Automatische Registrierung So konnte zumeinen die explizite Registrierung
von Dienstanbietern beim Interzeptor uber den TRADEr bzw. Broker automatischdurchgefuhrt
werden, da bei diesen domaneninternen Vermittlungsinstanzen
ohnehin alle beteiligten Diensterbringer registriert werden sollten. Hierbei
lie en sich die Dienstanbieter von entsprechendem Registrierungscode befreien,
allerdings unter Inkaufnahmeeines Eingri s in den TRADEr bzw. Broker. Da
ein solcher Eingri bei der Verwendung kommerzieller Produkte im allgemeinen
nicht moglich istoder zur Notwendigkeit der Einfuhrung weiterer Zusatzkomponenten
fuhrt und da die in TRADE erhobene Grundforderung ohnehin moglichst
wenige Eingri e in die originaren Mechanismen der beteiligten Systemumgebungen
verlangt, ist diese implizite Variante nicht sinnvoll einsetzbar. Stattdessen
wird hier die Idee des vorab bereits kurz beschriebenen Framework bevorzugt,
das eine konsistente und transparente Erweiterung der fur den domanenubergreifenden
Einsatz vorgesehenen Dienstanbieter erlaubt (siehe Kapitel 6).
Dynamische Proxy{Generierung Zum anderen erscheint es sinnvoll, den
Zeitpunkt der Proxy{Erzeugungunter den Aspekten Optimierung und Ressourcenschonung
zuvariieren. Die moglichen Varianten werden hier gema Abschnitt
3.4.2 als statisch bzw. dynamisch bezeichnet. Der statische Mechanismus, der in
den Abbildungen 5.14 und 5.15 gezeigt wurde, ermoglichtmaximale Transparenz,
indem bei der Verfugbarkeit eines Dienstanbieters in der einen Domane sofort
ein konformer Stellvertreter in der anderen Domane etabliert wird. Gleichzeitig
stellt dieseLosung auch eine Optimierung fur den Zugri dar, da beieinem
Operationsaufruf an Stellvertreter dieser sofort bereit steht. Andererseits kann
diese Losung jedoch zueinem hohen Ressourcenaufwand fuhren, da auch fur
vielleicht niemals nachgefragte Dienstanbieter Proze { und Speicherressourcen
in Anspruch genommen werden. Die dynamische Variante kehrt diese Situation
genau um. Der Interzeptor wird explizit durch den TRADEr bzw. Broker
angesprochen, sobald diese die Anfrage nach einem bestimmten Dienstangebot
erhalten haben, welches in einer anderen Domane angeboten wird. Erst zu diesem
Zeitpunkt erzeugt er einen entsprechenden Proxy (siehe Abbildung 5.16).
Der Vorteil besteht inder Ressourcenschonung, indem nur wirklich benotigte
Proxies erzeugt werden, der Nachteilinder hoheren Antwortzeit fur den Dienstnehmer.
Um hier ein moglichst hohes Ma an Flexibilitat in der Anwendbarkeit
zu erreichen, erscheint dieUnterstutzung beider Varianten generell sinnvoll.

5.3 Domanenubergreifender Dienstzugri 187
2 Notify
3 Lookup
Broker Interzeptor TRADEr
Register Create
Transform
1
Lookup
8
Return
7
6
Typ-
Manager
5
Export
CORBA-
Klient
Bind & Call
DCE-
Proxy
Interception
9 10
Return
4
DCE-
Server
Abbildung 5.16: Dynamische Proxy{Generierung bei der Nutzung eines DCE{
Dienstes durch einen CORBA{Dienstnehmer
Ubertragung von Fremdkonzepten Weiterhin sind Anwendungen zu
berucksichtigen, die die vom Interzeptor angebotenen Abstraktionen beim
domanenubergreifenden Dienstzugri nicht nutzen mochten, da sie im Gegenteil
gerade darauf angewiesen sind, im obigen Sinne domanenfremde Konzepte in
die andere Domane ubertragen zu mussen. Fur derartige Anwendungen sind
vom Interzeptor zusatzliche Schnittstellen anzubieten, die auch eineInteraktion
unter Beteiligung solcher Fremdkonzepte erlauben. Im Rahmen von TRADE
bestand hier insbesondere die im IWT{Projekt 14 gestellte Forderung nach der
Unterstutzungder Zusammenarbeit von heterogen realisierten Tradernbzw.der
dort statt ndene Interaktion von Typmanagern heterogener Domanen. Diese
beiden Teilprojekte [Vog94, VBB95, MMaTT96, CMML96] bieten ein Beispiel
fur die Forderung nach einer derartigen nicht{abstrahierenden Interzeption. Hier
werden beispielsweise DCE{spezi sche Bindungsinformationen vom TRADEr
weitergereicht, die bei dem Trader einer CORBA{basierten Verwaltungsdomane
vorgehalten werden mussen.
5.3.4 Implementationsaspekte des Interzeptors
Aufbauend auf den angefuhrten Entwurfsmoglichkeiten wird im folgenden die
in TRADE realisierte Interzeptionskomponente beschrieben. Die Implementation
des Interzeptors erfolgte unter Nutzung von C++ und Motif. Als Middleware
standen stellvertretend fur eine CORBA{Umgebung eine aktuelle Orbix{
Implementation von IONA Technologies Ltd. [ION94] und DCEvon IBM zur
Verfugung.
Um bei der hier beschriebenen prototypischen Realisierung von Interzeptionsmechanismen
prinzipiell die O enheit auch gegenuber weiteren verteilten Systemplattformen
zu gewahrleisten, wurde insbesondere auf einen hochgradig modularisierten
Aufbau des Interzeptors geachtet. Die Idee der Einbettung ineinen
modularen Programmier{Framework (siehe auch Abschnitt 6.1) stand ebenfalls
14 siehe Abschnitt 5.2.3

188 Systemunterstutzung fur den Dienstzugang
fruhzeitig fest, so da zunachst eine C++{Klassenbibliothek erstellt wurde, die
dem Programmierer immer wieder gleichartig benotigte Funktionalitat, wie beispielsweise
die Kommunikation mit dem TRADEr bzw. Broker, das Erhalten
von Bindungs{ und Referenzinformationen sowie die Ereignisverwaltung, auf einheitliche
Weise bereitstellt. Dabei werden sowohl die Orbix als auch die DCE{
Mechanismen innerhalb der C++{Bibliothek gemeinsam berucksichtigt und in
einer moglichst fur DCE und CORBA homogenen und symmetrischen Form
dem Programmierer zuganglich gemacht. Gleichzeitig wurde diese Bibliothek
auch fur die Entwicklung des Interzeptorkerns genutzt, so da automatisch eine
durchgangige und konsistente Sicht auf das spatere Gesamtkonzept besteht.
Der Kern entsteht dabei aus den wichtigsten Bibliotheksklassen ORB server,
ORB client bzw. DCE server und DCE client durchMehrfachvererbung [Gri96].
Somit konnte einehohe Rationalitat bei der gesamten Entwicklung erreicht und
auf ausgiebig getestete Software{Bausteine zuruckgegri en werden.
Der bisher realisierte Interzeptor ist als aktiver Einzelproze konzipiert und
vereint als solcher die Dienstnehmer{ und Diensterbringerrolle sowohl in der
CORBA{ als auch inder DCE{Domane. Dadurch mu ten zur Gestaltung der
Schnittstellen des Interzeptors keine neuen Mechanismen eingefuhrt werden, sondern
es konnten die in den entsprechenden Domanen jeweils vorhandenen verwandt
werden. Diese Art der Realisierung erforderte eineinterne mehrpfadige
(engl. multi{threaded) Strukturierung des Interzeptionsprozesses mit einem
komplexen Konsistenzsicherungs{ und Priorisierungsverfahren fur die Ereignisbehandlung.
Basis fur das Modul zur Ereignisbehandlungsind die DCE{Threads,
mit deren Hilfe eine gemeinsame Verwaltung der Orbix{ und DCE{Events sowie
der X{Events der Benutzerschnittstelle des Interzeptors realisiert wurde.
Da hier der Interzeptor als zentrale Komponente einen potentiellen Flaschenhals
darstellt, wurde der Optimierung des Zeitverhaltens, insbesondere bei der
Ereignisbehandlung, besondere Aufmerksamkeit gewidmet. Allerdings lassen die
in TRADE speziell zu unterstutzenden Kooperationsanwendungen diese Problematik
ohnehin etwas unkritischer erscheinen, da sie sich aus Diensten recht
hoher funktionaler Komplexitat zusammensetzen und somit der hauptsachliche
Zeitbedarf eher bei der Dienstausfuhrung als bei der Kommunikation uber den
Interzeptor auftritt.
Weiterhin enthalt der gegenwartig realisierte Interzeptor ein eigenes, internes
Typmanagementsystem, das alternativ zum externen Typmanager zu Testzwecken
zur Untersuchung von Performanzeigenschaften dient. Die eigentliche
Interaktionsfahigkeit fur die DCE{ und CORBA{Dienstnehmer bzw. {nutzer
stellen die internen Proxy{Handler des Interzeptors bereit, die die Generierung
und dieUberwachung von Proxies ubernehmen. Hierbei wurden zwei Varianten
implementiert:
Die DCE{Proxies, also Komponenten, die stellvertretend fur DCE{
Dienstanbieter in die CORBA Domane eingefuhrt werden, sind eigene
externe Prozesse, die selbstandig Aufgaben der Interzeption ausfuhren
konnen und anderen CORBA{Dienstnehmern durch einen Eintrag im
Broker auf Nachfrage zur Verfugung stehen.

5.3 Domanenubergreifender Dienstzugri 189
Die CORBA{Proxies dagegen werden in der DCE{Domane sichtbar, indem
der Interzeptor sich selbst als Stellvertreter mit dem entsprechenden
Diensttyp im TRADEr der DCE{Umgebung eintragt und etwaige Aufrufe
dann in einem eigenen Thread abarbeitet.
Diese Realisierung beider Varianten ermoglicht Untersuchungen und Vergleiche
des Zeit{ und Ressourcenverhaltens der Einproze { gegenuber der Mehrproze
losung. Steuer{ und kon gurierbar werden die Funktionen dieser Kernmodule
durch eineaufgesetzte Benutzerschnittstelle, die sowohl unterstutzende Funktionen
zur Systemkon guration, wie beispielsweise die Steuerung der Sichtbarkeit
von Proxies, als auch zur Erstellung von Kooperationsanwendungen (siehe den
Application Builder in Kapitel 6) und deren Uberwachung und Kontrolle anbietet.
Insgesamt prasentiert sich die Benutzerschnittstelle dem Benutzer mit
einer komfortablen graphischen Bedienung (siehe auch Bild 6.3). Fur die Sicherheitsmechanismen
wurden keine eigenen Techniken implementiert, sondern die
Moglichkeiten der jeweiligen Verwaltungsdomanen ausgenutzt, auf deren Grundlage
eine benutzerorientierte Vergabe von Rechten fur die Erzeugung, Aktivierung
und Weitergabe von Komponenten durchgefuhrt werden kann.
external
G
U
I
internal external
Event Dispatcher
Type Checker Type Checker
Transformer Transformer
Type Management Interface
DCE Proxy
Handler
CORBA
Head
CORBA
Proxy Hand
DCE
Head
Administration Interface
T
y
p
e
M
P
r
x
y
A
d
m
i
n
Abbildung 5.17: Architektureller Aufbau des Interzeptors
Zusammenfassend ergibt sich somit das obige Bild 5.17 der groben Interzeptorstruktur
mit seiner Proxy{Schnittstelle, der Typmanagementschnittstelle und
der Interaktionsschnittstelle. Letztere wird gleichzeitig auch zu Administrationszwecken
genutzt. Der Entwurf der einzelnen Module richtet sich im Sinne einer
modernen Software{Eentwicklung nach gangigen etablierten Entwurfsmustern
(engl. design patterns) [GHJV94], welches sich beispielsweise in der Anlehnung
an die Muster Mediator, Bridge, Observer und Proxy sowie Acceptor, Connector
und Reactor zeigt. Zur Zeit wird untersucht, ob ein eigenstandiges Interzeptor{

190 Systemunterstutzung fur den Dienstzugang
Muster sinnvoll etabliert werden kann [Gri96].
5.3.5 Bewertung und erganzende Anmerkungen
Ein unmittelbares Resultat der gestellten Anforderungen an das Interzeptionskonzept
ist die Moglichkeit zur Scha ung sanfter Technologieubergange,
da die beteiligten Eigenschaften der technisch unterschiedlichen Verwaltungsdomanen
beibehalten werden und dennoch die Anbindung aneineandere Technologie
moglich wird. Dieses erhoht die Akzeptanz eines entwickelten Interzeptors
und erlaubt ein Wachsen bestehender Systemlandschaften ohne abrupte
technische und konzeptionelle Bruche. Hierzu tragt auch der Verzicht auf die
Einfuhrung neuer plattform{ bzw. domanenubergreifender Mechanismen bei,
die einen erhohten Anpassungsaufwand inden Verwaltungsdomanen zur Folge
hatten. Spezielle Anwendungen, wie beispielsweise die in Abschnitt 5.2.3 angefuhrten
Trader{Kooperationen, sind ohne die domanenintegrierenden Konzepte
des Interzeptors in dieser Form gar nicht realisierbar. Hier relativiert sich
jedoch gleichzeitig auch der Vorteil der Interzeption, keine Fremdkonzepteindie
Verwaltungsdomanen einzubringen, daeine Klasse spezieller Anwendungen diese
Abstraktion zu Gunsten eigener Verarbeitungsmoglichkeiten aufgeben mu . Zudem
stehen zu einem gegebenen Zeitpunkt ohnehin nicht alle benotigten Mechanismen,
beispielsweise fur die Transaktionssicherungindem in Abschnitt 6.1.2.4
vorgestellten Hotelbeispiel, plattformubergreifend zur Verfugung, so da die angestrebte
hochgradige Symmetrie des Interzeptionskonzeptes nur bis zu einer
gewissen Stufe realisiert werden kann. Andererseits ist der Interzeptor selbst
in der Lage, gewisse fehlende Funktionalitat einer Domane zukompensieren.
So ubernimmt er beispielsweise in TRADE fur die CORBA{Domane gewisse
Trading{Eigenschaften, indem er beispielsweise den dortigen Diensterbringern
Diensttypen zuordnet.
In Bezug auf die Software{Entwicklung selbst bietet die vorgestellte Art der
Interzeption den besonderen Vorteil, Transformations{ und Bindungskonzepte
nicht fur jeden Dienstanbieter neu entwerfen zu mussen, sondern einen einheitlichen
gemeinsamen Mechanimus zur Verfugung stellen zu konnen. Hierbei
hat sich die Integration des TRADErs, des CORBA{Brokers, des Typmanagers
und des in Kapitel 6 beschriebenen Koordinationmanagers mit dem entwickelten
TRADE{Interzeptor in einem umfassenden Framework als besonders fruchtbar
erwiesen und bietet neuartige Moglichkeiten einer Software{Entwicklung inheterogenen
verteilten Systemumgebungen. Trotz der hohen Eigenfunktionalitat
bereits dieser Einzelteile ermoglicht erst das Interzeptionskonzept eine wesentliche
Erweiterung ihrer Einsatzmoglichkeiten. So ist es zwar nur sinnvoll beim
gleichzeitigen Einsatz entsprechender Vermittlungskomponenten einsetzbar, wie
beispielsweise dem TRADEr und Broker, andererseits wird bereits fur die ubergreifende
Zusammenarbeit von Tradern ein der Interzeption aquivalentes Konzept
benotigt. Ebenso wird die Interaktionsfahigkeit bei der Zusammenarbeit
von Typmanagern erreicht, wobei das Auslagern des Typmanagements aus dem
eigentlichen Interzeptor sinnvoll ist, da diese Komponente, wie insbesondere bei
der Dienstvermittlung deutlich wurde, auch eigenstandig innerhalb einer Verwal-

5.3 Domanenubergreifender Dienstzugri 191
tungsdomane von allgemeinem Nutzen ist. Daruberhinaus liefert die Betrachtung
der fur einen konkreten Interzeptor notwendigen Funktionalitat Aussagen
uber Starken, Schwachen und fehlende Funktionen der beteiligten Verwaltungsdomanen.
So konnen Erfahrungen bei der Realisierung eines Interzeptionskonzeptes
eine direkte Migration dort verwandter Funktionalitat in entsprechend
unzureichend ausgestattete Domanen zur Folge haben. Ein konkretes Beispiel
fur ein solches Vorgehen ware die Realisierung eines CORBA{Traders bei Verwendung
des bereits unter DCE existierenden TRADErs.
Insgesamt erweist sich der so entwickelte Interzeptor in Zusammenarbeit mit
dem TRADEr und dem Typmanager als tragfahige Grundlage fur die Realisierung
des in dieser Arbeit geforderten Zieles eines weitgehend uneingeschrankten
domanenubergreifenden Dienstzugangs. Mit ihm wird es moglich, auf eine
Vielzahl von Diensten unterschiedlicher Verwaltungsdomanen unabhangig von
ihrer technischen Realisierungsgrundlage zuzugreifen. Hierdurch wird eine wichtige
Voraussetzung fur die Nutzung von in heterogenen verteilten elektronischen
Markten angebotenen Diensten zur exiblen Entwicklung von o enen Kooperationsanwendungen
gescha en.

Kapitel 6
Entwicklung und Ausfuhrung
von Kooperationsanwendungen
Aufsetzend auf Kapitel 4, in dem das in dieser Arbeit verwendete, abstrakte
Petri{Netz{basierte Beschreibungs{ und Ausfuhrungsmodell von Kooperationsanwendungen
vorgestellt wurde, beschreibt das vorliegendeKapitel seine konkrete
Umsetzungineinefur den Anwendungsentwickler nutzbare Entwicklungs{ und
Ablaufumgebung. Grundlage hierfur bilden die im vorherigen Kapitel beschriebenen
Systemdienstedes Typmanagers,des TRADErs und des Interzeptors, die
in Zusammenarbeit mit den DCE{ und CORBA{Mechanismen die systemtechnische
Unterstutzung fur den Dienstzugang in TRADE bereitstellen. Mit ihrer
Hilfe kann ein Anwendungsprogrammierer potientiell auf eine gro e Anzahl
von verschiedenartigen Diensten im Sinne eines verteilten Systembaukastens von
Diensten [MML95d, MML95e, GML96] zugreifen. Diese Dienste konnen dann im
Rahmen der Entwicklungkomplexer Anwendungsvorgange innerhalb von Kooperationsanwendungen
beliebig miteinander kombiniert werden, wobei es generell
keine Rolle spielt, auf welcher konkreten verteilten Systemplattform die Dienste
angeboten werden. So sind beispielsweise aus einer DCE{Verwaltungsdomane
heraus uber den Interzeptor auch die in einer CORBA{basierten Verwaltungsdomane
angebotenen Dienste nutzbar. Dieses gilt auch umgekehrt fur die Nutzung
von DCE{Diensten in einer CORBA{Verwaltungsdomane. Um nun konkret
verteilte Kooperationsanwendungen mit ihren Anwendungsvorgangen spezi
zieren zu konnen, stellt TRADE auf Basis der Ausfuhrungsumgebung eine
integrierte Entwicklungsumgebung zur Verfugung. Zusatzlich wird die TRADE{
Ausfuhrungsumgebung um Systemmechanismen zur Dienstkoordination (siehe
auch Abbildung 4.13) erganzt, welche die Ausfuhrung von Kooperationsanwendungen
durchentsprechendeKoordinationsmechanismen in Form eines sogenannten
Koordinationsmanagers systemtechnisch unterstutzen.
Im folgenden wird zunachst auf die Entwicklungsumgebung eingegangen und der
dort entwickelte Programmier{Framework erlautert. Hierbei wird insbesondere
die in dieser Arbeit entwickelte Koordinationssprache PAMELA, die eine programmiersprachliche
Umsetzung des abstrakten Petri{Netz{basierten Anwen-

194 Entwicklung und Ausfuhrung von Kooperationsanwendungen
dungsmodells realisiert, beispielhaft vorgestellt und zwei verschiedene Moglichkeiten
ihrer Verwendung verdeutlicht. In diesem Zusammenhang wird auch auf
den in TRADE entwickelten Application Builder eingegangen, der eine Erstellung
von Kooperationsanwendungen nach dem " Plug in and play\{Prinzip
ermoglicht. Im Anschlu wird in Abschnitt 6.2 der Koordinationsmanager in
seinen Details vorgestellt. Dieser ubernimmt die Aufgaben der Dienstkoordination
in der TRADE{Ausfuhrungsumgebung und erlaubt eine direkte Umsetzung
einer PAMELA{Anwendungsbeschreibung in ein ausfuhrbares Anwendungsprogramm.
6.1 TRADE{Entwicklungsumgebung
Die von TRADE vorgeschlageneund realisierte Entwicklungsumgebungla t sich
grob in einen Bereich fur die Erstellung von einzelnen Diensten und ineinen zur
Systemerstellung bzw. zur Entwicklung von Kooperationsanwendungen unterteilen.
6.1.1 Diensterstellung
Fur die Erstellung einzelner Dienste steht in TRADE neben den von den Systemplattformen
DCE und CORBA angebotenen Programmierwerkzeugen, insbesondere
den dortigen IDL{Sprachubersetzern und Programmierbibliotheken
[OSF93a, ION94] ubergeordnete C++{Klassenbibliotheken fur beide Plattformen
zur Verfugung. Diese vereinfachen die Programmierung einzelner Dienste
ma geblich, indem sie den Programmierer vor allem von den in der Regel umfangreichen
Initialisierungsvorgangen befreien. Zum einen ermoglichen sie eine
vergleichsweise einfache Nutzung der vom Typmanager, TRADEr, Interzeptor
und vom Koordinationsmanager bereitgestellten Dienste, indem sie unter anderem
den im allgemeinen komplexen Aufbauder zum Austauschvon Diensttypbeschreibungen
benotigten Typreprasentation, den Ex{ bzw. Import von Dienstangeboten
an den TRADEr und die Registration von Dienstangeboten beim Interzeptor
unterstutzen. Weiterhin stellen sie auch Methoden bereit, mit denen eine
transaktionale Ausfuhrung von Diensterbringern in einer DCE{Domanemoglich
ist. Hierbei werden ebenfalls die im allgemeinen komplizierten Initialisierungsvorgange
des im Rahmen von TRADE genutzten, auf DCE aufsetzenden Encina{
Transaktionspaketes [IBM93] weitgehend vor dem Anwendungsentwickler verborgen.
Diese in [Gri96, Bri95, Mul96, Spr96, CM96, Gre95] ausfuhrlich beschriebenen
Klassenbibliotheken sind Bestandteil eines durch TRADE realisierten
neuartigen Programmier{Framework. 1 Grundlegende Idee des Programmier{
Framework ist es, die Erstellung von Einzeldiensten trotz technisch heterogener
Verteilungsplattformen unter einem gemeinsamen konsistenten Konzept erscheinen
zu lassen und einekomplette Entwicklungsumgebung fur die System{ bzw.
Anwendungserstellung mit Entwicklungs{ und Laufzeitsystem bereitzustellen. Er
1 Fur eine generelle De nition des Begri es Framework siehe unter anderem [Ber93] und
[Ber95].

6.1 TRADE{Entwicklungsumgebung 195
besteht zumeinen aus den aktiven Komponenten der TRADE{Ausfuhrungsumgebung
|Typmanager, TRADEr, Interzeptor, CORBA{Broker und Koordinationsmanager
| und zumanderen aus den erwahnten Klassenbibliotheken, die
die passiven Komponenten des Framework bilden.
Insgesamt realisiert der TRADE{Programmier{Frameworkdamit eine integrierteEntwicklungs{
und Ausfuhrungsumgebung, die eine e ziente Realisierung von
neuen Kooperationsanwendungen und einzelnen Diensten ermoglicht. Hierbei
wird der Programmier{Framework nicht nur fur die Erstellung von Anwendungen
genutzt, sondern bietet gleichzeitig auch die Grundlage fur die Entwicklung
der TRADE{Basisdienste selbst. So nutzt beispielsweise der Interzeptor
die angebotenen Bibliotheksklassen ORB server, ORB client bzw. DCE server
und DCE client [Gri96], die die fur seine Registrierung in CORBA und DCE
notwendigen Initialisierungsschritte ausfuhren (siehe auch Abschnitt 5.3.4).
Ein wichtiger Bestandteil des Programmier{Framework ist die Bereitstellung eines
Kommunikationskonzeptes, um beliebige, in der Regel zum Kompilationszeitpunkt
einer Anwendung unbekannteDatenstrukturen ubergeben und Operationsaufrufe
ausfuhren zu konnen. Dieses wird innerhalb von TRADE durch die
Realisierung eines Dynamic Invocation Interface (DII) bereitgestellt, das eine
typattributierte Ubergabe beliebiger Daten erlaubt. In der auf Orbix aufsetzenden
CORBA{Domane [ION94] ist ein solcher Mechanismus gema der CORBA{
Spezi kation [OMG91] bereits vorhanden, wahrend erfur die DCE{Domane |
sich ebenfalls am CORBA Vorschlag orientierend |neu implementiert wurde
[Bri95,Gri96]. Um hier fur die Implementierungsowohl in DCE als auch CORBA
eine einheitliche Programmmierungschnittstelle zu scha en, wurden die jeweiligen
Implementierungen von einer sogenannte Wrapper{Klasse umgeben, so da
ihre Unterschiede bei der Anwendungsprogrammierung weitgehend verborgen
bleiben. Verwendung ndet das DII bei samtlichen im Zusammenhang mit dem
Interzeptor und dem Koordinationsmanager durchgefuhrten Interaktionen.
6.1.2 Entwicklung von Kooperationsanwendungen mittels der
Koordinationssprache PAMELA
Zum Erreichen des in dieser Arbeit verfolgten Ziels der Erstellung von verteilten
Anwendungen unter weitestgehender oder sogar ausschlie licher Nutzung
externer Dienste sind geeignete Ausdrucksmittel zu entwickeln, mit denen
die Dienstnutzung imRahmen verteilter kooperativer Anwendungen darstellbar
ist. Zu diesem Zweck wurde in Kapitel 4 das in dieser Arbeit entwickelte
Beschreibungs{ und Ausfuhrungsmodell von Kooperationsanwendungen vorgestellt.
Dieses ermoglichteine abstrakte vorgangsorientierte Sicht auf die Nutzung
von Diensten im Rahmen von Anwendungsvorgangen. Formale Grundlage fur
die Beschreibung von Anwendungsvorgangen bilden Petri{Netze, die hinsichtlich
der von Kooperationsanwendungen geforderten Beschreibungskonzepte um
entsprechende Darstellungsmittel erweitert wurden (siehe Abschnitt 4.2.3).
Um diesen formalen Beschreibungsansatz nun ineinefur den Anwendungsprogrammierer
unmittelbar nutzbare Form zu uberfuhren, ist die Bereitstellung ei-

196 Entwicklung und Ausfuhrung von Kooperationsanwendungen
ner konkreten Programmiersprache erforderlich, die eine Verknupfung zueiner
realen Systemumgebung ermoglicht. Erst hierdurch konnen spezi zierte Anwendungsvorgange,
beispielsweise bei Verwendung eines bestimmten Datentypmodells
(siehe auch Abschnitt 4.2.3.1), ineiner spezi schen Systemumgebung zur
Ausfuhrung gebrachtwerden. Das Schlie en dieser Lucke zwischen dem abstrakten
Beschreibungsmodell und einer bestimmten Ausfuhrungumgebung wird in
diesem Abschnitt konkret am Beispiel der TRADE{Systemumgebung und der
Koordinationssprache PAMELA 2 [MML95d, MML95e, Gri95] verdeutlicht.
6.1.2.1 Zielstellung und Entwurfsentscheidungen
Ziel des Sprachentwurfs von PAMELA war die Bereitstellung von Ausdrucksmitteln,
mit denen die koordinierte Nutzung von in o enen verteilten Dienstemarkten
angebotenen bzw. in Entwicklung be ndlichen Dienstangeboten innerhalb
von Anwendungsvorgangen adaquat beschrieben werden kann. Konzeptionelle
Grundlage hierfur bildet das oben erwahnte, auf erweiterten Petri{Netzen
basierende Modell von Kooperationsanwendungen und Anwendungsvorgangen.
Zusatzlich wurden im Sprachentwurf auch Randbedingungen berucksichtigt, die
sich aus der unmittelbaren Nutzung von DCE und CORBA als Realisierungsgrundlage
von TRADE ergaben und somit nicht direkt aus dem Anwendungsmodell
ersichtlich sind. Dieses betri t insbesondere die Verwendung der CORBA{
IDL als Diensttypbeschreibungssprache, auf deren Integration in PAMELA im
folgenden noch genauer eingegangen wird.
Wie bereits in Kapitel 4 ausfuhrlich erlautert wurde, stellen Petri{Netze als Darstellungsmittel
von Nebenlau gkeit und Synchronisation eine geeignete Grundlage
fur die Beschreibung von Anwendungsvorgangen dar. Mit ihnen ist die Intra{
und Intervorgangsnebenlau gkeit von Anwendungsvorgangen auf intuitive und
einfache Artund Weise beschreibbar. Durch diese Integration in einer Beschreibungsform
kann der konzeptuelle Bruch vermieden werden, der im allgemeinen
bei der Einfuhrung von Nebenlau gkeits{ und Synchronisationskonzepten in
herkommlichen sequentiellen Beschreibungsansatzen auftritt. Hierdurch wird ein
hohes Abstraktionsniveau fur den Anwendungsentwickler bei der Beschreibung
von Anwendungsvorgangen erreicht. Unterstutzt wird dieses dadurch, da beispielsweise
mit der in dieser Arbeit und konkret in PAMELA gewahlten Petri{
Netz{basierten Darstellungsweise von Anwendungsvorgangen eine vollstandige
Trennung ihrer koordinativen undverarbeitungsbezogenen Aspekteerreichtwird.
PAMELA{Programme spezi zieren deshalb ausschlie lich Koordinationsaspekte,
wahrend die Beschreibung und Realisierung der eigentlichen anwendungsspezi
schen Berechnungsfunktionalitat in den Diensten verborgen ist und beispielsweise
unter Nutzung der in TRADE angebotenen C++{Klassenbibliotheken des
Programmier{Framework erfolgen kann. Aus diesem Grund wirdPAMELA in
Anlehnung an [GC92] auch als eine Koordinationssprache bezeichnet.
Angestrebt wird weiterhin eine moglichst weitgehende Abstraktion von den unterliegenden
Systemmechanismen der TRADE{Ausfuhrungsumgebung, um von
2 Petri net based Activity Management Execution Language

6.1 TRADE{Entwicklungsumgebung 197
dem verteilten Charakter einer Kooperationsanwendung zuabstrahieren und eine
einheitliche Nutzung der in TRADE angebotenen Anwendungs{ und Systemdienste
zu erlauben. Hierdurch wird eine der in TRADE ubergeordnet verfolgten
Zielstellungen nach Verteilungsabstraktion erfullt (siehe auch Kapitel 1). Hierzu
mussen in Anlehnung an[Tol94] insbesondere die folgenden vier Heterogenitatsaspektevon
o enen heterogenen verteilten Systemumgebungen bzw. Dienstemarkten
adaquat behandelt werden:
die Heterogenitat der Rechnerarchitekturen undder sie verbindenden Netzwerktechnologien,
die Heterogenitat der eingesetzen Programmiersprachen, die zur Realisierung
der genutzten Dienste verwandt wurden,
die Heterogenitat der bearbeiteten Informationen, beispielsweise numerische
Daten, Texte oder Multimedia{Dokumente, und
die Heterogenitat der Struktur einer komplexen Anwendung, in der beispielsweise
Teilkomponenten unvorhergesehen und plotzlichnicht mehr zur
Verfugung stehen konnen.
Samtliche dieser aufgefuhrten Aspekte werden im vorliegenden PAMELA{
Sprachentwurf durch das der TRADE{Systemumgebung unterliegende Dienstnutzungsparadigma
ineinem einzigen Konzept behandelt. PAMELA bietet jedoch
nicht nur die Abstraktion von Heterogenitatsproblemen, sondern verbirgt
auch die | trotz des Vorhandenseins der im vorherigen Abschnitt vorgestellten
und vergleichsweise einfach zuhandhabenden Klassenbibliothek | im allgemeinen
hohe Programmierkomplexitat bei der Nutzung der in TRADE entwickelten
Systemdienste. Erreicht wird dieses durch die Bereitstellung eines generischen
Koordinationsmanagers, der samtliche mit diesen Systemdiensten durchzufuhrenden
Interaktionen auf der Grundlage des PAMELA{Beschreibung automatisch
abwickelt (siehe Abschnitt 6.2).
6.1.2.2 Sprachkonzepte
Das Prinzip von PAMELA, ausschlie lich die Koordination von Diensten zu beschreiben,
ist eines ihrer wesentlichen Hauptmerkmale. Daruberhinaus zeichnet
sich PAMELA durch folgende weitere Eigenschaften aus:
die sprachliche Umsetzung des auf gefarbten Petri{Netzen basierenden
Anwendungsmodells mit Erweiterungen hinsichtlich des Dienstkonzeptes�
um bei der Beschreibung von Anwendungsvorgangen generell den Bezug
zu Petri{Netzen weiterhin beizubehalten, wurde die Syntax von PAME-
LA moglichst wenig abstrakt, sondern durch eine aus dem Englischen
stammende Wortwahl leichtverstandlich und anwendungsorientiert gehalten.
Hierdurch bleiben fur den Anwendungsprogrammierer auch komplexe
Anwendungsvorgange durch die Moglichkeit der Abbildung der PAMELA{
Beschreibung auf eine graphische Petri{Netz{Darstellung durchschaubar�

198 Entwicklung und Ausfuhrung von Kooperationsanwendungen
die Einbettung der in o enen verteilten Systemen etablierten IDL{
Beschreibungen von Diensterbringern, im speziellen der CORBA{IDL zur
De nition von Diensttypen (d. h. Schnittstellentypen, Operationstypen,
Attributtypen und Datentypen),
die Spezi kation von Aktivitatsemantiken, wie beispielsweise synchrone,
asynchrone und transaktionale Ausfuhrung von Aktionen innerhalb von
Aktivitaten� das hierbei verwendete dienstorientierte Aktionskonzept von
PAMELA ist angelehntandas ebenfalls auf der Grundlage gefarbter Petri{
Netze entwickelte LOOPN [Lak92]�
die Darstellung parallel oder sequentiell auszufuhrender Aktionen innerhalb
einer Aktivitat und
die Beschreibung externer, synchroner und asynchroner Benutzerinteraktionen,
die von au en an einen laufenden Anwendungsvorgang herangetragen
werden.
Die IDL{Integration stellt hierbei fur den Sprachentwurf einen wichtigen Aspekt
dar, da soeinhoher Integrationsgrad mit den bereits von DCE und CORBA
angebotenen Dienstbeschreibungskonzepten erreicht werden kann. In PAMELA
spiegelt sichdiesesunmittelbar in der Anlehnung der Sprache an die bereits in
der CORBA{IDL gewahlten syntaktischen Konstrukte wider, die der Programmiersprache
C++ahneln. Dieses betri t sowohl Datentypde nitionen als auch
die Wahl der Kontrollkonstrukte, insbesondere aber die Art des Aufrufs externer
Dienste inForm von Operationen. Die grundlegendeIdee dieser IDL{Integration,
insbesondere der konkret durchgefuhrten Integration der CORBA{IDL, besteht
zum einen darin, eine homogene Basis fur die Beschreibung von Diensten zu
erhalten.Sokonnen in CORBA{IDL verfa te Diensttypbeschreibungen direkt
in PAMELA{Programmen wiederverwendet werden. Zum anderen kann hiermit
auch ausgenutzt werden, da mit Hilfe der IDLs gleichzeitig auch automatisch
Programmkode generiert werden kann, wie es konkret in DCE und CORBA
fur die Generierung von RPC{Programmierkoderumpfen (engl. stubs) zum Aufruf
und zur Entgegennahmeentfernter Prozeduraufrufe verwendet wird. In einer
PAMELA{Beschreibung werden diese IDLs au erdem dazu benutzt, entsprechende
Operationsaufrufe zum Zugri auf den Koordinationsmanager zu generieren,
die Voraussetzung fur eine anschlie ende Anwendungsausfuhrung sind.
Diese Integration vorhandener DienstbeschreibungeninPAMELA und die anschlie
ende Referenzierunginden Aktivititaten eines Anwendungsvorganges mittels
des dienstorientierten Aktionskonzeptes ist eines der wesentlichen Unterschiede
zuvergleichbaren Ansatzen zur Beschreibung von Vorgangen in anderen
Anwendungsbereichen. Beispiele hierfur sind insbesondere die aus dem Umfeld
des Work ow{Managementsund der Transaktionsverarbeitungstammende Aktivitatenbeschreibungssprache
ActSpec [Rei93], die Distributed Operation Language
[HAB + 92] und die im ConTract{Modell [WR91] verwandte De nitionssprache.
Diese ermoglichen jeweils die Beschreibungvon Vorgangen in ahnlicher Form
wie die in dieser Arbeit speziell betrachteten Anwendungsvorgange. Analog zum

6.1 TRADE{Entwicklungsumgebung 199
in dieser Arbeit gewahlten Ansatz werden dort oftmals ebenso zur Reprasentation
von Vorgangen, beispielsweise im ConTract{Modell oder im FlowMark{
System [LR94], Petri{Netz{basierte Modelle verwendet. Eine Einschrankung
aller genannten Ansatze ist jedoch, da sie keine explizite Unterstutzung der
fur Kooperationsanwendungen notwendigen Dienstsicht bieten. Insbesondere die
Dienstauswahl bzw. die Abstraktion von einem konkreten Diensterbringer ndet
bei ihnen keine oder nur eine sehr rudimentare Berucksichtigung. So ist beispielsweise
innerhalb der Distributed Operation Language nur eine Zuweisung
von Diensterbringern zu einem Vorgang vor Beginn seiner Ausfuhrung moglich.
Hierdurch ergibt sich einestarre Struktur der im Anwendungsverlauf genutzten
Diensterbringer, bei der auf Veranderungen, beispielsweise beim Erscheinen neuer
leistungsfahigerer Dienstanbieter, entweder nicht reagiert werden kann oder
der Vorgang erneut unter expliziter Angabe anderer Diensterbringer gestartet
werden mu . Hier weist das in PAMELA umgesetzte dienstorientierte Aktionskonzept
einen wesentlichen Vorteil auf, da eseinen hohen Grad an Flexibilitat
bei der Anwendungsausfuhrung durch Unterstutzungeiner dynamischen Dienstauswahl
gewahrleistet.
Mit den oben beschriebenen Eigenschaften erfullt PAMELA alle in Abschnitt
4.1.2 gestellten Anforderungen zur Beschreibung koordinierter Dienstnutzung
im Rahmen verteilter kooperativer Anwendungen:
Strukturierungskonzept Grundlegende Strukturierungseinheit in PAMELA
sind sogenannte Prozesse. Ein Proze beinhaltet hierbei die gesamte Beschreibung
eines Anwendungsvorganges und kapselt ihn von der Beschreibung
anderer Anwendungsvorgangeab. Letztendlichhandelt essich hierbei
um die unmittelbare textuelle programmiersprachliche Umsetzung des in
Abschnitt 4.2dargestellten erweiterten Petri{Netzes, indem die Elemente
eines Petri{Netzes, d.h. Stellen, Transitionen und Kanten, durch entsprechende
Sprachkonstrukte spezi zierbar sind.
Datenkonzept Die Umsetzung des Datenkonzeptes erfolgt in PAMELA
durch dieVerwendung des Typsystems der CORBA{IDL fur die Typisierung
der im Petri{Netz{Modell enthaltenen Marken. Hierdurch wird
der konkrete Bezug des bisher abstrakten Beschreibungsansatzes zur
TRADE{Systemumgebung und der zugrundeliegenden CORBA{ bzw.
DCE{Systemplattform hergestellt.
Aktions{ und Transaktionskonzept Zur Beschreibung der Dienstnutzung
innerhalbder Aktivitaten eines Anwendungsvorganges bietet PAMELA die
sprachliche Umsetzung des Transitionskonzeptes von Petri{Netzen. Dieses
geschieht inForm des oben bereits genannten dienstorientierten Aktionskonzeptes
(siehe auch Abschnitt 4.2.3.3), das die Spezi kation von Operationsaufrufen
zum Zugri auf die im Rahmen einer Aktivitat bzw. Aktion
genutzten Dienste erlaubt. Die Auswahl eines hierfur gewunschten Dienstangebotes
wird durch die Angabe von quali zierenden Dienstattributen
unterstutzt, die als Grundlage fur die spatere Dienstvermittlung durch den
in der TRADE{Systemumgebung realisierten TRADEr dienen. Durch ent-

200 Entwicklung und Ausfuhrung von Kooperationsanwendungen
sprechende Deklaration einer Aktivitat als transaktional kann auch auf
einfache Weise eine transaktionale Ausfuhrung samtlicher der in ihr durchzufuhrenden
Operationsaufrufe erreicht werden.
Fehlerbehandlungskonzept Die Behandlung von Fehlern bei der Aktivitatsausfuhrung
wird entsprechend der geforderten Ausfuhrungssemantik |
transaktional oder nicht{transaktional | durch eine Deklaration von speziellen
Ausgangsstellen einer Transition erreicht (siehe auch Abschnitt
4.2.3.6).
Kontroll u { und Nebenlau gkeitskonzept Durch die Deklaration von
Stellen, Transitionen, Ein{ und Ausgangskanten und Kantenausdrucken
in einem PAMELA{Proze erfolgt bereits implizit die Darstellung der
Intra{ und Intervorgangsnebenlau gkeit von Anwendungsvorgangen und
den dort ablaufenden Kontroll ussen. Weiterhin ist in PAMELA auch
innerhalb der Aktivitaten eines Anwendungsvorganges die Spezi kation
einer nebenlau gen oder sequentiellen Ausfuhrung von Operationsaufrufen
moglich.
Interaktionskonzept Die Unterstutzung des Interaktionskonzeptes geschieht
in PAMELA mittels ausgezeichneter Transitionen, den sogenannten Task{
Transitionen. Diese ermoglichen die Beschreibung von Benutzerinteraktionen
gema der in Abschnitt 4.2.3.7 festgelegten Ablaufsemantik.
Im einzelnen bietet PAMELA fur jedes der obigen Beschreibungskonzepte eine
entsprechende sprachliche Umsetzung. Im folgenden sollen die Sprachelemente
anhand eines Beispiels informell eingefuhrt und ihre Ausdrucksmoglichkeiten
zur Beschreibung von Anwendungsvorgangen exemplarisch verdeutlicht werden.
Eine detaillierte Darstellung der vollstandigen Syntax von PAMELA und ihrer
Semantik gibt Anhang A.1. In Anhang A.2 ist au erdem ein umfangreiches,
in sich abgeschlossenes PAMELA{Beispiel einer Hotelanwendung dargestellt.
Auf dieses Hotelbeispiel geht Abschnitt 6.1.2.4 noch genauer ein. Weiterhin sei
auch auf [Bri95] und [Gri95] verwiesen, in denen sich neben der Erlauterung von
PAMELA{Sprachkonzepten erganzende Anmerkungen vor allem hinsichtlich der
Implementation des zu PAMELA gehorenden Sprachubersetzers und des Koordinationsmanagers
nden.
6.1.2.3 PAMELA{Beispielspezi kation eines verteilten kooperativen
Anwendungsvorganges
Abbildung 6.1 zeigt eine einfache PAMELA{Spezi kation einer Versicherungsanwendung.
Im Verlaufe des gezeigten Ausschnittes eines Anwendungsvorganges
in einer Versicherung werden mehrere externe Dienste in Anspruch genommen,
wie beispielsweise der eines Sachbearbeiters zur Eingabe von Daten oder
die Nutzung eines Druckers zur Ausfertigung einer Bestatigung fur den Versicherungskunden.
Der Ablauf wird innerhalb eines process{Blocks dargestellt.
Dieser klammert die De nition der Aktivitaten (trans), der Aktivitatsubergange

6.1 TRADE{Entwicklungsumgebung 201
JobPool
cust
userInput
ReadyToCompute
computeBill
module Insurance_Service {
typedef unit_t ...; typedef task_t ...;
struct policy_data_t {
customer_id customer;
name_t name; ...
} ;
readonly attribute unit_t unit;
readonly attribute task_t task;
interface Employee {
Add_Insurance_Data ([inout] policy_data_t customer);
}; //CORBA interface
}; //CORBA module
process PartOfInsurance {
import : service Insurance_Service with Employee;
token job_t {
long job_nr;
Insurance: policy_data_t policy;
};
places : job_t JobPool, ReadyToCompute; ...
trans userInput {
get cust from JobPool;
put cust to ReadyToCompute;
action {
Add_Insurance_Data (cust.policy);
using Employee with {unit = Insurance && task = Billing};
} ...
} } //process
printAck
Abbildung 6.1: Ausschnitt einer PAMELA{Vorgangsbeschreibung
bzw. Stellen (place) und der Marken (token), welche von Aktivitat zu Aktivitat
uber die Aktivitatsubergange weitergegeben werden. Die in der Abbildung
beschriebene Aktivitat userInput entnimmt hierbei eine Marke von dem
Aktivitatsubergang JobPool (get{Anweisung) und fuhrt die Aktion (action)
Add Insurance Data mit den entsprechenden Argumentwerten aus. Nach erfolgreicher
Ausfuhrung der Aktion wird die um die entsprechenden Daten erganzte
Marke anden ReadyToCompute{Aktivititatsubergang weitergereicht (put{
Anweisung), welcher mit der ComputeBill{Aktivitat verbunden ist.
Der Operationsaufruf Add Insurance Data wird quali ziert durch den dazugehorigen
Schnittstellentyp (Employee) und die Dienstattribute (unit =
Insurance && task = Billing), die den gewunschten Dienst genauer spezi
zieren. Der Bezug des Schnittstellentyps zu dem dazugehorigen Diensttyp
(Insurance Service) wird mittels der service{Deklaration innerhalb der

202 Entwicklung und Ausfuhrung von Kooperationsanwendungen
import{Anweisung des process{Blocks angegeben. Hierbei wird die Beziehung
der in der CORBA{IDL de nierten Schnittstelle (interface Employee)
mit der diese Schnittstelle umfassenden CORBA{Modulde nition (module
Insurance Service) hergestellt. Hierbei ndet ein semantisches Uberladen
des CORBA{Modulkonzeptes statt, indem der Modulname als Diensttypname
innerhalb von PAMELA und auch fur die Dienstvermittlung durchden TRADEr
verwendet wird. 3
Je nach De nition der Aktivitat konnen prinzipiell auch mehrere Aktionen sequentiell
bzw. parallel (durch hier nichtdargestellte par{und seq{Anweisungen)
bei einem oder jeweils fur jede Aktion separat spezi zierten Diensterbringer
ausgefuhrt werden. Dieses wird durch entsprechende Schachtelung der using{
und action{Anweisungen erreicht. Sollen innerhalb eines Anwendungsvorganges
Aktionen, die innerhalb verschiedener Aktivitaten auftreten, bei demselben
Diensterbringer ausgefuhrt werden, so mu dieses explizit durch die entsprechende
Wahl der quali zierenden Dienstattribute ausgedruckt werden. Hiermit
wird ein Halten von Diensterbringerbindungen uber mehrere Aktivitaten hinweg
erreicht.
Im Gegensatz zu den durch Dienstaufrufe initiierten externen Eingaben, beispielsweise
durch die obige userInput{Aktivitat, erlauben sogenannte Task{
Transitionen externe Eingaben in den Anwendungsvorgang unabhangig von seinem
konkreten Abarbeitungszustand. Sie sind Bestandteil des in Abschnitt 4.1.2
geforderten Interaktionskonzeptes. In Bezug auf das Versicherungsbeispiel konnte
eine Task{Transition dispatchJobs existieren, die asynchron neue Token bzw.
Auftrage durch eineentsprechende Benutzereingabe in den durch JobPool spezi
zierten Aktivitatsubergang einfugt.
Die Spezi kation einer Aktivitat als transaktional ([transactional] trans)
garantiert die Ausfuhrung der spezi zierten Aktionen gema der bekannten
ACID{Transaktionseigenschaften [GR93]. So lassen sich mehrere Aktionen zu
einer Transaktion zusammenfassen, wobei je nach Ausgang der Transaktion
(commit{oder abort{Anweisung) entsprechendeVerknupfungen zu anwendungsspezi
schen Aktivitatsubergangen de niert werden mussen. Ahnlich der beiden
commit{ oder abort{Ausgange einer Transaktion lassen sich fur jede Aktivitat
mittels einer error{Anweisung aktionsspezi sche Fehler behandeln. Dieses
betri t jedoch nur die mit der Dienstnutzung verbundenen Fehlerfalle, wie
beispielsweise das Nichtvorhandensein eines geeigneten Diensterbringers. Fehlerfalle
aufgrund anwendungsspezi scher Resultatauswertungen eines Dienstaufrufes
mussen von Anwendungsprogrammierer beim Entwurf eines Anwendungsvorganges
explizit beschrieben werden. Abbildung A.9 in Anhang A.1.1 gibt eine
zusammenfassende Ubersicht uber die generelle Struktur einer PAMELA{
Beschreibung, die auch dem obigen Versicherungsbeispiel unterliegt.
3 Diese Art der Diensttypbeschreibung stellt einealternative Methode zuder in Abschnitt
5.1.1 beschriebenen dar. Sie bietet jedoch dieselbe Ausdrucksmachtigkeit.

6.1 TRADE{Entwicklungsumgebung 203
6.1.2.4 Sichtweisen der Anwendungsprogrammierung mitPAMELA
Im folgenden werden zwei Anwendungsbeispiele skizziert, die jeweils eine bestimmte
Sichtweise auf die Nutzung von Diensten in TRADE verdeutlichen. Beide
Anwendungen, in denen sich zumeinen eine Work ow{orientierte und zum
anderen eine komponentenorientierte Programmiersichtweise widerspiegelt, sind
vollstandig in PAMELA beschrieben und innerhalb der realisierten TRADE{
Systemumgebung ablau ahig [Bri95, Gri95]. Sie sind als Testanwendungen konzipiert,
mit deren Hilfe das Zusammenspiel der verschiedenen Systemmechanismen
von TRADE integriert evaluiert werden kann. Zudem ermoglichen sie Aussagen
uber die Anwendbarkeit und Praktikabilitat von PAMELA, insbesondere
daruber, ob sie die in dieser Arbeit verfolgte Zielstellung der einfachen Wiederverwendbarkeit
und Kombination von vorhandenen Diensten zu neuen Kooperationsanwendungen
erfullen kann.
Vorgangsbeschreibungen
Das erste Anwendungsbeispiel entstammt dem Bereich des Work ow{
Managements. Diese Anwendung simuliert ein rudimentares Hotelmanagementsystem,
in dem Dienste, wie beispielsweise der Zimmerdienst, Abrechnungsdienste,
Kreditkartenbetreuung und der Empfang sowie der " Checkout\
von Gasten, koordiniert werden. Wesentliches Merkmal dieser Anwendung ist
eine vorgangsorientierte Sichtweise. Hierbei wird die Verwaltung eines Gastes
im Hotel als ein Vorgang verstanden, dessen Verlauf durch ein bestimmtes
Handlungsmuster vorgegeben ist. Im Rahmen dieses Vorganges werden verschiedene
Aktivitaten durchgefuhrt, die wiederum den Ansto weiterer Aktivitaten
verursachen konnen. Letztendlich gliedern sie sich in einzelne Aktionen auf, in
denen letztendlich die eigentliche Nutzung der oben genannten Dienste erfolgt.
Abbildung 6.2 zeigt die Hotelanwendung mittels der in Abschnitt 4.2 fur Anwendungsvorgange
eingefuhrten Petri{Netz{Notation. Die Abbildung verdeutlicht
die moglichen Anwendungsablaufe in der Hotelanwendung. Aus Grunden der
Ubersichtlichkeit ist dabei auf die Angabe von Kantenbedingungen zwischen den
Transitionen und die Typsierung von Stellen verzichtet worden. An dieser Stelle
sei auf den Anhang A.2verwiesen, in dem die vollstandige textuelle PAMELA{
Beschreibung der Hotelanwendung zu nden ist. Anhang A.2.1 zeigt in der
Abbildung A.13 au erdem die graphische Benutzerschnittstelle der Hotelanwendung
im Zusammenhang mit der Darstellung der Administrationsschnittstelle
des Koordinationsmanagers. Mit diesen graphischen Endanwendungen konnen
dann Benutzereingaben an den in Abbildung 6.2 gezeigten Anwendungsvorgang
ubergeben werden.
Grundsatzlich spielt es bei der Spezi kation der Anwendungsvorgange keine Rolle,
auf welcher der beiden unterliegenden verteilten Systemplattformen die in
der Anwendung genutzten Dienste realisiert sind. Die Verwendung sowohl von
CORBA{ als auch DCE{Diensten geschieht auf einheitliche Weise mittels den in
der erweiterten CORBA{IDL (siehe auch Abschnitt 5.1.1) spezi zierten Diensttypbeschreibungen.
Diese lassen sichnahtlos in die PAMELA{Beschreibung ein-

204 Entwicklung und Ausfuhrung von Kooperationsanwendungen
arrival
HOTEL
initAcc checkCard
notify
ACCOUNTING
I
initialize
T
abort
abort
checkIn
commit
checkOut chargeCard
print printBill
rooms
notifyManager
taxReturn payTax
binden.
departure
commit
abort
commit
charge
notify
T
abort
guests
getBalance
commit
T
pay
abort
commit
processOrder
order
notify
deliver
notifyStaff
printBill
notify
notifyManager
deliverY
deliverX
error
deliver
deliver
handleError
Abbildung 6.2: Vergroberte Petri{Netz{Darstellung des Hotelbeispiels
Eine Einschrankung der in PAMELA gebotenen Dienstabstraktion bildet die
Nutzung transaktionaler Dienste, da das fur ihre Realisierung verwendete
Encina{Toolkit [IBM93] derzeit nur fur die DCE{Umgebung zur Verfugung
steht. Dieses betri t in dem Hotelbeispiel vor allem die fur die Rechnungsabwicklung
erforderlichen Kreditkartendienste, die realistischerweise innerhalb
von transaktional gesicherten Anwendungsvorgangen spezi ziert sind. An dieser
Stelle ist somit ein gewisses Vorwissen des Anwendungsentwicklers uber die
Art des gewunschten Dienstes notwendig. Hilfestellung fur die Gewinnung dieser
Informationen erfahrt er in TRADE durch durch den Typmanager und seine
in Abschnitt 5.1.2 vorgestellte graphische Benutzerschnittstelle, mit deren Hilfe
Diensttypbeschreibungen gesucht und angezeigt werden konnen.
Komponentenbeschreibungen
Das zweite Beispiel veranschaulichteineSichtweise von Dienstnutzung ino enen
verteilten Dienstemarkten, bei der die vorhandenen Diensteauf einfacheWeise im
Rahmen einer komponentenbasierten Software{Entwicklung [GML96] zuneuen
Kooperationsanwendungen zusammengefugt werden konnen. Erreicht wird dieses
in TRADE durch dieUnterstutzung des Anwendungsprogrammiers mittels
einer einfachen Art von visueller Programmierung, die ein schnelles Austesten
notify

6.1 TRADE{Entwicklungsumgebung 205
von neu entwickelten Diensten erlaubt. Hierzu lassen sich inPAMELA spezi -
zierte Anwendungsablaufe, wie beispielsweise der fur den in der Abbildung 6.3
gezeigten Taschenrechner, zusammen mit einer zusatzlichen Spezi kation ihrer
graphischen Benutzerschnittstelle in einen sogenannten Application Builder |
in der Abbildung unten erkennbar | laden. 4
Abbildung 6.3: Der Application Builder aus Benutzersicht
Dort konnen dann anschlie end einzelne Dienstangebote aus der CORBA{
oder DCE{Domane, die jeweils durch ein Ober achenelement im sogenannten
Dienstangebots{Pool des Interzeptors (unten links) reprasentiert werden, durch
ein " drag & drop\{Verfahren fur die Realisierung des Taschenrechners genutzt
werden. Auf diese Weise lassen sich die Tasten des Taschenrechners mit Diensten
hinterlegen, die jeweils die Grundrechenarten zur Verfugung stellen. Durch Ansteuerung
des Koordinationsmanagers, der in der obigen Abbildung rechts unten
angedeutet ist, ist anschlie end das Austesten des Zusammenspiels der im Rahmen
der Taschenrechneranwendung genutzten Einzelkomponenten moglich. Bei
Bedarf konnen Dienste auch zur Laufzeit durch einfaches " drag & drop\ ausgetauscht
werden. Ebenso wie im obigen Hotelbeispiel spielt esdurch die Einbeziehung
des Interzeptors generell keine Rolle, ob hierfur DCE{ oder CORBA{
basierte Dienstangebote genutzt werden.
4 Der Application Builder ist Bestandteil der graphischen Benutzerschnittstelle des in TRA-
DE realisierten Interzeptors (siehe auch Abbildung 5.17).

206 Entwicklung und Ausfuhrung von Kooperationsanwendungen
6.2 Ablaufkontrolle
Die im vorherigen Abschnitt beschriebeneVerwendungvon PAMELA ermoglicht
die Spezi kation von verteilten Anwendungen unter ausschlie licher Nutzung extern
angebotener Dienste. Samtlicheinden Anwendungsvorgangen zu erbringende
Teilaufgaben und deren Verarbeitung sinddabei in externe Dienste ausgelagert.
Um diese in PAMELA spezi zierten Anwendungsvorgange nun ineiner
konkreten Systemumgebungausfuhren zu konnen, mussen sie in eineablau ahige
Form uberfuhrt werden. Diese Aufgabe wird in der Regel durch eigenstandige,
einem spezi schen Anwendungsvorgang zugeordnete Klientenanwendungen (siehe
Abschnitt 4.1.1) ubernommen. Als Konsequenz aus der Art und Weise der
Programmierung mit PAMELA beschrankt sich hierbei im Vergleich zur heute
ublichen Programmierung jedoch die Aufgabe der Klientenanwendung, die
bisher neben dem Aufruf der einzelnen Dienste nochselbst wesentliche Teile
der anwendungsspezi schen Verarbeitung realisiert, nur noch auf die Steuerung
und Uberwachungder Koordination der genutzten Dienste und die Verarbeitung
von Benutzerinteraktionen. Hierdurch verandert sich fur den Anwendungsprogrammierer
nicht nur der eigentliche Anwendungsentwurf und seine Programmierung
| wie es konkret am Beispiel von PAMELA gezeigt wurde | sondern
es ergeben sich fur ihn gleichzeitig auch erweiterte Moglichkeiten der Anwendungsausfuhrung.
Dieses au ert sich vor allem darin, da sich aufgrund der
Beschrankung einer Klientenanwendung auf koordinative Aspekte nun zumAblauf
von Anwendungsvorgangen dedizierte, generische Koordinationsdienste entwickeln
lassen, welche die Kontrollfunktionen fur eine Vielzahl verschiedener
Klientenanwendungen stellvertretend ubernehmen.
Der vorliegende Abschnitt verdeutlicht anhand des in der TRADE{Systemumgebung
entwickelten und konkret realisierten Koordinationsmanagers diese Vorgehensweise.
Dieser bietet einen dementsprechenden generischen Ablaufkontroll{
bzw. Koordinationsdienst, welcher die Ausfuhrung von in PAMELA spezi zierten
Anwendungsvorgangen steuert und uberwacht. Er bildet als Komponente
der Ausfuhrungsumgebung neben dem Typmanager, TRADEr und Interzeptor
einen der Basisdienste von TRADE. Zunachst wird im folgenden die Rolle des
Koordinationsmanagersinder TRADE{Systemumgebungbeschrieben und seine
grundlegenden Aufgaben vorgestellt. Hierauf aufsetzend beschreiben die nachfolgenden
Abschnitte genauere Details seiner Konzeption und Realisierung. Hierbei
wird auch der enge Bezug zum inAbschnitt 4.2 vorgestellten Petri{Netz{
basierten Modell von Kooperationsanwendungen deutlich, das die Grundlage fur
den Entwurf der Steuerungsmechanismen im Koordinationsmanager bildet.
6.2.1 Einordnung des Koordinationsmanagers in TRADE
Abbildung 6.4 gibt einen Uberblick uber die grobe Konzeption des Koordinationsmanagers
und seine Beziehungen zu den sonstigen in der TRADE{
Systemumgebung vorhandenen Basisdiensten. Die Abbildung zeigt eine verfeinerte
Darstellung der bereits inAbbildung 4.13 gezeigten Grundstruktur von

6.2 Ablaufkontrolle 207
PAMELA-
Sprachübersetzer
Entwicklungsumgebung
PAMELA-
Beschreibung
Diensttypbeschreibung
Typmanager
Koordinationsmanagerklient
Definition
Import
TRADEr
Ausführungsumgebung
Administration Ausführung
Koordinationsmanager
DCE-Dienst
Transaktionaler DCE-Dienst
CORBA-Dienst
Interzeptor
DCE-
DII
Encina-
DII
Abbildung 6.4: Architektur und Beziehungen des Koordinationsmanagers
TRADE, in der grob eine Entwicklungs{ und eineAusfuhrungsumgebung unterschieden
wurden. Auf der linken Seite, der Entwicklungsumgebung von TRA-
DE, sind die Details der Verarbeitung von PAMELA{Beschreibungen verdeutlicht.
Dort existiert ein PAMELA{Sprachubersetzer [Gri95], dessen Hauptaufgabe
die Generierung von Programmkode zumAufruf des Koordinationsmanagers
ist. Dieser Programmkode wird anschlie end mit Hilfe eines herkommlichen C{
Sprachubersetzers zu einem lau ahigen Programm,dem sogenannten Koordinationsmanagerklienten,
ubersetzt. Dieser fuhrt letztendlich inder Ausfuhrungsumgebung
von TRADE die konkreten Operationsaufrufe ander De nitionsschnittstelle
des Koordinationsmanagers durch. Diese Schnittstelle ist eine von
insgesamt drei, nach funktionalen Kriterien getrennten DCE{Schnittstellen. Sie
werden in den nachfolgenden Abschnitten noch genauer beschrieben. Eine andere
Verknupfung der Entwicklungs{ und Ausfuhrungsumgebung wirdneben dem
PAMELA{Sprachubersetzer durch den in Abschnitt 5.1beschriebenen Typmanager
realisiert. Dieser verwaltet die Diensttypbeschreibungen, die in PAMELA{
Beschreibungen beliebig integriert werden konnen. Sie dienen jedoch gleichzeitig
auch zumAu nden diensttypkonformer Dienstangebote imRahmen der gestaffelten
Dienstauswahl des TRADErs.
Im Verlaufe der Abarbeitung eines vorher registrierten Anwendungsvorganges
nutzt der Koordinationsmanager den TRADEr zum Au nden geeigneter
Dienstanbieter. Der TRADEr verwaltet hierbei zum einen die innerhalb von
DCE angebotenen und realisierten Dienste. Diese konnen auch eine transaktionale
Ausfuhrungssemantik besitzen, wobei im Unterschied zu herkommlichen
DCE-
DII

208 Entwicklung und Ausfuhrung von Kooperationsanwendungen
DCE{Diensten der Zugri uber ein spezielles transaktionales Dynamic Invocation
Interface durchgefuhrt wird, welches mit Hilfe des auf DCE aufsetzenden
Encina{Toolkit [IBM93] realisiert ist [Bri95] (siehe auch Abschnitt 6.2.3.2).Zum
anderen verwaltet der TRADEr die in der CORBA{Domane angebotenen Dienste,
die in der DCE{DomaneinForm von durchden Interzeptor generierten Proxies
erscheinen (siehe Abschnitt 5.3.3). Diese sind ebenso wie die herkommlichen
DCE{Dienste uber ein auf dem DCE{RPC aufsetzendes Dynamic Invocation
Interface zugreifbar, so da fur den Koordinationsmanager prinzipiell kein Unterschied
beim Zugri auf DCE{ oder CORBA{Dienste erkennbar ist. Einziges
Problem beim Aufruf von CORBA{Diensten ist ihre derzeit noch fehlende Einbindung
in transaktionale Aktivitaten. Hierfur existiert in CORBA noch keine
adaquate Systemunterstutzung, die vergleichbar zu dem auf DCE{Seite genutzten
Encina{Toolkit ist.
6.2.2 Schnittstellen des Koordinationsmanagers
Zum Zugri auf seine Funktionen bietet der Koordinationsmanager den Klienten
drei verschiedene Schnittstellen an (Abbildung 6.4). Diese sind nach funktionalen
Kriterien getrennt und ermoglichen so einen dedizierten Zugang zu dort
angebotenen, modular abgrenzbaren Teilfunktionen des Koordinationsmanagers.
6.2.2.1 De nitionsschnittstelle
Die De nitionsschnittstelle 5 ermoglicht die Registration von Anwendungsvorgangen,
um diese anschlie end durch den Koordinationsmanager ausfuhren
zu lassen. Grundidee der hierzu vom Koordinationsmanager angebotenen
Operationen ist ihre Anlehnung an die den Anwendungsvorgangen unterliegende
Petri{Netz{Darstellung. So wird ein Anwendungsvorgang in Form
von Stellen, Transitionen und Kanten als dynamisches Objekt innerhalb des
Koordinationsmanagers erzeugt. Zusatzlich werden die Transitionen mit den
dazugehorigen Dienstaufrufen verbunden und die Kanten um die de nierten
Kantenbedingungen erganzt. Wesentliche von der De nitionsschnittstelle
angebotene Operationen sind:
createNet erzeugt eine neue Netzreprasentation
createTransition erzeugt ein neue Transition
createPlace erzeugt ein neue Stelle
createInputArc stellt eine Eingangskantenbeziehung her
createOutputArc stellt eineAusgangskantenbeziehung her
addService verknupft eine Transition mit einem Dienst
modifyToken erlaubt eine Operation auf einer Marke
Prinzipiell sind diese Operationen auch direkt bei der Programmierung von
Klientenanwendungen nutzbar. Generell sollte hierauf jedoch aus Grunden der
Komplexitat verzichtet werden. Diese Komplexitat, die sich bereits schon bei
5 Die vollstandige, in DCE{IDL beschriebene Schnittstelle ndet sich inAnhang E.

6.2 Ablaufkontrolle 209
vergleichsweise kleinen Anwendungsvorgangen zeigt, wird in Anhang E.2 am
Beispiel des vom PAMELA{Sprachubersetzer generierten De nitionskodes deutlich.
Statt der direkten Verwendung der Operationen der De nitionsschnittstelle
sollte deshalb im allgemeinen der ubliche und komfortablere Weg uber die Generierung
des Koordinationsmanagerklienten aus einer PAMELA{Beschreibung
gewahlt werden. Zudem ermoglicht der PAMELA{Sprachubersetzer bereits vor
dem Ausfuhrungszeitpunkt die Uberprufung der Typkonformitat zwischen Stellen
und der auf ihnen abgelegten Marken sowie von Dienstaufrufen und den ihnen
zugeordneten Parametern.
6.2.2.2 Administrationsschnittstelle
Die Administrationsschnittstelle stellt Operationen zur Verfugung, mit denen
sich Anwendungsvorgange sowohl steuern als auch manipulieren lassen:
startNet aktiviert einen Anwendungsvorgang
stopNet deaktiviert einen Anwendungsvorgang
suspendTransition suspendiert eine Transition vorubergehend
resumeTransition reaktiviert eine supendierte Transition
stopTransition deaktiviert eine Transition dauerhaft
Durch die Kombination mit den an der De nitionsschnittstelle angebotenen Operationen
kann prinzipiell zur Laufzeit die statische Netzstruktur und damit das
Netzverhalten geandert werden. So kann beispielsweise eine fehlerhafte Transition
durch stopTransition deaktiviert werden und durch eineneue Transition
uber createTransition ersetzt werden. Die Administrationsschnittstelle umfa
t weiterhin auch Operationen zur Abfrage des statischen Netzzustandes und
zur Ermittlung des aktuellen Markierung des Netzes:
getNets liefert die registrierten Netze
getTransitions liefert die Transitionen eines Netzes
getPlaces liefert die Stellen sowie ihre momentane Markierung
getInputPlaces liefert die Eingangsstellen einer Transition
getOutputPlaces liefert die Ausgangsstellen einer Transition
Die Nutzung samtlicher Administrationsoperationen wird durch ein graphisches
Administrationswerkzeug unterstutzt (Abbildung 6.5), welches auch die vom Koordinationsmanager
wahrend der Ausfuhrung eines Anwendungsvorganges erzeugten
Kontrollinformationen darstellt.
6.2.2.3 Ausfuhrungsschnittstelle
Mit Hilfe der vom Koordinationsmanager angebotenen Ausfuhrungsschnittstelle
kann der externeBenutzer auf das Verhalten eines Anwendungsvorganges einwirken.
Die Realisierung dieses Interaktionskonzeptes (sieheauch Abschnitt 4.2.3.7)
geschieht mittels der Operation putToken, mit der Marken auf ausgezeichnete
Stellen des Petri{Netzes gelegt werden konnen. Die Ubergabe der Marken
erfolgt dabei unter Nutzung von Teilen der in Abschnitt 5.1.3 und Anhang B

210 Entwicklung und Ausfuhrung von Kooperationsanwendungen
Abbildung 6.5: Graphische Administrationsschnittstelle des Koordinationsmanagers
vorgestellten Diensttypreprasentation. Diese ist nicht nur zum Austausch von
Typinformationen geeignet, sondern ermoglicht gleichzeitig auch den Transport
von Datenwerten. Zur Gewahrleistung der Typsicherheit der Benutzereingabe
fuhrt der Koordinationsmanager zusatzlich eineTypvergleich mit dem der Stelle
zugeordneten Markentyp durch.
6.2.3 Steuerung von Anwendungsvorgangen
Aufgrund der in Petri{Netzen inharent gegebenen Integration von Struktur und
Verhalten, bei der die statische Netzbeschreibung gleichzeitig auch ihr dynamisches
Verhalten festlegt, bietet sich bei der Realisierung von Steuerungskomponenten
an, die Schaltsemantik von Petri{Netzen auch als Grundlage fur die
Ausfuhrung von Anwendungsvorgangen zu verwenden. Diese Idee lag bereits
schon den in den vorherigen Abschnitten vorgestellten Schnittstellen des Koordinationsmanagers
zugrunde. Hierdurch la t sich der durch Abbildungsprobleme
hervorgerufenekonzeptionelle Bruch zwischen Modellierung und Ausfuhrungvon
Anwendungsvorgangen vermeiden.

6.2 Ablaufkontrolle 211
6.2.3.1 Objektorientierte Umsetzung von Petri{Netzen
Grundlage fur samtliche Steuerungs{ und Kontrollmechanismen im Koordinationsmanager
bildet die Abbildung von Petri{Netzen in eine systemtechnisch verarbeitbare
Datenstruktur. Um hier einen maximalen Grad an Wiederverwendbarkeit
und Orthogonalitat ihrer Nutzung zu erreichen, wird fur ihre Implementation
ein objektorientierter Ansatz gewahlt, welcher eine unmittelbare Reprasentation
der Elementeeines Petri{Netzes durchentsprechende Objektklassen
erlaubt. In der Implementation des Koordinationsmanagers existiert dementsprechend
fur jedes Petri{Netz{Element jeweils eine eigene Objektklasse, die durch
Assoziations{ und Vererbungsbeziehungen mit anderen Klassen verknupft ist.
Die einzelnen Objektklassen sind inAbbildung 6.6 verdeutlicht, wobei die Darstellung
die in der Object Modeling Technique [RBP + 91] angebotenen Beschreibungsmittel
nutzt.
class
Place
class
OutputArc
class
Token
class
Net
class
Arc
class class
Transition Service
class
InputArc
class
Expression
Legende
Vererbung
m:1 Beziehung
optionale Beziehung
Abbildung 6.6: Objektorientierte Modellierung eines Petri{Netzes
Netze (class Net): Auf oberster Ebene des Objektmodells be nden sich die
Petri{Netze selbst, die als ubergeordnete Objektesamtliche weiteren Objekte
eines Petri{Netzes beinhalten.
Die Einfuhrung dieser Klasse dient vor allem zur parallelen Verwaltung
mehrerer Netze, die jeweils eine eigene Struktur und einunabhangiges
Verhalten besitzen. Sie stellt samtliche Methoden zum Aufbau von Netzen
uber die De nitionsschnittstelle, zur Uberwachung und Kontrolle uber
die Administrationsschnittstelle und zur Benutzerinteraktion bereit. Samtliche
Methoden spiegeln sich unmittelbar an der DCE{Schnittstelle des
Koordinationsmanagers wider.

212 Entwicklung und Ausfuhrung von Kooperationsanwendungen
Stellen (class Place): Die Klasse der Stellen realisiert ein passives, typisiertes
Speicherobjekt fur Objekte der Klasse Token. Die von ihr angebotenen
Methoden unfassen das Ablegen und Entfernen der Marken, wobei diese
die Typvertraglichkeit zwischen dem Stellentyp undden abgelegten Marken
uberprufen. Da auf einzelne Stellen durch mehrere verschiedene Transitionen
des Petri{Netzes nebenlau g zugegri en werden kann, realisieren die
Methoden weiterhin auch konsistenzsichernde Synchronisationsfunktionen,
die auf Semaphoren aufsetzen. Des weiteren existieren Methoden, mit denen
eine Stelle mit Eingangs- und Ausgangskanten verknupft werden kann.
Transitionen (class Transition): Die aktiven Objekte innerhalb eines
Petri{Netzes sind die Transitionen. Sie sind mit den Objekten der
Klasse Service assoziiert, die die wahrend einer Aktivitat auszufuhrenden
Dienstaufrufe reprasentieren. Durch Nutzung von DCE{Threads
[OSF93a] konnten die Transitionen als aktive Objekte realisiert werden,
die selbstandig ihre Aktivierung uberwachen und ihr Schalten auslosen.
Hierdurch konnte auf die Realisierung einer ubergeordneten und zentralen
Kontrollkomponente fur Transitionen (engl. transition scheduler)
verzichtet werden.
Kanten (class Arc): Die Klasse der Kanten dient primar zur besseren Modularisierung
des Objektmodells. Samtliche von ihr angebotenen Methoden
sind durch Vererbung auch in den Klassen InputArc und OutputArc
verfugbar. Neben den Uberprufungsmethoden fur Kantenbedingungen
stellt sie dem Anwendungsprogrammierer Methoden bereit, welche die
Transitionen mit den Stellen eines Petri{Netzes verknupfen.
Marken (class Token): Marken sind typisierte und sichselbst beschreibende
Datenobjekte, die zwischen den Stellen uber die Transitionen bewegt
werden. Sie reprasentieren die veranderbaren Nutz{ und Steuerdaten, die
von Aktivitat zu Aktivitat ubermittelt werden und die durch ihre konkrete
Wertbelegung den Ablauf bzw. das Schaltverhalten eines Petri{Netzes beein
ussen. Im wesentlichen realisieren MarkenobjekteMethoden zum Auslesen
und zum Setzen der Datenwerte sowie zum Ubertragen der Datenwerte
bei Operationsaufrufen an die Diensterbringer.
Ausdrucke (class Expression): Die Klasse der Ausdrucke stellt Methoden
zur De nition und Auswertung logischer Ausdrucke bereit, die fur die Bearbeitung
der Kantenbedingungen benotigt werden. Weiterhin werden die
Ausdrucke auch dazu verwandt, um die Dienstattribute fur die Auswahl
geeigneter Dienstangebote beim TRADEr zu spezi zieren.
Dienste (class Service): Fur die Verknupfung des Koordinationsmanagers
mit der TRADE{Ausfuhrungsumgebung spielt die Klasse der Dienste eine
wichtige Rolle. Sie realisiert zum einen die Interaktion mit dem TRADEr,
der die benotigten Diensterbringer entsprechend der geforderten Eigenschaften
vermittelt. Zumanderen steuert sie die Durchfuhrungder anschlieenden
Operationsaufrufe bei den DCE{Dienstanbietern bzw. den vom Interzeptor
generierten Proxies, wobei erstere je nach Semantik entweder in

6.2 Ablaufkontrolle 213
herkommlicher Weise oder transaktional erfolgen konnen. Sie ermoglicht
hierbei auch die nebenlau ge Ausfuhrungverschiedener Operationsaufrufe,
indem sie jedem Operationsaufruf einem eigenen Thread zuordnet, der in
geeigneter Weise mit den anderen Threads sychronisiert wird. Diese werden
dann je nachAnwendungsspezi kation beliebig sequentiell oder parallel
und unter Umstanden sogar rekursiv ausgefuhrt.
6.2.3.2 Steuerungsalgorithmen
Im folgenden wird exemplarisch gezeigt, wie geeignete Steuerungsalgorithmen
im Koordinationsmanager realisiert werden konnen. Sie unterstutzen die in
Petri{Netzen inharent gegebene Nebenlau gkeit des Schaltens von Transitionen
bzw. | im Kontext von Kooperationsanwendungen | der Ausfuhrung
von Aktivitaten unter Gewahrleistung von Verklemmungsfreiheit und maximaler
Nebenlau gkeit. Systemtechnische Grundlage hierfur bildet die uber die Denitionsschnittstelle
des Koordinationsmanagers aufgebaute interne Petri{Netz{
Reprasentation von Anwendungsvorgangen, die intern mit Hilfe der im vorherigen
Abschnitt beschriebenen Programmierklassen realisiert ist. In der Implementation
des Vorgangsverwalters kann ein hoher Grad an nebenlau ger Aktivitatsausfuhrung
durch die Verwendung des Thread-Konzeptes erreicht werden,
indem die auf Programmiersprachebene angebotene Transitionsausfuhrungsmethode
Transition::run fur jedeTransition einen eigenstandigen Thread kreiert.
Der dieser Methode zugrundeliegende Algorithmus ist im Koordinationsmanager
realisiert worden und inAbbildung 6.7 und inder nachfolgend erlauterten Abbildung
6.8 graphisch dargestellt. Die Ausfuhrung der Transitionen ndet dabei
generell in Form einer Schleife statt, die durchdas Ablaufprinzip Ereignis, Bedingung,
Handlung (engl. event, condition, action | ECA) [DHL90] charakterisiert
ist. Durch das Ereignis der Ablage einer Markeauf der Eingangsstelle einer Transition
wird diese programmtechnisch aktiviert, worauf sie ihre Schaltbedingungen
uberpruft und gegebenenfalls die mit ihr verknupften entfernten Dienste aufruft.
Bei der nebenlau gen Ausfuhrung der Transitionen sind insbesondere Konkurrenzsituationen
beim Zugri auf die Marken der Eingangsstellen der Transitionen
zu berucksichtigen. Um hier eine konsistente Vorgehensweise zu realisieren,
mussen die Stellen programmiertechnischdurch Semaphore geschutzt werden. So
kann auf eine Stelle nur dann zugegri en werden, wenn die Transition eine exklusive
Sperre auf die Stelle besitzt. Da dieses nebenlau g zu allen anderen Transitionen
geschieht, besteht beim Erwerb mehrerer Sperren zu verschieden Stellen
das Risikovon Verklemmungen (engl. deadlock), die durch zyklische Wartebeziehungen
zwischen den Transitionen entstehen. Um dieses zu vermeiden wird eine
Strategie zur Verklemmungsvorbeugung (engl. deadlock prevention) eingesetzt,
die auf dem Konzept der Vorbelegung (engl. preclaiming) beruht (siehe hierzu
auch [PS85]). Jede Transition strebt hierbei zunachst den Erwerb von Sperren
auf allen Eingangsstellen an. Tritt ein Kon ikt auf, da eineStelle bereits durch
eine andere Transition vorbelegt ist, so werden alle erworbenen Sperren freigegeben,
so da Wartebeziehungen prinzipiell nicht auftreten konnen. Anschlie end
wiederholt die Transition den Sperrvorgang von neuem (siehe Abbildung 6.7).

214 Entwicklung und Ausfuhrung von Kooperationsanwendungen
Transition::
run()
Erwerb von
Sperren auf alle
Eingangsstellen
erfolgreich
ja
Test der
Kantenbedingungen
erfolgreich
ja
Erzeugung
einer neuen
Transitionsinstanz
Freigabe aller
bestehenden Sperren
Freigabe aller
bestehenden Sperren
Entfernen der
Marken von
Eingangstellen
Transitionsresultat
Sperrerwerb
auf Ausgangsstellen
auf Ausgangsstellen
für Commit für Abort
Ablage
der Marken
auf Ausgangsstellen
nein
nein
commit
nein
erfolgreich
Signal durch
parallelen Thread
abort error
Reaktivierung
des Threads
Suspendierung
des Threads
Service::
invokeAll()
Sperrerwerb Sperrerwerb
ja
Freigabe
bestehender Sperren
auf Ausgangsstellen
für Fehler
Freigabe von
Datenstrukturen
Thread-Beendigung
Abbildung 6.7: Algorithmus fur die Ausfuhrung einer Transition
Sind alle gewunschten Sperren erworben, so werden die Kantenbedingungen im
Kontext der auf den jeweiligen Stellen vorhandenen Marken ausgewertet.Indem
Fall, wenn alle Kantenbedingungen zu wahr evaluieren, wird die Transition anschlie
end geschaltet. Evaluiert jedoch eineder Kantenbedingungen zu falsch
oder sind auf einer Stelle eventuell gar keine Marken vorhanden, so ist die Transition
nicht aktiviert und kann somit auch nicht geschaltet werden. Alle auf
die Stellen gehaltenen Sperren werden in diesem Fall freigegeben, um anderen
Transitionen den Zugri zu ermoglichen. Sind jedoch alle Bedingungen an den
Eingangskanten erfullt, werden die ausgewahlten Marken von den Eingangsstellen
entfernt und die Sperren freigegeben. Um ein nebenlau ges Schalten der-

6.2 Ablaufkontrolle 215
selben Transition zu ermoglichen, erzeugt die Transition vor der weiteren Verarbeitung
zunachst einen weiteren Thread, der als neue Transitionsinstanz die
Methode Transition::run ausfuhrt. Hierdurch wird erreicht, da eine Transition
bei Belegung ihrer Eingangsstellen mit mehreren Marken nebenlau g zu
sich selbst schalten kann. Diese Eigenschaft wurde inAbschnitt 4.2.3.4 als Intravorgangsnebenlau
gkeit bezeichnet. Beim Schalten der Transition wird entweder
die Methode Service::invokeAll fur nicht{transaktionale Transitionen oder
die Methode Service::invokeTopTransaction fur transaktionale Transitionen
aufgerufen (Abbildung 6.8).
Service::
invokeAll() bzw.
invokeTopTrans()
transaktional:
beginTran()
weitere
sequentielle
Dienste
ja
Erzeugung
eines neuen
Threads
Service::
invoke()
weitere
parallele
Dienste
nein
Warten auf
Terminierung
paralleler Threads
Dienstresultat
commit
nein
ja
abort/
error
transaktional:
commitTran()
return
commit
return
abort/error
transaktional:
abortTran()
Service::
invoke()
Bereitstellung
der Parameter
aus Markenwerten
Ermittlung
eines
Diensterbringers
Dienst
vorhanden
ja
Dienstaufruf
mit Parametern
Ergebnisüberprüfung
Fehler
ja
return
error
nein
nein
TRADEr
importOffer()
return
error
Dienst
invokeService()
invokeTran()
return
commit
Abbildung 6.8: Algorithmus fur den Aufruf von Operationen innerhalb einer
Transition
Der Algorithmus transaktional geschutzter Transitionen mit mehreren Dienstaufrufen
wird fur den Fall der Nutzung von DCE{Diensten mittels der vom
Encina{Toolkit [IBM93] angebotenen Funktionen realisiert, welche die atomare
Ausfuhrung aller innerhalb einer Transition ausgefuhrten Operationsaufrufe
bei externen Diensten sichern. Der Schaltvorgang beginnt hierbei mit dem Start
einer Transaktion, die nur dann durcheinCommit abgeschlossen wird, sofern alle

216 Entwicklung und Ausfuhrung von Kooperationsanwendungen
aufgerufenen transaktionalen Operationen erfolgreich beendet worden sind. Die
im Encina{Toolkit bereitgestellte Ausnahmebehandlung garantiert, da im Fall
des Scheiterns einer der Teiltransaktionen bzw. Operationsaufrufe die gesamte
Operationsfolge explizit beendet wird und entsprechende Ma nahmen fur die
Herstellung des originaren Ausgangszustandes vor der Transaktion (engl. rollback)
getro en werden.
Die in der Transition in Anspruch genommenen Diensterbringer werden mittels
der vom TRADEr angebotenen importOffer{Operation (siehe Abschnitte
3.3.2.3 und 5.2.2.3) ausgewahlt. Kann hierbei vom TRADEr kein geeigneter
Diensterbringer ermitteltwerden, so wird mit der Ruckgabe eines Fehlers (error)
bzw. mit dem Abbruch der Transaktion (abort) reagiert. In diesem Fall werden
alle weiteren Operationsaufrufe in dieser Transition nicht mehr ausgefuhrt.
Sollte die Dienstvermittlung jedoch erfolgreich gewesen sein, so wird die vom
TRADEr fur einen Diensterbringer zuruckgelieferte Bindungsinformation beim
Operationsaufruf unter Nutzung des Dynamic Invocation Interface (siehe auch
Abbildung 6.4)verwendet. Hieruber werden dann die von den Eingangsstellen
stammenden Markenwerte als Operationsparameter ubergeben. Die nach dem
Dienstaufruf moglicherweise veranderten Marken werden anschlie end durch die
Transition auf den Ausgangsstellen abgelegt. In ahnlicher Weise wie bei den
Eingangsstellen werden vorher fur die Ausgangsstellen Sperren angefordert, um
Konsistenzprobleme beim Zugri mehrerer Transitionen auf dieselben Stellen zu
vermeiden. Abschlie end wird die Methode Transition::run beendet.
6.3 Bewertung und erganzende Anmerkungen
Die in diesem Kapitel und in Anhang A vorgestellte Koordinationssprache
PAMELA berucksichtigt in ihrem Sprachumfang alle im Kapitel 4.2 geforderten
Beschreibungskonzepte. Durch das Anbieten eines Daten{, eines
Aktions{, eines Kontroll u {, eines Nebenlau gkeits{, eines Transaktions{,
eines Fehlerbehandlungs{, eines Interaktions{ und eines Strukturierungskonzeptes
stehen dem Anwendungsprogrammierer samtliche Ausdrucksmittel zur
Verfugung, die zur Realisierung von Kooperationsanwendungen benotigt werden.
PAMELA stellt damit eine konkrete programmiersprachliche Umsetzung des in
Kapitel 4 eingefuhrten abstrakten und auf Petri{Netzen aufsetzenden Modells
von Kooperationsanwendungen dar. PAMELA erbringt hierdurch gleichzeitig
auch den Nachweis der Durchfuhrbarkeit der in diesem Modell entwickelten,
zunachst nur abstrakten Beschreibungskonzepte in eine konkrete verteilte
Systemumgebung, in diesem Fall in die auf DCE und CORBA aufsetzende
TRADE{Systemumgebung. Durch die Integration von dort bereits vorhandenen
Dienstbeschreibungen und deren unmittelbare Bezugnahme beim Dienstaufruf
in PAMELA wird die Verbindung der Entwicklungs{ zur Ausfuhrungsumgebung
in TRADE gescha en. Hierdurch wird es fur den Anwendungsprogrammierer
moglich, auf samtliche innerhalb von TRADE vorhandenen Dienste zuzugreifen,
wobei er in PAMELA ausschlie lich die Koordination der gewunschten Dienste
beschreiben mu . Hierbei wird er neben der von PAMELA bzw. Petri{Netzen

6.3 Bewertung und erganzende Anmerkungen 217
gegebenen Ausdrucksmoglichkeit von Nebenlau gkeit und Synchronisation,
die zur Darstellung der koordinativen Aspekte der Dienstnutzung innerhalb
von Anwendungsvorgangen geeignet ist, vor allem durch das dienstorientierte
Aktionskonzept unterstutzt. Dieses ermoglicht die einfache Verwendung der
durch die TRADE{Systemumgebung zur Verfugung gestellten exiblen Dienstvermittlungsmechanismen,
die dort in Form des TRADErs unter expliziter
Verwendung von Trader{Kooperationen realisiert werden.
Trotz der vielseitigen Ausdrucksmoglichkeiten von PAMELA, die in diesem
Kapitel beispielhaft anhand der Versicherungsanwendung, der Hotelanwendung
und dem Taschenrechner verdeutlicht wurden, sind konzeptuelle Erweiterungen
denkbar, die ihr Anwendungsfeld und ihre Beschreibungsmachtigkeit vergro ern.
Hierfur sind zumeinen diejenigen Erweiterungen zu betrachten, die das zugrundeliegende
Petri{Netz{basierte Anwendungsmodell betre en. Hierauf wurde bereits
bei der Bewertung des Anwendungsmodells in Abschnitt 4.3 eingegangen.
Zum anderen sind derartige Erweiterungen zu betrachten, die sich aus der engen
Kopplung von PAMELA an die TRADE{Ausfuhrungsumgebung und den
hierdurch bereitgestellten Verarbeitungsmoglichkeiten ergeben. Dieses betri t
vor allem das Dienstkonzept von PAMELA, welches den direkten Bezug zum
Typmanager und TRADEr ermoglicht. Hier ist insbesondere interessant, ob der
von PAMELA gebotene hohe Grad an Programmierabstraktion zugunsten direkterer
Ein u moglichkeiten auf die unterliegenden Systemdienste von TRA-
DE gelockert werden sollte. Im Fall der Dienstauswahl konnte beispielsweise die
Ausdrucksmoglichkeit der using{Anweisung zur Beein ussung der TRADEr{
Dienstauswahl durch Angaben von Suchvorschriften oder einem Suchkontext erweitert
werden. Diese wurden dann die ansonsten greifenden Standardannahmen
ersetzen oder weiter verfeinern. Die zur Zeit fur PAMELA de nierten Standardeinstellungen
erlauben die " maximale\ Ausnutzung der durch die TRADE{
Basisdienste gegebenen Moglichkeiten, so da im Rahmen von vorhandenen
Trader{Kooperationen grundsatzlich beider Dienstauswahl immer auch Dienste
anderer angeschlossener Verwaltungsdomanen berucksichtigt werden. Auf diese
mu te dann nach der Dienstvermittlung gegebenfalls uber den Interzeptor zugegri
en werden. In diesem Fall ware, beispielsweise falls die Anforderung nach
moglichst schneller Ausfuhrung eines Dienstaufrufes besteht, die Beschrankung
auf lokal innerhalbeiner Verwaltungsdomaneangebotene Dienste sinnvoll. In PA-
MELA wurde auf derartige Ein u moglichkeiten bisher ausdrucklich verzichtet,
umdem Anwendungsprogrammierer einen hochstmoglichen Grad an Abstraktion
von den in TRADE in der Ausfuhrungsumgebung ablaufenden und inder Regel
komplexen systemtechnischen Ablaufen zu bieten.
Diese Entscheidung zuweitestgehender Programmierabstraktion in PAMELA
sollte generell als ein Experiment angesehen werden, mit dem Erfahrungen im
Umgang mit Diensten bei der Entwicklung von Kooperationsanwendungen im
Sinne einer komponenten{ oder Work ow{basierten Programmiersichtweise gesammelt
werden konnen. PAMELA versteht sich hierbei als ein Hilfsmittel, das
|angesichts der Forderungen bei der Entwicklung verteilter Anwendungen unter
anderem nachAusdrucksmoglichkeiten fur Nebenlau gkeit, Transaktionalitat
und automatischer Fehlerbehandlung |eineAnwendungsentwicklung erlaubt,

218 Entwicklung und Ausfuhrung von Kooperationsanwendungen
die mit verhaltnisma ig geringem Aufwand durchfuhrbar ist. So haben die bisherigen
Erfahrungen mit PAMELA gezeigt, da mit ihr sehr schnell | im Sinne
eines Rapid{Prototyping |neue Anwendungen aus bereitsvorhandenen Diensten
zusammengesetzt werden konnen, die dann anschlie end unter Verwendung des
Koordinationsmanagers sofort ausfuhr{ und austestbar sind. Dieses wird insbesondere
bei dem gezeigten Application Builder und der Taschenrechneranwendung
deutlich, bei der verschiedene Dienstangebote durch einfaches " drag
& drop\ genutzt und getestet sowie auch zur Laufzeit durch andere Dienstangebote
ausgetauscht werden konnen. Systemtechnisch unterstutzt wird dieser
Entwicklungsproze von Kooperationsanwendungen durch den in der TRADE{
Systemumgebung prototypisch realisierten Koordinationsmanager,der samtliche
Funktionen zur Dienstkoordination zur Verfugung stellt. Hierbei kann er aufgrund
des in PAMELA gewahlten Ansatzes, ausschlie lich koordinativeAspekte
der Steuerung und Uberwachung der in den Anwendungsvorgangen genutzten
Dienste zubeschreiben, als eigenstandiger, generischer Koordinationsdienst realisiert
werden. Dieser fuhrt fur alle in PAMELA spezi zierten Kooperationsanwendungen
die Anwendungssteuerung und {kontrolle durch und ubernimmt damit
die bisherigen Aufgaben von herkommlichen Klientenanwendungen. Fur den
Anwendungsprogrammierer ergibt sichdadurch die Moglichkeit zur direkten und
automatischen Ausfuhrungder von ihm spezi zierten Kooperationsanwendungen.

Teil III
Zusammenfassung und Ausblick

Zusammenfassung und Ausblick 221
Ausgangspunkt fur diese Arbeit war die Betrachtung o ener heterogener verteilter
Dienstemarkte, in denen Dienstnutzern eine Vielzahl und Vielfalt von
Diensten an unterschiedlichen Orten angeboten werden. Diese Dienste sollen
prinzipiell in beliebiger Art und Weise bei der Entwicklungverteilter Anwendungen
genutzt werden konnen, um einen hohen Grad an Wiederverwendung und
somit an E zienzgewinn bei der Anwendungsentwicklung zu erreichen. Bevor
jedoch einederartig uneingeschrankte Dienstnutzung und Kombination zu neuen
verteilten Anwendungen realisiert werden kann, sind sowohl modellierungs{
als auch systemtechnische Voraussetzungen zu erfullen:
Geeignete Modellierung von Diensten in o enen verteilten Dienstemarkten
Die Modellierung von Diensten mu aus der Sicht eines Dienstnutzers eine
einheitlicheBehandlungder in der Regel auf der Basis unterschiedlicher verteilter
Systemplattformen und organisationeller Rahmenbedingungen entwickelten
und realisierten Dienstleistungen moglich machen. In dieser Arbeit
wird hierfur ein objektbasiertes Dienstmodell vorgeschlagen, welches
durch seinen Diensttypbegri einen hohen Grad an Abstraktion von der
eigentlichen Realisierung einer Dienstleistung bietet (siehe Abschnitt 2.2).
Bereitstellung geeigneter formaler Beschreibungsmittel, mit denen Dienstleistungen
auch bezuglich ihrer Semantik beschrieben werden konnen
Bei der Beschreibung von Diensten mu generell zwischen der Ausdrucksmachtigkeit
auf der einen Seite und der Automatisierbarkeit ihrer
Verarbeitung auf der anderen Seite abgewogen werden. Aus diesem Grund
wird in dieser Arbeit die Beschreibung von Diensten mittels Operationssignaturen
und Dienstattributen als eine hierfur geeignete Kompromi losung
unterstutzt (siehe Abschnitt 2.4.5). Aufgrund ihres hohen Grades an automatischer
Verarbeitung, vor allem bei dem Vergleich und der Suche von
Dienstbeschreibungen, bildet diese Art der Beschreibung eine geeignete
Grundlage fur die in dieser Arbeit entwickelten Dienstzugangsmechanismen
(Typmanagement, Dienstvermittlung, Interzeption) und Koordinationsmechanismen
(Dienstkoordination), da diese in der Regel selbst hochgradig
automatisch ablaufen bzw. eine automatische Ausfuhrung der in
dieser Arbeit speziell betrachteten Kooperationsanwendungen unterstutzen
mussen.
Systemtechnische Unterstutzung der Entwicklung verteilter Anwendungen
unter weitestgehender bzw. ausschlie licher Nutzung von Diensten
Bei konsequenter Wiederverwendung und Neukombination bereits irgendwo
in o enen verteilten Dienstemarkten vorhandener Dienste spielt insbesondere
die Beschreibung ihrer Koordination eine wichtige Rolle. Hierzu
schlagt diese Arbeit die Abstraktion der Kooperationsanwendungen
vor, die aufbauend auf dem formalen Ansatz eines erweiterten gefarbten
Petri{Netzes die Beschreibung strukturierter Dienstnutzung imRahmen
von Anwendungsvorgangen erlaubt (siehe Abschnitt 4.2). Dieser Ansatz
beruht auf der Beschreibung der Kooperationsbeziehungen der genutzten
Dienste. Hierzu stellt ererweiterte Petri{Netz{basierte Ausdrucksmittel

222 Zusammenfassung und Ausblick
zur Verfugung, mit denen unter anderem die | moglicherweise transaktionale
| nebenlau ge oder sequentielle Dienstnutzung imRahmen von
Anwendungsvorgangen dargestellt werden kann. Kernkonzept ist hierbei
das dienstorientierte Aktionskonzept, welches die Kopplung der Dienste
zum ubergeordneten Anwendungsablauf ermoglicht. Insgesamt bildet der
gewahlte Petri{Netz{basierte Beschreibungsansatz die Grundlage fur die
anschlie ende Umsetzung in die konkrete Koordinationssprache PAMELA,
die innerhalbvon TRADE zur Entwicklungvon Kooperationsanwendungen
eingesetzt wird.
Unterstutzungder Ausfuhrungund Steuerungvon Kooperationsanwendungen
Um Kooperationsanwendungen bzw. die dort enthaltenen Anwendungsvorgange
ausfuhren zu konnen, mussen die entsprechenden PAMELA{
Beschreibungen in eine ablau ahige Form uberfuhrt werden. Diese Arbeit
schlagt hierfur die Bereitstellung eines dedizierten Koordinationsdienstes
|den Koordinationsmanager |vor, welcher eine direkte Ausfuhrung der
spezi zierten Anwendungsvorgange vornimmt. Bei der Entwicklungder im
Koordinationsmanager benotigten Steuerungsmechanismen konnte ausgenutzt
werden, da mit der in Petri{Netzen gegebenen Schaltsemantik zugleich
auch eine geeignete Ausgangsbasis fur ihre Realisierung gegeben ist.
Dieses wurde insbesondere bei den realisierten Verarbeitungsalgorithmen
deutlich, in denen das in Petri{Netzen de nierte Schalten von Transitionen
nachgebildet wird (siehe Abschnitt 6.2.3.2). Insgesamt ubernimmt der
Koordinationsmanager somit die Aufgabe herkommlicher Klientenanwendungen,
indem er die bisher jeweils fur jede Kooperationsanwendung neu
zu entwickelnden Steuerungsmechanismen als generische Dienstleistung im
Dienstemarkt anbietet. Diese Dienstleistung kanndann beispielsweise uber
die aus PAMELA{Beschreibungen generierten Koordinationsmanagerklienten
auf einfache Art und Weise in Anspruch genommen werden (siehe
Abschnitt 6.2.1).
Systemtechnische Unterstutzung des Dienstzugangs in heterogenen Systemumgebungen
Voraussetzung fur die Realisierung des Koordinationsmanagers bilden diejenigen
Systemtechniken, die trotz der in verteilten Dienstemarkten vorhandenen
technischen und administrativen Heterogenitat einen weitgehend
uneingeschrankten Zugang zuden dort angebotenen Diensten ermoglichen.
Fur eine Untersuchung geeigneter Systemmechanismen wurden hierzu
zunachst wesentliche Heterogenitatsprobleme bei der Dienstnutzung in
o enen verteilten Dienstemarkten charakterisiert und eineAufteilung des
Dienstzugangs in die Phasen der Diensttyp ndung, der Dienstvermittlung
und des Dienstzugri s vorgenommen (siehe Kapitel 3). Diese erlaubt eine
problemorientierte Betrachtung der fur die einzelnen Phasen am besten
geeigneten Systemmechanismen, ohne jedoch gleichzeitig ihre Integration
hinsichtlich der Unterstutzungdes gesamten Dienstzugangs aus den Augen
zu verlieren. Eines der Ergebnisse dieser Untersuchungen ist der Vorschlag

Zusammenfassung und Ausblick 223
der Kombination von Typmanagement{, Dienstvermittlungs{ undInterzeptionsmechanismen
in einem integrierten Ansatz (siehe Abschnitt 3.5). Dieser
legt sowohl die zur Unterstutzung der einzelnen Dienstzugangsphasen
zu erbringenden Funktionen als auch die gegenseitigen Kooperationsbeziehungen
zwischen den identi zierten Systemmechanismen fest. Die Kooperationsbeziehungen
werden insbesondere bei den im Rahmen des Projektes
Interworking of Traders untersuchten Formen von Trader{Kooperationen
deutlich, bei denen eine enge Beziehung zwischen den Typmanagern und
den Tradern bei der domanenubergreifenden Dienstvermittlung besteht
(siehe Abschnitt 3.3.3.2). Finden derartige Trader{Kooperationen au erdem
noch uber technischeHeterogenitatsgrenzen statt, so bestehen weitere
Beziehungenzuden Interzeptoren, die eine derartige plattformubergreifende
Kooperation erst ermoglichen.
Die Umsetzung der obigen, fur die Unterstutzung koordinierter Dienstnutzung
in o enen heterogenen verteilten Dienstemarkten benotigten Systemmechanismen
in einem integrierten Losungsansatz wurde imRahmen dieser Arbeit anhand
der Service Trading and Coordination Environment (TRADE) praktisch
demonstriert. Mit TRADE wird vor allem der Nachweis der Realisierbarkeit
der in Teil I und IIentwickelten Losungsansatze in verteilte Systemumgebungen
auf der Grundlage existierender und derzeit besonders praxisrelevanter verteilter
Systemplattformen erbracht. Neben der praktischen Evaluierung der einzelnen
Systemmechanismen unter den in TRADE nachgebildeten realistischen Bedingungen
heterogener verteilter Dienstemarkte ermoglicht die Prototypimplementation
zudem auch Aufschlusse uber die derzeitigen De zite der genutzten Systemplattformen,
die sich vor allem in den Bereichen des Typmanagements und
der Dienstvermittlung zeigen (siehe unter anderem Abschnitte 3.2.2 und 3.4.1.4).
Konkrete Untersuchungs{ und Realisierungsgrundlage bilden die beiden verteilten
Systemplattformen DCE und CORBA, die vor allem aufgrund ihrer weiten
Verbreitung und ihrer zahlreichen bereits standardma ig angebotenen Funktionalitat
zur Unterstutzung genereller verteilter Verarbeitung, beispielsweise den
Namensdiensten in DCE, als besonders interessante stellvertretende Beispiele
auch fur andere Systemplattformen gewahlt wurden. Obwohl bei der Umsetzung
einzelner Systemmechanismen, wie beispielsweise des TRADErs und des
Interzeptors, spezi zische Eigenschaften der beiden Systemplattformen ausgenutzt
wurden, lassen sich die hierbei erzielten Ergebnisse vergleichsweise einfach
unddirektauchauf andere verteilte Systemplattformen ubertragen. Dieses wurde
vor allem durch einehochgradige Modularisierung der einzelnen Losungsansatze
erreicht, wie sie sich unmittelbar in dem Aufbau des TRADErs, des Typmanagers,
des Interzeptors und des Koordinationsmanagers widerspiegelt (siehe Teil
II).
Bei zusammenfassender Betrachtung der im Rahmen dieser Arbeit entwickelten
System{ und Beschreibungsmechanismen ergibt sich die in Abbildung 6.9
gezeigte Darstellung, welche die Gesamtarchitektur der konzipierten und prototypisch
realisierten verteilten TRADE{Systemumgebung zeigt. TRADE erfullt
damit mit den vorgeschlagenen und realisierten Mechanismen die eingangs die-

224 Zusammenfassung und Ausblick
PAMELA-Beschreibung
Trader
Typmanager
DCE-Dienste
Koordinationsmanager
Administrative
Heterogenitätsgrenze
Dienstkoordination
TRADEr
Typmanager
DCE-Dienste
Interzeptor
Technische/
administrative
Heterogenitätsgrenze
Diensttypbeschreibungen
Übergang zwischen Entwicklungsund
Ausführungsumgebung
Domänenübergreifender
Dienstzugang
Broker
Typmanager
CORBA-Dienste
Abbildung 6.9: TRADE{Gesamtarchitektur zur Unterstutzung koordinierter
Dienstnutzung ino enen heterogenen verteilten Dienstemarkten
ser Arbeit gestellte Anforderung nach moglichst weitgehender systemtechnischer
Unterstutzung der e zienten Wiederverwendung und Neukombination von in
o enen verteilten Dienstemarkten angebotenen Diensten zu neuen verteilten Anwendungen.
Ermoglicht wird dieses durch die Bereitstellung der Systemmechanismen
in der Ausfuhrungsumgebung, die eine uneingeschrankte domanenubergreifende
und uber Heterogenitatsgrenzen hinausreichende Dienstnutzung realisieren.
Hierzu wurden vor allem entsprechende verteilte Mechanismen zur Unterstutzung
des Diensttypmanagements, der Dienstvermittlung, des Dienstzugri
s und der Dienstkoordination entwickelt. Die konkretekoordinierte Nutzung
der nun domanenubergreifend zur Verfugung stehenden Dienste von Seiten der
Anwendungsprogrammierer oder Endbenutzer geschieht mit Hilfe der KoordinationssprachePAMELA,
welche einen hohen Grad an Programmierabstraktion
unter anderem durch ihre Konzentration auf die Beschreibung der koordinativen
Aspekte von Dienstnutzung bietet. Durch die bereitgestellte weitestgehende
Verteilungsabstraktion spielt esdabei in PAMELA insbesondere keine Rolle,
ob die genutzten Dienste auf Basis von CORBA oder DCE entwickelt wurden.
Zusammengenommen ergibt sich somit fur die Anwendungsprogrammierung die

Zusammenfassung und Ausblick 225
Moglichkeit zur weitgehend uneingeschrankten Nutzung der in o enen heterogenen
Dienstemarkten angebotenen Dienste, wobei samtliche Heterogenitatsaspekte
durch Verwendung des in TRADE bzw. von PAMELA bereitgestellten
einheitlichen Diensttypbegri s verborgen werden. Die Ausfuhrung einer derartig
spezi zierten Kooperationsanwendung kann anschlie end automatischdurch den
Koordinationsmanager gesteuert erfolgen. Dieser ubernimmt im Zusammenspiel
mit den Tradern und Typmanagern sowie Interzeptoren samtliche Aufgaben der
Anwendungssteuerung.
Die Art und Weise der Anwendungsentwicklung mittels PAMELA und dem dazugehorigen
Koordinationsmanager sollte hierbei zunachst als ein erstes Experiment
angesehen werden, mit dem eine einfache und koordinierte Nutzung der
in o enen heterogenen verteilten Dienstemarkten angebotenen Dienste erreicht
werden kann. PAMELA bietet hierdurch auch einemogliche Antwort auf die in
der Einleitung vorgestellte Vision ausschlie licher Dienstnutzung beider Entwicklung
zukunftiger verteilter Anwendungen. Durch die in Abschnitt 6.1.2.4
gezeigten Beispiele einer Hotel{ und einer Taschenrechneranwendung konnte
die Praktikabilitat des Koordinationsansatzes von PAMELA demonstriert werden.
Inwieweit die dort gemachten Erfahrungen in dieser Form auch auf andere
Anwendungsbereiche verallgemeinerbar sind, mu in anderen Anwendungsentwicklungsprojekten
zukunftig noch weiter untersucht werden. In diesem Zusammenhang
ware auch zuuberlegen, inwieweit die Anwendungsentwicklung durch
zusatzliche komfortable Entwicklungswerkzeuge noch weiter unterstutzt werden
sollte. So konnte beispielsweise die in Abschnitt 4.2 vorgestellte, an Petri{Netzen
angelehnte graphische Notation von Anwendungsvorgangen als Grundlage fur
die Entwicklung eines graphischen Programmierwerkzeuges verwendet werden.
Hierbei konnten unter anderem auch die " drag & drop\{Verfahren des bei der
Taschenrechneranwendung vorgestellten Application Builder herangezogen werden.

Anhang A
Koordinationssprache PAMELA
A.1 Beschreibung der Syntax und Semantik
Dieser Anhang gibteine Ubersicht uber die einzelnen PAMELA{Konstrukte
durch Angabe ihrer grammatikalischen Produktionen. Weiterhin wird eine informale
Beschreibung der zugehorigen Semantik gegeben und verschiedene
PAMELA{Programmbeispiele vorgestellt, die jeweils die sprachliche Umsetzung
der in Kapitel 4.2 eingefuhrten Modellierungs{ bzw. Beschreibungskonzepte zeigen.
Tabelle A.1 verdeutlichtdiefur die weitere Beschreibung verwendeteNotation in
Erweiterter Backus{Naur Form. PAMELA{Beschreibungen folgen den gleichen
lexikalischen Regeln wie die CORBA{IDL, die ihrerseits auf der Sprache C++
aufsetzt. Im Rahmen des PAMELA{Entwurfs wurden die von der CORBA{
IDL stammenden Regeln lediglich umneue Schlusselworter zur Beschreibung
von Anwendungsvorgangen erganzt. Daher soll hier auf eine weitere Au istung
der grundlegenden lexikalischen Konventionen verzichtet und stattdessen auf den
CORBA{Standard [OMG91] verwiesen werden.
Symbol Bedeutung
::=
" ist de niert als\
| Alternative
normal ein Nicht-Terminal
" fett\ ein Terminal
" der voranstehende Ausdruck kann ein{, mehrfach oder
gar nicht auftreten\
+
" der voranstehende Ausdruck kann ein{ oder mehrfach auftreten\
fg Gruppierung
[] Option
Tabelle A.1: Konventionen der angefuhrten Grammatik

228 Koordinationssprache PAMELA
Bezeichnung CORBA{Bezeichnung
ident ist ein identi er
name entspricht einem scoped name
inherit entspricht einem inheritance spec
intcon ist eine integer Konstante
charcon ist eine character Konstante
floatcon ist eine oat Konstante
string ist eine string Zeichenkette
Tabelle A.2: Abgekurzte Nicht{Terminale der CORBA{Spezi kation
In den aufgefuhrten Produktionen erscheinen einige unde nierte Nicht{
Terminale, die entweder unmittelbar der CORBA{Spezi kation entnommen
oder als Abkurzungen ihrer Entsprechungen in der CORBA{Spezi kation
aufzufassen sind. Sie werden im folgenden, beispielsweise die Basisdatentypen
int oder char,nichtweiter erlautert. Tabelle A.2 gibt hierzu eine Ubersicht. Der
zur CORBA{IDL gehorende Praprozessor entspricht dem C++{Praprozessor,
so da er auch inPAMELA{Programmen verwendet werden kann, womit unter
anderem das Einbinden von anderen IDL{Dateien moglich ist. Einige CORBA{
IDL{Konstrukte erhalten im Zusammenhang mit PAMELA{Programmen
eine erweiterte Semantik, auf die im folgenden an den entsprechenden Stellen
hingewiesen wird. Eine Zusammenfassung der Grammatik und der reservierten
Worter der Sprache geben Anhange A.1.2 und A.1.3.
process{De nition
Ein Proze in PAMELA wird durch das Schlusselwort process gefolgt von
einem Proze namen beschrieben. Dem Namen ist eventuell noch eine Liste
von " Eltern\{Prozessen angefugt, deren Netzbeschreibung geerbt wird. Bei Namensubereinstimmungen
von Proze komponenten haben die jeweils am weitesten
rechtsinder Vererbungslistestehenden De nitionen Vorang, es sei denn, sie werden
durch den erbenden Proze selbst neude niert. Eine Vorwartsdeklaration ist
zulassig. Prozesse konnen nichtineinander verschachteltwerden. Bei Angabe von
mehreren Prozessen werden dem Koordinationsmanager (siehe Abschnitt 6.2)
alle Netzbeschreibungen einzeln an der De nitionsschnittstelle ubergeben. Eine
Kopplung verschiedener Netze bzw. Prozesse kann jedoch mittels von export{
und import{Anweisungen erfolgen (siehe Abbildung A.1)).
process decl ::= \process" ident inherit \f" process body \g" \�"
| \process" ident \�"
Der Proze rumpf enthalt in beliebiger Abfolge beliebig viele Deklarationen von
Markentypen, Stellen und Transitionen. Er darf jedoch nicht leer sein, sondern

A.1 Beschreibung der Syntax und Semantik 229
mu nach der optionalen Au istung einoder mehrerer export{ und import{
Anweisungen mindestens eine der vorgenannten Deklarationen enthalten.
process body ::= [ extern decls ]
f token decl | place decl | trans decl g +
extern decls ::= f import decl | export decl g +
import{ und export{Deklarationen
Die Import{Sektion des Proze rumpfes ermoglicht die Verknupfung mitanderen
Prozessen durch die gemeinsame Nutzung bestimmter Link{Stellen. Zudem
beinhaltet sie auch die Deklaration von Dienstschnittstellen, deren Operationen
fur die Nutzung inden Transitionen an dieser Stelle eingefuhrt werden, Dieses
geschieht durch das unten erlauterte service{Konstrukt von PAMELA (siehe
auch Abbildung A.2).
import decl ::= \import" \:" import body
import body ::= f link decl | serv decl g +
export decl ::= \export" \:" export body
export body ::= f link decl g +
link decl ::= \link" name f \," name g \�"
Mit Hilfe der link{Deklaration werden gemeinsam zu nutzende Stellen durch
Aufzahlung ihrer Namen eingefuhrt. Genutzt werden konnen diese ausgezeichneten
Stellen dann durch synchrone oder asynchrone Task-Transitionen (siehe
unten). Analog kann ein Proze auch Stellen aus seinem eigenen Netz anderen
Prozessen mittels der export{Deklaration freigeben. Diensttypbeschreibungen
selbst konnen nicht exportiert werden, da sie nicht von einem Proze selbst
realisiert, sondern nach dem Grundkonzept von PAMELA von au en integriert
werden.
process CreditCard {
export:
link newOrder;
...
};
process Amex : CreditCard {
...
};
process Master : CreditCard {
...
};
process Bank {
import:
link newOrder;
...
};
Abbildung A.1:PAMELA-Beispiel: Verknupfung von Prozessen

230 Koordinationssprache PAMELA
Alle von Prozessen exportierten Stellen werden im gemeinsamen Export{
Namensraum verwaltet, indem jedem enthaltenem Namen sein zugehoriger
exportierender Proze name vorangestellt ist. Dadurch kann durch die Angabe
eines entsprechenden Gultigkeitsbereichs (engl. namescope) jede Stelle eindeutig
identi ziert werden.
service{Konstrukt
Das service{Konstrukt erlaubt die Angabe eines CORBA{Modulnamens. Dabei
spezi ziert das Modul einen Diensttyp,indem er eine interface{Deklaration
zur Beschreibung der operationalen Schnittstellen und beliebig viele attribute{
Deklarationen zur De nition der Dienstattribute enthalt. 1 Die in einem Proze
gewunschten Schnittstellen konnen anschlie end durch eine with{Klausel der
actions{Deklaration selektiert werden.
module ::= \module" ident \f" f attr dcl g \�"
f definition g + f \�" attr dcl g \g"
serv decl ::= \service" f ident \with" interfaces \�" g +
interfaces ::= ident f \," ident g
module CardService {
interface handleAccount {
boolean checkAccount(in long account);
};
...
};
process CreditCard {
import:
service CardService with handleAccount;
...
Abbildung A.2:PAMELA{Beispiel: Nutzung und Integration von Diensttypbeschreibungen
token{De nition
Durch das Schlusselwort token konnen komplex strukturierte Typen als Markierung
der Netz{Stellen de niert werden.
1 Wie in Abschnitt 6.1.2.3 bereits angemerkt wurde, ist diese Art der Diensttypbeschreibung
aquivalent zuder ansonsten in TRADE ublichen Beschreibung (siehe beispielsweise Abbildung
5.1).

A.1 Beschreibung der Syntax und Semantik 231
token decl ::= \token" ident inherit \f" token body \g" [ \�" ]
| \token" ident \�"
token body ::= f type spec declarators \�" g +
Diesem Typnamen kann eine Listeanderer token{Namen nachgestellt werden,
deren De nitionen vererbt werden sollen. Bei vorhandener Namensgleichheit hat
die in der Vererbungsliste amweitesten rechts stehende De nition Gultigkeit,
au er der erbende Typ nimmt eine Neude nition vor. Der token{Rumpf enthalt
Bezeichnerdeklarationen, fur die alle in der CORBA{IDL vorhandenen Typen
verwendet werden konnen.
...
token tCard {
string id;
long num;
short acc;
};
...
token tAmex : tCard {
struct i_tag {
string ins_name;
long ins_num;
} insurance;
};
Abbildung A.3:PAMELA{Beispiel: Typisierung von Marken
places{Deklaration
Vor der Verwendung von Bezeichnern fur die Stellen eines Petri{Netzes mussen
diesen Typen in Form von vorher de nierten token zugeordnet werden. Dieses
geschieht innerhalb einoder mehrerer places{Sektionen.
place decl ::= \places" \:" place body
place body ::= f name ident f \," ident g g +
trans{De nition
Eine Transition wird durch Angabe des Schlusselwortes trans gefolgt von einem
Bezeichner de niert. Diesem Schlusselwort kann zusatzlich ein Spezi zierer
voranstehen, der die Art der Transition festlegt:

232 Koordinationssprache PAMELA
Spezi zierer Auswirkung
Regulare (synchrone) Transition
sync Regulare (synchrone) Transition2 async Asynchrone Transition
init Starttransition eines Netzes
stask Synchrone Task{Transition
atask Asynchrone Task{Transition
transactional Transaktionale Ausfuhrung der Transitionsaktivitaten
Tabelle A.3: Transitionsarten in PAMELA
Jeder Proze besitzt grundsatzlich genau eine initiale Transition. Die Varianten
der Task{Transitionen (stask, atask) entsprechen dem im Anwendungsmodell
des Abschnitts 4.2.3.7 de nierten Verhalten.
trans decl ::= [ \[" trans spec \]" ]
\trans" ident \f" trans body \g" [ \�" ]
trans spec ::= \sync" | \async"
| \stask" | \atask"
| \init"
| \transactional"
trans body ::= f get decl | put decl | action decl g +
Der Transitionsrumpf besteht aus einer Folge von einer oder mehreren get{,
put{ bzw. actions{Sektionen. Diese bestimmen die Verknupfungen von Stellen
mit Eingangs- und Ausgangskanten und legen au erdem die beim Schalten einer
Transition auszufuhrenden Aktivitaten bzw. Operationsaufrufe bei externen
Diensten fest.
process ...
export:
link signature;
...
[atask] trans signCard{
get s from signature;
put s to s_pool;
...
};
};
process ...
export:
link in_form, out_form;
...
[stask] trans orderCard {
get f from in_form;
put f to checkForm;
get ok_form from pool;
put ok_form to out_form;
};
};
Abbildung A.4: PAMELA{Beispiel: Unterstutzung des Interaktionskonzeptes
2 Die sync und async Varianten sind fur zukunftige Erweiterungen vorgesehen.

A.1 Beschreibung der Syntax und Semantik 233
get{Anweisung
Das Schlusselwort get gefolgt von ein oder mehreren Bezeichnern erzeugt eine
entsprechende Anzahl von Eingangskanten fur die jeweilige Transition.
get decl ::= \get" get body f [ \get" ] get body g
get body ::= ident f \," ident g \from" ident \�"
| ident f \," ident g \from" ident \if" com expr \�"
Die Bezeichner stehen fur die entlang der Kanten bewegten Marken (token) und
werden als Token{Variablen bezeichnet. Die Stelle, von der die Kante ausgehen
soll, wird durch eine from{Klausel und einem nachgestellten Stellenbezeichner
angegeben. Durch den Bezug auf eine bestimmte Stelle wird der dazugehorigen
Token{Variablen implizit ihr Typ zugewiesen, der vorher der Stelle zugeordnet
wurde.
Durch die Angabe eines optionalen if{Konstruktes konnen zusatzliche Bedingungen
fur das Schalten eines Transition in Form von Kantenbedingungen spezi
ziert werden. Dabei nden die weiter unten eingefuhrten Ausdrucke (engl.
expressions) Verwendung, in denen logische und vergleichende Operationen auf
den Token{Variablen ausgefuhrt werden konnen.
trans ...
get card from atm if card.acc != 0;
Abbildung A.5: PAMELA{Beispiel: Steuerung des Kontroll usses durch Kantenbedingungen
put{Anweisung
Analog zu den Eingangskanten werden mittels der put{Anweisung die Ausgangskanten
einer Transition beschrieben. Falls die hierbei verwendeten Variablenbezeichner
vorher in keiner get{Anweisung benutzt wurden, werden sie zu diesem
Zeitpunkt deklariert, wobei sie den Typ der in der to{Klausel bezeichneten Stelle
erhalten. Sind sie bereitsdurcheine Eingangskantedeklariert worden, so mu der
Typ der ursprunglichen Eingangsstelle und der jetzige Ausgangsstelle identisch
sein.
Durch die Angabe eines optionalen with{Konstrukts konnen den Token{
Variablen durch entsprechende Ausdrucke Werte zugewiesen werden (siehe
unten). Ansonsten werden sie als anonyme Marken auf der dazugehorigen
Ausgangsstelle abgelegt.
Eine Transition kann mehrere unterschiedlich quali zierte, durch put{Sektionen
gekennzeichnete Ausgangskanten besitzen. Diese beschreiben die regulare Weiterfuhrung
der Transition, die generelle Fehlerbehandlung inder error{Sektion

234 Koordinationssprache PAMELA
und die Ergebnisbehandlung bei transaktionalen Transitionen innerhalb der
commit{ oder abort{Sektion (siehe Abbildung A.6).
put decl ::= f [ put cond \:"]
\put" put body f [ \put" ] put body g g +
put cond ::= \commit" | \abort" | \error"
put body ::= ident f \," ident g \to" ident
| ident f \," ident g \to" ident \with" set decl
set decl ::= set expr \�"
| \f" f set expr \�" g + \g"
[transactional] trans Bye {
get g from guestList;
commit:
put g to checkOut;
abort:
put g to waitingRoom;
actions:
par {
checkRoomService(g.num);
checkRestaurant(g.table);
};
};
AbbildungA.6:PAMELA{Beispiel: Transaktion mit unterscheidbaren Ausgangskanten
Ausdrucke
Bei den bereits angesprochenen Ausdrucken lassen sich zumeinen die in der
if{Klausel und die zur Beschreibung von Dienstattributen verwendeten Vergleichsausdrucke
und zumanderen die in den put{Sektionen benutzten Zuweisungsausdrucke
unterscheiden.
In beiden Fallen konnen Token{Variablen in einer sogenannten " Punkt{
Notation\ genutzt werden, die den Zugri auf Komponenten dieser Variablen
erlaubt. Weiterhin sind Konstanten der Basistypen erlaubt. Bei binaren Operatoren
mussen beide Operanden vom selben Typ sein, beim unaren not{Operator
sind nur boolesche Operanden zugelassen. Vergleichsausdrucke konnen beliebig
geklammert werden.
com expr ::= dotted ident

A.1 Beschreibung der Syntax und Semantik 235
| set const
| com expr \&&" com expr
| com expr \||" com expr
| \!" com expr
| com expr \==" com expr
| com expr \!=" com expr
| com expr \>" com expr
| com expr \

236 Koordinationssprache PAMELA
Symbol Bedeutung
= Gleichsetzung
+= Addition des rechten Operanden
-= Subtraktion des rechten Operanden
*= Multiplikation mit dem rechten Operanden
/= Division durch den rechten Operanden
%= Modulo{Division durch den rechten Operanden
Tabelle A.5: Zulassige Operatoren in Zuweisungsausdrucken
actions{Deklaration
Das Schlusselwort actions kennzeichnet den Abschnitt einer Transitionsbeschreibung,
in der die auszufuhrende Aktivitat durch Angabe von Aktionen
in Form von Operationsaufrufen mit ihren Parametern und Attributen festgelegt
wird. Hierbei lassen sich mehrere Operationen mittels der par{ und seq{
Konstrukte zuunter Umstanden auch verschachtelten Blocken zusammenfassen,
die entsprechend nebenlau g oder sequentiell ausgefuhrt werden. Als Operationsparameter
werden Token{Variablen mit ihren Komponenten in " Punkt{
Notation\ angegeben. Etwaige Ruckgabewerteder aufgerufenen Operationen, die
nicht uber Parameter sondern explizit als Operationsresultat zuruckgeliefert werden,
konnen anschlie end einer Token{Variable zugewiesen werden. Die Typen
des Ruckgabewertes und der Parameter und deren Reihenfolge sind durch die
am Anfang der PAMELA{Beschreibung referenzierten Diensttypbeschreibungen
festgelegt. Die fur die Wertaufnahme verwendeten Variablen mussen dabei
denselben Typ besitzen. Generell konnen nur Operationen genutzt werden, die
Bestandteil eines in der service{Anweisung des import{Abschnitts importierten
Diensttyps sind.
action decl ::= \actions" \:" action body
action body ::= f f [ par | seq ] \f" action list \g" action use g
| action list g +
action list ::= f [ dotted ident \=" ]
ident [ \(" param list \)" ] action use g +
param list ::= dotted ident f \," dotted ident g

A.1 Beschreibung der Syntax und Semantik 237
...
trans CheckCard {
...
actions:
readCard(card.id);
par {
ok.a = checkAccount(card.acc);
ok.n = checkNumber(card.num);
} using handleAccount;
};
};
Abbildung A.7: PAMELA{Beispiel: Umsetzung des Aktionskonzepts
using{Anweisung
Sind die im Rahmen einer PAMELA{Beschreibung verwendeten Operationsbezeichnungen
aller importierten Schnittstellen unterschiedlich, konnen diese eindeutigen
Namen ohneweitere Quali zierung benutzt werden. Diese Eindeutigkeit
kann jedoch beider Nutzung vieler verschiedener Dienstangebote nicht garantiert
werden. In PAMELA exisitiert hierfur die using{Anweisung, die neben der
Angabe der zur gewunschten Operation gehorigen Schnittstelle eines bestimmten
Diensttyps zusatzlichdieAngabe von gewunschten Dienstattributen erlaubt. Diese
dienen anschlie end dem TRADEr fur die Steuerung seiner Dienstauswahl im
Rahmen seines gesta elten Auswertevorganges (siehe unter anderem Abschnitt
5.2.2.3).
action use ::= \using" name [ \with" com expr ] \�"
| \�"
Sind auch die Bezeichner der Schnittstellen nicht eindeutig, so kann dem jeweiligen
Schnittstellentypbezeichner der Name seines Diensttyps als Gultigkeitsbereich
voran gestellt werden. Die erwunschten Attribute werden hierbei mittels
der with{Anweisung festgelegt. Die angegebenen Bezeichner mussen denen in
der zugehorigen Diensttypbeschreibung entsprechen und konnen in Ausdrucken
zusammen mit Konstanten undVariablen auftreten. Eine using{Anweisungkann
auch auf einen ganzen Block von Operationen bezogen werden, wobei dann die
angegebene Schnittstelle und die vorgegebenen Dienstattribute fur alle enthaltenen
Operationsaufrufe gultig sind.
actions:
checkAccount(c.acc)
using handleAccount with responseTime < 90;
Abbildung A.8: PAMELA{Beispiel: Dienstauswahl durch Attributquali zierung

238 Koordinationssprache PAMELA
A.1.1 Darstellung der Programmstruktur
Insgesamt ergibt sich unter Verwendung der oben dargestellten Sprachelemente
die in Abbildung A.9 gezeigte prinzipielle Struktur eines PAMELA{Programms.
module sName {
attribute attrib;
interface iName {
void a1Name(in long l);
};
};
process pName {
import:
link lname;
service sName with iName;
export:
link ...;
token tName {
long v;
...
};
places:
tName plName;
[init] trans tiName {
put mName to plName;
...
};
trans tnName {
get mName from plName if mName.v > 5;
put mName to plName with mName.v = 3;
error:
put mName to plName with mName.v = 0;
actions:
seq {
a1Name(mName.v) using iName
with attrib

A.1 Beschreibung der Syntax und Semantik 239
A.1.2 Vollstandige Grammatik
Im folgenden wird die in Anhang A.1 schrittweise vorgestellte Grammatik von
PAMELA vollstandig angegeben. Die Notation richtet sich nach den oben eingefuhrten
Konventionen.
module ::= \module" ident \f" f attr dcl g \�"
f definition g + f \�" attr dcl g \g"
process decl ::= \process" ident inherit \f" process body \g" \�"
| \process" ident \�"
process body ::= [ extern decls ]
f token decl | place decl | trans decl g +
extern decls ::= f import decl | export decl g +
import decl ::= \import" \:" import body
import body ::= f link decl | serv decl g +
link decl ::= \link" name f \," name g \�"
serv decl ::= \service" f ident \with" interfaces \�" g +
interfaces ::= ident f \," ident g
export decl ::= \export" \:" export body
export body ::= f link decl g +
token decl ::= \token" ident inherit \f" token body \g" [ \�" ]
| \token" ident \�"
token body ::= f type spec declarators \�" g +
place decl ::= \places" \:" place body
place body ::= f name ident f \," ident g g +
trans decl ::= [ \[" trans spec \]" ]
\trans" ident \f" trans body \g" [ \�" ]
trans spec ::= \sync" | \async"
| \stask" | \atask"
| \init"
| \transactional"

240 Koordinationssprache PAMELA
trans body ::= f get decl | put decl | action decl g +
get decl ::= \get" get body f [ \get" ] get body g
get body ::= ident f \," ident g \from" ident \�"
| ident f \," ident g \from" ident \if" com expr \�"
com expr ::= dotted ident
| set const
| com expr \&&" com expr
| com expr \||" com expr
| \!" com expr
| com expr \==" com expr
| com expr \!=" com expr
| com expr \>" com expr
| com expr \

A.1 Beschreibung der Syntax und Semantik 241
action body ::= f f [ par | seq ] \f" action list \g" action use g
| action list g +
action list ::= f [ dotted ident \=" ]
ident [ \(" param list \)" ] action use g +
param list ::= dotted ident f \," dotted ident g
action use ::= \using" name [ \with" com expr ] \�"
| \�"
A.1.3 Reservierte Schlusselworter
Die folgenden Worter sind inPAMELA zusatzlich zuden in der CORBA{IDL
de nierten reserviert undkonnen nicht als Bezeichner in PAMELA{Programmen
verwendet werden. PAMELA unterscheidet hierbei zwischen Gro - und Kleinschreibung.
Schlusselworter verwenden grundsatzlich Kleinbuchstaben. Kursiv
gesetzte Worter sind fur zukunftige Erweiterungen reserviert und konnen derzeit
noch nicht verwendet werden.
abort actions async atask commit delay error
export from get guard if import init
link par places priority process put seq
service stask suspend sync task timeout to
token trans transactional using with
Tabelle A.6: Reservierte Schlusselworter

242 Koordinationssprache PAMELA
A.2 Anwendungsbeispiel: Work ow{Unterstutzung
im Hotel
Die folgenden Abbildungen zeigen die textuelle PAMELA{Beschreibung des Hotelbeispiels
aus Abschnitt 6.1.2.4. Sie dient zur Erganzung der dort gezeigten
graphischen Petri{Netz{Darstellung.
module Card {
attribute string Company�
interface CardCustomer {
void checkCard(in long cardNum)�
void debitCard(in long cardNum,
in double amount)�
void creditCard(in long cardNum,
in double amount)�
void getCardBalance(in long cardNum,
out double amount)�
}�
interface Management {
void initAccounts()�
}�
}�
module Mail {
attribute long Urgency�
interface Electronic
attribute string Who�
void notify(in long reason,
in string name,
in long roomNum,
in double amount)�
}�
}�
module HotelService {
interface FrontDesk {
void initAccount(in long roomNum)�
void charge(in long roomNum,
in double amount,
out double total)�
void getBalance(in long roomNum,
out double balance)�
void pay(in long roomNum,
in double amount)�
}�
}�
module Accounting {
interface Internal {
void payTax(in double a)�
void prepareTaxReturn(in double a)�
}�
}�
process Hotel {
export:
link arrival,departure,order�
import:
link incoming�
service Card
with CardCustomer,Management�
service HotelService
with FrontDesk�
service Mail with Electronic�
token Arriving {
string name�
long cardNum�
string cardType�
long roomType�
}
token Departing {
string name�
}
token Ordering {
string customer�
long item�
double price�
}
token Money {
double amount�
}
token Guest {
string name�
long cardNum�
string cardType�
long roomNum�
long roomType�
long count�
double total�
}
token Room {
long number�
long type�
}
Abbildung A.10: PAMELA{Programm des Hotelbeispiels (Teil 1)

A.2 Anwendungsbeispiel: Work ow{Unterstutzung im Hotel 243
token NotifyData {
long reason�
string customerName�
long roomNum�
double amount�
long cardNum�
}
token Dummy {
long i�
}
places:
Room rooms�
Arriving arrival�
Departing departure�
Ordering order�
Guest guests�
NotifyData notification�
Dummy serviceInit�
Money due�
[init] trans initialize {
put r1 to rooms with
{r1.number = 1� r1.type = 0�}�
put r2 to rooms with
{r2.number = 2� r2.type = 1�}�
put r3 to rooms with
{r3.number = 3� r3.type = 0�}�
}�
[transactional] trans checkIn {
get a from arrival�
get r from rooms
if r.type == a.roomType�
commit:
put data to guests with
{data.roomNum = r.number�
data.roomType = r.type�
data.cardNum = a.cardNum�
data.cardType = a.cardType�
data.name = a.name�}�
}
abort:
put msg to notification with
{msg.reason =4�
msg.customerName = a.name�
msg.roomNum = r.number�
msg.amount = 0.0�
msg.cardNum = a.cardNum�
}�
actions:
initAccount(r.number)�
checkCard(a.cardNum)
using CardCustomer
with Company == a.cardType�
[transactional] trans processOrder {
get o from order�
get g from guests
if g.name == o.customer�
commit:
put g to guests�
put o to order�
abort:
put g to guests�
put msg to notification with
{msg.reason = 5�
msg.customerName = g.name�
msg.roomNum = o.item�
msg.amount = o.price�
msg.cardNum = g.roomNum�
}�
actions:
charge(g.roomNum,o.price,g.total)�
}
trans checkInOutFailure {
get msg from notification
if msg.reason !=5�
put r to rooms with
r.number = msg.roomNum�
error:
put msg to notification�
actions:
notify(msg.reason,msg.customerName,
msg.cardNum,msg.amount)
using Electronic with Urgency == 3�
}
trans orderFailure {
get msg from notification
if msg.reason ==5�
put r to rooms with
r.number = msg.roomNum�
error:
put msg to notification�
actions:
notify(msg.reason,msg.customerName,
msg.cardNum,msg.amount)
using Electronic with Urgency == 1�
}
[transactional] trans checkOut{
get d from departure�
get g from guests if g.name == d.name�
get m from due�
Abbildung A.11: PAMELA{Programm des Hotelbeispiels (Teil 2)

244 Koordinationssprache PAMELA
commit:
put r to rooms with
{r.number = g.roomNum�
r.type = g.roomType�}�
put m to due with m.amount = 0.0�
abort:
put msg to notification with
{msg.reason =2�
msg.amount = m.amount�
msg.customerName = g.name�
msg.roomNum = g.roomNum�
}�
put g to guests�
put m to due with m.amount = 0.0�
put d to departure�
actions:
seq {
getBalance(g.roomNum,m.amount)�
}�
par {
debitCard(g.cardNum,m.amount)
using CardCustomer
with Company == g.cardType�
pay(g.roomNum,m.amount)�
}�
}�
}�
process Accounting {
export:
link incoming�
import:
service Accounting with Internal�
token Bill {
double amount�
}
places:
Bill incoming,irs�
trans taxPayment {
get b from incoming�
put b to irs�
actions:
payTax(b.amount)�
}�
trans taxReturn {
get b from irs�
actions:
prepareTaxReturn(b.amount)�
}�
}�
Abbildung A.12: PAMELA{Programm des Hotelbeispiels (Teil 3)

A.2 Anwendungsbeispiel: Work ow{Unterstutzung im Hotel 245
A.2.1 Graphische Benutzerschnittstellen der Hotelanwendung
Die folgende Abbildung A.13 zeigt die zum Hotelbeispiel gehorigen Benutzerschnittstellen,
mit denen Hotelangestellte und Gaste Eingaben durchfuhren
konnen. Diese werden vom Koordinationsmanager uber die Ausfuhrungsschnittstelle
entgegengenommen, der anschlie end entsprechende Folgeaktivitaten im
Anwendungsvorgang initiiert.
Abbildung A.13: Graphische Benutzerschnittstellen der Hotelanwendung

Anhang B
Beschreibung des kanonischen
Typmodells
Dieser Anhang zeigt die gesamte CORBA{IDL{Beschreibung des in TRADE
verwendeten kanonischen Typmodells, welches zur Beschreibung von Dienst{
und Beziehungstypen benutzt wird (siehe Abschnitt 5.1.1.1). Eine ausfuhrliche
Beschreibung der einzelnen Datenstrukturen gibt [CM95]. Dort ndet sich auch
eine aquivalente Beschreibung des kanonischen Typmodells in der DCE{IDL.
#include "odpTradingFunction.idl" // references to definitions used
// in TRADEr/IWT project
module CanonicalTypeModel {
#include "corbaExtensions.idl" // definition of DCE types
(e.g. hyper, unsigned hyper)
/* Bezeichner */
typedef string Identifier�
typedef sequence IdentifierList�
/* Typbezeichner */
typedef odpTradingFunction::RepositoryIdType TypeId�
typedef sequence TypeIdList�
enum KindOfType {
DATA_TYPE, CONST_TYPE, TYPEDEF_TYPE, EXCEPTION_TYPE,
ATTRIBUTE_TYPE, OPERATION_TYPE, INTERFACE_TYPE, SERVICE_TYPE,
RELATIONSHIP_TYPE, NO_TYPE
}�

248 Beschreibung des kanonischen Typmodells
/*-------------------------------------------------*/
/* Fundamentale Datentypen */
enum TCKind {
tk_void,
tk_small, tk_short, tk_long, tk_hyper,
tk_usmall, tk_ushort, tk_ulong, tk_uhyper,
tk_float, tk_double,
tk_boolean, tk_char, tk_octet,
tk_iso_latin_1, tk_iso_multilingual, tk_iso_ucs,
tk_any,
tk_object_reference,
tk_binding_handle, tk_customized_binding_handle,
tk_context_handle,
tk_error_status,
tk_pipe,
tk_pointer,
tk_struct, tk_union, tk_enum,
tk_array, tk_string,
tk_identifier
}�
typedef TCKind BasicType�
/* Typen mit Bereichseinschraenkungen */
struct SmallBounds {
small lower�
small upper�
}�
struct ShortBounds {
short lower�
short upper�
}�
struct LongBounds {
long lower�
long upper�
}�
struct HyperBounds {
hyper lower�
hyper upper�
}�
struct UsmallBounds {
unsigned_small lower�
unsigned_small upper�

}�
struct UshortBounds {
unsigned short lower�
unsigned short upper�
}�
struct UlongBounds {
unsigned long lower�
unsigned long upper�
}�
struct UhyperBounds {
unsigned_hyper lower�
unsigned_hyper upper�
}�
struct FloatBounds {
float lower�
float upper�
}�
struct DoubleBounds {
double lower�
double upper�
}�
struct CharBounds {
char lower�
char upper�
}�
union RangeType switch(TCKind) {
case tk_small: SmallBounds smb�
case tk_short: ShortBounds shb�
case tk_long: LongBounds lb�
case tk_hyper: HyperBounds hb�
case tk_usmall: UsmallBounds usmb�
case tk_ushort: UshortBounds ushb�
case tk_ulong: UlongBounds ulb�
case tk_uhyper: UhyperBounds uhb�
case tk_float: FloatBounds flb�
case tk_double: DoubleBounds db�
case tk_char: CharBounds cb�
}�
/*-------------------------------------------------*/
/* Objektreferenzen */
typedef Identifier ObjectReference�
249

250 Beschreibung des kanonischen Typmodells
/* Customized Binding Handle */
struct CustomizedBindingHandle{
TypeId type� // TypeCode
Identifier aliasName�
}�
/* Error Status */
const unsigned long ERR_DEF_IN_IDL = 0x01�
const unsigned long ERR_DEF_IN_ACF = 0x02�
const unsigned long ERR_COMM_STATUS = 0x04�
const unsigned long ERR_FAULT_STATUS = 0x08�
typedef unsigned long ErrorStatus�
/*-------------------------------------------------*/
/* Strukturen */
struct StructMember {
Identifier name�
TypeId type� // TypeCode
Identifier aliasName�
}�
typedef sequence StructMemberList�
struct Struct {
Identifier name�
Identifier tag�
StructMemberList members�
}�
/* Unions */
enum KindOfDiscriminator {
u_small, u_short, u_long, u_hyper,
u_usmall, u_ushort, u_ulong, u_uhyper,
u_char, u_boolean,
u_enum, u_default
}�
union UnionLabelValue switch(KindOfDiscriminator) {
case u_small: small sm�
case u_short: short sh�
case u_long: long l�
case u_hyper: hyper h�
case u_usmall: unsigned_small usm�
case u_ushort: unsigned short ush�

case u_ulong: unsigned long ul�
case u_uhyper: unsigned_hyper uh�
case u_char: char c�
case u_boolean: boolean b�
case u_enum: Identifier i�
case u_default: short dummy�
}�
typedef sequence UnionLabelValueList�
struct UnionMember {
Identifier name�
UnionLabelValueList values�
TypeId type� // TypeCode
Identifier aliasName�
}�
typedef sequence UnionMemberList�
struct Union {
Identifier name�
Identifier tag�
Identifier c_union_name�
Identifier discriminator_name�
TCKind discriminator_kind�
TypeId discriminator_type� // TypeCode
Identifier aliasName�
UnionMemberList members�
}�
/* Enums */
struct Enum {
Identifier name�
IdentifierList members�
}�
/* Strings */
enum StringKind {STR_FIXED,
STR_CONFORMANT_BY_ARRAY,
STR_CONFORMANT_BY_PTR,
STR_CONFORMANT_BY_REF,
STR_OPEN_BY_MAX,
STR_OPEN_BY_SIZE
}�
struct String {
StringKind kind�
unsigned long length� /* kind=STR_FIXED */
Identifier maxsize_is_variable� /* kind=STR_OPEN_BY_MAX oder
251

252 Beschreibung des kanonischen Typmodells
}�
/* Arrays */
const unsigned long ARR_SIZE_IS = 0x01�
const unsigned long ARR_MAX_IS = 0x02�
const unsigned long ARR_FIRST_IS = 0x04�
const unsigned long ARR_LAST_IS = 0x08�
const unsigned long ARR_LENGTH_IS = 0x10�
typedef unsigned long ArrayAttributes�
struct Array {
ArrayAttributes attributes�
TypeId type� // TypeCode
Identifier aliasName�
unsigned long length�
Identifier maxsize_is_variable�
Identifier first_is_variable�
Identifier lastlength_is_variable�
}�
kind=STR_OPEN_BY_SIZE */
/*-------------------------------------------------*/
/* Pipes */
struct Pipe {
TypeId type� // TypeCode
Identifier aliasName�
}�
/* Pointer */
enum PointerKind {REF_POINTER, FULL_POINTER}�
struct Pointer {
PointerKind kind�
TypeId type� // TypeCode
Identifier aliasName�
}�
/* TypeCodes */
enum KindOfDataType {
BASIC_TYPE, RANGE_TYPE,
STRUCT_TYPE, UNION_TYPE, ENUM_TYPE,
STRING_TYPE, ARRAY_TYPE,
OBJECT_REFERENCE_TYPE,

POINTER_TYPE, ERROR_STATUS_TYPE,
CUSTOMIZED_BINDING_HANDLE_TYPE, PIPE_TYPE
}�
union TypeCode switch(KindOfDataType) {
case BASIC_TYPE: BasicType bt�
case RANGE_TYPE: RangeType rt�
case STRUCT_TYPE: Struct s�
case UNION_TYPE: Union u�
case ENUM_TYPE: Enum e�
case STRING_TYPE: String str�
case ARRAY_TYPE: Array arr�
case OBJECT_REFERENCE_TYPE: ObjectReference or�
case POINTER_TYPE: Pointer ptr�
case CUSTOMIZED_BINDING_HANDLE_TYPE: CustomizedBindingHandle cbh�
case ERROR_STATUS_TYPE: ErrorStatus err�
case PIPE_TYPE: Pipe p�
}�
/*-------------------------------------------------*/
/* Konstanten */
enum KindOfConst {
c_small, c_short, c_long, c_hyper,
c_usmall, c_ushort, c_ulong, c_uhyper,
c_float, c_double,
c_char, c_boolean,
c_string, c_enum,
c_context_handle
}�
union ConstValue switch(KindOfConst) {
case c_small: small sm�
case c_short: short sh�
case c_long: long l�
case c_hyper: hyper h�
case c_usmall: unsigned_small usm�
case c_ushort: unsigned short ush�
case c_ulong: unsigned long ul�
case c_uhyper: unsigned_hyper uh�
case c_float: float fl�
case c_double: double d�
case c_char: char c�
case c_boolean: boolean b�
case c_string: string str�
case c_enum: Identifier i�
case c_context_handle: short dummy�
}�
struct Const {
Identifier name�
253

254 Beschreibung des kanonischen Typmodells
ConstValue value�
Identifier aliasName�
string def�
}�
/*-------------------------------------------------*/
/* Typdeklarationen (typedefs) */
struct Typedef {
IdentifierList names�
TypeId type� // TypeCode
Identifier aliasName�
}�
/*-------------------------------------------------*/
/* Attribute */
struct Attribute {
Identifier name�
boolean rdonly�
TypeId type� // TypeCode
Identifier aliasName�
}�
/*-------------------------------------------------*/
/* Ausnahmen (Exceptions) */
typedef StructMember ExceptionMember�
typedef sequence ExceptionMemberList�
struct Exception {
Identifier name�
ExceptionMemberList members�
}�
/* Operationen */
enum ParamAttribute {PARAM_IN, /* [in] bzw. in */
PARAM_OUT, /* [out] bzw. out */
PARAM_INOUT /* [in,out] bzw. inout */
}�
struct Parameter {
Identifier name� /* Parametername */
ParamAttribute attr� /* Richtungsattribut */

TypeId type� /* Parametertyp (TypeCode) */
Identifier aliasName�
}�
const unsigned long OPATTR_NORMAL = 0x00�
const unsigned long OPATTR_MAYBE = 0x01�
const unsigned long OPATTR_BROADCAST = 0x02�
const unsigned long OPATTR_IDEMPOTENT = 0x04�
typedef unsigned long OpAttributes�
typedef sequence ParameterList�
struct Operation {
Identifier name�
OpAttributes opattr�
TypeId returntype� // TypeCode
Identifier aliasName�
ParameterList params�
TypeIdList exceptions� // Exceptions
IdentifierList contexts�
IdentifierList semantics�
IdentifierList categories�
}�
/*-------------------------------------------------*/
/* Schnittstellen */
struct Interface {
Identifier name�
TypeIdList baseInterfaces� // Interfaces
TypeIdList definitions� // Consts, Typedefs, Exceptions,
IdentifierList semantics� // Attributes, Operations
IdentifierList categories�
}�
/*-------------------------------------------------*/
/* Dienstattributtypen */
struct Property {
Identifier propertyName�
TypeId propertyType�
boolean dynamic�
}�
typedef sequence PropertyList�
/* Diensttypen */
255

256 Beschreibung des kanonischen Typmodells
struct ServiceType {
Identifier name�
string uuid�
string originalImplementationMiddleware�
TypeId interfaceType� // Interface
PropertyList properties�
IdentifierList semantics�
IdentifierList categories�
}�
/*-------------------------------------------------*/
/* Relationen */
const unsigned long RC_SYMMETRIC = 0x1�
const unsigned long RC_ANTISYMMETRIC = 0x2�
const unsigned long RC_TRANSITIVE = 0x4�
const unsigned long RC_ANTITRANSITIVE = 0x8�
const unsigned long RC_REFLEXIVE = 0x10�
const unsigned long RC_ANTIREFLEXIVE = 0x20�
typedef unsigned long RelationshipCharacteristics�
enum RelationshipStoragePolicy {
MINIMAL_INSTANCES, /* speichereffizient */
ALL_KNOWN_INSTANCES, /* zugriffseffizient */
DEFINITION_ONLY /* Charakteristika werden
nicht ausgenutzt */
}�
typedef string RelationshipDefinition�
struct Relationship {
Identifier name�
KindOfType between�
KindOfType relatedTypes�
RelationshipCharacteristics characteristics�
RelationshipStoragePolicy storagePolicy�
RelationshipDefinition definition�
TypeId hierarchyRoot�
string semantics�
}�
/*-------------------------------------------------*/
/* Allgemeiner Typ */
union Type switch (KindOfType) {
case DATA_TYPE: TypeCode dt�
case CONST_TYPE: Const cnst�

case TYPEDEF_TYPE: Typedef tdef�
case EXCEPTION_TYPE: Exception exc�
case ATTRIBUTE_TYPE: Attribute attr�
case OPERATION_TYPE: Operation op�
case INTERFACE_TYPE: Interface intf�
case SERVICE_TYPE: ServiceType svc�
case RELATIONSHIP_TYPE: Relationship rel�
case NO_TYPE: short dummy�
}�
}� // module CanonicalTypeModel
257

Anhang C
Operationale Schnittstelle des
Typmanagers
Dieser Anhang zeigt die operationale Schnittstelle des Typmanagers in der
CORBA{IDL. Diese benutzt die im vorherigen Anhang Bvorgestellten Typde
nitionen des kanonischen Typmodells. Eine detaillierte Beschreibung der einzelnen
Operationen ist in [CM96] gegeben, wo sichauch dieaquivalenteSchnittstellenbeschreibung
des Typmanagers in der DCE{IDL ndet.
#include "canonicalTypeModel.idl"
interface TypeManager {
/*-------------------------------------------------*/
/* Allgemeine Typdefinitionen */
enum KindOfError {
SUCCESS,
/* Standardfehler */
OUT_OF_MEMORY,
INVALID_DOMAIN_NAME,
INVALID_TYPEID,
INVALID_INSTANCEID,
CANNOT_CONNECT_TO_REPOSITORY,
CANNOT_CONNECT_TO_DESCLANGUAGEMAPPER,
INTERNAL_ERROR,
UNKNOWN_ERROR,
/* Domaenen */
NAME_ALREADY_EXISTS,
NAME_DOES_NOT_EXIST,
DOMAIN_DOES_NOT_EXIST,
NOT_EMPTY,
/* Typmanager-Policies */

260 Operationale Schnittstelle des Typmanagers
UNKNOWN_POLICY,
INVALID_POLICY_EXPRESSION,
/* Abbildungskomponente */
DESCLANGUAGEMAPPER_NOT_REGISTERED,
/* Anfrage- und Suchschnittstelle */
TYPEID_DOES_NOT_EXIST,
NO_DIRECT_TYPEID,
NO_SERVICE_TYPE,
NO_RELATIONSHIP_TYPE,
INVALID_TYPE,
INVALID_TYPE_DESCRIPTION,
INVALID_RELATIONSHIP_EXPRESSION,
RELATIONSHIP_GIVEN_BY_RULE,
RELATIONSHIP_DEFINED_BY_INSTANCES,
NO_TYPEID_FOUND,
CONVERSION_FAILED,
UNKNOWN_PROPERTY,
INVALID_PROPERTY_VALUE,
/* Typverwaltungsschnittstelle */
INDIRECT_TYPEID,
TYPE_STILL_IN_USE,
NO_KNOWN_DESCRIPTION_LANGUAGE,
RELATIONSHIP_DEMANDED_IN_IDL,
DIFFERENT_OTHER_INFO_ALREADY_EXISTS,
CHARACTERISTICS_VIOLATION,
DEFINITIONRULE_VIOLATION,
INSTANCEID_DOES_NOT_EXIST,
INSTANCE_DOES_NOT_EXIST,
INSTANCE_CAN_STILL_BE_DERIVED
}�
struct Environment {
unsigned short parameterNo�
KindOfError error�
string errorString�
}�
typedef string Description�
/*-------------------------------------------------*/
/* Allgemeine Funktionen */
void EnvironmentToString(
in Environment environment,
out Description str
)�
/*-------------------------------------------------*/

* Typmanager-Policies */
enum KindOfPolicyValue { STRING, NUMBER }�
union PolicyValue switch (KindOfPolicyValue) {
case STRING: string str�
case NUMBER: long number�
}�
struct SinglePolicyExpression {
CanonicalTypeModel::Identifier policyName�
PolicyValue policyValue�
}�
typedef sequence PolicyExpression�
void SetDefaultPolicy(
in PolicyExpression policyExpression,
out Environment environment /* UNKNOWN_POLICY,
INVALID_POLICY_EXPRESSION */
)�
void GetDefaultPolicy(
out PolicyExpression policyExpression,
out Environment environment
)�
/*-------------------------------------------------*/
/* Domaenen */
typedef CanonicalTypeModel::Identifier Domain�
typedef CanonicalTypeModel::IdentifierList DomainList�
void CreateDomain(
in Domain superDomain,
in CanonicalTypeModel::Identifier subDomainName,
in Description description,
out Environment environment /* NAME_ALREADY_EXISTS */
)�
void DeleteDomain(
in Domain fullDomainName,
in boolean recursive, // RECURSIVE or DOMAIN_ONLY?
in boolean always, // DELETE_ALWAYS or DELETE_ONLY_IF_EMPTY?
out Environment environment /* NOT_EMPTY, DOMAIN_DOES_NOT_EXIST */
)�
void SetDomainDescription(
in Domain fullDomainName,
in Description description,
out Environment environment /* DOMAIN_DOES_NOT_EXIST */
261

262 Operationale Schnittstelle des Typmanagers
)�
void GetDomainDescription(
in Domain fullDomainName,
out Description description,
out Environment environment /* DOMAIN_DOES_NOT_EXIST */
)�
void GetSubDomains(
in Domain fullDomainName,
in boolean absolutNames, /* full or relative */
in PolicyExpression policyExpression,
out DomainList subDomains,
out unsigned long totalNoOfSubDomains,
out Environment environment /* DOMAIN_DOES_NOT_EXIST,
UNKNOWN_POLICY, INVALID_POLICY_EXPRESSION */
)�
void MoveDomain( /* RenameDomain */
in Domain fromFullDomainName,
in Domain toDomainName, /* full or relative */
out Environment environment /* DOMAIN_DOES_NOT_EXIST,
NAME_ALREADY_EXIST */
)�
/*-------------------------------------------------*/
/* Abbildungskomponenten */
void RegisterDescLanguageMapper(
in CanonicalTypeModel::Identifier descLanguage,
in Description description,
in string stringBinding,
out Environment environment
/* NAME_ALREADY_EXISTS,
CANNOT_CONNECT_TO_DESCLANGUAGEMAPPER*/
)�
void UnregisterDescLanguageMapper(
in CanonicalTypeModel::Identifier descLanguage,
out Environment environment
/* DESCLANGUAGEMAPPER_NOT_REGISTERED */
)�
void GetDescLanguages(
out CanonicalTypeModel::IdentifierList descLanguages,
out Environment environment
)�
void GetDescLanguageDetails(
in CanonicalTypeModel::Identifier descLanguage,
out Description description,
out string stringBinding,

out Environment environment /* DESCLANGUAGEMAPPER_NOT_REGISTERED */
)�
/*-------------------------------------------------*/
/* Typverwaltungsschnittstelle: Typbeschreibungen */
struct DescByDescLanguage {
CanonicalTypeModel::Identifier descLanguage�
string description�
}�
enum TypeDescKind { byTypeId, byCanonicalTypeModel, byDescLanguage }�
union TypeDesc switch (TypeDescKind) {
case byTypeId:
CanonicalTypeModel::TypeId descByTypeId�
case byCanonicalTypeModel:
CanonicalTypeModel::Type descByCanonicalTypeModel�
case byDescLanguage:
DescByDescLanguage descByDescLanguage�
}�
void AddType(
in Domain fullDomainName,
in TypeDesc type,
out CanonicalTypeModel::TypeId id,
out Environment environment /* DOMAIN_DOES_NOT_EXIST,
INVALID_TYPE_DESCRIPTION, DESCLANGUAGEMAPPER_NOT_REGISTERED,
CONVERSION_FAILED */
)�
void AddServiceType(
in Domain fullDomainName,
in odpTradingFunction::DescByInterfaceIdType serviceType,
in CanonicalTypeModel::Identifier serviceTypeName,
out CanonicalTypeModel::TypeId id,
out Environment environment /* DOMAIN_DOES_NOT_EXIST,
TYPEID_DOES_NOT_EXIST */
)�
void GetDomain(
in CanonicalTypeModel::TypeId type,
out Domain domain,
out Environment environment /* INVALID_TYPEID,
TYPEID_DOES_NOT_EXIST */
)�
void SetAliasName(
in CanonicalTypeModel::TypeId type,
in CanonicalTypeModel::Identifier aliasName,
out Environment environment /* TYPEID_DOES_NOT_EXIST,
NAME_ALREADY_EXISTS */
263

264 Operationale Schnittstelle des Typmanagers
)�
void RemoveAliasName(
in CanonicalTypeModel::TypeId type,
in CanonicalTypeModel::Identifier aliasName,
out Environment environment /* TYPEID_DOES_NOT_EXIST,
NAME_DOES_NOT_EXIST */
)�
void GetAliasNameList(
in CanonicalTypeModel::TypeId type,
out CanonicalTypeModel::IdentifierList aliasNameList,
out Environment environment /* TYPEID_DOES_NOT_EXIST */
)�
void GetTypeId(
in Domain fullDomainName,
in CanonicalTypeModel::Identifier aliasName,
out CanonicalTypeModel::TypeId id,
out Environment environment /* DOMAIN_DOES_NOT_EXIST,
NAME_DOES_NOT_EXISTS */
)�
void DeleteType(
in CanonicalTypeModel::TypeId type,
in boolean recursive,
out Environment environment /* INVALID_TYPEID, TYPEID_DOES_NOT_EXIST,
INDIRECT_TYPEID, RELATIONSHIP_STILL_IN_USE */
)�
void GetType(
in CanonicalTypeModel::TypeId type,
inout TypeDesc typeDescription,
out Environment environment /* INVALID_TYPEID,
TYPEID_DOES_NOT_EXIST, DESCLANGUAGEMAPPER_NOT_REGISTERED */
)�
void GetServiceType(
in CanonicalTypeModel::TypeId type,
out odpTradingFunction::DescByInterfaceIdType
serviceTypeDescription,
out CanonicalTypeModel::Identifier serviceTypeName,
out Environment environment /* INVALID_TYPEID, TYPEID_DOES_NOT_EXIST,
NO_SERVICE_TYPE */
)�
/*-------------------------------------------------*/
/* Typverwaltungsschnittstelle: Beziehungen */
typedef string InstanceId�
typedef sequence InstanceIdList�

typedef string OtherInfo�
265
void AddRelationshipInstance(
in CanonicalTypeModel::TypeId relationship,
in CanonicalTypeModel::TypeId fromType,
in CanonicalTypeModel::TypeId toType,
in OtherInfo info,
out InstanceId instance,
out Environment environment /* INVALID_TYPEID, TYPEID_DOES_NOT_EXIST,
NO_DIRECT_TYPEID, NO_RELATIONSHIP_TYPE, INDIRECT_TYPEID, INVALID_TYPE,
DIFFERENT_OTHER_INFO_ALREADY_EXISTS, CHARACTERISTICS_VIOLATION,
DEFINITIONRULE_VIOLATION */
)�
void DeleteRelationshipInstance(
in InstanceId instance,
out Environment environment /* INVALID_INSTANCEID,
INSTANCEID_DOES_NOT_EXIST, RELATIONSHIP_GIVEN_BY_RULE */
)�
void GetInstanceId(
in CanonicalTypeModel::TypeId relationship,
in CanonicalTypeModel::TypeId fromType,
in CanonicalTypeModel::TypeId toType,
out InstanceId instance,
out Environment environment /* INVALID_TYPEID, TYPEID_DOES_NOT_EXIST,
NO_DIRECT_TYPEID, NO_RELATIONSHIP_TYPE, INDIRECT_TYPEID, INVALID_TYPE,
INSTANCE_DOES_NOT_EXIST */
)�
void GetRelationshipInstance(
in InstanceId instance,
out CanonicalTypeModel::TypeId relationship,
out CanonicalTypeModel::TypeId fromType,
out CanonicalTypeModel::TypeId toType,
out OtherInfo info,
out Environment environment /* INVALID_INSTANCEID,
INSTANCEID_DOES_NOT_EXIST */
)�
typedef CanonicalTypeModel::RelationshipStoragePolicy WhichInstances�
struct Instance {
CanonicalTypeModel::TypeId fromType�
CanonicalTypeModel::TypeId toType�
}�
typedef sequence InstanceList�
void GetAllRelationshipInstances(
in CanonicalTypeModel::TypeId relationship,
in WhichInstances whichInstances,

266 Operationale Schnittstelle des Typmanagers
in PolicyExpression policyExpression,
out InstanceList result, // InstanceIdList??
out Environment environment /* INVALID_TYPEID, TYPEID_DOES_NOT_EXIST,
NO_DIRECT_TYPEID, NO_RELATIONSHIP_TYPE,
UNKNOWN_POLICY, INVALID_POLICY_EXPRESSION */
)�
/*-------------------------------------------------*/
/* Anfrage- und Suchschnittstelle */
boolean AreRelated(
in CanonicalTypeModel::TypeId relationship,
in TypeDesc fromType,
in TypeDesc toType,
out Environment environment /* INVALID_TYPEID, TYPEID_DOES_NOT_EXIST,
NO_DIRECT_TYPEID, NO_RELATIONSHIP_TYPE, INVALID_TYPE */
)�
enum KindOfMatch { MATCHALLTERMS,
MATCHANYTERM,
MATCH2TERMS,
MATCH3TERMS,
MATCH4TERMS,
MATCH5TERMS,
NOCATEGORIES }�
struct CategoryExpression {
CanonicalTypeModel::IdentifierList categories�
KindOfMatch kind�
}�
void FindAllRelatedTypes(
in CanonicalTypeModel::TypeId relationship,
in TypeDesc referenceType,
in Domain startSearchAt,
in CategoryExpression categoryExpression,
in PolicyExpression policyExpression, /* GetMoreRelatedTypes */
out CanonicalTypeModel::TypeIdList relatedTypes,
out Environment environment /* INVALID_TYPEID, TYPEID_DOES_NOT_EXIST,
NO_DIRECT_TYPEID, NO_RELATIONSHIP_TYPE, INVALID_TYPE,
DOMAIN_DOES_NOT_EXIST, UNKNOWN_POLICY, INVALID_POLICY_EXPRESSION */
)�
void FindAllRelatedServiceTypes(
in CanonicalTypeModel::TypeId relationship,
in odpTradingFunction::ServiceDescriptionType referenceType,
in Domain startSearchAt,
in CategoryExpression categoryExpression,
in PolicyExpression policyExpression, /* GetMoreRelatedTypes */
out CanonicalTypeModel::TypeIdList relatedTypes,
out Environment environment /* INVALID_TYPEID, TYPEID_DOES_NOT_EXIST,
NO_DIRECT_TYPEID, NO_RELATIONSHIP_TYPE, INVALID_TYPE,

)�
267
DOMAIN_DOES_NOT_EXIST, UNKNOWN_POLICY, INVALID_POLICY_EXPRESSION */
boolean TypeCheckServicePropertyValueList(
in odpTradingFunction::ServiceDescriptionType serviceType,
in odpTradingFunction::PropertyValueListType properties,
out Environment environment /* TYPEID_DOES_NOT_EXIST, NO_SERVICE_TYPE,
UNKNOWN_PROPERTY, INVALID_PROPERTY_VALUE */
)�
/*-------------------------------------------------*/
/* Browsing - Schnittstelle */
boolean AreDirectRelated(
in CanonicalTypeModel::TypeId relationship,
in CanonicalTypeModel::TypeId fromType,
in CanonicalTypeModel::TypeId toType,
out InstanceId instance,
out Environment environment /* INVALID_TYPEID, TYPEID_DOES_NOT_EXIST,
NO_DIRECT_TYPEID, NO_RELATIONSHIP_TYPE, INVALID_TYPE */
)�
struct RelatedType {
CanonicalTypeModel::TypeId type�
boolean symmetric�
Domain domain�
}�
typedef sequence RelatedTypeList�
long FindAllDirectRelatedTypes(
in boolean subTypes,
in CanonicalTypeModel::TypeId relationship,
in TypeDesc referenceType,
in Domain startSearchAt,
in CategoryExpression categoryExpression,
in boolean symmetricTypes,
in PolicyExpression policyExpression, /* GetMoreRelatedTypes */
out RelatedTypeList relatedTypes,
out unsigned long totalNoOfRelatedTypes,
out Environment environment /* INVALID_TYPEID, TYPEID_DOES_NOT_EXIST,
NO_DIRECT_TYPEID, NO_RELATIONSHIP_TYPE, INVALID_TYPE,
DOMAIN_DOES_NOT_EXIST, UNKNOWN_POLICY, INVALID_POLICY_EXPRESSION */
)�
long FindAllEquivalentTypes(
in CanonicalTypeModel::TypeId relationship,
in TypeDesc referenceType,
in Domain startSearchAt,
in CategoryExpression categoryExpression,
in PolicyExpression policyExpression, /* GetMoreRelatedTypes */
out RelatedTypeList equivalentTypes,

268 Operationale Schnittstelle des Typmanagers
out unsigned long totalNoOfEquivalentTypes,
out Environment environment /* INVALID_TYPEID, TYPEID_DOES_NOT_EXIST,
NO_DIRECT_TYPEID, NO_RELATIONSHIP_TYPE, INVALID_TYPE,
DOMAIN_DOES_NOT_EXIST, UNKNOWN_POLICY, INVALID_POLICY_EXPRESSION */
)�
void FindTypes(
in Domain startSearchAt,
in CanonicalTypeModel::KindOfType whichKind,
in CategoryExpression categoryExpression,
in boolean searchSubdomains,
in PolicyExpression policyExpression, /* GetMoreTypeIdsInDomain */
out TypeManager::RelatedTypeList types,
out unsigned long totalNoOfTypes,
out Environment environment /* DOMAIN_DOES_NOT_EXIST,
UNKNOWN_POLICY, INVALID_POLICY_EXPRESSION */
)�
}� // interface TypeManager

Anhang D
TRADEr{Schnittstellen
Dieser Anhang zeigt die in DCE{IDL beschriebenen operationalen Schnittstelle
des TRADErs. Zunachst wird die Trading{Schnittstelle des TRADErs angegeben.
Anschlie end beschreibt Anhang D.2 die Link{Management{Schnittstelle
des TRADErs. Beide Schnittstellen bilden die gemeinsame Grundlage fur die
im Rahmen des Projektes Interworking of Traders kooperierenden Trader (siehe
Abschnitt 5.2.3).
D.1 Trading{Schnittstelle
[
uuid(003b8c92-74e2-102f-9219-02608c2ec366),
version(1.0),
pointer_default(ptr)
]
interface TRADEr
{
import "iwt_types.idl"� /* IWT type definitions */
/* Definition of service offer information given
back by the importOffer operation */
typedef struct {
[ptr] InterfaceIdentifierType *InterfaceIdentifier�
[ptr] PropertyValueListType *servicePropertyValues�
[ptr] PropertyValueListType *serviceOfferPropertyValues�
} ServiceOfferDetailType�
typedef struct ServiceOfferDetailListType {
ServiceOfferDetailType *ServiceOfferDetails�
[ptr] struct ServiceOfferDetailListType *next�
} ServiceOfferDetailListType�

270 TRADEr{Schnittstellen
/* special return code types for the importOffer operation */
typedef enum { ok, partial_ok, not_ok } QualificationType�
typedef enum { INVALID_ARGUMENTS, POLICY_EXCEPTION, NO_OFFERS_IN_SCOPE
} ErrorCodeType�
/*####################################################################
definition of the importOffer operation,
including the context name parameter */
####################################################################*/
void importOffer (
[in] OpaqueIdentifierType clientId,
[in] ContextNameType contextName,
[in] ServiceTypeDescriptionType serviceTypeDescription,
[in] PolicySpecificationType importerPolicy,
[in] ConstraintSpecificationType matchingConstraint,
[in] PreferenceSpecificationType selectionPreference,
[in] PropOfInterestListType servicePropOfInterest,
[in] OfferPropOfInterestListType serviceOfferPropOfInterest,
)�
[out] QualificationType *qualification,
[out] ErrorCodeType *errorCode,
[out] ServiceOfferDetailListType *serviceOfferDetailList
/*####################################################################
definition of the exportOffer operation,
including the context name parameter */
####################################################################*/
void exportOffer(
[in] OpaqueIdentifierType clientId,
[in] ContextNameType contextName,
[in] ServiceTypeDescriptionType serviceTypeDescription,
[in] PropertyValueListType *servicePropertyValues,
[in] PropertyValueListType *serviceOfferPropertyValues,
[in] InterfaceIdentifierType *serviceInterfaceId,
[in] InterfaceIdentifierType *serviceOfferEvaluatorIfId,
[out] QualificationType *qualification,
[out] ErrorCodeType *errorCode,
[out] OpaqueIdentifierType *serviceOfferIdentifier)�
/*####################################################################
definition of the withdrawOffer operation,
including the context name parameter
#####################################################################*/
void withdrawOffer(
[in] OpaqueIdentifierType clientId,

D.1 Trading{Schnittstelle 271
}
[in] ContextNameType contextList,
[out] QualificationType *qualification,
[out] ErrorCodeType *errorCode)�
Weitere wichtige IDL{Beschreibungen beinhalten die in der obigen Schnittstellenbeschreibung
genutzten Typde nitionen.
[
uuid(61323372-e62f-11cd-b678-08002b37748c),
version(1.0),
pointer_default(ptr)
]
interface iwt_types
{
/* definitions for IWT type representation */
import "iwt_ast.idl"�
/*#################################################################*/
/* names are just human readable strings */
typedef [string,ptr] char *NameType�
/* opaque identifiers, just a bunch of data */
typedef [string, ptr] char *OpaqueIdentifierType�
/* type of certain values, to specified elsewhere */
/*typedef [string, ptr] char *ValueType�*/
/* name list type to determine properties and contexts by name */
typedef struct NameListType {
NameType name�
[ptr] struct NameListType *next�
} NameListType�
typedef [ptr] NameListType *ContextNameType�
typedef [ptr] NameListType *PropOfInterestListType�
typedef [ptr] NameListType *OfferPropOfInterestListType�
/*#################################################################*/
/* specifies a type for DCE string binding�
please note that string binding includes an unique object identifier
and that the binding is only partial, i.e. endpoints not included */
typedef struct {
[string, ptr] char *stringBinding�
} DceStringBindingType�
/* specifies a type for DCE binding using the CDS */
typedef struct {
[string, ptr] char *CdsEntryName�
[string, ptr] char *objectUuid� /*optional*/
} DceCdsBindingType�

272 TRADEr{Schnittstellen
/* there might be more options for bindings in DCE */
typedef enum { bindByString, bindByCds } DceKindBindingType�
typedef union switch( DceKindBindingType dceKindBinding ) dceInterfaceId {
case bindByString : DceStringBindingType *dceStringBinding�
case bindByCds : DceCdsBindingType *dceCdsBinding�
} DceInterfaceIdentifierType�
/* CORBA interfaces identifier are assumed to be object references
presented as strings */
typedef [string, ptr] char *CorbaInterfaceIdentifierType�
/* ANSA interfaces identifier are assumed to be presented as strings */
typedef [string, ptr] char *AnsaInterfaceIdentifierType�
/* ONC interfaces identifier are assumed to be a hostname
represented by a string */
typedef [string, ptr] char *OncInterfaceIdentifierType�
/* defines a common interface identifier type,
which can be either direct or indirect. The indirect
includes a pointer to type description (type manager)
and a value (chunk of data). The direct one which allows
binding in a particular middlerware domain */
typedef enum { DIRECT, INDIRECT } KindType�
typedef enum { DCE_MW, CORBA_MW, ANSA_MW, ONC_MW } MiddlewareType�
typedef union switch( MiddlewareType middleware ) directId {
case DCE_MW: [ptr] DceInterfaceIdentifierType
*dceInterfaceIdentifier�
case CORBA_MW: [ptr] CorbaInterfaceIdentifierType
*corbaInterfaceIdentifier�
case ANSA_MW: [ptr] AnsaInterfaceIdentifierType
*ansaInterfaceIdentifier�
case ONC_MW: [ptr] OncInterfaceIdentifierType
*oncInterfaceIdentifier�
} DirectInterfaceIdType�
typedef struct {
/* identifies the interface of a type manager */
[ptr] DirectInterfaceIdType *typeManagerIdentifier�
/* this one identifies the type definition within the type manager */
OpaqueIdentifierType internalIdentifier�
} TypeManagerIdentifierType�
/* an indirect interface identifier is determined by a 'typeOfIdentifier'
which allows to get the type information of this interface ident from
a type manager, the 'valueOfIdentifier' is a value of this type */
typedef struct {
[ptr] TypeManagerIdentifierType *typeOfIdentifier�
[string, ptr] char *valueOfIdentifier�
} IndirectInterfaceIdType�

D.1 Trading{Schnittstelle 273
typedef union switch( KindType kindInterface ) interfaceId {
case DIRECT: [ptr] DirectInterfaceIdType
*directInterfaceIdentifier�
case INDIRECT: [ptr] IndirectInterfaceIdType
*indirectInterfaceIdentifier�
} InterfaceIdentifierType�
typedef struct InterfaceIdentifierListType {
[ptr] InterfaceIdentifierType *InterfaceIdentifier�
[ptr] struct InterfaceIdentifierListType *next�
} InterfaceIdentifierListType�
/* computational interface types and service types
are assumed to be stored in a type manager */
typedef TypeManagerIdentifierType CompInterfaceTypeIdentType�
typedef TypeManagerIdentifierType ServiceTypeIdentifierType�
/*#################################################################*/
/* DirectValueType is being used to store values in
NamedValue-Structures */
typedef Any DirectValueType�
typedef struct {
TypeManagerIdentifierType *ValueTypeId�
char *Value�
} IndirectValueType�
typedef union switch (KindType valueKind) value
{
case DIRECT : DirectValueType *directValue�
case INDIRECT : IndirectValueType *indirectValue�
} ValueType�
/*#################################################################*/
/* direct relational operators */
typedef enum
{
short_eq, short_lt, short_le, short_gt , short_ge, short_ne,
long_eq, long_lt, long_le, long_gt, long_ge, long_ne,
ushort_eq, ushort_lt, ushort_le, ushort_gt , ushort_ge, ushort_ne,
ulong_eq, ulong_lt, ulong_le, ulong_gt, ulong_ge, ulong_ne,
float_eq, float_lt, float_le, float_gt, float_ge, float_ne,
double_eq, double_lt, double_le, double_gt, double_ge, double_ne,
boolean_eq, boolean_ne,
char_eq, char_lt, char_gt, char_ne,
octet_eq, octet_ne,
struct_eq, struct_ne,
union_eq, union_ne,
enum_eq, enum_ne,
eq_string_case_sensitive, eq_string_case_insensitive,
sub_string_case_sensitive, sub_string_case_insensitive,
sequence_eq, sequence_ne, sub_sequence,

274 TRADEr{Schnittstellen
array_eq, array_ne, sub_array
} DirectRelationshipIdType�
/* definition of relationship type */
/* direct relationships are defined in iwt_ast.idl ! */
typedef union switch (KindType relationshipKind ) relationshipIdentifier {
case DIRECT:
[ptr] DirectRelationshipIdType
*directRelationshipIdentifier�
case INDIRECT:
[ptr] TypeManagerIdentifierType
*indirectRelationshipIdentifier�
} RelationshipIdentifierType�
/*#################################################################*/
/* signature of properties, i.e. property type and property name */
typedef struct {
[ptr] TypeManagerIdentifierType *propertyType�
NameType propertyName�
} PropertySigType�
typedef struct PropertySigListType {
PropertySigType *propertySig�
[ptr] struct PropertySigListType *next�
} PropertySigListType�
/* property values, i.e. property signature and property value */
typedef struct {
/*PropertySigType *propertySig�*/
NameType propertyName�
ValueType *value�
} PropertyValueType�
typedef struct PropertyValueListType {
PropertyValueType *propertyValue�
[ptr] struct PropertyValueListType *next�
} PropertyValueListType�
/*#################################################################*/
/* kind of service description */
typedef enum { byServiceId, byInterfaceId, bySignature } ServiceDescKindType�
typedef struct {
[ptr] CompInterfaceTypeIdentType *compInterfaceTypeIdent�
[ptr] PropertySigListType *servicePropertyTypeList�
} DescByInterfaceIdType�
typedef enum {
DCE_IDL, CORBA_IDL, ANSA_IDL, ONC_IDL, ENCINA_TIDL ,
DCE_AST, CORBA_AST, /* string representations of abstract syntax trees
used at the DSTC */

D.1 Trading{Schnittstelle 275
IWT_AST /* servive type represenation based on type codes
proposed by Kay Mueller-Jones, Univ. of Hamburg */
/*,... */}
TypeDescriptionLanguageType�
typedef union switch( TypeDescriptionLanguageType tdl ) td {
case DCE_IDL:
case CORBA_IDL:
case ANSA_IDL:
case ONC_IDL:
case DCE_AST:
case CORBA_AST: [string, ptr] char *ifTypeDesc�
case IWT_AST: [ptr] SvcTypeDescType *svcTypeDesc�
} TypeDescriptionType�
typedef struct {
[ptr] TypeDescriptionType *typeDescription�
[ptr] PropertySigListType *servicePropertyTypeList�
/* is NULL when IWT_AST type
description is used */
} DescBySignatureType�
typedef union switch( ServiceDescKindType sdkt ) serviceTypeDesc {
case byServiceId: [ptr] ServiceTypeIdentifierType
*serviceTypeIdentifier�
case byInterfaceId: [ptr] DescByInterfaceIdType
*descByInterfaceId�
case bySignature: [ptr] DescBySignatureType
*descBySignature�
} ServiceTypeDescriptionType�
/*#################################################################*/
typedef struct {
[ptr] RelationshipIdentifierType *relationshipIdentifier�
NameType propertyName�
ValueType *value�
} RelationshipType�
/* Rules for specifying policies and constraints */
typedef enum { exist, relation } RuleIndicatorType�
typedef union switch( RuleIndicatorType ruleIndicator ) simpleRule {
case exist: NameType propertyName�
case relation: [ptr] RelationshipType *relationship�
} SimpleRuleType�
typedef enum { NOT, AND, OR } OperatorType�
typedef enum { SIMPLE, COMPLEX } ComplexityType�
typedef struct RuleType {
union switch( ComplexityType complexity ) rule {
case SIMPLE: SimpleRuleType *simpleRule�

276 TRADEr{Schnittstellen
case COMPLEX: union switch( OperatorType op ) complexRule {
case NOT: [ptr] struct RuleType *unary_rule�
case AND:
case OR:
struct {
[ptr] struct RuleType *left_rule�
[ptr] struct RuleType *right_rule�
} binary_rule�
} complexRule�
} RuleUnionType�
} RuleType�
/* types derived from rule type */
typedef [ptr] RuleType *PolicySpecificationType�
typedef [ptr] RuleType *ConstraintSpecificationType�
typedef [ptr] RuleType *PreferenceSpecificationType�
}
%###############################################################
%###############################################################
%###############################################################
[
uuid(00439d24-8209-1f52-a638-02608c2d4e81),
pointer_default(ptr),version(1.0)
]
interface iwt_ast {
/* flags for specifying operation parameters and results */
const unsigned long DCE_ARG_IN = 0x1�
const unsigned long DCE_ARG_OUT = 0x2�
const unsigned long DCE_ARG_INOUT = 0x4�
const unsigned long DCE_STATIC = 0x8�
const unsigned long DCE_DYNAMIC = 0x10�
/* additional flags - implementation dependent */
const unsigned long DCE_DONT_CARE = 0x10000�
const unsigned long DCE_VAR = 0x20000�
const unsigned long DCE_INITIALIZED = 0x40000�
typedef unsigned long DCE_Flags�
/* type codes for basic data types (similiar as in CORBA) */
typedef enum {
tk_null,tk_void,
tk_short,tk_long,tk_ushort,tk_ulong,
tk_float,tk_double,tk_boolean,tk_char,
tk_octet,tk_any,tk_TypeCode,
tk_Principal, tk_objref,
tk_struct,tk_union,tk_enum,tk_string,

D.1 Trading{Schnittstelle 277
tk_sequence,tk_array
} TCKind�
typedef struct NVList {
[ptr]struct NamedValue *curr�
[ptr]struct NVList *next�
} NVList�
typedef struct NamedValue{
[string]char *name�
[ptr]union Any *argument�
unsigned long len�
DCE_Flags argmode�
} NamedValue�
/* definitions of complex data structures */
typedef NVList Struct�
typedef NVList Sequence�
typedef struct EnumList{
[string]char *name�
short int value�
[ptr]struct EnumList *next�
} EnumList�
typedef struct Enum{
[string]char *label�
[ptr]EnumList *list�
} Enum�
typedef struct Union{
[string]char *label�
[ptr]NVList *u�
} Union�
typedef struct Array{
short int length�
[ptr]NVList *a�
} Array�
/* definition of Any Type representing distinct types */
typedef union Any
switch (TCKind type) value {
case tk_null: short int n�
case tk_void: short int v�
case tk_short: short int s�
case tk_long: long int l�
case tk_ushort: unsigned short int us�
case tk_ulong: unsigned long int ul�
case tk_float: float f�
case tk_double: double d�
case tk_boolean: boolean b�

278 TRADEr{Schnittstellen
case tk_char: char c�
case tk_octet: byte o�
case tk_any: [ptr] NamedValue *any�
case tk_TypeCode: TCKind t�
case tk_Principal: [string,ptr] char *principal�
case tk_objref: [string,ptr] char *objref�
case tk_struct: [ptr]Struct *st�
case tk_union: [ptr]Union *u�
case tk_enum: [ptr]Enum *e�
case tk_string: [string] char *str�
case tk_sequence: [ptr]Sequence *sq�
case tk_array: [ptr]Array *a�
} Any�
/* Flags defining operation call semantic */
typedef enum {MAYBE, AT_LEAST_ONCE, AT_MOST_ONCE, EXACTLY_ONCE}
OpFlagsType�
/* Exceptions */
typedef enum {
NO_EXCEPTION,USER_EXCEPTION,SYSTEM_EXCEPTION
} Exception_type�
typedef struct {
Exception_type major�
[string,ptr]char *identifier�
Any *value�
} Environment�
/* Standard Exception Identifiers */
/* ... (for further specification !!!) */
/* Attribute declarations as NVLists */
typedef NVList AttributeListType�
/* Operation type description */
typedef struct OperationType {
[string] char *opName�
[ptr] NVList *params�
OpFlagsType opMode�
Environment *execption�
[string] char *semantics�
} OperationType�
typedef struct OperationListType {
[ptr] OperationType *curr�
[ptr] struct OperationListType *next�
} OperationListType�
/* Interface type description */
typedef struct IfTypeRepType {
[string] char *ifTypeName�
[ptr] OperationListType *opSignatures�

D.2 Link{Management{Schnittstelle 279
[string] char *semantics�
} IfTypeRepType�
/* Service type description */
typedef struct SvcTypeDescType {
[string] char *svcTypeName�
[ptr] IfTypeRepType *ifType�
[ptr] AttributeListType *svcAttributeTypes�
[string] char *semantics�
} SvcTypeDescType�
}
D.2 Link{Management{Schnittstelle
[
uuid(049d5416-d454-11ce-a8a8-08002b3fae64),
version(1.0),
pointer_default(ptr)
]
interface iwt_lima
{
import "iwt_types.idl"� /* reference to TRADEr/IWT definitions */
import "iwt_import.idl"� /* reference to TRADEr/IWT definitions */
/* add link */
void addLink([in] PropertyValueListType *linkPropValues,
[in] InterfaceIdentifierType *targetInterfaceId,
[out] OpaqueIdentifierType **linkId,
[out] QualificationType *qualification,
[out] ErrorCodeType *errorCode)�
/* remove link */
void removeLink([in] OpaqueIdentifierType *linkId,
[out] QualificationType *qualification,
[out] ErrorCodeType *errorCode)�
/* modify link */
void modifyLink([in] OpaqueIdentifierType *linkId,
[in] PropertyValueListType *linkPropValues,
[out] QualificationType *qualification,
[out] ErrorCodeType *errorCode)�
/* describe link */
void describeLink([in] OpaqueIdentifierType *linkId,
[out] InterfaceIdentifierType **targetInterfaceId,
[out] PropertyValueListType **linkPropValues,
[out] QualificationType *qualification,

280 TRADEr{Schnittstellen
[out] ErrorCodeType *errorCode)�
/* list links */
void listLinks([out] NameListType **linkIds,
[out] QualificationType *qualification,
[out] ErrorCodeType *errorCode)�
}

Anhang E
De nitionsschnittstelle des
Koordinationsmanagers
Dieser Anhang zeigt zunachst die in DCE{IDL beschriebene De nitionsschnittstelle
des Koordinationsmanagers. Anschlie end gibt Anhang E.2 ein Beispiel
von Registrationskode, welcher vom PAMELA{Sprachubersetzer zum Zugri auf
die De nitionsschnittstelle generiert wurde. Ausfuhrliche Erlauterungen der einzelnen
Operationen des Koordinationsmanagers nden sich sowohl in Abschnitt
6.2.2.1 als auch in [Bri95] und [Gri95].
E.1 Schnittstellenbeschreibung
[
uuid(0024a0ae-2368-522f-ab0d-08005a018f9d),
version(1.0),
pointer_default(ptr)
]
interface act_netdef{
import "iwt_ast.idl"� // reference to TRADEr/IWT definitions
typedef [context_handle] void *net_handle_t�
typedef [context_handle] void *trans_handle_t�
typedef [context_handle] void *place_handle_t�
typedef [context_handle] void *service_handle_t�
typedef long status_t�
typedef [string] char *name_t�
typedef [string] char *serviceName_t�
typedef [string] char *serviceAttribute_t�

282 De nitionsschnittstelle des Koordinationsmanagers
/****************************************************************
* function : createNet
***************************************************************/
net_handle_t createNet([in]name_t name,
[out]status_t *stat)�
/****************************************************************
* function : createPlace
***************************************************************/
place_handle_t createPlace([in]net_handle_t net,
[in]name_t name,
[in,ptr]NamedValue *type,
[out]status_t *stat)�
/****************************************************************
* function : createTransition
***************************************************************/
typedef enum {
am_NOT,
am_AND,
am_OR
} boolop_t�
typedef enum {
EQUAL,
NOTEQUAL,
LESS,
LESSEQUAL,
GREATER,
GREATEREQUAL
} relop_t�
typedef struct {
relop_t relop�
NamedValue *left�
NamedValue *right�
} simpleExpr_t�
typedef enum {
simple,
complex
} exprKind_t�
typedef union expr_t switch (exprKind_t kind) expr{
case complex:
union complexExpr_t *complexEx�
case simple:
simpleExpr_t *simpleEx�
} expr_t�
typedef union complexExpr_t switch(boolop_t boolop)expr{

E.1 Schnittstellenbeschreibung 283
case am_NOT:
expr_t *notExpr�
case am_AND:
struct{
expr_t *left�
expr_t *right�
} andExpr�
case am_OR:
struct{
expr_t *left�
expr_t *right�
} orExpr�
} complexExpr_t�
typedef enum {
regular,
transactional,
synctask,
asynctask,
init
} transition_t�
trans_handle_t createTransition([in]net_handle_t net,
[in]name_t name,
[in]transition_t type,
[in,ptr]expr_t *guard,
[out]status_t *stat)�
/****************************************************************
* function : createInputArc
***************************************************************/
void createInputArc([in]trans_handle_t transition,
[in]place_handle_t place,
[in]name_t tokenName,
[in,ptr]expr_t *condition,
[out]status_t *stat)�
/****************************************************************
* function : createOutputArc
***************************************************************/
typedef enum{
on_commit,
on_error,
on_abort
} case_t�
void createOutputArc([in]trans_handle_t transition,
[in]place_handle_t place,
[in]name_t tokenName,
[in]case_t type,
[out]status_t *stat)�
/****************************************************************

284 De nitionsschnittstelle des Koordinationsmanagers
* function : createServiceCall
***************************************************************/
typedef enum{
SEQ,
PAR
} service_t�
typedef struct {
[string]char *serviceName�
[string]char *interfaceName�
[ptr]expr_t *serviceAttr�
[string]char *operation�
[ptr]NVList *callInputParams�
[ptr]NVList *callOutputParams�
} serviceCall_t�
service_handle_t createServiceCall([in]trans_handle_t trans)�
/****************************************************************
* function : addServiceCall
***************************************************************/
service_handle_t
addServiceCall([in]service_handle_t ancestor,
[in]service_t kind,
[in]serviceCall_t service)�
typedef enum {
create,
assign,
add,
subtract,
multiply,
divide,
modulo
} operation_t�
/****************************************************************
* function : addTokenModifier
***************************************************************/
void addTokenModifier([in]trans_handle_t transition,
[in,string]char *name,
[in]case_t in_case,
[in]operation_t operation,
[in,ptr]NamedValue *nv)�
}

E.2 Aus PAMELA generierter Programmkode 285
E.2 Aus PAMELA generierter Programmkode
Die folgende Abbildung zeigt ein Beispiel von Anwendungskode, welcher vom
PAMELA{Sprachubersetzer aus einer gegebenen PAMELA{Beschreibung erzeugt
wurde. Die dort generierten Operationen entsprechen denen der im vorherigen
Anhang beschriebenen De nitionsschnittstelle des Koordinationsmanagers.
/* DO NOT EDIT -- Automatically generated from st.idl */
#include “am.h”
#ifndef NULL
#define NULL 0
#endif
class Class_Dealer {
public:
void process_Dealer(void) {
status_t st;
void* Dealer = createNet(“Dealer”, &st);
NamedValue* Dealer_Money = NV_createStruct(“Dealer_Money”);
NamedValue* Dealer_Money_stuff = NV_createString(“Dealer_Money_stuff”);
NV_addStructMember(Dealer_Money, Dealer_Money_stuff);
...
void* Dealer_Prices = createPlace(Dealer, “Dealer_Prices”, NV_copyType(Dealer_Money), &st);
void* Dealer_Start = createTransition(Dealer, “Dealer_Start”, init, NULL, &st);
NamedValue* Dealer_Start_m = NV_copyType(Dealer_Owner);
addTokenModifier(Dealer_Start,
“m”,
on_commit, create,
Dealer_Start_m
);
...
void* Dealer_Buy = createTransition(Dealer, “Dealer_Buy”, regular, NULL, &st);
NamedValue* tmp_6 = NV_createLong(“c1.Dealer_Owner_buckets”);
NV_setFlag(tmp_6, DCE_VAR);
NamedValue* Dealer_Buy__Const_1 = NV_createLong(“const”);
NV_setLong(Dealer_Buy__Const_1, 0);
NamedValue* Dealer_Buy_c1 = NV_copyType(Dealer_Owner);
expr_t *Dealer_Buy_Customers_Exp1 = createSimpleExpression(NOTEQUAL,
tmp_6,
Dealer_Buy__Const_1
);
createInputArc(Dealer_Buy, Dealer_Customers, “c1”, Dealer_Buy_Customers_Exp1, &st);
...
void* Dealer_Buy__Actions = createServiceCall(Dealer_Buy);
NVList* Dealer_Buy_CardAgency_CreditCard_debitCard__inP_1 = NULL;
NVList* Dealer_Buy_CardAgency_CreditCard_debitCard__outP_1 = NULL;
NamedValue* tmp_9 = NV_createLong(“Class”);
NV_setFlag(tmp_9, DCE_VAR);
NamedValue* Dealer_Buy__Const_2 = NV_createLong(“const”);
NV_addNVListElement(&Dealer_Buy_CardAgency_CreditCard_debitCard__inP_1, tmp_10);
serviceCall_t CardAgency_CreditCard_debitCard_SvcInfo_1 = {
“CardAgency”,
“CreditCard”,
createSimpleExpression(EQUAL,
tmp_9,
Dealer_Buy__Const_2
),
“debitCard”,
Dealer_Buy_CardAgency_CreditCard_debitCard__inP_1,
Dealer_Buy_CardAgency_CreditCard_debitCard__outP_1
};
void* Dealer_Buy_CardAgency_CreditCard_debitCard_1 = addServiceCall(
Dealer_Buy__Actions,
SEQ,
CardAgency_CreditCard_debitCard_SvcInfo_1
);
} ...
Abbildung E.1:Vom PAMELA{Sprachubersetzer erzeugter De nitionskode

Abbildungsverzeichnis
2.1 Wechselseitige Umwandlung von Dienstbeschreibung und
Dienstreprasentation ::::::::::::::::::::::::: 17
2.2 Aufbau eines Objektes :::::::::::::::::::::::: 19
2.3 Grundlegendes Client/Server{Modell :::::::::::::::: 21
2.4 Konformitat von Schnittstellen ::::::::::::::::::: 27
2.5 DCE{Schnittstellenname ::::::::::::::::::::::: 29
2.6 Erweiterung von Schnittstellenbeschreibungen um Dienstattribute 32
2.7 Konzeptgraph zur Beschreibung der Eigenschaften eines Druckers 33
2.8 Standardisierte Bezeichner fur Konzepte und Relationen :::::: 34
2.9 Transitionssysteme fur die Diensttypen Stack und Variable ::: 36
2.10 Beispiel einer um Vor{ und Nachbedingungen erweiterten COR-
BA IDL :::::::::::::::::::::::::::::::: 39
3.1 Betrachtungsebenen des Dienstzugangs ::::::::::::::: 46
3.2 Heterogenitatsgrenzen beim Zugang zu Diensten : : : : : : : : : : 47
3.3 Mogliche Klienten eines Typmanagers :::::::::::::::: 53
3.4 Hierarchie von Typde nitionen im CORBA{Schnittstellenrepository 55
3.5 Namensbasierter Diensttypgraph in ANSA : : : : : : : : : : : : : 56
3.6 Bestandteile einer Diensttypbeschreibung : : : : : : : : : : : : : : 58
3.7 Struktureller Aufbau von Beziehungstypen : : : : : : : : : : : : : 60
3.8 Verwaltung von Typen und Instanzen :::::::::::::::: 63
3.9 Beispiel einer Diensttyphierarchie mit virtuellen Diensttypen ::: 65
3.10 Konformitatsbeziehungen zwischen realen Diensttypen :::::: 66
3.11 Strategien bei der Speicherung von Diensttyphierarchien : : : : : 67
3.12 Typuberprufung zum Bindungszeitpunkt : : : : : : : : : : : : : : 69
3.13 Typ{ und Wertuberprufung beim dynamischen Operationsaufruf : 70

288 ABBILDUNGSVERZEICHNIS
3.14 Typ{ und Wertuberprufung beim statischen, generierten Operationsaufruf
:::::::::::::::::::::::::::::::: 71
3.15 Verteiltes Diensttypmanagement ::::::::::::::::::: 72
3.16 Format eines Typbezeichners ::::::::::::::::::::: 73
3.17 Austausch von Dienstbeschreibungen zum Bindungszeitpunkt ::: 74
3.18 Der Trader und seine Nutzer ::::::::::::::::::::: 79
3.19 Trader{Kontexte ::::::::::::::::::::::::::: 80
3.20 Bestandteile eines Dienstangebotes ::::::::::::::::: 81
3.21 Rolle des Dienstangebots beim Trading ::::::::::::::: 82
3.22 Prinzip der gesta elten Auswertung ::::::::::::::::: 84
3.23 Komponenten einer Trader{Kooperation :::::::::::::: 86
3.24 Indirekte Trader{Kooperation :::::::::::::::::::: 87
3.25 Protokollgesteuerte, direkte Trader{Kooperation :::::::::: 89
3.26 Verknupfung von Tradern durch Links ::::::::::::::: 90
3.27 Weiterreichen einer Dienstanfrage :::::::::::::::::: 91
3.28 Typmanager{unterstutzte Trader{Kooperation ::::::::::: 92
3.29 Ignorante, Typmanager{gesteuerte Trader{Kooperation :::::: 94
3.30 Ignorante, Trader{gesteuerte Trader{Kooperation ::::::::: 95
3.31 Bewu te, Trader{gesteuerte Trader{Kooperation :::::::::: 96
3.32 Bewu te, Typmanager{gesteuerte Trader{Kooperation :::::: 97
3.33 Trader{Kooperation basierend auf standardisierten Diensttypbeschreibungen
::::::::::::::::::::::::::::: 98
3.34 Trader{Kooperation basierend auf standardisierten Diensttypbezeichnern
::::::::::::::::::::::::::::::: 99
3.35 Berucksichtigung von Beziehungstypen bei der Trader{Kooperation100
3.36 Dienstzugri uber organisationelle Heterogenitatsgrenzen hinweg : 102
3.37 Bindungsuberprufung durch einen Interzeptor :::::::::::104
3.38 Ausschnitt einer Abbildung einer DCE{ auf eine CORBA{
Dienstbeschreibung ::::::::::::::::::::::::::105
3.39 Object Mapping ::::::::::::::::::::::::::::108
3.40 Statischer, generierter Interzeptor ::::::::::::::::::109
3.41 Dynamischer Interzeptor :::::::::::::::::::::::110
3.42 Ubertragung von Fremdkonzepten ::::::::::::::::::111
3.43 Kooperationsbeziehungen beim Dienstzugang ::::::::::::113

ABBILDUNGSVERZEICHNIS 289
4.1 Grad der Dienstnutzung :::::::::::::::::::::::118
4.2 Nebenlau gkeit von Aktivitaten und Aktionen : : : : : : : : : : :122
4.3 Darstellung von Kontroll u konzepten :::::::::::::::126
4.4 Anbindung von Diensten an Transitionen : : : : : : : : : : : : : :127
4.5 Inter- und Intravorgangsnebenlau gkeit : : : : : : : : : : : : : :128
4.6 Wechselseitiger Ausschlu im kritischen Abschnitt :::::::::129
4.7 Strukturierung durch Klienten/Server{Netze : : : : : : : : : : : :130
4.8 Auslosung einer Fehlerbehandlung ::::::::::::::::::131
4.9 Unidirektionale Benutzerinteraktion :::::::::::::::::132
4.11 Bidirektionale Benutzerinteraktion durch Transitionsverschmelzung133
4.10 Bidirektionale Benutzerinteraktion mittels zwei Transitionen :::133
4.12 Commit{ und Abort{Ausgangsstellen zur Transaktionsbehandlung 135
4.13 Entwicklungs{ und Ausfuhrungsumgebung in TRADE :::::::141
5.1 Beispiel einer TRADE{Diensttypbeschreibung : : : : : : : : : : :146
5.2 Einfugen neuer Konformitatsbeziehungstypen auf der Granularitatsebene
der Schnittstellentypen :::::::::::::::::152
5.3 Graphische Visualisierung einer Diensttyphierarchie : : : : : : : :153
5.4 Komponenten des Typmanagers :::::::::::::::::::157
5.5 Komponenten des TRADErs :::::::::::::::::::::161
5.6 XDS/XOM{basierter Zugri auf Namensdienste im TRADEr :::163
5.7 Komponenten und Informations usse des Attributmanagementsystems
::::::::::::::::::::::::::::::::::165
5.8 Optionen bei der domanenbegrenzten Dienstauswahl : : : : : : : :167
5.9 Die Testumgebung des Projektes Interworking of Traders : : : : :169
5.10 Der Dienstangebotsmodus des Link{Kon gurationsmanagers :::171
5.11 Angabe von Suchstrategien am Beispiel eines Taxi{Klienten :::173
5.12 Ablauf einer Dienstanfrage im TRADEr im Rahmen einer Trader{
Kooperation ::::::::::::::::::::::::::::::174
5.13 Algorithmus fur die Abwicklung einer Trader{Kooperation im
TRADEr ::::::::::::::::::::::::::::::::174
5.14 Nutzung eines DCE{Dienstes durch einen CORBA{Dienstnehmer 185
5.15 Nutzung eines CORBA{Dienstes durch einen DCE{Dienstnehmer 185
5.16 Dynamische Proxy{Generierung bei der Nutzung eines DCE{
Dienstes durch einen CORBA{Dienstnehmer : : : : : : : : : : : :187

290 ABBILDUNGSVERZEICHNIS
5.17 Architektureller Aufbau des Interzeptors ::::::::::::::189
6.1 Ausschnitt einer PAMELA{Vorgangsbeschreibung :::::::::201
6.2 Vergroberte Petri{Netz{Darstellung des Hotelbeispiels :::::::204
6.3 Der Application Builder aus Benutzersicht :::::::::::::205
6.4 Architektur und Beziehungen des Koordinationsmanagers : : : : :207
6.5 Graphische Administrationsschnittstelle des Koordinationsmanagers210
6.6 Objektorientierte Modellierung eines Petri{Netzes :::::::::211
6.7 Algorithmus fur die Ausfuhrung einer Transition ::::::::::214
6.8 Algorithmus fur den Aufruf von Operationen innerhalbeiner Transition
::::::::::::::::::::::::::::::::::215
6.9 TRADE{Gesamtarchitektur zur Unterstutzung koordinierter
Dienstnutzung in o enen heterogenen verteilten Dienstemarkten : 224
A.1 PAMELA-Beispiel: Verknupfung von Prozessen ::::::::::229
A.2 PAMELA{Beispiel: Nutzung und Integration von Diensttypbeschreibungen
:::::::::::::::::::::::::::::230
A.3 PAMELA{Beispiel: Typisierung von Marken ::::::::::::231
A.4 PAMELA{Beispiel: Unterstutzung des Interaktionskonzeptes :::232
A.5 PAMELA{Beispiel: Steuerung des Kontroll usses durch Kantenbedingungen
::::::::::::::::::::::::::::::233
A.6 PAMELA{Beispiel: Transaktion mit unterscheidbaren Ausgangskanten
:::::::::::::::::::::::::::::::::234
A.7 PAMELA{Beispiel: Umsetzung des Aktionskonzepts :::::::237
A.8 PAMELA{Beispiel: Dienstauswahl durch Attributquali zierung : 237
A.9 PAMELA{Programmstruktur ::::::::::::::::::::238
A.10 PAMELA{Programm des Hotelbeispiels (Teil 1) ::::::::::242
A.11 PAMELA{Programm des Hotelbeispiels (Teil 2) ::::::::::243
A.12 PAMELA{Programm des Hotelbeispiels (Teil 3) ::::::::::244
A.13 Graphische Benutzerschnittstellen der Hotelanwendung ::::::245
E.1 Vom PAMELA{Sprachubersetzer erzeugter De nitionskode ::::285

Tabellenverzeichnis
5.1 Darstellbarkeit verschiedener Konformitatsbeziehungen mittels
De nitionsregelmustern ::::::::::::::::::::::::151
A.1 Konventionen der angefuhrten Grammatik : : : : : : : : : : : : :227
A.2 Abgekurzte Nicht{Terminale der CORBA{Spezi kation ::::::228
A.3 Transitionsarten in PAMELA ::::::::::::::::::::232
A.4 Zulassige Operatoren in Vergleichsausdrucken : : : : : : : : : : :235
A.5 Zulassige Operatoren in Zuweisungsausdrucken : : : : : : : : : : :236
A.6 Reservierte Schlusselworter :::::::::::::::::::::241

Literaturverzeichnis
[AA91] G. Almgren und M.Anderson. Open System Trader using X.500.
Telia Research Report Televerket/RC 02.01,Televerket, September
1991. ISA Project.
[AC91] R. Amadio und L. Cardelli. Subtyping recursive types. In Proceedings
of the 18th ACM Symposium on Principles of Programming
Languages, 1991.
[AHU74] A.V. Aho, J.E. Hopcroft und J.D. Ullman. The Design and Analysis
of Computer Algorithms. Addison{Wesley, 1974.
[AL90] P. America und F.van der Linden. A parallel object{oriented
language with inheritance and subtyping. In Proceedings of the
ECOOP/OOPSLA Conference, Ottawa, Canada, S. 21{25, 1990.
[Ame87] P. America. Inheritance and Subtyping in a Parallel Object{
Oriented Language. In European Conference on Object{Oriented
Programming (ECOOP '87), Paris, France, Lecture Notes in Computer
Science 276, S. 234{242. Springer{Verlag, 1987.
[Ame91] P. America. Designing an Object{Oriented ProgrammingLanguage
with Behavioural Subtyping. In J.W. de Baker, W.P. deRoever
und G. Rozenberg, Hrsg., Foundations of Object{OrientedLanguages,
REX School/Workshop, The Netherlands, 1991, Lecture Notes
in Computer Science 489, S. 60{90. Springer{Verlag, 1991.
[ANS87] Alvey Advanced Network Systems Architecture Project, 24 Hills
Road, Cambridge, UK. ANSA Reference Manual Release 0.03
(Draft), 1987.
[ANS95] ANSI/NISO. ANSI Z.39.50-1995, 1995.
[BB87] T. Bolognesi und E. Brinksma. Introduction to the ISO Speci cation
Language LOTOS. Computer Networks and ISDN Systems,
14, Heft 1, S. 25{59, 1987.
[BB94] A. Beitz und M. Bearman. An ODP Trading Service for DCE.
In Proceedings of the First International Workshop on Services
in Distributed and Networked Environments (SDNE), S. 42{49,
Prague, Czech Republic, Juni 1994. IEEE Computer Society Press.

294 LITERATURVERZEICHNIS
[Bea95] M. Bearman. Trading in Open Distributed Environments. In Proceedings
of the International Conference onOpen Distributed Processing
(ICODP '95), February 1995, Brisbane,Australia, 1995.
[Ber93] P. A. Bernstein. Middleware { An Architecture for Distributed
System Services. Technical Report CRL 93/6, Digital Equipment
Corporation, Cambridge Research Lab, 1993.
[Ber95] K. Berg. Software{Wiederverwendung und komponentenbasierte
Software{Entwicklung: 2 Seiten einer Medaille? In F. Huber-
Waschle, H. Schauer und P. Widmayer, Hrsg., GISI 95 { Herausforderungen
eines globalen Informationsverbundes fur die Informatik,
Zurich, 1995, S. 496{503. Springer{Verlag, 1995.
[Bet95] M. Betz. Networking Objects with CORBA. Dr. Dobb's Journal,
S. 18{26, November 1995.
[BIBY95] W. Brookes, J. Indulska, A. Bond und Z.Yang. Interoperabilityof
distributed platforms: a compatibility perspective. In K. Raymond
und L. Armstrong, Hrsg., Open DistributedProcessing: Experiences
with distributed environments, Proceedings of the third IFIP TC
6/WG 6.1 international conferenceonopen distributed processing,
1995, S. 67{78. Chapman & Hall, 1995.
[BKR93] A.D. Beitz, P.W. King und K.A. Raymond. Is DCE a Support
Environment for ODP? In Proceedings of the IFIP TC6/WG6.1
International Conference onOpen Distributed Processing, S. 188{
202. Elsevier Science Publishers B.V. (North{Holland), 1993.
[BKS91] I. Barth, E. Kovacs und F.Sembach. Trading andManagement{
Funktionen in MELODY. In Tagungsband zum Workshop: Entwicklungstendenzen
von Rechnernetzen, S. 25{34. Gau ig, 1991.
[BN84] A.D. Birrell und B.J. Nelson. Implementing Remote Procedure
Calls. ACM Transactions on Computer Systems, 2,Heft1,S.39{
59, Februar 1984.
[BR92a] M. Bearman und K. Raymond. Federating traders: An ODP adventure.
In J. de Meer, V. Heymer und R. Roth, Hrsg., Open Distributed
Processing, Proceedings of the IFIP TC6/WG6.4 International
Workshop on Open Distributed Processing, Berlin, 1991, S.
125{141. Elsevier Science Publishers B.V. (North{Holland), 1992.
[BR92b] G.S. Blair und T.Rodden. The Impact of CSCW on Open Distributed
Processing. In J. de Meer, V. Heymer und R.Roth, Hrsg.,
Proceedings of the International IFIP Workshop on Open Distributed
Processing, S. 143{154. Elsevier Science Publishers B.V.,
North{Holland, Oktober 1992.

LITERATURVERZEICHNIS 295
[BR93] M. Bearman und K.Raymond. Contexts, Views and Rules: An
Integrated Approach toTrader Contexts. In Proceedings of the
IFIP TC6/WG6.1 International Conference onOpen Distributed
Processing, S. 181{191. Elsevier Science Publishers B.V. (North{
Holland), 1993.
[Bri95] L.M. Brinckmann. Dynamische Koordination komplexer verteilter
Anwendungsvorgange: Entwurf und Implementation einer petrinetzbasierten
Steuerungskomponente. Diplomarbeit, Universitat
Hamburg, Fachbereich Informatik, 1995.
[Bur95] C. Burger. Cooperation policies for traders. In K. Raymond und
L. Armstrong, Hrsg., Open Distributed Processing: Experiences
with distributed environments, Proceedings of the third IFIP TC
6/WG 6.1 international conferenceonopen distributed processing,
1995, S. 208{218. Chapman & Hall, 1995.
[Cam91] APM Ltd. Cambridge. ANSAware 3.0 Implementation Manual,
Februar 1991. Document RM.097.00.
[Car89] L. Cardelli. Typeful Programming. DEC SRC Research Report,
No. 45, 1989.
[CC91] R.S. Chin und S.T. Chanson. Distributed Object{Based Programming
Systems. ACM Computing Surveys, 23, Heft 1, S. 91{124,
1991.
[CDK94] G.F. Coulouris, J. Dollimore und T. Kindberg. Distributed Systems
{ Concepts and Design. Addison{Wesley, 2.Ausgabe, 1994.
[CKO92] B. Curtis, M.I. Kellner und J.Over. Process Modeling. Communications
of the ACM, 35, Heft 9, S. 75{90, 1992.
[CM95] B. Christiansen und M.Munke. Diensttypmanagement ino enen
heterogenen verteilten Systemen unter besonderer Berucksichtigung
von DCE und CORBA. Studienarbeit, Universitat Hamburg,
Fachbereich Informatik, 1995.
[CM96] B. Christiansen und M.Munke. Typmanagementunterstutzung
fur Tradinginheterogenen verteilten Systemumgebungen: Entwurf
und Implementierung einer Typmanagementkomponente. Diplomarbeit,
Universitat Hamburg, Fachbereich Informatik, 1996.
[CMML96] B. Christiansen, M. Munke, K. Muller{Jones und W. Lamersdorf.
Type Management: A Key to Software Reuse in Open Distributed
Systems. Zur Vero entlichung eingereicht, 1996.
[Com88] D. Comer. Internetworking with TCP/IP: Principles, Protocols,
and Architecture. Prentice Hall, Englewood Cli s, New Jersey,
1988.

296 LITERATURVERZEICHNIS
[Cor91] J.R. Corbin. The Art of Distributed Applications { Programming
Techniques for Remote Procedure Call. Springer{Verlag, 1991.
[CR91] R.N. Chang und C.V. Ravishankar. A Service Acquisition Mechanism
for the Client/Service Model in Cygnus. In Proceedings of the
11th International Conference on Distributed Computing Systems,
S. 90{97, Mai 1991.
[CW85] L. Cardelli und P.Wegner. On Understanding Types, Data Abstraction,
and Polymorphism. ACM Computing Surveys, 17, Heft
4, S. 471{522, Dezember 1985.
[CZ96] D.B. Chapman und E.D. Zwicky. Einrichten von Internet Firewalls.
O'Reilly, 1996.
[DGSZ94] G. Dinkho , V. Gruhn, A. Saalmann und M. Zielonka. Business
Process Modeling inthe Work ow ManagementEnvironment Leu.
In Proceedings of the 10th International Conference on the Entity
Relationship Approach, Lecture Notes in Computer Science 881, S.
46{63. Springer{Verlag, 1994.
[DHL90] U. Dayal, M. Hsu und R. Ladin. Organizing Long{Running Activities
with Triggers and Transactions. In Proceedings of the ACM
SIGMOD International Conference on Management of Data, S.
204{214, Atlantic City, New Jersey, Mai 1990.
[Dud90] M. Dudet. X.500 Directory for those familar with Trading Concepts.
Technical Report Number 358.90 SEPT/SCE/SPM/MD {
V2, SEPT, Dezember 1990.
[EF86] W. E elsberg und A. Fleischmann. Das ISO{Referenzmodell fur
o ene Systeme und seine sieben Schichten. Informatik Spektrum,
9, Heft 5, S. 258{286, Oktober 1986.
[Elm91] A.K. Elmagarmid, Hrsg. Database Transaction Models for Advanced
Applications. Morgan Kaufmann Publishers, 1991.
[EM94] B. Elbert und B. Martyna. Client/Server Computing: Architecture,
Applications, and Distributed Systems Management. Artech
House, 1994.
[EN93] C.A. Ellis und G.J. Nutt. Modeling andEnactment ofWork ow
Systems. In Proceedings of the 14th International Conference on
Application and Theory of Petri Nets, Lecture Notes in Computer
Science 691, S. 1{16. Springer{Verlag, 1993.
[Fla96] D. Flanagan. Java in a Nutshell: A Desktop Quick Reference for
Java Programmers. O'Reilly & Associates, 1996.
[GC92] D. Gelernter und N. Carriero. Coordination Languages and their
signi cance. Communications of the ACM, 35, Heft 2, S. 97{107,
Februar 1992.

LITERATURVERZEICHNIS 297
[GGL + 95] K. Geihs, H. Grunder, W. Lamersdorf, M. Merz, K. Muller und
A. Puder. Systemunterstutzungfur o ene verteilte Dienstemarkte.
In K. Franke, U. Hubner und W.Kalfa,Hrsg.,Kommunikation in
Verteilten Systemen: Neue Lander { Neue Netze { Neue Dienste,
Informatik{Aktuell, S. 445{459. Springer{Verlag, Februar 1995.
[GHG + 93] J.V. Guttag, J.J. Hornig, S.J. Garland, K.D. Jones,A.Modet und
J.M. Wing. Larch: Languages and Tools for Formal Speci cation.
Springer{Verlag, 1993.
[GHJV94] E. Gamma, R. Helm, R. Johnson und J. Vlissides. Design Patterns:
Elements of Reusable Object{Oriented Software. Addison{Wesley,
1994.
[Glo89] P. Gloor.Synchronisation in verteilten Systemen. Teubner Verlag,
1989.
[GMGK + 91] H. Garcia-Molina, D. Gawlick, J. Klein, K. Kleissner undK.Salem.
Coordinating Activities Through Extended Sagas: A Summary. In
Proceedings of the 36th IEEE Computer Society International Conference
(Compcon), S. 568{573, 1991.
[GML96] F. Gri el, K. Muller{Jones und W. Lamersdorf. Komponentenbasierte
Entwicklung interoperabler Software auf heterogenen
Middleware{Plattformen. In H.C. Mayr, Hrsg., Beherrschung
von Informationssystemen, Informatik '96, Klagenfurt, September,
1996. R.Oldenbourg Verlag, 1996.
[GR83] A. Goldberg und D. Robson. Smalltalk{80: The Language and Its
Implementation. Addison{Wesley, 1983.
[GR93] J. Gray und A. Reuter. Transaction Processing: Concepts and
Techniques. Morgan{Kaufmann, San Mateo, California, 1993.
[Gra81] J. Gray. TheTransaction Concept: Virtues and Limitations. In
Proceedings of the 7th International ConferenceonVery Large Data
Bases, S. 144{154. IEEE Computer Society Press, 1981.
[Gre95] K. Greese. Verwaltungvon Diensten mit Hilfe von Verzeichnisdiensten.
Studienarbeit, Universitat Hamburg, Fachbereich Informatik,
1995.
[Gri95] F. Gri el. PAMELA: Entwurf und Realisierung einer Koordinationssprache
fur komplexe verteilte Anwendungen. Studienarbeit,
Universitat Hamburg, Fachbereich Informatik, 1995.
[Gri96] F. Gri el. Integration heterogener verteilter Systemarchitekturen
zur komponentenbasierten Softwareentwicklung. Diplomarbeit,
Universitat Hamburg, Fachbereich Informatik, 1996.
[Gro94] Object Management Group. Common Object Services Speci cations.
John Wiley & Sons, 1994.

298 LITERATURVERZEICHNIS
[Gru91] V. Gruhn. Validation and Ver cation of Software Process Models.
Dissertation, Universitat Dortmund, Fachbereich Informatik, 1991.
auch als Bericht Nr. 394/91 erschienen.
[HA93] H.-G. Hegering und S.Abeck. Integriertes Netz- und Systemmanagement.
Addison{Wesley, 1993.
[HAB + 92] Y. Halabi, M. Ansari, R. Batra, W. Jin, G. Karabatis, P. Krychniak,
M. Rusinkiewicz und L. Suardi. Narada: An Environment
for Speci cation and Execution of Multi{System Applications. In
Proceedings of the 2nd International Conference on Systems Integration
ICSI '92, S. 680{690. IEEE, Juni 1992.
[Her89] A.J. Herbert. The Computational Projection of ANSA. In S.J.
Mullender, Hrsg., Distributed Systems, Frontier Series, Kapitel 19,
S. 417{437. Addison{Wesley and ACM Press, 1989.
[HH89] R.G. Herrtwich und G. Hommel. Kooperation und Konkurrenz.
Springer{Verlag, 1989.
[Hof96] Y. Ho ner. Inter{operability and distributed application platform
design. In A. Schill, C. Mittasch, O. Spaniol und C.Popien,
Hrsg., Distributed Platforms | Proceedings of the IFIP/IEEE
International Conference on Distributed Platforms: Client/Server
and Beyond: DCE, CORBA, ODP and Advanced Distributed Applications,
S. 342{356. Chapman & Hall, 1996.
[Hog89] D. Hogrefe. Estelle, LOTOS und SDL | Spezi kationssprachen
fur verteilte Systeme. Springer{Verlag, 1989.
[IBM93] IBM. Encina for AIX/6000 Base Reference. IBM, 1993. Order
Number SC23{2464.
[IBR93] J. Indulska, M. Bearman und K. Raymond. AType Management
System for an ODP Trader. In Proceedings of the IFIP
TC6/WG6.1 International Conference onOpen Distributed Processing.
Elsevier Science Publishers B.V. (North{Holland), 1993.
[ION94] IONA Technologies. The Orbix Programmer's Guide, 1994. Dublin,
Ireland, 1994.
[ISO] ISO 10165-7: Information Technology | Open System Interconnection
| Structure of Management Information | Part 7: General
Relationship Model. International Standardisation Organisation.
[ISO87] Information Processing | Open Systems Interconnection | Speci
cationofAbstract Syntax Notation One (ASN.1). International
Organization for Standardization and International Electrotechnical
Committee, 1987. International Standard 8824.

LITERATURVERZEICHNIS 299
[ISO94] ISO/IEC JTC1/SC21 N 8935rev: Proposed New Question on Type
Description. International Standardisation Organisation, Oktober
1994.
[ISO95] ISO/IEC JTC1/SC21 WG7/Kobe-9: Open Distributed Processing:
Type Repository Function. InternationalStandardisation Organisation,
November 1995. Output ofthe WG7 interim meeting
in Kobe.
[Jab93] S. Jablonski. Transaction Support for Activity Management. In
Proceedings Workshop on High Performance Transaction Processing
Systems, Asilomar, 1993.
[Jab95] S. Jablonski. Work ow{Management{Systeme: Motivation, Modellierung,
Architektur. Informatik Spektrum, 18, Heft 1, S. 13{24,
Februar 1995.
[Jen92] K. Jensen. Coloured Petri Nets: Basic Concepts, Analysis Methods
and Practical Use, Band 1. Springer{Verlag, 1992.
[Jen95] K. Jensen. Coloured Petri Nets. Basic Concepts, Analysis Methods
and Practical Use. Volume 2. EATCS Monographs on Theoretical
Computer Science. Springer{Verlag, 1995.
[Jon94] K. Jones. Vermittlung und Verwaltung von Diensten in o enen
verteilten Systemen: Ein Objekt{ und Architekturmodell. Diplomarbeit,
Universitat Hamburg, Fachbereich Informatik, 1994.
[JR91] K. Jensen und G.Rozenberg, Hrsg. High-Level Petri Nets. Theory
and Application. Springer{Verlag, 1991.
[JSS95] B. Janssen, D. Severson und M. Spreitzer. ILU 1.8 Reference
Manual. Xerox Corporation, 1995.
[JV87] E. Jessen und R.Valk. Rechensysteme: Grundlagen der Modellbildung.
Springer{Verlag, 1987.
[Kel93] L. Keller. Vom Name{Server zumTrader { Ein Uberblick uber Trading
inverteilten Systemen. Praxis der Informationsverarbeitung
und Kommunikation (PIK), 16, Heft 3, S. 122{133, 1993.
[KLS90] H.F. Korth, E. Levy und A.Silberschatz. A Formal Approach to
Recovery by Compensating Transactions. In Proceedings of the
16th Conference onVery Large Databases, S. 95{106. Morgan-
Kaufmann, 1990.
[KMV + 90] S. Krakowia, M. Meysembourg, H. Nguyen Van, M. Riveill, C. Roison
und X. Rousset de Pina. Design and Implementation of an
Object{Oriented, Strongly Typed Language for Distributed Applications.
Journal of Object{Oriented Programming, 1, Heft 5, S.
11{21, September 1990.

300 LITERATURVERZEICHNIS
[Kon93] D. Konstantas. Object Oriented Interoperability. In O.M.
Nierstrasz, Hrsg., 7th European Conference on Object{Oriented
Programming (ECOOP '93), Paris, Lecture Notes in Computer
Science 707, S. 80{102. Springer{Verlag, 1993.
[Kov92] E. Kovacs. E zienter Zugri auf dynamische Information im
MELODY{Trader. Interner Bericht, Universitat Stuttgart, IPVR,
1992.
[KR88] B.W. Kernighan und D.M. Ritchie. The C programming language:
ANSI C. Prentice Hall International, 2. Ausgabe, 1988.
[KW94] E. Kovacs und S. Wirag. Trading and Distributed Application
Management: An Integrated Approach. In Proceedings of the 5th
IFIP/IEEE International Workshop on Distributed Systems: Operation
and Management, Oktober 1994.
[LA94] F. Leymann und W.Altenhuber. Managing Business Processes As
An Information Resource. IBM Systems Journal, 33, Heft 2, 1994.
[Lak92] C. Lakos. The LOOPN User Manual. Technical Report TR 92{1,
Department of Computer Science, University ofTasmania, 1992.
[Lam94] W. Lamersdorf. Datenbanken in verteilten Sytemen: Konzepte,
Losungen, Standards. Vieweg, 1994.
[LC93] G.T. Leavens und Y.Cheon. Extending CORBA IDL to Specify
Behavior with Larch. Technical Report TR 93{20, IOWA STATE
UNIVERSITY of Science and Technology, Department of Computer
Science, August 1993.
[LHG86] B. Liskov, M. Herlihy und L. Gilbert. Limitations of Synchronous
Communication with Static Process Structure in Languages
for Distributed Computing. In 13th Symposium on Principles of
Programming Languages, St. Petersburg Beach, Florida, 1986.
[Lin95] P.F. Linington. RM{ODP: The Architecture. In K. Raymond
und L. Armstrong, Hrsg., Open DistributedProcessing: Experiences
with distributed environments, Proceedings of the third IFIP TC
6/WG 6.1 international conferenceonopen distributed processing,
1995, S. 15{33. Chapman & Hall, 1995.
[LMM95] W. Lamersdorf, M. Merz und K.Muller{Jones. Middleware Support
for Open Distributed Applications. In Proceedings of the First
International Workshop on High Speed Networks and Open Distributed
Platforms, St. Petersburg, Russia, Juni 1995.
[LR94] F. Leymann und D. Roller. Business Process Management With
FlowMark. In Proceedings COMPCON Spring 94, San Francisco,
CA., Februar 1994. IEEE.

LITERATURVERZEICHNIS 301
[LW93] B. Liskovund J.M. Wing. A New De nition of the Subtype Relation.
In O. Nierstrasz, Hrsg., Proceedings of the European Conference
on Object Oriented Programming, ECOOP '93, Berlin, Germany,
Lecture Notes in Computer Science 707, S. 118{141. Springer{
Verlag, 1993.
[Mah95] B. Mahr. Principles of Open Distributed Processing inMedicine
|The Berlin Approach. In E. Fleck, Hrsg., Open Systems in
Medicine, S. 6{23. IOS Press, 1995.
[Mar89] M.A. Marsan. Stochastic Petri Nets: an Elementary Introduction.
In Advances in Petri Nets, Lecture Notes in Computer Science 424,
S. 1{29. Springer{Verlag, 1989.
[Mar91] D.S. Marshak. ANSA: A Model for Distributed Computing. Network
Monitor, 6, Heft 11, November 1991.
[MB92] A. Macartney und G. Blair. Flexible trading in distributed multimedia
systems. Computer Networks and ISDN Systems, 25, Heft
2, S. 145{157, August 1992.
[MC94] T. Malone und K. Crowston. The interdisciplinary Study of Coordination.
Computing Surveys, 26, Heft 1, S. 87{120, 1994.
[Mer96] M. Merz. Elektronische Markte im Internet. TAT {Thompson's
aktuelle Tutorien. Thompson International Publishing, 1996.
[Met93] Meta Software Corporation. Design/CPN Tutorial for UNIX/X-
Window System Version 2.0, 1993.
[Mil84] R. Milner. A proposal for Standard ML. In Proceedings of the
Symposium on LISP and Functional Programming, Austin, Texas,
August 1984, S. 184{197, 1984.
[Mil89] R. Milner. Communications and Concurrency. Prentice{Hall,
1989.
[MJM94] K. Muller, K. Jones und M.Merz. VermittlungundVerwaltungvon
Diensten in o enen verteilten Systemen. In B. Wol nger, Hrsg.,
Innovationen bei Rechen{ und Kommunikationssystemen | Eine
Herausforderung fur die Informatik, Informatik Aktuell, S. 219{
226. Springer{Verlag, August 1994.
[MK95] B. Meyer und A.Koch. Ausfuhrbare Policies fur das Management
verteilter Anwendungen | Ein regelbasierter Ansatz mit MAR-
VEL. In H. Krumm, Hrsg., Entwicklung und Management verteilter
Anwendungssysteme: Tagungsband� 2. Arbeitstre ens der
GI/ITG Fachgruppe Kommunikation und Verteilte Systeme und
der GI Fachgruppe Betriebssysteme� Universitat Dortmund� 9./10.
Oktober 1995, S. 121{129, Munster, 1995. Krehl Verlag.

302 LITERATURVERZEICHNIS
[ML93a] M. Merz und W. Lamersdorf. Cooperation Support for an Open
Service Market. In Proceedings of the IFIP TC6/WG6.1 International
Conference onOpen Distributed Processing, S.329{340.
Elsevier Science Publishers B.V. (North{Holland), 1993.
[ML93b] M. Merz und W.Lamersdorf. Generic Interfaces to RemoteApplications
in Open Systems. In Proceedings of the International
IFIP Workshop on Interfaces in Industrial Production and Engineering
Systems, S. 267{281. Elsevier Science Publishers B.V.
(North{Holland), 1993.
[MLM94] M. Merz, W. Lamersdorf und K.Muller. Trusted Third{party
Services in COSM. EM { Electronic Markets, 4, Heft 12, S. 7{8,
September 1994.
[MLML96] M. Merz, B. Libermann, K. Muller{Jones und W.Lamersdorf. Interorganizational
Work ow Management with Mobile Agents in
COSM. In Proceedings of the First International Conference on
The Practical Application of Intelligent Agents and Multi{Agent
Technology (PAAM '96), London, 1996, S. 405{420, 1996.
[MMaTT96] S. Muller, K. Muller{Jones und W. Lamersdorf an T. Tu. Global
Trader Cooperation in Open Service Markets. In Aachen Workshop,
Trends in Distributed Systems, October, 1996, 1996.
[MML94a] M. Merz, K. Muller und W. Lamersdorf. Service Trading andMediation
in Distributed ComputingEnvironments. In Proceedings of
the 14th International Conference on Distributed Computing Systems
(ICDCS '94), S. 450{457. IEEE Computer Society Press,
1994.
[MML94b] K. Muller, M. Merz und W. Lamersdorf. Der TRADE{Trader: Ein
Basisdienst o ener verteilter Systeme. In C. Popien und B.Meyer,
Hrsg., Neue Konzepte fur die O ene Verteilte Verarbeitung, S. 35{
44. Verlag der Augustinus Buchhandlung, Aachen, September 1994.
[MML95a] M. Merz, K. Muller{Jones und W.Lamersdorf. Mobile Klienten:
Ortsubergreifender Zugang zu Diensten in o enen verteilten Informationssystemen.
In F. Huber-Waschle, H. Schauer und P. Widmayer,
Hrsg., GISI 95 { Herausforderungen eines globalen Informationsverbundes
fur die Informatik, Zurich, 1995, S.423{430.
Springer{Verlag, 1995.
[MML95b] M. Merz, K. Muller{Jones und W. Lamersdorf. Petrinetz{
basierte Modellierung und Steuerung unternehmensubergreifender
Geschaftsprozesse. In F. Huber-Waschle, H. Schauer und P. Widmayer,
Hrsg., GISI 95 { Herausforderungen eines globalen Informationsverbundes
fur die Informatik, Zurich, 1995, S.215{222.
Springer{Verlag, 1995.

LITERATURVERZEICHNIS 303
[MML95c] M. Merz, K. Muller und W.Lamersdorf. End{user support in the
tourist industry: requirementsand architectures. In Proceedings of
the International Conference on Information and Communication
Technologies in Tourism (ENTER '95), Innsbruck, Osterreich,
Februar 1995. Springer{Verlag.
[MML95d] K. Muller{Jones,M.Merz und W. Lamersdorf. Kooperationsanwendungen:
Integrierte Vorgangskontrolle und Dienstvermittlung
in o enen verteilten Systemen. In F. Huber-Waschle, H. Schauer
und P. Widmayer, Hrsg., GISI 95 { Herausforderungen eines globalen
Informationsverbundes fur die Informatik, Zurich, 1995, S.
518{525. Springer{Verlag, 1995.
[MML95e] K. Muller{Jones, M. Merz und W. Lamersdorf. Realisierung von
Kooperationsanwendungen auf der Basis erweiterter Diensttypbeschreibungen.
In H. Krumm, Hrsg., Entwicklung und Management
verteilter Anwendungssysteme: Tagungsband� 2. Arbeitstre ens der
GI/ITG Fachgruppe Kommunikation und Verteilte Systeme und
der GI Fachgruppe Betriebssysteme� Universitat Dortmund� 9./10.
Oktober 1995, S. 21{30, Munster, 1995. Krehl Verlag.
[MML95f] K. Muller{Jones,M.Merz und W. Lamersdorf. The TRADEr: Integrating
Trading Into DCE. In K. Raymond und L. Armstrong,
Hrsg., Open Distributed Processing: Experiences with distributed
environments, Proceedings of the third IFIP TC 6/WG 6.1 international
conference onopen distributed processing, 1995, S. 476{
487. Chapman & Hall, 1995.
[MML96] M. Merz, K. Muller{Jones und W. Lamersdorf. Services, Agents,
and Electronic Markets: How dothey Integrate ? In A. Schill,
C. Mittasch, O. Spaniol und C.Popien, Hrsg., Distributed Platforms
| Proceedings of the IFIP/IEEE International Conference
on Distributed Platforms: Client/Server and Beyond: DCE, COR-
BA, ODP and Advanced Distributed Applications, S. 287{300.
Chapman & Hall, 1996.
[MMML95] M. Merz, D. Moldt, K. Muller und W.Lamersdorf. Work ow Modelling
and Execution with Coloured Petri Nets inCOSM. In
Workshop on Applications of Petri Nets to Protocols, Proceedings
16th International Conference on Application and Theory of Petri
Nets, 1995.
[Mof94] J.D. Mo et. Speci cations of Management Policies and Discretionary
Access Control. In M. Sloman, Hrsg., Network and Distributed
Systems Management, Kapitel 17, S. 455{480. Addison{Wesley,
1994.
[Mul95] S. Muller. Abbildung eines Trader{Entwurfs auf eine vorhandene
System{Architektur. Studienarbeit, Fachbereich Informatik, Universitat
Hamburg, Februar 1995.

304 LITERATURVERZEICHNIS
[Mul96] S. Muller. Entwurf eines Kooperationskonzeptes fur Dienstvermittlungskomponenten
in o enen verteilten Systemen. Diplomarbeit,
Universitat Hamburg, Fachbereich Informatik, 1996.
[Mur89] T. Murata. Petri Nets: Properties, Analysis and Applications. In
Proceedings of the IEEE, Band 77, S. 541{580, 1989.
[MZP96] B. Meyer, S. Zlatintsis und C.Popien. Enabling Interworking between
Heterogeneous Distributed Platforms. In A. Schill, C. Mittasch,
O. Spaniol und C.Popien, Hrsg., Distributed Platforms |
Proceedings of the IFIP/IEEE International Conference on Distributed
Platforms: Client/Server and Beyond: DCE, CORBA, ODP
and Advanced Distributed Applications, S. 329{341. Chapman &
Hall, 1996.
[ND95] O. Nierstrasz und L. Dami. Component{Oriented Software Technology.
In O. Nierstrasz und D.Tsichritzis, Hrsg., Component{
Oriented Software Composition, Kapitel 1, S. 160{165. Prentice
Hall, 1995.
[NDC95] G. Nilsson, F. Dupuy und M.Chapman. An Overview of the Telecommunications
Information Networking Architecture. In Proceedings
of the TINA '95 Conference, Melbourne, Australia, 1995.
[Nel81] B.J. Nelson. Remote Procedure Call. Technical Report CSL{81{9,
Xerox PARC, Mai 1981.
[Neu89] G. Neufeld. Descriptive Names in X.500. ACM SIGCOM Computer
Communication Review, 19, Heft 4, S. 64{71, 1989.
[Nie93] O. Nierstrasz. Regular Types for Active Objects. In Proceedings
of the 8th Annual Conference on Object{Oriented Programming
Systems, Languages, and Applications (OOPSLA '93).ACM press,
1993.
[NM90] J. Nehmer und F.Mattern. Service Modeling in Distributed Operating
Systems. In Proceedings of the 2nd Workshop on Future
Trends on Distributed Computing in the 1990's, S. 70{96, Cairo,
Egypt, September 1990. IEEE.
[NP91] O. Nierstrasz und M.Papathomas. Towards a Type Theory for
Active Objects. In ACM OOPS Messenger, Proceedings OOPS-
LA/ECOOP '90 Workshop on Object{Based Concurrent Systems,
Band 2, S. 89{93. ACM press, April 1991.
[NS95] E. Najm und J.-B. Stefani. A formal semantics for the ODP computational
model. Computer Networks and ISDN Systems, 27, S.
1305{1329, 1995.
[ODP93] ISO/IEC JTC1/SC21: Working Document onTopic 9.1 { ODP
Trader. International Standardisation Organisation, November
1993.

LITERATURVERZEICHNIS 305
[ODP94a] ISO/IEC JTC1/SC21 N8409: Working Document { ODP Trading
Function. International Standardisation Organisation, Januar
1994.
[ODP94b] ISO/IEC JTC1/SC21 N9122: ISO/IEC 13235: 1994/Draft ODP
TradingFunction. International Standardisation Organisation, Juli
1994.
[ODP95a] ISO/IEC 13235 { ODP TradingFunction. International Organisation
for Standardization, International Electrotechnical Commission,
Juni 1995. Draft International Standard.
[ODP95b] Basic Reference Model of Open Distributed Processing |Part
1: Overview. Draft International Standard 10746{1 . International
Organisation for Standardization, International Electrotechnical
Commission, 1995.
[ODP95c] Basic Reference Model of Open Distributed Processing |Part 3:
Architecture. International Standard 10746{3 . International Organisation
for Standardization, International Electrotechnical Commission,
1995.
[Oh96] S.-H. Oh. Entwurf und Entwicklung einer Systemkomponente zur
Ablage von Dienstbeschreibungen in heterogenen verteilten Systemen.
Diplomarbeit, Universitat Hamburg, Fachbereich Informatik,
1996.
[OMG91] The Common Object Request Broker: Architecture and Speci cation.
Digital Equipment Corporation, Hewlett{Packard Company,
HyperDesk Corporation, NCR Corporation, Object Design Incorporated,
SunSoft Incorporated, 1991.
[OMG92] Object Management Architecture Guide. Object Management
Group, September 1992.
[OMG95] CORBA 2.0/Interoperability { Universal Networked Objects. BNR
Europe Ltd., Digital Equipment Corporation, Expersoft Corporation,
Hewlett{Packard Company, IBM Corporation, ICL, plc., IONA
Technologies, SunSoft Incorporated, 1995.
[OPR96] R. Otte, P. Patrick und M.Roy. Understanding CORBA: The
Common Object Request Broker Architecture. Prentice Hall, 1996.
[OSF92] OSF. Introduction to OSF DCE. Prentice{Hall, Englewood Cli s,
New Jersey, 1992.
[OSF93a] OSF. OSF DCE Application Development Guide. Prentice{Hall,
Inc., Englewood Cli s, New Jersey, 1993.
[OSF93b] OSF. OSF DCE Application Development Reference. Prentice{
Hall, Englewood Cli s, New Jersey, 1993.

306 LITERATURVERZEICHNIS
[Pag91] B. Page. Diskrete Simulation. Springer{Verlag, 1991.
[Par72] D.L. Parnas. On the criteria to beusedindecomposing systems
into modules. Communications of the ACM, 15, S. 1053{1058,
1972.
[Paw91] P. Pawlita. DCE | Verteilte Verarbeitung in Multi{Vendor{
Netzen wird Realitat. Praxis der Informationsverarbeitung und
Kommunikation (PIK), 14, Heft 4, S. 249{251, Oktober 1991.
[PB96] A. Puder und C. Burger. New Concepts for Qualitative Trader
Cooperation. In A. Schill, C. Mittasch, O. Spaniol und C.Popien,
Hrsg., Distributed Platforms | Proceedings of the IFIP/IEEE
International Conference on Distributed Platforms: Client/Server
and Beyond: DCE, CORBA, ODP and Advanced Distributed Applications,
S. 301{313. Chapman & Hall, 1996.
[Pet62] C.A. Petri. Kommunikation mit Automaten. Dissertation, Institut
fur Instrumentelle Mathematik, Universitat Bonn, 1962.
[Pet81] J.L. Peterson. Petri Net Theory and the Modeling of Systems.
Prentice{Hall, 1981.
[PGM95] A. Puder, F. Gudermann und S. Markwitz. Ein Mehrphasen{
Protokoll fur wissensbasierte Dienstvermittlung. In H. Krumm,
Hrsg., Entwicklung und Management verteilter Anwendungssysteme:
Tagungsband� 2. Arbeitstre ens der GI/ITG Fachgruppe
Kommunikation und Verteilte Systeme und der GI Fachgruppe
Betriebssysteme� Universitat Dortmund� 9./10. Oktober 1995,
Munster, 1995. Krehl Verlag.
[PM93] C. Popien und B.Meyer. Federating ODP Traders: An X.500 Approach.
In Proceedings of the International Conference on Communications
1993 (ICC'93), Geneva, Switzerland, S. 33{317, 1993.
[Pop95] C. Popien. Dienstvermittlung in Verteilten Systemen. Teubner,
1995.
[PS85] J.L. Peterson und A. Silberschatz. Operating System Concepts.
Addison{Wesley, 1985.
[PSW96] C. Popien, G. Schurmann und K.-H. Wei . Verteilte Verarbeitung
in O enen Systemen. Teubner, 1996.
[PZTT91] R. Popescu-Zeletin, V. Tschammer und M.Tschichholz. Y distributed
application platform. Computer Communication, 14, Heft 6,
S. 366{374, 1991.
[Rad94] S. Radicati. X.500 Directory Services: Technology and Deployment.
Van Nostrand Reinhold, 1994.

LITERATURVERZEICHNIS 307
[RBP + 91] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy und W. Lorenzen.
Object{oriented Modelling and Design. Prentice{Hall, 1991.
[Rei86] W. Reisig. Petrinetze: Eine Einfuhrung. Springer{Verlag, 1986.
[Rei93] B. Reinwald. Work ow{Management in verteilten Systemen. B.G.
Teubner Verlagsgesellschaft, 1993.
[RH95] A. Richman und D. Hoang. Accomplishing Distributed Traders
Utilizing the X.500 Directory. InProceedings of the 2nd IEEE Malaysia
International Conference on Communications (MICC'95),
November 1995, Malaysia, 1995.
[Ric83] G. Richter. Netzmodelle fur die Burokommunikation. Informatik
Spektrum, 6, Heft 4, S. 28{40, 1983. Teil 1.
[RKF93] W. Rosenberry, D.Kenny und G.Fisher. Understanding DCE.
O'Reilly & Associates, Inc., 1993.
[Ros92] M.T. Rose. The Little Black Book: Mail Bonding with OSI Directory
Services. Prentice{Hall, 1992.
[RTL + 91] R. Ray, E.Tempero, H. Levy, A. Black, N. Hutchinson und E. Jul.
Emerald: A General Purpose Programming Language. Software{
Practice and Experience, 21, Heft 1, S. 91{118, Januar 1991.
[SB93] C. Sibertin-Blanc. A Client-Server Protocol for the Composition of
Petri Nets. In Proceedings of the 14th International Conference on
Application and Theory of Petri Nets, Lecture Notes in Computer
Science 691, S. 377{396. Springer{Verlag, 1993.
[SB94] C. Sibertin-Blanc. Cooperative Nets. In Proceedings of the 15th International
Conference on Application and Theory or Petri Nets,
Lecture Notes in Computer Science 815, S. 471{490. Springer{
Verlag, 1994.
[Sch92a] A. Schill. Namensverwaltung inverteilten Systemen { Ein Uberblick.
Praxis der Informationsverarbeitung und Kommunikation,
15, Heft 1, S. 11{21, 1992.
[Sch92b] A. Schill. Remote Procedure Call: Fortgeschrittene Konzepte und
Systeme {einUberblick. Informatik{Spektrum, 15, Heft 2, S. 79{
87, April 1992.
[Sch92c] J.M. Schneider. Protocol Engineering: A Rule{Based Approach.
Vieweg, 1992.
[Sch93a] A. Scheller. Informationsmodellierung fur verteilte Anwendungen
auf Basis standardisierter Datenmodelle. GMD{Bericht Nr. 214,
Gesellschaft fur Mathematik und Datenverarbeitung, Bonn, 1993.

308 LITERATURVERZEICHNIS
[Sch93b] A. Schill. DCE: Das OSF Distributed Computing Environment.
Springer{Verlag, 1993.
[Sch93c] F. Schwenkreis. APRICOTS { A Prototype Implementation of
a ConTract System { Management ofthe Control Flow andthe
Communication System. In Proceedings of the 12th Symposium on
Reliable Distributed Systems. IEEE Computer Society Press, 1993.
[SM83] G. Salton und M.J. McGill. Introduction to Modern Information
Retrieval. McGraw{Hill, 1983.
[Sou94] J. Soukup. Taming C++: pattern classes and persistence for large
projects. Addison{Wesley, 1994.
[Sow84] J.F. Sowa. Conceptual Structures, information processing mind
and machine. Addison{Wesley, 1984.
[Spi89] J.M. Spivey. The Z Notation. Prentice Hall, 1989.
[SPM94] O. Spaniol, C. Popien und B.Meyer. Dienste und Dienstvermittlung
in Client/Server{Systemen, Band1ofThomson's aktuelle Tutorien.
International Thomson Publishing, Bonn, 1994.
[Spr96] A. Sprenger. Entwicklung einer Trader{Komponente zur Verwaltung
statischer und dynamischer Diensteigenschaften. Diplomarbeit,
Universitat Hamburg, Fachbereich Informatik, 1996.
[Str93] B. Stroustrup. The C++ Programming Language. Addison{
Wesley, 1993.
[Sun90] Sun Microsystems Incorporated. Network Programming Guide,
1990.
[SV89] M. Silva undR.Valette. Petri Netsand Flexible Manufacturing. In
Advances in Petri Nets, Lecture Notes in Computer Science 424,
S. 374{417. Springer{Verlag, 1989.
[Svo85] L. Svobodava. Client/Server Model of Distributed Processing.
Technical Report RZ 1350, IBM, Zurich, 1985.
[Tol94] R. Tolksdorf. Coordination in Open Distributed Systems. Dissertation,
Technische Universitat Berlin, 1994.
[Tsc94] V. Tschammer. Integration kooperierender Systeme: Architektur
und Dienstplattform fur o ene verteilte Anwendungen. Number
220 in Berichte der Gesellschaft fur Mathematik und Datenverarbeitung.
R. Oldenbourg Verlag, 1994.
[TWH90] V. Tschammer,A.Wolisz und J. Hall. Support for Cooperation and
Coherence in an Open Service Environment. In Proceedings of the
2nd IEEE Workshop on Future Trends on Distributed Computing
in the 1990's, S. 222{228, Cairo, Egypt, September 1990. IEEE.

LITERATURVERZEICHNIS 309
[TWW92] V. Tschammer,A.Wolisz und M.Walch. The performance of multiple
traders operating inthe same domain. In Proceedings of the
3rd IEEE Workshop on Future Trends on Distributed Computing
in the 1990's. IEEE, 1992.
[Val87] R. Valk. Modelling ofTask Flow in Systems of Functional Units.
Bericht FBI-HH-B-124/87, Universitat Hamburg, 1987.
[VBB95] A. Vogel, M. Bearman und A. Beitz. EnablingInterworkingofTraders.
In K. Raymond und L. Armstrong, Hrsg., Open Distributed
Processing: Experiences with distributed environments, Proceedings
of the third IFIP TC 6/WG 6.1 international conference onopen
distributed processing, 1995, S. 185{196. Chapman & Hall, 1995.
[Vog94] A. Vogel. Towards the Implementation of Interworking ofTraders.
http://www.dstc.edu.au/AU/projects/iwt, 1994.
[Vol95] B. Volker. Verwaltung von Schnittstellenbeschreibungen zur Unterstutzung
o ener Client/Server{Kooperationen. Diplomarbeit,
Universitat Hamburg, Fachbereich Informatik, Januar 1995.
[VS87] G. Vissers und G. Scollo. Formal Speci cation in OSI. In Proceedings
of the International Seminar on Networking in Open Systems,
Oberlech, Austria, 1986, Lecture Notes in Computer Science
248, S. 338{359. Springer{Verlag, 1987.
[Way94] P. Wayner. Agents Away. BYTE, S. 133{138, Mai 1994.
[WB95] A. Waugh und M. Bearman. Designing an ODP Trader Implementation
using X.500. In K. Raymondund L. Armstrong, Hrsg., Open
Distributed Processing: Experiences with distributed environments,
Proceedings of the third IFIP TC 6/WG 6.1 international conference
onopen distributed processing, 1995, S. 133{144. Chapman
& Hall, 1995.
[Weg87] P. Wegener. Dimensions of object{based language design. ACM
SIGPLAN Notices, 22, Heft 12, S. 168{182, Dezember 1987.
[Whi94] J.E. White. Telescript Technology: The Foundation for the Electronic
Marketplace. White Paper, General Magic Incorporated,
1994.
[Win93] A. Winckler. Dezentrale Ablaufsteuerung inVerteilten Systemen.
In N. Gerner, H.-G. Hegering und J.Swoboda, Hrsg., KommunikationinVerteilten
Systemen, S. 302{316, Munchen, Mai 1993.
Springer{Verlag. ITG/GI{Fachtagung.
[Wir82] N. Wirth. Programmierung in Modula{2. Springer{Verlag, 1982.
[WR90] H. Wachter und A. Reuter. Grundkonzepteund Realisierungsstrategien
des ConTract{Modells. Informatik Forschung und Entwicklung,
5, S. 202{212, 1990.

310 LITERATURVERZEICHNIS
[WR91] H. Wachter und A.Reuter. The ConTract Model. In A.K. Elmagarmid,
Hrsg., Database Transaction Models for Advanced Applications,
S. 219{263. Morgan Kaufmann Publishers, 1991.
[WT90] A. Wolisz und V. Tschammer. Service Provider Selection in
an Open Services Environment. In Proceedings of the 2nd IE-
EE Workshop on Future Trends on Distributed Computing in the
1990's, S. 229{235. IEEE, September 1990.
[WT93] A. Wolisz und V. Tschammer. Performance aspects of trading in
open distributed systems. computer communications, 16, Heft 5,
S. 277{287, Mai 1993.
[YV96] Z. Yang und A.Vogel. Achieving interoperability between COR-
BA and DCE applications using bridges. In A. Schill, C. Mittasch,
O. Spaniol und C.Popien, Hrsg., Distributed Platforms | Proceedings
of the IFIP/IEEE International Conference on Distributed
Platforms: Client/Server and Beyond: DCE, CORBA, ODP and
Advanced Distributed Applications, S. 144{155. Chapman & Hall,
1996.
[Zbo96] S. Zbornik. Elektronische Markte, elektronische Hierarchien und
elektronische Netzwerke: Koordination des wirtschaftlichen Leistungsaustausches
durch Mehrwertdienste auf der Basis von EDI
und o enen Kommunikationssystemen, diskutiert am Beispiel der
Elektronikindustrie. VVK, Universitatsverlag Konstanz, 1996.
[Zit95] M. Zitterbart. Hochleistungskommunikation. R. Oldenbourg Verlag,
Band 1:Technologie und Netze. Ausgabe, 1995.
[ZW95] A.M. Zaremski und J.M. Wing. Signature Matching: A tool for
using software libraries. ACM TOSEM, April 1995.