Koordinierte Dienstnutzung in offenen verteilten Dienstemärkten
Koordinierte Dienstnutzung in offenen verteilten Dienstemärkten
Koordinierte Dienstnutzung in offenen verteilten Dienstemärkten
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
<strong>Koord<strong>in</strong>ierte</strong> <strong>Dienstnutzung</strong><br />
<strong>in</strong> o enen <strong>verteilten</strong> Dienstemarkten<br />
Kay Muller{Jones<br />
Vom Fachbereich Informatik<br />
der Universitat Hamburg<br />
zur Erlangung des akademischen Grades<br />
Doktor der Naturwissenschaften<br />
| Dr. rer. nat. |<br />
genehmigte Dissertation<br />
Promotionsausschu :<br />
Vorsitzender: Prof. Dr. Jantzen (Universitat Hamburg)<br />
Gutachter: Prof. Dr. Lamersdorf (Universitat Hamburg)<br />
Prof. Dr. Mahr (Technische Universitat Berl<strong>in</strong>)<br />
Tag der Disputation: 4. Dezember 1996
Fur Kathr<strong>in</strong>
Danksagungen<br />
Zunachst mochte ich Prof. Dr. Lamersdorf danken, der mir im Rahmen me<strong>in</strong>er<br />
wissenschaftlichen Mitarbeit am Fachbereich Informatik der Universitat<br />
Hamburg e<strong>in</strong>e Arbeitsatmosphare ermoglichte, die Freiraum fur die Umsetzung<br />
<strong>in</strong>novativer Ideen bot. Zudem mochte ich ihm fur se<strong>in</strong>e Anregungen zu der<br />
vorliegenden Arbeit danken.<br />
In diesem Zusammenhang mochte ich mich auch bei Prof. Dr. Mahr fur die mit<br />
ihm gefuhrten Diskussionen bedanken.<br />
Weiterh<strong>in</strong> bedanke ichmich bei den zahlreichen Student<strong>in</strong>nen und Studenten,<br />
die mit ihren Studien{ und Diplomarbeiten ma geblich zu dieser Arbeit<br />
beigetragen haben, <strong>in</strong>sbesondere Ludwig Br<strong>in</strong>ckmann, Bernd Christiansen, Kai<br />
Greese, Frank Gri el, Stefan Muller, Malte Munke, Se{Hyeon Oh und Andre<br />
Sprenger.<br />
Insbesondere mochteichmichauch bei me<strong>in</strong>em Kollegen Michael Merz und beim<br />
Doktoranden Tuan Tu fur ihre Zusammenarbeit und Diskussionsbereitschaft<br />
bedanken.<br />
Nichtzuletzt danke ichauch unseren Projektpartnern von der GMD FOKUS <strong>in</strong><br />
Berl<strong>in</strong> und vom DSTC <strong>in</strong> Brisbane, Australien.
Zusammenfassung<br />
Durch die zunehmende Verfugbarkeit moderner hochleistungsfahiger Kommunikationstechnologien<br />
s<strong>in</strong>d heutzutage wesentliche Voraussetzungen fur e<strong>in</strong>e e ziente,<br />
rechnerbasierte Unterstutzung weltweiter Kooperationen gegeben. Trotz der <strong>in</strong> e<strong>in</strong>em<br />
derartig globalen " Internet\ <strong>in</strong>harent vorhandenen Heterogenitat sollte dabei auf<br />
verschiedenartigste Dienstleistungen zugegri en werden konnen, die nicht mehr am<br />
Ort des Zugri s, sondern an beliebiger Stelle im Netzwerk angeboten werden konnen.<br />
Durch e<strong>in</strong>ederartige <strong>Dienstnutzung</strong> wird die Scha ung elektronischer Dienstemarkte<br />
motiviert, <strong>in</strong> denen | ahnlich zuherkommlichen Warenmarkten|e<strong>in</strong>e gro e Vielfalt<br />
und Vielzahl von Dienstleistungen angeboten und von unterschiedlichen Interessenten<br />
<strong>in</strong> Anspruch genommen werden konnen.<br />
Angesichts dieser neuartigen Moglichkeiten gew<strong>in</strong>nen derartige o ene verteilte<br />
Dienstemarkte auch fur die Software{Entwicklung neuer verteilter Anwendungssysteme<br />
zunehmend anInteresse. E<strong>in</strong>er der Hauptgrunde hierfur ist die Forderung nach Wiederverwendung,<br />
um moglichst aufwendige und damit kosten<strong>in</strong>tensive Neuentwicklungen<br />
zu vermeiden. Um auf diese Weise die verteilt angebotenen Dienste nun <strong>in</strong>Form e<strong>in</strong>es<br />
Systembaukastens von Diensten bei der Entwicklung verteilter Anwendungen nutzen zu<br />
konnen, s<strong>in</strong>d |uber das Netz als re<strong>in</strong>es Kommunikationsmittel h<strong>in</strong>aus | zusatzliche<br />
systemtechnische Unterstutzungsmechanismen bereitzustellen. Diese sollen den Zugang<br />
zu den Diensten ermoglichen und die dann verfugbaren Dienste auch koord<strong>in</strong>iert und<br />
moglichst unberucksichtigt von Verteilungs{ und Heterogenitatsproblemen nutzbar<br />
machen.<br />
Die vorliegende Arbeitschlagt hierzu zunachst e<strong>in</strong>en umfassenden und <strong>in</strong>herkommliche<br />
verteilte Systemplattformen <strong>in</strong>tegrierten Losungsansatz vor, der sich dann konkret <strong>in</strong><br />
dem Entwurf und der prototypischen Realisierung der entwickelten Unterstutzungsmechanismen<br />
<strong>in</strong> der <strong>verteilten</strong> Systemumgebung TRADE (Service Trad<strong>in</strong>g and Coord<strong>in</strong>ation<br />
Environment) widerspiegelt. Dieser Ansatz zur systemtechnischen Unterstutzung<br />
koord<strong>in</strong>ierter <strong>Dienstnutzung</strong> <strong>in</strong> o enen heterogenen <strong>verteilten</strong> Dienstemarkten bietet<br />
als wesentliche " generische\ Systemkomponenten zum e<strong>in</strong>en Typmanagement{,<br />
Dienstvermittlungs{ und Interzeptionsmechanismen, die e<strong>in</strong>en weitgehend une<strong>in</strong>geschrankten<br />
Dienstzugang ermoglichen. Insbesondere die Dienstvermittlung stellt e<strong>in</strong>es<br />
der zentralen <strong>in</strong> dieser Arbeit untersuchten Probleme dar. Zum anderen werden<br />
|auf den elementaren generischen Unterstutzungsdiensten aufbauend | allgeme<strong>in</strong>e<br />
Koord<strong>in</strong>ationsmechanismen entworfen und imRahmen der TRADE{Realisierung<br />
zur Verfugung gestellt. Diese unterstutzen die verteilungsabstrahierende Beschreibung<br />
und Ausfuhrung sogenannter Kooperationsanwendungen. Der <strong>in</strong> dieser Arbeit hierfur<br />
gewahlte Ansatz zeichnet sich vor allem durch se<strong>in</strong>e Konzentration auf die Koord<strong>in</strong>ationsaspekte<br />
von <strong>Dienstnutzung</strong> aus. Dieses au ert sich unmittelbar auch <strong>in</strong>der im<br />
Rahmen der hier dargestellten Arbeiten entwickelten Koord<strong>in</strong>ationssprache PAMELA<br />
(Petri net based Activity Management Execution Language) und e<strong>in</strong>em dazugehorigen<br />
Koord<strong>in</strong>ationsmanager. Beide ermoglichen e<strong>in</strong>e neuartige Sichtweise auf die Programmierung<br />
verteilter Anwendungen unter Nutzung von <strong>in</strong> o enen <strong>verteilten</strong> Dienstemarkten<br />
an beliebiger Stelle angebotenen Diensten.
Inhaltsverzeichnis<br />
1 E<strong>in</strong>leitung 1<br />
1.1 Potentiale und Probleme verteilter Systeme : : : : : : : : : : : : : 1<br />
1.2 Das Paradigma der <strong>Dienstnutzung</strong> :::::::::::::::::: 5<br />
1.3 Vision ausschlie licher <strong>Dienstnutzung</strong> :::::::::::::::: 5<br />
1.4 Zielstellung und Uberblick :::::::::::::::::::::: 7<br />
I Grundkonzepte zur Unterstutzung koord<strong>in</strong>ierter <strong>Dienstnutzung</strong><br />
<strong>in</strong>heterogenen <strong>verteilten</strong> Dienstemarkten 11<br />
2 Modellierung und Beschreibung von Diensten 13<br />
2.1 Interoperabilitatsebenen ::::::::::::::::::::::: 13<br />
2.1.1 Dienstmodellebene :::::::::::::::::::::: 14<br />
2.1.2 Dienstbeschreibungsebene :::::::::::::::::: 15<br />
2.1.3 Dienstreprasentationsebene :::::::::::::::::: 16<br />
2.2 Dienstmodelle ::::::::::::::::::::::::::::: 18<br />
2.2.1 Der Objektbegri <strong>in</strong> <strong>verteilten</strong> Systemen : : : : : : : : : : 18<br />
2.2.2 Der Dienstbegri ::::::::::::::::::::::: 20<br />
2.2.3 Modellierung von Schnittstellen ::::::::::::::: 22<br />
2.3 Typisierung von Schnittstellen und Diensten : : : : : : : : : : : : 23<br />
2.3.1 Schnittstellen{ und Diensttypen ::::::::::::::: 24<br />
2.3.2 Beziehungen zwischen Diensttypen : : : : : : : : : : : : : 25<br />
2.4 Formen von Dienstbeschreibungen :::::::::::::::::: 28<br />
2.4.1 Benennung von Diensten ::::::::::::::::::: 29<br />
2.4.2 Strukturelle Dienstbeschreibungen : : : : : : : : : : : : : 30<br />
2.4.3 Beschreibung von Diensteigenschaften : : : : : : : : : : : 32<br />
2.4.3.1 Dienstattribute ::::::::::::::::::: 32<br />
2.4.3.2 Konzeptgraphen :::::::::::::::::: 33<br />
2.4.4 Beschreibung des Verhaltens von Diensten ::::::::: 35<br />
2.4.4.1 Protokollspezi kationen : : : : : : : : : : : : : : 35<br />
2.4.4.2 Anwendung von Transitionssystemen ::::::: 37<br />
2.4.4.3 Spezi kation von Vor{ und Nachbed<strong>in</strong>gungen : : 38<br />
2.4.5 Bewertung ::::::::::::::::::::::::::: 40<br />
2.5 Zusammenfassung ::::::::::::::::::::::::::: 43
ii INHALTSVERZEICHNIS<br />
3 Zugang zu Diensten <strong>in</strong> heterogenen Umgebungen 45<br />
3.1 Grundlegende Problemstellungen :::::::::::::::::: 45<br />
3.1.1 Heterogenitat auf Verarbeitungsebene :::::::::::: 47<br />
3.1.2 Dienstzugangsphasen ::::::::::::::::::::: 49<br />
3.1.2.1 Au nden von Diensttypen ::::::::::::: 49<br />
3.1.2.2 Dienstauswahl ::::::::::::::::::: 51<br />
3.1.2.3 Dienstzugri :::::::::::::::::::: 51<br />
3.2 Diensttypmanagement :::::::::::::::::::::::: 52<br />
3.2.1 Typmanagement<strong>in</strong>heutigen <strong>verteilten</strong> Systemplattformen 54<br />
3.2.1.1 Schnittstellenrepository <strong>in</strong> CORBA : : : : : : : : 54<br />
3.2.1.2 Typverwaltung <strong>in</strong>ANSA:::::::::::::: 55<br />
3.2.2 Aufgaben des Diensttypmanagements :::::::::::: 56<br />
3.2.2.1 Anforderungen an Dienstbeschreibungen : : : : : 57<br />
3.2.2.2 Arten von Typbeziehungen :::::::::::: 58<br />
3.2.2.3 Ablage von Beziehungen und Typen ::::::: 63<br />
3.2.2.4 Typbezeichner und Aliasnamen :::::::::: 63<br />
3.2.2.5 Typverwaltungsdomanen :::::::::::::: 64<br />
3.2.2.6 Diensttyphierarchien :::::::::::::::: 65<br />
3.2.2.7 Typuberprufungen und {vergleiche : : : : : : : : 68<br />
3.2.3 Grundlagen e<strong>in</strong>es <strong>verteilten</strong> Diensttypmanagements :::: 71<br />
3.2.3.1 Global e<strong>in</strong>deutige Typbezeichner ::::::::: 72<br />
3.2.3.2 Austausch von Typbeschreibungen : : : : : : : : 73<br />
3.3 Vermittlung und Verwaltung von Dienstangeboten ::::::::: 75<br />
3.3.1 Mechanismen zur Dienstauswahl ::::::::::::::: 75<br />
3.3.1.1 Namens{ und attributbasierte Dienstauswahl : : 75<br />
3.3.1.2 Brows<strong>in</strong>g{basierte Dienstauswahl ::::::::: 77<br />
3.3.1.3 Diensttypbasierte Dienstauswahl ::::::::: 78<br />
3.3.2 ODP{basiertes Trad<strong>in</strong>g :::::::::::::::::::: 78<br />
3.3.2.1 Export und Import von Dienstangeboten : : : : : 78<br />
3.3.2.2 Verwaltung von Dienstangeboten ::::::::: 80<br />
3.3.2.3 Dienstangebotsauswahl ::::::::::::::: 83<br />
3.3.3 Verteilte Dienstangebotsvermittlung ::::::::::::: 85<br />
3.3.3.1 Kooperationsformen von Tradern ::::::::: 86<br />
3.3.3.2 Aufbau direkter Trader{Kooperationen :::::: 90<br />
3.3.3.3 Kooperationsprotokolle ::::::::::::::: 91<br />
3.4 Domanenubergreifender Dienstzugri ::::::::::::::::101<br />
3.4.1 Aufgaben von Interzeption ::::::::::::::::::102<br />
3.4.1.1 Uberw<strong>in</strong>dung technischer Heterogenitatsgrenzen : 103<br />
3.4.1.2 Uberwachung und Kontrolle adm<strong>in</strong>istrativer Heterogenitatsgrenzen<br />
:::::::::::::::::106<br />
3.4.1.3 Erweiterung von Plattformkonzepten :::::::107<br />
3.4.1.4 Kompensation fehlender Domanenkonzepte :::108<br />
3.4.2 Entwurfsvarianten von Interzeptoren ::::::::::::108<br />
3.4.2.1 Statische Interzeption :::::::::::::::108<br />
3.4.2.2 Dynamische Interzeption ::::::::::::::110<br />
3.4.3 Ubermittlung von Fremdkonzepten :::::::::::::110<br />
3.5 Zusammenfassung :::::::::::::::::::::::::::112
INHALTSVERZEICHNIS iii<br />
4 Koord<strong>in</strong>ation von Diensten 115<br />
4.1 <strong>Dienstnutzung</strong> <strong>in</strong><strong>verteilten</strong> Anwendungen : : : : : : : : : : : : :116<br />
4.1.1 Ubergang zur weitestgehenden Nutzung externer Dienste : 116<br />
4.1.2 Benotigte Beschreibungs{ und Modellierungskonzepte :::119<br />
4.2 Beschreibung und Modellierung koord<strong>in</strong>ierter <strong>Dienstnutzung</strong> :::121<br />
4.2.1 Kooperationsanwendungen und Anwendungsvorgange :::121<br />
4.2.2 Petri{Netze als Beschreibungsgrundlage : : : : : : : : : :122<br />
4.2.3 Beschreibungskonzepte ::::::::::::::::::::124<br />
4.2.3.1 Datenkonzept ::::::::::::::::::::124<br />
4.2.3.2 Kontroll u konzept ::::::::::::::::126<br />
4.2.3.3 Dienstorientiertes Aktionskonzept :::::::::126<br />
4.2.3.4 Nebenlau gkeitskonzept : : : : : : : : : : : : : :128<br />
4.2.3.5 Strukturierungskonzept : : : : : : : : : : : : : :129<br />
4.2.3.6 Fehlerbehandlungskonzept : : : : : : : : : : : : :130<br />
4.2.3.7 Interaktionskonzept ::::::::::::::::132<br />
4.2.3.8 Transaktionskonzept ::::::::::::::::134<br />
4.3 Bewertung und erganzende Bemerkungen : : : : : : : : : : : : : :136<br />
II TRADE: E<strong>in</strong>e verteilte Systemumgebung zur Vermittlung<br />
und Koord<strong>in</strong>ation von Diensten 139<br />
5 Systemunterstutzung fur den Dienstzugang 143<br />
5.1 Diensttypmanagement <strong>in</strong> TRADE ::::::::::::::::::144<br />
5.1.1 Beschreibung von Diensten ::::::::::::::::::145<br />
5.1.1.1 E<strong>in</strong> kanonisches Diensttypmodell :::::::::147<br />
5.1.2 Beschreibung und Verwaltung von Beziehungstypen und<br />
{<strong>in</strong>stanzen :::::::::::::::::::::::::::148<br />
5.1.2.1 Unterstutzung von Konformitatsbeziehungen :::149<br />
5.1.2.2 Automatisierter Aufbau von Diensttyphierarchien 152<br />
5.1.2.3 Suche nach konformen Diensttypen : : : : : : : :153<br />
5.1.3 Austausch und Verarbeitung von Typbeschreibungen :::154<br />
5.1.4 Aufbau des Typmanagers :::::::::::::::::::156<br />
5.1.4.1 Typmanagerkern ::::::::::::::::::157<br />
5.1.4.2 Repositories :::::::::::::::::::::157<br />
5.1.4.3 Abbildungskomponenten : : : : : : : : : : : : : :158<br />
5.1.4.4 Graphische Benutzerschnittstelle :::::::::158<br />
5.1.5 Bewertung und erganzende Anmerkungen : : : : : : : : : :159<br />
5.2 Dienstvermittlung und {verwaltung durch den TRADEr ::::::160<br />
5.2.1 Komponenten des TRADErs :::::::::::::::::160<br />
5.2.2 Dienstangebotsverwaltung und {vermittlung : : : : : : : :161<br />
5.2.2.1 Verwendung attributbasierter Namensdienste : :162<br />
5.2.2.2 Das Attributmanagementsystem : : : : : : : : : :164<br />
5.2.2.3 Ablauf e<strong>in</strong>er domanenbegrenzten Dienstangebotsvermittlung<br />
:::::::::::::::::::166<br />
5.2.3 Aufbau von Trader{Kooperationen : : : : : : : : : : : : :167<br />
5.2.3.1 IWT{Testszenario :::::::::::::::::169
iv INHALTSVERZEICHNIS<br />
5.2.3.2 L<strong>in</strong>k{Kon gurationsmanager :::::::::::170<br />
5.2.3.3 Verwaltung und Nutzung von L<strong>in</strong>ks im TRADEr 172<br />
5.2.4 Bewertung und erganzende Anmerkungen ::::::::::175<br />
5.3 Domanenubergreifender Dienstzugri ::::::::::::::::180<br />
5.3.1 Voraussetzungen fur die Interzeption ::::::::::::181<br />
5.3.2 Entwurfsziele fur e<strong>in</strong>e Interzeptor{Komponente ::::::182<br />
5.3.3 Der Interzeptionsmechanismus ::::::::::::::::183<br />
5.3.3.1 Pr<strong>in</strong>zipielle Funktionsweise ::::::::::::183<br />
5.3.3.2 Entwurfsvarianten :::::::::::::::::186<br />
5.3.4 Implementationsaspekte des Interzeptors ::::::::::187<br />
5.3.5 Bewertung und erganzende Anmerkungen ::::::::::190<br />
6 Entwicklung und Ausfuhrung von Kooperationsanwendungen 193<br />
6.1 TRADE{Entwicklungsumgebung ::::::::::::::::::194<br />
6.1.1 Diensterstellung ::::::::::::::::::::::::194<br />
6.1.2 Entwicklung von Kooperationsanwendungen mittels der<br />
Koord<strong>in</strong>ationssprache PAMELA :::::::::::::::195<br />
6.1.2.1 Zielstellung und Entwurfsentscheidungen : : : : :196<br />
6.1.2.2 Sprachkonzepte :::::::::::::::::::197<br />
6.1.2.3 PAMELA{Beispielspezi kation e<strong>in</strong>es <strong>verteilten</strong><br />
kooperativen Anwendungsvorganges : : : : : : : :200<br />
6.1.2.4 Sichtweisen der Anwendungsprogrammierung<br />
mit PAMELA ::::::::::::::::::::203<br />
6.2 Ablaufkontrolle ::::::::::::::::::::::::::::206<br />
6.2.1 E<strong>in</strong>ordnung des Koord<strong>in</strong>ationsmanagers <strong>in</strong> TRADE ::::206<br />
6.2.2 Schnittstellen des Koord<strong>in</strong>ationsmanagers ::::::::::208<br />
6.2.2.1 De nitionsschnittstelle :::::::::::::::208<br />
6.2.2.2 Adm<strong>in</strong>istrationsschnittstelle ::::::::::::209<br />
6.2.2.3 Ausfuhrungsschnittstelle ::::::::::::::209<br />
6.2.3 Steuerung von Anwendungsvorgangen ::::::::::::210<br />
6.2.3.1 Objektorientierte Umsetzung von Petri{Netzen : 211<br />
6.2.3.2 Steuerungsalgorithmen :::::::::::::::213<br />
6.3 Bewertung und erganzende Anmerkungen ::::::::::::::216<br />
III Zusammenfassung und Ausblick 219<br />
A Koord<strong>in</strong>ationssprache PAMELA 227<br />
A.1 Beschreibung der Syntax und Semantik :::::::::::::::227<br />
A.1.1 Darstellung der Programmstruktur :::::::::::::238<br />
A.1.2 Vollstandige Grammatik :::::::::::::::::::239<br />
A.1.3 Reservierte Schlusselworter :::::::::::::::::241<br />
A.2 Anwendungsbeispiel: Work ow{Unterstutzung im Hotel ::::::242<br />
A.2.1 Graphische Benutzerschnittstellen der Hotelanwendung : :245<br />
B Beschreibung des kanonischen Typmodells 247<br />
C Operationale Schnittstelle des Typmanagers 259
INHALTSVERZEICHNIS v<br />
D TRADEr{Schnittstellen 269<br />
D.1 Trad<strong>in</strong>g{Schnittstelle :::::::::::::::::::::::::269<br />
D.2 L<strong>in</strong>k{Management{Schnittstelle :::::::::::::::::::279<br />
E De nitionsschnittstelle des Koord<strong>in</strong>ationsmanagers 281<br />
E.1 Schnittstellenbeschreibung ::::::::::::::::::::::281<br />
E.2 Aus PAMELA generierter Programmkode : : : : : : : : : : : : :285<br />
Abbildungsverzeichnis 287<br />
Tabellenverzeichnis 291<br />
Literaturverzeichnis 293
Kapitel 1<br />
E<strong>in</strong>leitung<br />
1.1 Potentiale und Probleme verteilter Systeme<br />
Die Nutzung weltweiter Netzwerke und der dort angebotenen Dienstleistungen<br />
gew<strong>in</strong>nt immer mehr an Bedeutung. Schlusseltechnologie dieser Entwicklung ist<br />
die Telekommunikation. Durch Bereitstellung leistungsfahiger Kommunikationsmechanismen<br />
bietet sie die notwendigen technischen Voraussetzungen, Rechner<br />
lokal oder aber auch weltweit zu e<strong>in</strong>er geme<strong>in</strong>samen Infrastruktur zu verb<strong>in</strong>den.<br />
Moderne Hochleistungskommunikation [Zit95] ermoglicht hierbei e<strong>in</strong>e e ziente<br />
Ubermittlung gro er Mengen an Informationen mit hohen Geschw<strong>in</strong>digkeiten<br />
auch uber weite Distanzen h<strong>in</strong>weg. In diesem S<strong>in</strong>ne stellt die Kommunikationstechnologie<br />
e<strong>in</strong>e der elementaren Wegbereiter{Technologien (engl. enabl<strong>in</strong>g technologies)<br />
fur die Scha ung e zienter weltweiter rechnergestutzter Kooperation<br />
dar.<br />
Aufsetzend auf e<strong>in</strong>er derartigen Kommunikations<strong>in</strong>frastruktur konnen verschiedenartigstekooperativeAnwendungen<br />
entwickeltwerden, die die allgeme<strong>in</strong>en Potentiale<br />
verteilter Verarbeitungfur ihre speziellen Anwendungszweckeausnutzen.<br />
Aktuell diskutiert werden neuartige, sogenannte Gigabitanwendungen [Zit95], die<br />
e<strong>in</strong> Hochstma an Verzogerungsfreiheit bei der Versendung gro er Datenmengen<br />
auch uber gro e Entfernungen erfordern. Typische Anwendungsbeispiele s<strong>in</strong>d<br />
unter anderem Videokonferenzen, der Zugri auf graphische Informationen im<br />
" World{Wide{Web\ des Internets, " Video{on{Demand\, Virtuelle Realitat\,<br />
"<br />
kooperative rechnergestutzte Gruppenarbeit oder das verteilte Spielen.<br />
Neben diesen Gigabitanwendungen existieren noch e<strong>in</strong>e Vielzahl anderer verteilter<br />
Anwendungen, die direkten Nutzen aus der angebotenen Hochleistungskommunikation<br />
ziehen. So zeigt sich der Hauptnutzen leistungsfahiger Kommunikation<br />
nicht nur <strong>in</strong> der Versendung gro er Datenmengen <strong>in</strong> akzeptabler Zeit.<br />
Vielmehr tragt die Ubertragungsgeschw<strong>in</strong>digkeit auch zue<strong>in</strong>er " virtuellen Nahe\<br />
bei, so da die raumliche Verteilung der Komponenten, die oftmals uber weite<br />
Distanzen e<strong>in</strong>es <strong>verteilten</strong> Systems erfolgt, zunehmend anBedeutung verliert.<br />
Insbesondere fur den kommerziellen Sektor ist dieses <strong>in</strong> Zeiten des Aufbaus weltweiter<br />
unternehmens<strong>in</strong>terner und {ubergreifender Kooperationen sowie aufgrund
2 E<strong>in</strong>leitung<br />
zunehmender Dezentralisierung und Auslagerung (engl. outsourc<strong>in</strong>g) von Funktionsbereichen<br />
wirtschaftlich von hohem Interesse. Typische Beispiele derartiger<br />
kooperativer Anwendungen s<strong>in</strong>d die Abwicklung weltweit verteilter Buchungstransaktionen<br />
bei Fluggesellschaften oder Banken, die verteilte Abwicklung von<br />
zum Teil auchunternehmensubergreifenden Geschaftsprozessen oder die geme<strong>in</strong>same<br />
Nutzung teurer Ressourcen (beispielsweise massiver Parallelrechner) auch<br />
uber weite Entfernungen h<strong>in</strong>weg.<br />
Komplexitat bei der Entwicklung verteilter Anwendungen Die Art<br />
der genannten Anwendungsbeispiele zeigt bereits deutlich, da Anwendungen<br />
<strong>in</strong> <strong>verteilten</strong> Systemen aufgrund der Globalisierung verteilter Verarbeitung im<br />
zunehmenden Ma e immer komplexer werdende Aufgaben zu erfullen haben.<br />
Die Losung der anwendungsspezi schen Problemetragt jedoch nur zum Teil zur<br />
zunehmenden Komplexitat bei der Entwicklung dieser <strong>verteilten</strong> Anwendungen<br />
bei. Zusatzlich s<strong>in</strong>d beim Ubergang von e<strong>in</strong>er zentralen zu e<strong>in</strong>er dezentralen,<br />
<strong>verteilten</strong> Verarbeitung daruber h<strong>in</strong>ausgehend auch Problemstellungen bei der<br />
Anwendungsentwicklung und {ausfuhrung zuberucksichtigen, die sich durch die<br />
system<strong>in</strong>harenten Eigenschaften verteilter Systeme ergeben, wie beispielsweise<br />
die raumliche Entfernung kooperierender Anwendungskomponenten mit neuartigen<br />
Klassen von Fehlerfallen.<br />
Weiterh<strong>in</strong> s<strong>in</strong>d <strong>in</strong>sbesondere Probleme der Heterogenitat zu berucksichtigen, die<br />
sich beider Ausfuhrungverteilter Anwendungen <strong>in</strong> realen Umgebungen ergeben.<br />
So kann generell nicht von e<strong>in</strong>er homogenen Welt verteilter Verarbeitung ausgegangen<br />
werden, sondern es mu vielmehr <strong>in</strong> weltweitenNetzen<strong>in</strong>der Regel<br />
von e<strong>in</strong>er hochgradig heterogenen Landschaft verteilter Verarbeitungskomponenten<br />
ausgegangen werden. Heterogenitat auf dieser technischen Ebene au ert sich<br />
unter anderem <strong>in</strong> der Wahl der verwendeten Rechner{Hardware, Betriebssystem{<br />
Software und Programmiersprachen sowie der Nutzung verschiedener Kommunikationsprotokolle<br />
und Netzubertragungsmechanismen.<br />
Weitere Problemstellungen ergeben sich, wenn zusatzlich organisationelle Gesichtspunkte<br />
berucksichtigt werden mussen, die sich aus der Autonomie der <strong>in</strong><br />
<strong>verteilten</strong> Systemen beteiligten autonomen Verwaltungsdomanen ergeben und<br />
ma geblichen E<strong>in</strong> u auf den Entwurf und die Steuerungverteilter Anwendungen<br />
haben.<br />
Forderung nach Verteilungsabstraktion und O enheit Die Fulle der genannten<br />
Problemstellungen verdeutlicht bereits die Komplexitat e<strong>in</strong>er Systemunterstutzung<br />
fur kooperative Anwendungen <strong>in</strong> heterogenen <strong>verteilten</strong> Systemen.<br />
Dieses betri t grundsatzlich sowohl die Entwicklung verteilter Anwendungen als<br />
auchderen Ausfuhrung. Je mehr verteilungsbed<strong>in</strong>gte Aspekteberucksichtigt werden<br />
mussen, desto gro er ist die Forderung nach adaquater Verteilungsabstraktion,<br />
die die Probleme heterogener verteilter Verarbeitung soweit wie moglich<br />
verbirgt. Idealvorstellung ist hierbei, das existierende verteilte System trotz der<br />
Heterogenitatsaspekteund spezi schen Verteilungsprobleme als e<strong>in</strong> logisches, <strong>in</strong><br />
sich homogenes System anzusehen, das e<strong>in</strong>e Konzentration der Betrachtung auf
1.1 Potentiale und Probleme verteilter Systeme 3<br />
die fur das System spezi schen Anwendungskomponenten erlaubt. Die unterliegende<br />
Systemtechnik soll dabei moglichst nicht sichtbar se<strong>in</strong>. Diese Forderung<br />
nach Abstraktion wird durch das im Rahmen <strong>in</strong>ternationaler Standardisierung<br />
erarbeitete ODP{Referenzmodell1 [ODP95b] <strong>in</strong>pragnanter Form beschrieben:<br />
" Transparency: Theproperty ofmask<strong>in</strong>g from applications the details and the<br />
di erences <strong>in</strong> mechanisms used to overcome problems caused by distribution.<br />
This is a central requirementthat arises from the need to facilitate the construction<br />
of distributed applications. Aspects of distribution which should be masked<br />
(totally or partially) <strong>in</strong>clude: heterogeneity of support<strong>in</strong>gsoftware andhardware,<br />
location and mobility of components, (...)\.<br />
Das ODP{Referenzmodell unterscheidet unter anderem die folgenden Arten von<br />
Abstraktionen: 2<br />
Zugri sabstraktion (engl. access transparency) ermoglicht die Zusammenarbeit<br />
von Anwendungskomponenten trotz Unterschiede <strong>in</strong>den Datenreprasentationen<br />
und den Aufrufmechanismen.<br />
Fehlerabstraktion (engl. failure transparency) verbirgt das Auftreten von<br />
verteilungsbed<strong>in</strong>gten Fehlern, so da Anwendungen weitgehend von e<strong>in</strong>er<br />
expliziten Fehlerbehandlung befreit s<strong>in</strong>d.<br />
Ortsabstraktion (engl. location transparency) verbirgt die Lokation e<strong>in</strong>er<br />
Anwendungskomponente, so da nur deren logischer Name, nichtjedoch die<br />
physikalische Adresse, die sich unter Umstanden andern kann, verwaltet<br />
werden mu .<br />
Transaktionsabstraktion (engl. transaction transparency) verbirgt die Koord<strong>in</strong>ationsmechanismen,<br />
die bei e<strong>in</strong>er uber mehrere Anwendungskomponenten<br />
durchgefuhrten Aktivitat zur Erreichung von Konsistenz notwendig<br />
s<strong>in</strong>d.<br />
Geeignete Verteilungsabstraktionen erleichtern die Entwicklung verteilter Anwendungen<br />
im hohen Ma e und ermoglichen so die Konzentration des Anwendungsentwicklers<br />
auf die eigentlichen, unabhangig von den Verteilungsaspekten<br />
zu losenden Anwendungsprobleme.<br />
Eng verknupft mit der Forderung nach Abstraktion ist die nach der O enheit<br />
verteilter Verarbeitung. O enheit charakterisiert die Art und Weise, <strong>in</strong> der die an<br />
e<strong>in</strong>em <strong>verteilten</strong> System beteiligten, <strong>in</strong> der Regel heterogenen Komponenten mite<strong>in</strong>ander<br />
verknupft und gegenseitig benutzt werden konnen. E<strong>in</strong> Hauptziel von<br />
O enheit ist die Une<strong>in</strong>geschranktheit, mit der diese Verknupfungen pr<strong>in</strong>zipiell<br />
moglich s<strong>in</strong>d. Grundvoraussetzung hierfur ist die Scha ung e<strong>in</strong>er Infrastruktur,<br />
die die Grundlage fur die verarbeitungstechnische und organisationelle Zusammenarbeit<br />
zur Verfugung stellt. In e<strong>in</strong>er derartigen Infrastruktur mussen <strong>in</strong>sbe-<br />
1 Open Distributed Process<strong>in</strong>g<br />
2 In der deutschen Fachliteratur wird der Begri Transparenz oft als direkte Ubersetzung<br />
von transparency benutzt, im S<strong>in</strong>ne von " durchsche<strong>in</strong>end, nicht sichtbar\. In dieser Arbeit<br />
wird synonym der hier passendere Begri der Abstraktion verwendet.
4 E<strong>in</strong>leitung<br />
sondere die verschiedenartigen Heterogenitatsaspekteder an e<strong>in</strong>em <strong>verteilten</strong> System<br />
beteiligten Kooperationspartner berucksichtigt, adaquat behandelt und die<br />
entsprechenden Systemkomponenten entsprechend ane<strong>in</strong>ander angeglichen werden.<br />
In Konsequenz bedeutet somit die Scha ung von O enheit gleichzeitig auch<br />
die Festlegung geme<strong>in</strong>samer, vere<strong>in</strong>heitlichender Standards, auf deren Grundlage<br />
Rechner{ und Software{Systeme <strong>in</strong>wohlde nierter Art und Weise <strong>in</strong>teragieren<br />
und kooperieren konnen.<br />
E<strong>in</strong> <strong>in</strong>sbesondere aus der Sicht verteilter Anwendungen wichtiger Teilaspekt<br />
von O enheit ist hierbei die Interoperabilitat zwischen den e<strong>in</strong>zelnen Anwendungskomponenten,<br />
die e<strong>in</strong>e weitgehend une<strong>in</strong>geschrankte Kooperation der e<strong>in</strong>zelnen<br />
Komponenten ermoglicht. Grundvoraussetzung hierfur ist jedoch nicht<br />
nur die kommunikationstechnischeInteroperabilitat, wie sie beispielsweise durch<br />
das OSI{Referenzmodell [EF86] gewahrleistet wird. Vielmehr mussen zusatzliche<br />
Mechanismen angeboten werden, die die Grundlage fur e<strong>in</strong> geme<strong>in</strong>sames<br />
Verstandnis von Interaktion und Kooperation auf Anwendungsebene zur<br />
Verfugung stellen. Diese mussen sowohl systemtechnische Aspekte von Interoperabilitat,<br />
wie beispielsweise die zur Kooperation notwendigen Interaktionsprotokolle,<br />
als auch semantische Aspekte behandeln, die die anwendungsspezi sche<br />
Kompatibilitat beabsichtigter Kooperationen betre en.<br />
Resultate aktueller Bestrebungen zur Realisierung oener verteilter Verarbeitung<br />
zeigen sich <strong>in</strong>sbesondere <strong>in</strong> der zunehmenden Verfugbarkeit sogenannter<br />
verteilter Systemplattformen wie beispielsweise das OSF Distributed Comput<strong>in</strong>g<br />
Environment (DCE) [OSF92], die OMG Common Object Request Broker Architecture<br />
(CORBA) [OMG91, OPR96], die Advanced Network Systems Architecture<br />
(ANSA) [Mar91] und die Telecommunications Information Network<strong>in</strong>g<br />
Architecture (TINA) [NDC95]. Sie bieten jeweils <strong>in</strong>tegrierte systemtechnische<br />
Losungsansatze zur Entwicklung und Ausfuhrung verteilter Anwendungen <strong>in</strong> heterogenen<br />
<strong>verteilten</strong> Systemen an. Sie unterscheiden sich vor allem im Umfang<br />
der jeweils realisierten Verteilungsabstraktion, die bei der Anwendungsprogrammierung<br />
zur Verfugung steht. O enheit verteilter Verarbeitung bezuglich der<br />
systemtechnischen Interoperabilitat von Anwendungskomponenten ist hierbei jedoch<br />
de{facto zur Zeit nur dann gewahrleistet, wenn sie auf die Nutzung e<strong>in</strong>er<br />
bestimmten <strong>verteilten</strong> Systemplattform beschrankt wird. E<strong>in</strong>e une<strong>in</strong>geschrankte<br />
plattformubergreifende Zusammenarbeit heterogener, auf verschiedenen Systemplattformen<br />
entwickelter undablaufender Anwendungskomponenten wird zur Zeit<br />
<strong>in</strong> der Praxis noch nicht unterstutzt. Zur Erreichung plattformubergreifender Interoperabilitat<br />
mussen daher erganzende Mechanismen entwickelt werden, die<br />
e<strong>in</strong> Uberw<strong>in</strong>den der Heterogenitatsgrenzen zwischen den jeweiligen <strong>verteilten</strong><br />
Systemplattformen ermoglichen, wobei gleichzeitig auch adm<strong>in</strong>istrative Aspekte<br />
mit berucksichtigt werden mussen. Die Uberw<strong>in</strong>dungder Heterogenitatsprobleme<br />
verteilter Systemplattformen bildet e<strong>in</strong>e der Grundvoraussetzungen fur Kooperation<br />
<strong>in</strong> heterogenen <strong>verteilten</strong> Systemen.
1.2 Das Paradigma der <strong>Dienstnutzung</strong> 5<br />
1.2 Das Paradigma der <strong>Dienstnutzung</strong><br />
Fur die Kooperation von beliebigen Anwendungskomponenten verteilter Systeme<br />
mussen zunachst geeignete Kooperationsprotokolle vere<strong>in</strong>bart und de -<br />
niert werden, die e<strong>in</strong>en verb<strong>in</strong>dlichen Standard bilden, auf dessen Basis e<strong>in</strong>e<br />
geregelte Interaktion der Komponenten untere<strong>in</strong>ander statt nden kann. Gangige,<br />
von heutigen <strong>verteilten</strong> Systemplattformen angebotene Kooperationsmodelle<br />
s<strong>in</strong>d unter anderem das Klienten{Diensterbr<strong>in</strong>ger{Modell, das Erzeuger{<br />
Verbraucher{Modell sowie das Gruppen{Modell. Das am weitesten gebrauchliche<br />
Modell ist hierbei das Klienten{Diensterbr<strong>in</strong>ger{Modell (engl. client/server<br />
model) [Svo85, NM90, EM94]. Die Grundidee dieses Modells ist, da Anwendungskomponenten,<br />
die sogenannten Server, Dienste anbieten, die von den Klienten<br />
oder Kunden <strong>in</strong> Anspruch genommen werden konnen. Server und Klient<br />
s<strong>in</strong>d dabei Rollen, die wahrend e<strong>in</strong>es Kooperationsvorganges von den beteiligten<br />
Anwendungskomponenten e<strong>in</strong>genommen werden. Aufsetzendauf diesem grundlegenden<br />
Paradigmader Diensterbr<strong>in</strong>gung und {nutzung lassen sich nun komplexe<br />
o ene <strong>Dienstnutzung</strong>sumgebungen [Tsc94] aufbauen, <strong>in</strong> denen beliebige Dienste<br />
angeboten und von potentiellen Dienstnutzern <strong>in</strong> Anspruch genommen werden<br />
konnen. Die hierbei erbrachten Dienstleistungen konnen beispielsweise von elementaren<br />
Betriebssystemdiensten zur Speicherverwaltung, generischen <strong>verteilten</strong><br />
Systemdiensten zur Datei{ und Transaktionsverarbeitung bis h<strong>in</strong> zu komplexen<br />
Anwendungsdiensten zur Durchfuhrung von Datenbankrecherchen oder Flugreservierungen<br />
reichen. Die Art undWeise der Nutzung dieser verschiedenen Arten<br />
von Diensten hangt dabei ma geblichvon den Intentionen und Zielstellungen der<br />
Dienstnutzer sowie der jeweiligen Anwendungssituation ab.<br />
Die Dienstsicht bietet dabei die grundlegende Abstraktion, die e<strong>in</strong>e e<strong>in</strong>heitliche<br />
Betrachtung und Behandlung der <strong>in</strong> o enen <strong>verteilten</strong> Systemen angebotenen<br />
Funktionalitat ermoglicht. Die Granularitat der betrachteten Dienste kanndabei<br />
von e<strong>in</strong>fachen Diensten, beispielsweise dem Anbieten von Onl<strong>in</strong>e{Informationen<br />
oder der Addition zweier Zahlen, bis h<strong>in</strong> zu komplexen Anwendungsdiensten,<br />
beispielsweise von Buchungssystemen, reichen. Auch bietet die Dienstsicht e<strong>in</strong><br />
hohes Ma an Skalierbarkeit. So kann durch Komposition e<strong>in</strong>zelner Dienste mit<br />
e<strong>in</strong>facher Funktionalitat e<strong>in</strong> neuer Dienst gescha en werden, der durch die Kooperation<br />
der jeweiligen Teildienste e<strong>in</strong>ewesentlich machtigere Funktionalitat<br />
erbr<strong>in</strong>gen kann.<br />
1.3 Vision ausschlie licher <strong>Dienstnutzung</strong><br />
Das Pr<strong>in</strong>zip der Verteilungvon E<strong>in</strong>zeldiensten auf verschiedene Rechnerknoten <strong>in</strong><br />
e<strong>in</strong>em globalem Kommunikationsnetzwerk und deren anschlie ende koord<strong>in</strong>ierte<br />
Nutzung imRahmen e<strong>in</strong>er <strong>verteilten</strong> Gesamtanwendungla t sich <strong>in</strong>Richtung<br />
der Entwicklung o ener Markte von Diensten [TWH90, GGL + 95, MML94a]weiterfuhren,<br />
<strong>in</strong> denen ahnlich wie <strong>in</strong> herkommlichen Warenmarkten (hier: elektronische)<br />
Marktmechanismen die Kooperation und <strong>Dienstnutzung</strong>sbeziehungen zwischen<br />
Dienstanbietern und Dienstnachfragern regeln [MML96, Mer96, Zbo96].
6 E<strong>in</strong>leitung<br />
Derartige Marktebieten die Infrastruktur und notwendige Rahmenbed<strong>in</strong>gungen,<br />
um e<strong>in</strong>e Vielfalt und Vielzahl von Diensten und Dienstleistungen auf exible und<br />
e ziente Weise anzubieten.<br />
Vom Blickw<strong>in</strong>kel der Software{Technik aus lassen sich diese Dienste dann<br />
auch als Bestandteile e<strong>in</strong>es weltweit <strong>verteilten</strong> Systembaukastens von Diensten<br />
[MML95d, MML95e, GML96] verstehen, mit dessen Hilfe neue verteilte Anwendungen<br />
auf e<strong>in</strong>fache und e ziente Weise durch Wiederverwendung und Neukomb<strong>in</strong>ation<br />
vorhandener Diensteentworfen und realisiert werden konnen. Dabei la t<br />
die von der unterliegenden Hochleistungskommunikation bereitgestellte virtuelle<br />
Nahe bei der spateren Ausfuhrung der aus den verteilt ablaufenden Diensten<br />
bestehenden Anwendung kaum mehr Unterschiede zue<strong>in</strong>er nur lokal auf e<strong>in</strong>em<br />
Rechner ablaufenden Anwendung erkennen.<br />
E<strong>in</strong>e mogliche, hieraus resultierende Idealvorstellung ist es, die Entwicklung und<br />
Realisierung von <strong>verteilten</strong> Anwendungen weitestgehend oder sogar ausschlie -<br />
lich unter Nutzung extern angebotener Dienste durchzufuhren. Samtliche <strong>in</strong>der<br />
Gesamtanwendungzuerbr<strong>in</strong>gende Teilaufgaben und deren Verarbeitung konnen<br />
dabei aus der Klientenanwendung <strong>in</strong>externe Dienste ausgelagert werden. Die<br />
Aufgabe der Klientenanwendung beschrankt sich dann im Vergleich zur heute<br />
ublichen Programmierung nur noch auf die Steuerung und Uberwachung der<br />
Koord<strong>in</strong>ation der genutzten Dienste und die Verarbeitung von Benutzer<strong>in</strong>teraktionen.<br />
Hierdurch verandert sich fur den Anwendungsprogrammierer nicht<br />
nur der eigentliche Anwendungsentwurf und se<strong>in</strong>e Programmierung, sondern<br />
es ergeben sich fur ihn gleichzeitig auch erweiterte Moglichkeiten der Anwendungsausfuhrung.<br />
Entsprechend lassensichdann zur Steuerung e<strong>in</strong>er derartigen<br />
<strong>Dienstnutzung</strong>dedizierte, generische Koord<strong>in</strong>ationsdienste entwickeln, welchedie<br />
bisherigen Kontrollfunktionen fur e<strong>in</strong>e Vielzahl verschiedener Klientenanwendungen<br />
ubernehmen.<br />
Diese Art der Anwendungsausfuhrung stellt somit e<strong>in</strong>e konsequente Weiterfuhrungdes<br />
im vorherigen Abschnitt e<strong>in</strong>gefuhrten <strong>Dienstnutzung</strong>sparadigmas<br />
dar. Dabei werden die bisherigen Aufgaben e<strong>in</strong>er Klientenanwendung, die<br />
sich durch den Ubergang zur ausschlie lichen <strong>Dienstnutzung</strong> nur noch auf<br />
koord<strong>in</strong>ative Aspekte beschranken, selbst Gegenstand e<strong>in</strong>er im Dienstemarkt<br />
angebotenen Dienstleistung. Fur die Anwendungsausfuhrung bedeutet dieses<br />
<strong>in</strong>sbesondere, da die Kontrolle e<strong>in</strong>er <strong>verteilten</strong> Anwendung pr<strong>in</strong>zipiell an<br />
beliebiger Stelle im weltweiten Kommunikationsnetzwerk erbracht werden kann.<br />
In Konsequenz hei t dieses letztendlich fur den Anwendungsentwickler bzw.<br />
auch fur die sonstigen Endanwender, da sie selbst nicht mehr uber die fur<br />
die Ausfuhrungskontrolle benotigten, <strong>in</strong> der Regel kosten<strong>in</strong>tensiven Verarbeitungsressourcen<br />
verfugen mussen und stattdessen irgendwo im Dienstemarkt<br />
vorhandene Rechenleistung nutzen konnen. 3<br />
3 Dieser Ansatz konnte auch e<strong>in</strong>en Beitrag zur derzeit gefuhrten Diskussion um die Funktionalitat<br />
e<strong>in</strong>es sogenannten " Internet{PCs\ bieten. E<strong>in</strong> Internet{PC soll hiernach generell<br />
nur den Zugri auf die im Internet angebotenen Dienste erlauben und dadurch bed<strong>in</strong>gt selbst<br />
ke<strong>in</strong>e anwendungsspezi schen Berechnungen mehr durchfuhren mussen. In diesem Fall konnte<br />
dann unter Verwirklichung ausschlie licher <strong>Dienstnutzung</strong> und der Verwendung von Koord<strong>in</strong>ationsdiensten<br />
die vom Internet{PC zur Verfugung zustellende eigene Rechenleistung auf e<strong>in</strong>
1.4 Zielstellung und Uberblick 7<br />
An dieser Stelle wird bereits ersichtlich, da neben den Systemmechanismen zur<br />
Unterstutzungdes Dienstzugangs undder Dienstkoord<strong>in</strong>ation <strong>in</strong> o enen heterogenen<br />
<strong>verteilten</strong> Systemumgebungen weiterh<strong>in</strong> auch geeignete Ausdrucksmittel zur<br />
Verfugungstehen mussen, mit denen die verschiedenen Aspekteder Koord<strong>in</strong>ation<br />
von Diensten beschrieben werden konnen. Diese Beschreibung dient beispielsweise<br />
den genannten Koord<strong>in</strong>ationsdiensten zur Unterstutzung der Ausfuhrung und<br />
Steuerung der <strong>verteilten</strong> Anwendung unter Nutzung der benotigten elementaren<br />
Dienste ohneRucksicht auf deren Art der Verfugbarkeit im Netzwerk.<br />
1.4 Zielstellung und Uberblick<br />
Die obige Vision ausschlie licher <strong>Dienstnutzung</strong> <strong>in</strong> o enen heterogenen <strong>verteilten</strong><br />
Dienstemarkten bildet den Ausgangspunkt der vorliegenden Arbeit. Sie de niert<br />
zugleich auch das hier verfolgte Ziel des Entwurfes und der Realisierung von<br />
geeigneten Systemmechanismen, die die Umsetzung e<strong>in</strong>er derartigen Vision auf<br />
der Basis heutiger heterogener verteilter Systemplattformen ermoglichen. Hierzu<br />
s<strong>in</strong>d <strong>in</strong>sbesondere folgende Teilaufgaben zu bearbeiten, die entsprechend im<br />
Verlauf der Arbeit vertieft behandelt werden:<br />
ModellierungundBeschreibungvon Diensten als Grundlage fur e<strong>in</strong> geme<strong>in</strong>sames<br />
Dienstverstandnis und die wohlde nierte Nutzung von Diensten�<br />
Unterstutzung von Dienstnutzern beim Dienstzugang <strong>in</strong>den Phasen der<br />
Diensttyp ndung, der Dienstvermittlung und des Dienstzugri s�<br />
Unterstutzung von Anwendungsentwicklern beim Entwurf und der Realisierungvon<br />
<strong>verteilten</strong> Anwendungen unter weitestgehender bzw. ausschlie -<br />
licher Verwendung externer Dienste�<br />
Ausfuhrung und Steuerung der entwickelten <strong>verteilten</strong> Anwendungen.<br />
Bei allen diesen Problemfeldern spielt die Berucksichtigungder <strong>in</strong> Dienstemarkten<br />
vorhandenen Heterogenitatsprobleme e<strong>in</strong>e wichtige Rolle. Diese zeigen sich<br />
vor allem <strong>in</strong> Form von Heterogenitatsgrenzen zwischen den an Dienstemarkten<br />
beteiligten Verwaltungsdomanen, die e<strong>in</strong>en une<strong>in</strong>geschrankten Dienstzugang<br />
grundsatzlich zunachst verh<strong>in</strong>dern. Zur Uberw<strong>in</strong>dung der Heterogenitatsgrenzen<br />
gilt esLosungsansatze zu entwickeln, die e<strong>in</strong>en geeigneten Kompromi bereitstellen,<br />
der die Autonomie der jeweiligen Verwaltungsdomanen weitestgehend<br />
aufrecht erhalt, aber dennoch e<strong>in</strong>e s<strong>in</strong>nvolle gegenseitige Nutzung der dort angebotenen<br />
Dienste erlaubt. Hierfur ist zum e<strong>in</strong>en e<strong>in</strong>e Losung der technischen Heterogenitatsprobleme<br />
zwischen den Verwaltungsdomanen erforderlich. Zum anderen<br />
s<strong>in</strong>d weiterh<strong>in</strong> auch adm<strong>in</strong>istrative Heterogenitatsprobleme zubehandeln.<br />
Neben verwaltungsbed<strong>in</strong>gten Regeln, mit denen beispielsweise die Sichtbarkeit<br />
von Diensten nach au en generell e<strong>in</strong>geschrankt werden kann, zeigen sie sich vor<br />
M<strong>in</strong>imum zur Unterstutzung der Benutzer<strong>in</strong>teraktionen beschrankt werden.
8 E<strong>in</strong>leitung<br />
allem bei der Beschreibung von Diensten. So kann generell nicht davon ausgegangen<br />
werden, da semantisch aquivalente Dienste anverschiedenen Orten im<br />
Netzwerkauch auf dieselbe Art und Weise beschrieben s<strong>in</strong>d, so da sich dadurch<br />
Interoperabilitatsprobleme bei der <strong>Dienstnutzung</strong> ergeben konnen. Diese Form<br />
adm<strong>in</strong>istrativer Heterogenitat la t sich auch nicht durch die Bereitstellung von<br />
Losungen technischer Interoperabilitatsprobleme losen, die nur e<strong>in</strong>e notwendige,<br />
jedoch nochke<strong>in</strong>e h<strong>in</strong>reichende Voraussetzung fur die anwendungsspezi sche<br />
Interoperabilitat bei der <strong>Dienstnutzung</strong> darstellen.<br />
Entsprechend untergliedert sich die weitere Arbeit <strong>in</strong> <strong>in</strong>sgesamt drei Teile:<br />
Teil I behandelt verschiedene Grundkonzepte, die zur Unterstutzung koord<strong>in</strong>ierter<br />
<strong>Dienstnutzung</strong> <strong>in</strong> o enen heterogenen <strong>verteilten</strong> Dienstemarkten<br />
benotigt werden.<br />
Hierzu betrachtet Kapitel 2 zunachst die Aspekteder Modellierung undBeschreibungvon<br />
Diensten. Dort wird <strong>in</strong>sbesondere das dieser Arbeit zugrundeliegende<br />
Dienstmodell entwickelt, welches auch der <strong>in</strong> Teil II beschriebenen,<br />
im Rahmen dieser Arbeit entwickelten Systemumgebung TRADE<br />
(Service Trad<strong>in</strong>g and Coord<strong>in</strong>ation Environment) zugrunde liegt. Zudem<br />
werden verschiedene Arten von Dienstbeschreibungen vorgestellt, und es<br />
wird der <strong>in</strong> dieser Arbeit gewahlte Beschreibungsansatz motiviert.<br />
Kapitel 3 geht anschlie endauf die Aspektedes Dienstzugangs <strong>in</strong> heterogenen<br />
Systemumgebungen und die oben genannten technischen und adm<strong>in</strong>istrativen<br />
Heterogenitatsprobleme e<strong>in</strong>. Schwerpunkt der dort durchgefuhrten<br />
Untersuchungen ist die Identi zierung und Beschreibung von Techniken,<br />
die e<strong>in</strong>e adaquate Unterstutzung des Zugangs zu Diensten <strong>in</strong> o enen<br />
<strong>verteilten</strong> Dienstemarkten erlauben. Das Kapitel entwickelt hierzu e<strong>in</strong>en<br />
<strong>in</strong>tegrierten Losungsansatz, der auf Systemebene e<strong>in</strong>en weitgehend une<strong>in</strong>geschrankten<br />
Dienstzugang auch <strong>in</strong>heterogenen <strong>verteilten</strong> Umgebungen<br />
erlaubt. Dieser Ansatz, der auf der Kooperation von sogenannten Typmanagern,<br />
Tradern und Interzeptoren basiert, dient als Grundlage fur die anschlie<br />
ende exemplarische Umsetzung dieser Systemkomponenten <strong>in</strong> TRA-<br />
DE.<br />
Abschlie end beschreibt Kapitel 4 den <strong>in</strong> dieser Arbeit entwickelten Ansatz<br />
zur Beschreibung koord<strong>in</strong>ierter <strong>Dienstnutzung</strong>. Aufbauend auf der <strong>in</strong><br />
Kapitel 2 vorgeschlagenen Dienstabstraktion und den <strong>in</strong> Kapitel 3 vorgestellten<br />
Systemtechniken wird dort das Konzept der sogenannten Kooperationsanwendungen<br />
vorgestellt. Dieses erlaubt e<strong>in</strong>e modellhafte Sicht<br />
auf <strong>Dienstnutzung</strong> <strong>in</strong> o enen heterogenen <strong>verteilten</strong> Dienstemarkten und<br />
be<strong>in</strong>haltet <strong>in</strong>sbesondere Ausdrucksmittel, die zur Beschreibung der koord<strong>in</strong>ativen<br />
Aspekte beider ausschlie lichen <strong>Dienstnutzung</strong> benotigt werden.<br />
Es bildet die Grundlage fur die Koord<strong>in</strong>ationssprache PAMELA (Petri net<br />
based Activity Management Execution Language), die das abstrakte Beschreibungsmodell<br />
<strong>in</strong> e<strong>in</strong>e fur den Anwendungsprogrammierer unmittelbar<br />
nutzbare Form umsetzt.
1.4 Zielstellung und Uberblick 9<br />
Teil II beschreibt den Entwurf und die Realisierung e<strong>in</strong>er Systemumgebung<br />
zur koord<strong>in</strong>ierten Nutzung von Diensten <strong>in</strong> o enen heterogenen <strong>verteilten</strong><br />
Dienstemarkten. Dieser als TRADE bezeichnete Prototyp bietet e<strong>in</strong>e<br />
<strong>in</strong>tegrierte Umsetzung der <strong>in</strong> Teil I identi zierten Beschreibungsansatze<br />
und Systemmechanismen zur Unterstutzung des Dienstzugangs und der<br />
koord<strong>in</strong>ierten <strong>Dienstnutzung</strong> imRahmen von Kooperationsanwendungen.<br />
Grundlage fur die Realisierung bilden die beiden oben genannten <strong>verteilten</strong><br />
und zue<strong>in</strong>ander heterogenen Systemumgebungen DCE und CORBA,<br />
welche die technische Heterogenitat <strong>in</strong> o enen <strong>verteilten</strong> Dienstemarkten<br />
beispielhaft widergeben.<br />
Zunachst stellt Kapitel5dazu den Entwurf und die Realisierung e<strong>in</strong>es <strong>in</strong><br />
TRADE realisierten Typmanagers, e<strong>in</strong>es Traders und e<strong>in</strong>es Interzeptors<br />
vor, die <strong>in</strong>sgesamt e<strong>in</strong>en weitgehend une<strong>in</strong>geschrankten Zugang zuallen<br />
auf den derzeit wichtigsten praktischen <strong>verteilten</strong> Systemplattformen DCE<br />
und CORBA angebotenen Diensten ermoglichen.<br />
Anschlie endbeschreibt Kapitel 6 die Koord<strong>in</strong>ationssprache PAMELA und<br />
e<strong>in</strong>en Koord<strong>in</strong>ationsmanager, mit denen zum e<strong>in</strong>en die koord<strong>in</strong>ierte Nutzung<br />
von Diensten beschreibbar und zumanderen diese Beschreibung auch<br />
unmittelbar <strong>in</strong> der TRADE{Systemumgebung ausfuhrbar ist.<br />
Teil III gibt abschlie end e<strong>in</strong>e zusammenfassende Darstellung der <strong>in</strong> dieser Arbeit<br />
behandelten Probleme und systemtechnischen Losungsansatze.<br />
Hierbei wird <strong>in</strong>sbesondere noch e<strong>in</strong>mal die e<strong>in</strong>gangs erwahnte Vision ausschlie<br />
licher <strong>Dienstnutzung</strong> aufgegri en, und eswerden die <strong>in</strong> dieser Arbeit<br />
erzielten Ergebnisse h<strong>in</strong>sichtlich ihrer Eignung fur die Umsetzung dieser<br />
Vision <strong>in</strong> konkrete Systemumgebungen beurteilt.<br />
Weiterh<strong>in</strong> nden sich <strong>in</strong>den Anhangen erganzende Informationen uber verschiedene<br />
Realisierungsaspekte der TRADE{Systemumgebung. Die wichtigste dieser<br />
Erganzungen bildet Anhang A,der e<strong>in</strong>e umfangreiche Beschreibung der syntaktischen<br />
und semantischen Aspekte der Koord<strong>in</strong>ationssprache PAMELA umfa t.<br />
Zudem be<strong>in</strong>halten die nachfolgenden Anhange die Schnittstellenbeschreibungen<br />
der <strong>in</strong> TRADE entwickelten Systemkomponenten.
Teil I<br />
Grundkonzepte zur<br />
Unterstutzung koord<strong>in</strong>ierter<br />
<strong>Dienstnutzung</strong> <strong>in</strong> heterogenen<br />
<strong>verteilten</strong> Dienstemarkten
Kapitel 2<br />
Modellierung und Beschreibung<br />
von Diensten<br />
Die Modellierung und Beschreibung von Diensten spielt e<strong>in</strong>e zentrale Rolle<br />
bei der koord<strong>in</strong>ierten <strong>Dienstnutzung</strong> <strong>in</strong> o enen <strong>verteilten</strong> Systemen. Sie bildet<br />
die notwendige Grundlage fur die wohlde nierte Zusammenarbeit e<strong>in</strong>zelner Anwendungsobjekte<br />
<strong>in</strong><strong>verteilten</strong> Systemen, im speziellen von Dienstnehmern und<br />
Diensterbr<strong>in</strong>gern <strong>in</strong> e<strong>in</strong>em o enen Dienstemarkt. Im folgenden wird zuerst auf<br />
den Begri der Interoperabilitat genauer e<strong>in</strong>gegangen und verschiedene Betrachtungsebenen<br />
unterschieden. Darauf aufbauend wird e<strong>in</strong> objektbasiertes Dienstmodell<br />
fur die Modellierung von Anwendungkomponenten und der von ihnen<br />
erbrachten Dienstleistungen vorgestellt. Hierbei wird unter anderem auch der<br />
Begri des Diensttyps gepragt, der elementare Bedeutung fur diese Arbeit, <strong>in</strong>sbesondere<br />
fur die Entwicklung von Systemtechniken zur Vermittlung und Verwaltung<br />
von Diensten <strong>in</strong> o enen heterogenen <strong>verteilten</strong> Systemen, besitzt. Im<br />
Anschlu wird auf verschiedene Formen von Dienstbeschreibungen e<strong>in</strong>gegangen,<br />
wobei unter anderem auch der Aspekt der Interoperabilitat wieder aufgegri en<br />
wird. Abschlie end erfolgt e<strong>in</strong>e Zusammenfassungund Bewertungder Ergebnisse<br />
dieses Kapitels.<br />
2.1 Interoperabilitatsebenen<br />
Bevor e<strong>in</strong>e Nutzung von Diensten <strong>in</strong> heterogenen <strong>verteilten</strong> Systemen generell<br />
statt nden kann, mu die Interoperabilitat von Dienstnehmern und Diensterbr<strong>in</strong>gern<br />
sichergestellt werden. Hierfur ist e<strong>in</strong> vorheriger Abstimmungsproze<br />
erforderlich, der pr<strong>in</strong>zipiell auf drei verschiedenen Abstraktionsebenen statt ndet:<br />
Ebene der Dienstmodelle: Auf dieser Ebene ist abzustimmen, auf welche<br />
Art und Weise die <strong>in</strong> der " realen\ Welt vorhandenen Dienstleistungen, von<br />
denen im allgeme<strong>in</strong>en nur e<strong>in</strong>e vage und <strong>in</strong>formelle Vorstellung herrscht,<br />
reprasentiert werden konnen, damit diese computertechnisch handhabbar
14 Modellierung und Beschreibung von Diensten<br />
werden. E<strong>in</strong> Beispiel hierfur ist die Modellierung der Gegenstande der realen<br />
Welt als e<strong>in</strong>e Vielzahl mite<strong>in</strong>ander kooperierender Objekte, die uber<br />
Nachrichtenaustausch mite<strong>in</strong>ander kommunizieren. Mit diesen Objekten<br />
la t sich dann beispielweise e<strong>in</strong>e e<strong>in</strong>heitliche Reprasentation e<strong>in</strong>er menschlichen<br />
oder masch<strong>in</strong>ellen Dienstleistung erreichen, wobei von den <strong>in</strong>dividuellen<br />
Details ihrer realen Erbr<strong>in</strong>gung abstrahiert werden kann.<br />
Ebene der Dienstbeschreibung: Hier erfolgt die Festlegung auf konkrete<br />
Beschreibungstechniken, mit denen die Informationen e<strong>in</strong>es bestimmten<br />
Dienstmodells <strong>in</strong> e<strong>in</strong>er geeigneten sprachlichen, textuellen oder graphischen<br />
Form dargestellt werden konnen. E<strong>in</strong> Beispiel hierfur s<strong>in</strong>d Schnittstellenbeschreibungssprachen<br />
(engl. <strong>in</strong>terface de nition languages { IDL), die e<strong>in</strong>e<br />
textuelle Darstellung der Semantik e<strong>in</strong>er erbrachten Dienstleistung erlauben.<br />
Hierbei wird von den Aspekten ihrer konkreten Realisierung, beispielsweise<br />
<strong>in</strong> e<strong>in</strong>er bestimmten Programmiersprache, abstrahiert, weshalb<br />
derartige Darstellungsformen auch als abstrakte Syntaxen [Sch93a] bezeichnet<br />
werden.<br />
Ebene der Dienstreprasentation: Auf dieser Ebene ist das Format zubestimmen,<br />
mit denen die sprachlich, textuell oder graphisch abgefa ten<br />
Dienstbeschreibungen zwischen Dienstnutzer und Diensterbr<strong>in</strong>ger ausgetauschtwerden<br />
sollen. Derartige systemtechnischeTransferformatewerden<br />
auch alskonkrete Syntaxen [Sch93a] bezeichnet, da sie von den konkret<br />
vorhandenen Implementierungsmitteln e<strong>in</strong>er Ablaufumgebungabhangen. In<br />
dieser Arbeit wird hierfur der Begri der Dienstreprasentation verwendet<br />
(siehe auch [GGL + 95]). So kann beispielsweise e<strong>in</strong>e textuelle IDL{<br />
Beschreibung im e<strong>in</strong>fachsten Fall als e<strong>in</strong>fache Zeichenkette reprasentiert<br />
werden, die zwischen Dienstnehmer und Diensterbr<strong>in</strong>ger ausgetauschtwird.<br />
Denkbar ist jedoch auch dieNutzung komplexer Datenstrukturen, auf die<br />
die e<strong>in</strong>zelnen Bestandteile e<strong>in</strong>er IDL abgebildet werden, wodurch sichbeispielsweise<br />
| ahnlich zurTransfersyntax <strong>in</strong> ASN.1 [ISO87] |e<strong>in</strong>e Selbstbeschreibung<br />
der Dienstreprasentation erreichen la t.<br />
Damit die Interoperabilitat zwischen Dienstnehmer und Diensterbr<strong>in</strong>ger sichergestellt<br />
werden kann, ist auf allen drei Ebenen e<strong>in</strong>e Ubere<strong>in</strong>stimmung zu erzielen,<br />
damit die auf den e<strong>in</strong>zelnen Ebenen vorhandenen Modelle, Beschreibungen<br />
und Reprasentationen e<strong>in</strong>heitlich verstanden werden. Die drei Ebenen werden im<br />
folgenden genauer beschrieben, wobei die Aspekteder Dienstmodelle und Dienstbeschreibungen<br />
<strong>in</strong> den darau olgenden Abschnitten weiter vertieft werden.<br />
2.1.1 Dienstmodellebene<br />
Elementare Grundlage fur <strong>Dienstnutzung</strong> <strong>in</strong> o enen <strong>verteilten</strong> Systemen ist e<strong>in</strong><br />
geme<strong>in</strong>sames und e<strong>in</strong>heitliches Verstandnis des Begri es Dienst bzw. Dienstleistung<br />
sowohl bei den Dienstnutzern als auch beiden Diensterbr<strong>in</strong>gern. Hierfur<br />
ist die De nition e<strong>in</strong>es Dienstmodells notwendig, mit denen Dienste der " realen\
2.1 Interoperabilitatsebenen 15<br />
Welt e<strong>in</strong>heitlich beschrieben werden konnen. Dabei sollten bei der Modellbildung,<br />
d.h. dem Proze der Abbildung von realen Dienstleistungen <strong>in</strong> e<strong>in</strong>e datenverarbeitungstechnischhandhabbare<br />
Reprasentation, moglichst alle wesentlichen<br />
Merkmale e<strong>in</strong>es Dienstes beschrieben werden konnen. Modellbildung bzw.Abstraktion<br />
bedeutet hierbei auch immer e<strong>in</strong>e e<strong>in</strong>schrankende Sichtweise auf das<br />
reale System, um bestimmte geme<strong>in</strong>same Eigenschaften der dort betrachteten<br />
Gegenstandeherausarbeiten zu konnen. Kontextunabhangigkeit bezeichnet dabei<br />
die Abstraktion von Abhangigkeiten, die sich durch lokale Randbed<strong>in</strong>gungen ergeben.<br />
Zum Beispiel ist es fur die Betrachtung der Eigenschaften e<strong>in</strong>es Dienstes<br />
unwichtig, <strong>in</strong> welcher Programmiersprachediespatere Implementation e<strong>in</strong>es konkreten<br />
Diensterbr<strong>in</strong>gers durchgefuhrt wird.<br />
Mit e<strong>in</strong>em Dienstmodell werden gleichzeitig auch verb<strong>in</strong>dliche Absprachen uber<br />
Verhaltensaspekte getro en, die unter anderem die Interaktion von Dienstnehmer<br />
und Diensterbr<strong>in</strong>ger regeln. E<strong>in</strong>e derartige Verhaltensregel ist beispielsweise<br />
bei der im folgenden Abschnitt beschriebenen objektbasierten Dienstmodellierung<br />
de niert, die festlegt, da auf den Zustande<strong>in</strong>es Objektes bzw. Diensterbr<strong>in</strong>gers<br />
nur uber dessen extern angebotene Schnittstelle zugegri en werden kann. Wie<br />
diese Schnittstelle selbst modelliert wird, beispielsweise <strong>in</strong> Form von Operationen<br />
oder Datenstromen, ist e<strong>in</strong> weiterer Bestandteil des Dienstmodells. Hierbei<br />
ist dann auch zuklaren, was unter e<strong>in</strong>em Dienst genau zuverstehen ist. So wird<br />
beispielsweise bei der Darstellung des RPC{orientierten Client/Server{Modells<br />
<strong>in</strong> [Svo85] e<strong>in</strong> Dienst <strong>in</strong>formell verstanden als " ... a software entity runn<strong>in</strong>g on<br />
one or more mach<strong>in</strong>es\, wobei diese De nition o en la t, ob e<strong>in</strong> Dienst mit e<strong>in</strong>er<br />
Prozedur oder mit der gesamten Menge der vom Server realisierten Prozeduren<br />
gleichzusetzen ist.<br />
Dienstmodelle stellen somit e<strong>in</strong>e abstrakte Sichtweise auf Dienste <strong>in</strong><strong>verteilten</strong><br />
Systemen zur Verfugung. Interoperabilitat auf Dienstmodellebene wird hierbei<br />
entweder durch dieWahl e<strong>in</strong>es geme<strong>in</strong>samen Dienstmodells oder durch e<strong>in</strong>e<strong>in</strong>deutige<br />
Abbildung zwischen verschiedenen Dienstmodellen erreicht. Im ersten<br />
Fall mussen dann gegebenfalls die lokal verwendeten Dienstmodelle <strong>in</strong> das geme<strong>in</strong>sam<br />
verwendete Dienstmodell abgebildet werden.<br />
2.1.2 Dienstbeschreibungsebene<br />
Der Proze der Modellbildung auf der Dienstmodellebene ist eng verknupft mit<br />
e<strong>in</strong>er abstrakten Darstellungsform, der Dienstbeschreibung, mit deren Hilfe die<br />
Informationen des Dienstmodells dargestellt werden. Sie sollte soausdrucksstark<br />
se<strong>in</strong>, da die modellierten Eigenschaften der Dienste moglichst weitgehend darstellbar<br />
s<strong>in</strong>d. Dieses betri t sowohl die Beschreibung struktureller Aspekte, wie<br />
beispielsweise der Operationssignaturen der Schnittstelle e<strong>in</strong>es Objektes, als auch<br />
semantischer Eigenschaften, die das Verhalten des Objektes an se<strong>in</strong>er Schnittstelle<br />
festlegen. Die Auspragung e<strong>in</strong>er bestimmten Syntax fur e<strong>in</strong>e Dienstbeschreibung,<br />
beispielsweise <strong>in</strong> textueller oder graphischer Form, kann dabei je nach<br />
Anwendungsbereich gewahlt werden. Verteilte Systemplattformen, wie beispielsweise<br />
CORBA oder DCE, bieten zur Beschreibung von Diensten <strong>in</strong> der Regel so-
16 Modellierung und Beschreibung von Diensten<br />
genannte Schnittstellenbeschreibungssprachen (engl. <strong>in</strong>terface de nition language<br />
{ IDL) an, mit deren Hilfe die an e<strong>in</strong>er Schnittstelle angebotenen Operationen<br />
e<strong>in</strong>es Objektes beschrieben werden.<br />
E<strong>in</strong> generelles Problem beim Ubergang von der Dienst{ zur Beschreibungsebene<br />
ist der mogliche Verlust an Informationen. Ursache hierfur ist, da e<strong>in</strong>ige<br />
Aspekte des Dienstmodells, <strong>in</strong>sbesondere semantischeauf der Ebene der Dienstbeschreibungen<br />
nicht reprasentierbar s<strong>in</strong>d. Die genannten Schnittstellenbeschreibungssprachen<br />
reichen <strong>in</strong> der Regel nichtaus, um beispielsweise die " Bedeutung\<br />
e<strong>in</strong>es Druckdienstes auszudrucken. Hierdurch bed<strong>in</strong>gt kann es unter Umstanden<br />
auch dazu kommen, da semantisch verschiedene Dienste auf dieselbe Art und<br />
Weise beschrieben werden, da wesentliche Unterscheidungsmerkmale nicht dargestellt<br />
werden konnen. E<strong>in</strong> hierfur oft zitiertes Beispiel s<strong>in</strong>d diebeiden Dienste<br />
Stack und Queue, welche trotz syntaktischer Kompatibilitat der Schnittstellen,<br />
beispielsweise mit den Operationen put und get, e<strong>in</strong> unterschiedliches Verhalten<br />
aufweisen [RTL + 91]. Generell fuhrt der Informationsverlust dazu, da e<strong>in</strong>e<br />
E<strong>in</strong>e<strong>in</strong>deutigkeit zwischen Diensten im Dienstmodell und deren Beschreibung<br />
nichtmehr gewahrleistet ist. Interoperabilitat auf Beschreibungsebenela t somit<br />
nicht automatischauch auf die Interoperabilitat der hiermit beschriebenen Dienste<br />
auf Dienstmodellebene schlie en. Erst durch Erweiterungen h<strong>in</strong>sichtlich der<br />
Beschreibung auch von semantischen Aspekten von Diensten lassen sich derartige<br />
unbeabsichtigten syntaktischen Kompatibilitatsbeziehungen zwischen semantisch<br />
verschiedenen Diensten vermeiden. Abschnitt 2.4geht hierauf im Rahmen<br />
der Darstellung verschiedener Ansatze von Dienstbeschreibungen genauer e<strong>in</strong>.<br />
Weitere Probleme ergeben sich, wenn Dienstbeschreibungen auf der Grundlage<br />
verschiedenartiger Diensttypmodelle de niert s<strong>in</strong>d, die sich beispielsweise <strong>in</strong><br />
den Datentypen zur Darstellung der E<strong>in</strong>{ und Ausgabeparameter der Operationen<br />
unterscheiden. Diese Problematik tritt <strong>in</strong>der Regel dann auf, wenn Dienste<br />
auf der Basis verschiedener verteilter Systemplattformen entwickelt und <strong>in</strong>der<br />
jeweilgen Dienstbeschreibungssprache spezi ziert werden. Hier mu dann entweder<br />
e<strong>in</strong>e E<strong>in</strong>igung auf e<strong>in</strong> geme<strong>in</strong>sames e<strong>in</strong>heitliches Diensttypmodell erfolgen,<br />
<strong>in</strong> das die jeweiligen lokalen Diensttypmodelle abgebildet werden, oder es wird<br />
e<strong>in</strong>e e<strong>in</strong>e<strong>in</strong>deutige Abbildung zwischen den verschiedenartigen Diensttypmodellen<br />
de niert. E<strong>in</strong>e derartige gegenseitige Abbildung zweier Dienstbeschreibungen<br />
ist beispielsweise <strong>in</strong> [CM95] anhandder erweiterten Schnittstellenbeschreibungssprachen<br />
von DCE und CORBA dargestellt, die als Grundlage fur e<strong>in</strong>e plattformubergreifende<br />
<strong>Dienstnutzung</strong> <strong>in</strong>nerhalb der auf diesen beiden Plattformen<br />
entwickelten TRADE{Systemarchitektur dient. Abschnitt 5.1.1.1 geht auf e<strong>in</strong>ige<br />
Teilaspekte dieser Abbildung genauer e<strong>in</strong>.<br />
2.1.3 Dienstreprasentationsebene<br />
Um Dienstbeschreibungen <strong>in</strong> o enen heterogenen <strong>verteilten</strong> Systemen austauschen<br />
zu konnen, ist zwischen den beteiligten Objekten e<strong>in</strong> geme<strong>in</strong>sames Transferformat<br />
zu de nieren, mit dem die <strong>in</strong> e<strong>in</strong>er abstrakten Dienstbeschreibung<br />
vorhandenen Informationen auf e<strong>in</strong>deutige Art und Weise ablegbar s<strong>in</strong>d. Die Ab-
2.1 Interoperabilitatsebenen 17<br />
bildung der Dienstbeschreibung<strong>in</strong>e<strong>in</strong>ederartige Dienstreprasentation [GGL + 95]<br />
wird durch Kodierregeln gesteuert, die jeweils spezi sch fur das gewahlte Format<br />
de niert s<strong>in</strong>d. Dekodierregeln dienen umgekehrt dazu, samtliche Informationen<br />
wieder aus der Dienstreprasentation zu entnehmen und <strong>in</strong>e<strong>in</strong>eentsprechende<br />
Dienstbeschreibung abzubilden. Die Dienstreprasentation versteht sich<br />
somit als e<strong>in</strong> standardisierter Datenconta<strong>in</strong>er, auf den mit Hilfe von Umwandlungsregeln<br />
zugegri en werden kann. Pr<strong>in</strong>zipiell kann durch verschiedenartige<br />
Kodierregeln auch e<strong>in</strong>eAbbildung auf mehrere verschiedene Dienstreprasentationen<br />
durchgefuhrt werden. Dieses ist zum Beispiel der Fall bei der Umwandlung<br />
der standardisierten Datenbeschreibungssprache ASN.1 [ISO87, Ros92] <strong>in</strong><br />
e<strong>in</strong>e betriebssystemunabhangige Datenreprasentation. Hierfur konnen pr<strong>in</strong>zipiell<br />
verschiedene Abbildungen <strong>in</strong> Form von Encod<strong>in</strong>g Rules de niert werden, wobei<br />
zur Zeit jedoch nur e<strong>in</strong>e Abbildung durch die sogenannten Basic Encod<strong>in</strong>g Rules<br />
(BER) standardisiert ist.<br />
Abbildung 2.1 verdeutlicht das Grundpr<strong>in</strong>zip der Umwandlung e<strong>in</strong>er Dienstbeschreibung<br />
<strong>in</strong>e<strong>in</strong>e Dienstreprasentation und umgekehrt.<br />
struct { char* <strong>in</strong>terface_name;<br />
char* operation_name; }<br />
...<br />
"Test" "operation_A"<br />
"<strong>in</strong>terface Test { void operation_A(); };"<br />
Dienstrepräsentation A<br />
Dienstbeschreibung<br />
<strong>in</strong>terface Test {<br />
void operation_A ();<br />
};<br />
Kodierregeln A Kodierregeln B<br />
<strong>in</strong>terface Test {<br />
void operation_A ();<br />
};<br />
char* <strong>in</strong>terface_description;<br />
Dienstrepräsentation B<br />
Dekodierregeln A Dekodierregeln B<br />
Dienstbeschreibung<br />
Abbildung 2.1: Wechselseitige Umwandlung von Dienstbeschreibung und<br />
Dienstreprasentation<br />
Die Abbildung zeigt die Umwandlung e<strong>in</strong>er e<strong>in</strong>fachen CORBA{Schnittstellenbeschreibung<br />
<strong>in</strong>e<strong>in</strong>e Dienstreprasentation, deren Format abstrakt durch e<strong>in</strong>e<br />
Datenstruktur <strong>in</strong> der ProgrammierspracheCdargestellt ist. Die Dienstreprasentation<br />
B stellt e<strong>in</strong>evergleichsweise e<strong>in</strong>fache Moglichkeit der Kodierung e<strong>in</strong>er textuellen<br />
Dienstbeschreibung <strong>in</strong>Form e<strong>in</strong>er Zeichenkette dar. Im Vergleich hierzu<br />
ist bei der Dienstreprasentation A bereits e<strong>in</strong> Interpretationsvorgang vorausgegangen,<br />
bei dem die strukturellen Bestandteile der Dienstbeschreibung identi<br />
ziert wurden. Diese Aufgabe der syntaktischen Analyse ubernimmt <strong>in</strong>der
18 Modellierung und Beschreibung von Diensten<br />
Regel e<strong>in</strong> IDL{Parser, der die <strong>in</strong> der Schnittstellenbeschreibung enthaltenen Informationen<br />
nach bestimmten Auswertungskriterien untergliedert. Anschlie end<br />
erfolgt auf dieser Grundlage die Umwandlung <strong>in</strong> die Dienstreprasentation mit<br />
Hilfe von Generierungsfunktionen, die e<strong>in</strong>e Realisierung der Kodierregeln A darstellen.<br />
Nachdem die Dienstreprasentation dem Empfanger ubergeben wurde,<br />
kann dieser mit Hilfe entsprechender Dekodierregeln die dort enthaltenen Informationen<br />
entnehmen, so da letztendlich die orig<strong>in</strong>are Dienstbeschreibungrekonstruiert<br />
werden kann. Alternativ konnen auch andere Dekodierregeln verwendet<br />
werden, die e<strong>in</strong>e Abbildung <strong>in</strong> pr<strong>in</strong>zipiell verschiedenartigste Reprasentationsformen<br />
ermoglichen.<br />
Interoperabilitat auf der Dienstreprasentationsebene setzt somit sowohl die Nutzung<br />
e<strong>in</strong>er geme<strong>in</strong>samen Dienstreprasentation als auch die Wahl wohlde nierter<br />
Kodierungsregeln voraus, die e<strong>in</strong>e e<strong>in</strong>e<strong>in</strong>deutige Abbildung zwischen Dienstbeschreibung<br />
und Dienstreprasentation gewahrleisten.<br />
2.2 Dienstmodelle<br />
Um die <strong>in</strong> heterogenen <strong>verteilten</strong> Systemen vorhandene Funktionalitat von Anwendungskomponenten<br />
<strong>in</strong>nerhalbvon <strong>verteilten</strong> Anwendungen nutzen zu konnen,<br />
ist e<strong>in</strong>e Abstraktion erforderlich, die Eigenschaften, Verhaltensweisen und erbrachte<br />
Leistungen e<strong>in</strong>er Anwendungskomponente <strong>in</strong> geeigneter Weise formal<br />
erfa t. Diese Abstraktion wird durch e<strong>in</strong>Dienstmodell bereitgestellt, das unter<br />
anderem den Begri des Dienstes <strong>in</strong> e<strong>in</strong>deutiger Art und Weise festlegt. E<strong>in</strong> im<br />
Rahmen verteilter SystemezunehmendanBedeutung gew<strong>in</strong>nender Ansatz ist die<br />
objektbasierte Dienstmodellierung, die auch <strong>in</strong>der vorliegenden Arbeit verfolgt<br />
wird. Die weitere Darstellung basiert unter anderem auf den im Rahmen des<br />
ODP{Referenzmodells [ODP95c, L<strong>in</strong>95, NS95, PSW96] und der ODP{Trad<strong>in</strong>g{<br />
Funktion [ODP95a] entwickelten Konzepten. E<strong>in</strong>e Zusammenfassung dieses Objektmodells,<br />
das im wesentlichen auf den Begri en von Objekt, Dienst, Schnittstelle<br />
und Operation beruht, ndet sich auch <strong>in</strong> [Jon94].<br />
2.2.1 Der Objektbegri <strong>in</strong> <strong>verteilten</strong> Systemen<br />
Zentraler Begri des objektbasierten Dienstmodells ist das Objekt. Sowirde<strong>in</strong><br />
Objekt <strong>in</strong>nerhalb des ODP{Referenzmodells [ODP95c] als e<strong>in</strong>e elementare E<strong>in</strong>heit<br />
verstanden, die e<strong>in</strong>e Modularisierung und Strukturierung der im <strong>verteilten</strong><br />
System vorhandenen Komponenten ermoglicht. Dabei ist es gekennzeichnet<br />
durch se<strong>in</strong>e Identitat, die es unterscheidbar zu anderen Objekten macht, sowie<br />
durch die Pr<strong>in</strong>zipien von Kapselung, Abstraktion und Verhalten:<br />
Kapselung (engl. encapsulation) beschreibt die Eigenschaft e<strong>in</strong>es Objektes,<br />
den Zugri auf se<strong>in</strong>e <strong>in</strong>ternen Daten nur uber dessen wohlde nierte<br />
Schnittstellen zuzulassen. So konnen ke<strong>in</strong>e Anderungen an den Daten<br />
durch Seitene ekte erzeugt werden, die durch unkontrollierten, moglicherweise<br />
unzulassigen Zugri anderer Objekte hervorgerufen werden konnen.
2.2 Dienstmodelle 19<br />
Damit wird gleichzeitig auch e<strong>in</strong>e Abstraktionsbarriere erzwungen, die die<br />
<strong>in</strong>terneVerarbeitungund Verwaltungder Daten nachau en h<strong>in</strong> vollstandig<br />
verbirgt. Dieses sogenannte <strong>in</strong>formation hid<strong>in</strong>g hat den Vorteil, da von<br />
objektspezi schen Internas bei der Betrachtunge<strong>in</strong>es Objektes abstrahiert<br />
werden kann. So kann die e<strong>in</strong>er Schnittstelle h<strong>in</strong>terliegende Funktionalitat<br />
pr<strong>in</strong>zipiell auch auf verschiedene Art und Weise durch e<strong>in</strong> Objekt implementiert<br />
oder wahrend der Lebenszeit e<strong>in</strong>es Objektes geandert werden,<br />
ohne da dieses nach au en h<strong>in</strong> sichtbar wird. Da Objekte <strong>in</strong><strong>verteilten</strong><br />
Systemen oftmals e<strong>in</strong>e Vielzahl verschiedener Aufgaben und Funktionen<br />
ubernehmen, konnen Objekte pr<strong>in</strong>zipiell auch mehrere Schnittstellen besitzen.<br />
Dies ermoglicht e<strong>in</strong>efunktionale Separation der Gesamtfunktionalitat<br />
e<strong>in</strong>es Objektes, die anderen Objekten den Zugri auf gewunschteTeilfunktionalitaten<br />
erleichtert. E<strong>in</strong> Beispiel ist e<strong>in</strong> Objekt, welches neben se<strong>in</strong>er<br />
<strong>in</strong>dividuellen Schnittstelle gleichzeitig auch e<strong>in</strong>estandardisierte Systemverwaltungsschnittstelle<br />
realisiert, uber die beispielsweise die Auslastung<br />
erfragt werden kann.<br />
Das Verhalten (engl. behaviour) e<strong>in</strong>es Objektes hangt eng mit dessen Zustand<br />
zusammen, welcher durch die <strong>in</strong>ternen Daten des Objektes bestimmt<br />
wird. Das Verhalten ist hierbei de niert durch dieMenge aller potentiellen<br />
Aktionen, an denen das Objekt beteiligt werden kann. Nach au en<br />
h<strong>in</strong> au ert sich Verhalten durch entsprechende Reaktionen, die gleichzeitig<br />
auchdieAnderung se<strong>in</strong>es <strong>in</strong>ternen Zustandes widerspiegeln unddas weitere<br />
Verhalten des Objektes bestimmen. E<strong>in</strong> Objekt hei t verhaltenskompatibel<br />
zu e<strong>in</strong>em anderen, wenn es dieses ersetzen kann, ohne da <strong>in</strong> der au eren<br />
Umgebung diese Ersetzung bemerkt wird.<br />
E<strong>in</strong> verteiltes System wird somit als e<strong>in</strong> Objektsystem [Jon94] verstanden, das<br />
sich aus e<strong>in</strong>er Ansammlung von e<strong>in</strong>zelnen Objekten zusammensetzt. Abbildung<br />
2.2 zeigt den Aufbau e<strong>in</strong>es Objektes, wobei sich die dortige Schnittstelle aus<br />
e<strong>in</strong>er Menge e<strong>in</strong>zelner Operationen (Op) zusammensetzt, die e<strong>in</strong>e von mehreren<br />
Moglichkeiten zur Realisierung e<strong>in</strong>er Schnittstelle darstellen.<br />
Objekt<br />
Op<br />
Interner Zustand<br />
(Daten)<br />
Schnittstelle<br />
Op ... Op<br />
Abbildung 2.2:Aufbau e<strong>in</strong>es Objektes<br />
Ausschlaggebende Kriterien fur die Wahl e<strong>in</strong>es objektbasierten Ansatzes zur<br />
Modellierung von Anwendungskomponenten s<strong>in</strong>d vor allem deren Abstraktionsmoglichkeiten,<br />
diee<strong>in</strong>e Objektsichtweise bietet (siehe zumVergleich auch<br />
[ODP95b] und [PSW96]):
20 Modellierung und Beschreibung von Diensten<br />
Durch e<strong>in</strong>eabstrakte Objektsicht konnen alle Dienste <strong>in</strong><strong>verteilten</strong> Systemen<br />
unabhangig von kontextspezi schen Gegebenheiten <strong>in</strong> e<strong>in</strong>heitlicher<br />
Art und Weise betrachtet werden. Abstraktion bedeutet dabei unter anderem,<br />
da Aspekte der Heterogenitat, die sich beispielsweise <strong>in</strong> verschiedenen<br />
Dienstimplementierungen durch Wahl unterschiedlicher Programmiersprachen<br />
oder verschiedener Kommunikationsmechanismen au ern konnen,<br />
nicht berucksichtigt werden mussen. Erst hierdurch wirdesmoglich, e<strong>in</strong>e<br />
Konzentration auf die wesentlichen geme<strong>in</strong>samen Charakteristika von<br />
Diensten zu erreichen, die unabhangig von deren <strong>in</strong>terner Struktur s<strong>in</strong>d.<br />
Die Objektabstraktion ermoglicht e<strong>in</strong>e strenge Separation der Objekte untere<strong>in</strong>ander.<br />
Dadurch bed<strong>in</strong>gt konnen sie verandert, erweitert oder durch<br />
andere Objekte ersetzt werden, ohne da e<strong>in</strong>e Anderung anihrerUmgebung<br />
vorgenommen werden mu . Dabei ist jedoch zubeachten, da die<br />
von ihnen erbrachten Dienste auch weiterh<strong>in</strong> den Erwartungen der Umgebung<br />
entsprechen, d.h. Objekte mussen ruckwartskompatibel se<strong>in</strong>. Diese<br />
Fahigkeit zur Fortentwicklung und Erweiterung ist <strong>in</strong>sbesondere <strong>in</strong> gro en<br />
heterogenen <strong>verteilten</strong> Umgebungen von Wichtigkeit, die aufgrund ihrer<br />
Gegebenheiten e<strong>in</strong>em standigen Wandlungsproze unterworfen s<strong>in</strong>d.<br />
Mit Objekten la t sich e<strong>in</strong>hoher Grad an Modularisierung des Gesamtsystems<br />
erreichen, die e<strong>in</strong>e Wiederverwendungvon Modulen und deren Komposition<br />
zu neuen, <strong>in</strong> der Regel komplexeren Modulen unterstutzt. Diese<br />
Eigenschaft ist besonders fur e<strong>in</strong>e exible und e ziente Anwendungs{ und<br />
Systementwicklung von Bedeutung.<br />
Ahnliche Argumente fur den E<strong>in</strong>satz objektbasierter bzw. objektorientierter<br />
Technologien nden sich auch bei anderen Autoren, bespielsweise <strong>in</strong> [ND95], die<br />
Objektorientierung vor allem als Organisationspr<strong>in</strong>zip und Paradigma der Wiederverwendung<br />
verstehen. Das dort erklarte Ziel ist, e<strong>in</strong>e komponentenbasierte<br />
Anwendungsentwicklung zuunterstutzen, deren Hauptmerkmal <strong>in</strong> der Komposition<br />
bestehender Objekte zuneuen Anwendungen besteht.<br />
In H<strong>in</strong>blick auf das <strong>in</strong> dieser Arbeit verfolgte Ziel, die koord<strong>in</strong>ierte Nutzung von<br />
Diensten im Rahmen verteilter Anwendungen zu unterstutzen, ersche<strong>in</strong>t der Objektansatz<br />
mit se<strong>in</strong>en oben genannten Vorteilen deshalb als besonders geeignet,<br />
Anwendungskomponenten mit ihren erbrachten Dienstleistungen <strong>in</strong> ihren fur den<br />
Aspekt der <strong>Dienstnutzung</strong> wesentlichen Eigenschaften adaquat zu beschreiben.<br />
2.2.2 Der Dienstbegri<br />
Wie schon oben dargestellt s<strong>in</strong>d e<strong>in</strong> wesentliches Merkmal e<strong>in</strong>es Objektes dessen<br />
Schnittstellen, die die e<strong>in</strong>zige Moglichkeit zum Zugri auf die im Objekt<br />
abgekapselten Daten darstellen. In Anlehnung an die im Rahmen der <strong>in</strong>ternationalen<br />
Standardisierung e<strong>in</strong>er Dienstvermittlungskomponente, den ODP{Trader<br />
[ODP95a], wird die an e<strong>in</strong>er Schnittstelle angebotene Funktionalitat als e<strong>in</strong><br />
Dienst bezeichnet. Entsprechend wirddas den Dienst bereitstellende Objekt<br />
Diensterbr<strong>in</strong>ger und der Nutzer e<strong>in</strong>es Dienstes Dienstnehmer oder Dienstnutzer
2.2 Dienstmodelle 21<br />
genannt. Da e<strong>in</strong> Objekt pr<strong>in</strong>zipiell mehrere Schnittstellen besitzen kann, kann es<br />
somit auch mehrere Dienste gleichzeitig anbieten. E<strong>in</strong> Dienst kennzeichnet e<strong>in</strong>e<br />
bestimmte, von e<strong>in</strong>em Diensterbr<strong>in</strong>ger zur Verfugunggestellte Dienstleistung, die<br />
von Dienstnutzern fur ihre jeweiligen Ziele verwendet werden konnen. In [Mah95]<br />
hei t es hierzu pragnant: " A service establishes an agreed relationship between<br />
partners <strong>in</strong> two dist<strong>in</strong>guished roles, a service provider and a service user. A service<br />
is theresult generated by processes atthe<strong>in</strong>terface between theprovider and<br />
the userandby processes <strong>in</strong>ternal to the provider. A service is meant toproduce<br />
bene t of a de nite type to the service user, and tomeet the users need.\ Se<strong>in</strong>en<br />
Ursprung besitzt der hier gewahlte Dienstbegri im Client/Server{Modell<br />
[Svo85, NM90], welches e<strong>in</strong>e grundlegende Kooperationsforme<strong>in</strong>es Klienten und<br />
e<strong>in</strong>es Servers beschreibt (Abbildung 2.3).<br />
blockiert<br />
Klient<br />
Dienstaufruf<br />
Ergebnisrückgabe<br />
wartend<br />
wartend<br />
Server<br />
Abbildung 2.3: Grundlegendes Client/Server{Modell<br />
Klient und Server bezeichnen dabei die im Verlaufe e<strong>in</strong>er Interaktion von den<br />
Beteiligten e<strong>in</strong>genommenen Rollen, d.h. die e<strong>in</strong>es Anfragenden (der Klient bzw.<br />
Dienstnehmer) und e<strong>in</strong>es Antwortenden (der Server bzw. Diensterbr<strong>in</strong>ger). Diese<br />
Rollen konnen wahrendder Laufzeit auch gewechseltwerden. Bei der Interaktion<br />
von Klient und Server wird hierbei von e<strong>in</strong>em synchronen Ansatz ausgegangen,<br />
bei dem der Klient e<strong>in</strong>en Dienstaufruf <strong>in</strong>itiiert und solange im blockiertem Zustand<br />
wartet, bis das E<strong>in</strong>tre en der Antwort vom Server erfolgt.<br />
Wie die eigentliche Realisierung des an e<strong>in</strong>er Schnittstelle angebotenen Dienstes<br />
letztendlich durch das Objekt erfolgt, ist nicht mehr Bestandteil des hier dargestellten<br />
Dienstmodells. Durch diese Sichtweise la t sich die oben genannte Separation<br />
von Objekten untere<strong>in</strong>ander und e<strong>in</strong>e Konzentration auf die Betrachtung<br />
der au eren Eigenschaften und des Verhaltens von Objekten erreichen, ohne auf<br />
kontextabhangige Implementierungsdetails e<strong>in</strong>gehen zu mussen. Diese Abstraktion<br />
ist <strong>in</strong>sbesondere <strong>in</strong> heterogenen <strong>verteilten</strong> Systemen von Wichtigkeit, da<br />
dort Objekte pr<strong>in</strong>zipiell auf verschiedenste Art und Weise implementiert se<strong>in</strong><br />
konnen. Hier ergibt sich auch der wesentliche Unterschied dieses Dienstmodells<br />
zu anderen Ansatzen, die zusatzlich noch die Implementation von Objekten betrachten.<br />
Aus diesem Grund wird <strong>in</strong> Anlehnung an [CC91] und [Weg87] das obige<br />
Dienstmodell auch alsobjektbasiert bezeichnet. In Abgrenzung hierzu werden
22 Modellierung und Beschreibung von Diensten<br />
Systeme bzw. Modelle als klassenbasiert bezeichnet, wenn sie zusatzlich zuden<br />
oben genannten Objekteigenschaften das Implementationskonzept der Klassenbildung<br />
unterstutzen. Wird au erdem noch die Vererbung von Implementationskode<br />
berucksichtigt, wird von objektorientierten Modellen gesprochen. Beispiele<br />
fur objektbasierte Systemes<strong>in</strong>dunter anderem die ProgrammierspracheModula{<br />
2 [Wir82], deren Modulkonzept ebenfalls e<strong>in</strong>e Trennung von Modulschnittstelle<br />
und Modulimplementation vornimmt. Im Bereich verteilter Systemplattformen<br />
s<strong>in</strong>d hier unter anderem CORBA [OMG91] und ANSA [Cam91] zuerwahnen.<br />
Weitere Beispiele nden sich <strong>in</strong> [CC91], wo verschiedene Aspekte objektbasierter<br />
Programmsysteme untersucht werden. Beispiele fur objektorientierte Systeme<br />
s<strong>in</strong>dunter anderem die Programmiersprachen C++ [Str93] und Smalltalk<br />
[GR83].<br />
2.2.3 Modellierung von Schnittstellen<br />
Pr<strong>in</strong>zipiell existieren verschiedene Ansatze fur die Modellierung e<strong>in</strong>er Schnittstelle,<br />
die sich im Grad der angebotenen Abstraktion fur den Dienstnehmer unterscheiden.<br />
Nach [ODP95c] konnen drei verschiedene Formen gewahlt werden:<br />
Operationen (engl. operations) konnen ahnlich wie Prozeduren <strong>in</strong> prozedurorientierten<br />
Sprachen, beispielsweise Modula [Wir82], an der Schnittstelle<br />
aufgerufen werden.<br />
Strome (engl. ows) s<strong>in</strong>d Abstraktionen von Daten ussen, d.h. zusammenhangende<br />
Abfolgen von Daten.<br />
Datenstrome eignen sich <strong>in</strong>sbesondere zur Unterstutzung der Kooperation<br />
zwischen e<strong>in</strong>em Erzeuger unde<strong>in</strong>em Verbraucher (engl. producer/consumer<br />
model). Sie konnen beispielsweise dazu benutzt werden, um den Datenu<br />
von Audio{ oder Video<strong>in</strong>formationen <strong>in</strong> Multimedia{Anwendungen zu<br />
modellieren. E<strong>in</strong> Datenstrom ist durch se<strong>in</strong>en Namen und se<strong>in</strong>en Typ charakterisiert,<br />
der die Art und das Format der auszutauschenden Daten beschreibt.<br />
Signale (engl. signals) beschreiben die elementarste Form von Interaktion<br />
uber atomare Aktionen, die zwischen e<strong>in</strong>em <strong>in</strong>itiierenden und e<strong>in</strong>em reagierenden<br />
Objekt ausgetauscht werden.<br />
Anwendung nden Signale vor allem <strong>in</strong> ereignisbasierten Systemen, wo e<strong>in</strong><br />
bestimmtes Ereignis e<strong>in</strong>e wohlde nierte Aktion bei e<strong>in</strong>em anderen Objekt<br />
auslost [Glo89].<br />
Operationen und Strome konnen auf entsprechende Folgen von Signalen<br />
abgebildet werden. Zum Beispiel la t sich e<strong>in</strong>e Operation <strong>in</strong> Analogie zum<br />
ISO/OSI{Referenzmodell [EF86] durch e<strong>in</strong>eKomb<strong>in</strong>ation der folgenden<br />
Signale bzw. Primitiven darstellen: REQUEST, INDICATE, RESPONSE,<br />
CONFIRM.<br />
Die operationale Sichtweise eignet sich hierbei <strong>in</strong>sbesondere zur Darstellung der<br />
Interaktionen e<strong>in</strong>es Dienstnehmers mit e<strong>in</strong>em Diensterbr<strong>in</strong>ger, da sie e<strong>in</strong>e e<strong>in</strong>fa-
2.3 Typisierung von Schnittstellen und Diensten 23<br />
che Ubertragungder aus dem Programmiersprachenbereichwohlbekannten Konzepte<br />
von Prozeduren und Funktionen auch <strong>in</strong>verteilte Umgebungen ermoglicht.<br />
Operationen s<strong>in</strong>d hierbei e<strong>in</strong>e verallgeme<strong>in</strong>erteForm des mit dem Client/Server{<br />
Modell assoziierten Remote Procedure Calls (RPC) [Nel81, BN84, Sch92b]. Die<br />
dem RPC unterliegende Idee ist dabei, die Abstraktion des lokalen Prozeduraufrufs<br />
auch beie<strong>in</strong>er Verteilung der Prozeduren auf andere Rechnerknoten<br />
aufrecht zu erhalten, d.h. der Dienstnutzer soll ke<strong>in</strong>en Unterschied zwischen e<strong>in</strong>em<br />
lokalen und e<strong>in</strong>em entfernten Prozeduraufruf bemerken. Die Durchfuhrung<br />
e<strong>in</strong>er Operation bzw. e<strong>in</strong>es entfernten Prozeduraufrufs setzt sich <strong>in</strong>der Regel<br />
aus drei elementaren Teilaktivitaten zusammen, die den Ablauf e<strong>in</strong>er Interaktion<br />
von Klient und Diensterbr<strong>in</strong>ger regeln:<br />
1. Aufruf der Operation durch den Klienten,<br />
2. Bearbeitung der mit der Operation verbundenen Aufgabe und<br />
3. Beendigung,diesichentweder <strong>in</strong> der Ruckgabe von geforderten Resultaten<br />
oder von Fehlermitteilungen beim Fehlschlagen der Bearbeitung au ert.<br />
Die Beendigung ist jedoch e<strong>in</strong>eoptionale Forderung und hangt grundsatzlich<br />
von der Art des erbrachten Dienstes ab. Zum Beispiel ist bei e<strong>in</strong>fachen<br />
Empfangsdiensten, an die Klienten Benachrichtigungen schicken konnen,<br />
e<strong>in</strong>e Ruckbestatigung oftmals nicht erforderlich.<br />
Wie auch schon <strong>in</strong> der Abbildung 2.3verdeutlicht worden ist, wird dabei von<br />
e<strong>in</strong>em sychronen Ablauf ausgegangen, bei dem der Dienstnehmer bis zum Erhalt<br />
der Operationsresultate blockiert.<br />
2.3 Typisierung von Schnittstellen und Diensten<br />
Nachdem im vorherigen Abschnitt das dieser Arbeit unterliegende Verstandnis<br />
des Dienstbegri s dargestellt worden ist, stellt sich die Frage nach Formalismen,<br />
die e<strong>in</strong>e abstrakte Darstellung bzw. Beschreibung von Diensten erlauben,<br />
auf deren Grundlage Verfahren fur die Klassi kation und Vergleichbarkeit von<br />
Diensten <strong>in</strong> o enen <strong>verteilten</strong> Systemen entwickelt werden konnen. E<strong>in</strong> aus dem<br />
Bereich der Programmiersprachen bekanntes und weitverbreitetes Konzept ist<br />
das der Typisierung [CW85, Car89]. E<strong>in</strong> Ziel von Typisierung ist unter anderem<br />
die De nition von Bed<strong>in</strong>gungen (engl. constra<strong>in</strong>ts), die die Interaktion von Objekten<br />
untere<strong>in</strong>ander festlegen. Im Orig<strong>in</strong>altext hei t es dazu [CW85]: " Typed<br />
versions of set theory, just like typed programm<strong>in</strong>g languages, impose constra<strong>in</strong>ts<br />
on object <strong>in</strong>teraction that prevent objects (<strong>in</strong> this case sets) from <strong>in</strong>consistent<br />
<strong>in</strong>teraction with other objects.\ Bezogen auf Objekte <strong>in</strong>o enen <strong>verteilten</strong> Systemen<br />
dienen Typen dazu, die von den Objekten angebotenen Dienste derartig zu<br />
formalisieren, da e<strong>in</strong>e unkontrollierte und somit eventuell <strong>in</strong>konsistente <strong>Dienstnutzung</strong><br />
von Seiten der Dienstnehmer ausgeschlossen werden kann.<br />
E<strong>in</strong> Typ wird <strong>in</strong> diesem Zusammenhang oft auch alsPradikat [ODP95c] verstanden,<br />
mit dessen Hilfe Aussagen daruber gemacht werden konnen, ob e<strong>in</strong>
24 Modellierung und Beschreibung von Diensten<br />
Objekt bestimmte Eigenschaften erfullt oder nicht. Dabei s<strong>in</strong>d <strong>in</strong>sbesondere die<br />
Schnittstellen e<strong>in</strong>es Diensterbr<strong>in</strong>gers mit den dort vorhandenen Operationen zu<br />
spezi zieren, die den Dienstnehmern zum Zugri auf die Dienste zur Verfugung<br />
gestellt werden. Diese Forderung nach moglichst weitgehender Typisierung der<br />
Schnittstellen von Objekten wird deswegen auch als strenge Typisierung bezeichnet<br />
[CW85]. Sie bildet die Grundlage fur die Sicherstellung der Typsicherheit bei<br />
der Interaktion zwischen zwei Objekten und stellt somit e<strong>in</strong>e wichtige Grundvoraussetzungfur<br />
die Interoperabilitat von Dienstnehmer und Diensterbr<strong>in</strong>ger <strong>in</strong><br />
o enen heterogenen <strong>verteilten</strong> Systemen dar.<br />
2.3.1 Schnittstellen{ und Diensttypen<br />
Zusatzlich zuden oben genannten grundlegenden Arbeiten zur Typisierung bilden<br />
e<strong>in</strong>e weitere wichtige Grundlage diejenigen Arbeiten, die im Rahmen der<br />
<strong>in</strong>ternationalen Standardisierung des ODP{Referenzmodells [ODP95c, PSW96]<br />
und der ODP{Trad<strong>in</strong>g{Funktion [ODP95a] durchgefuhrt worden s<strong>in</strong>d. Das dort<br />
de nierte Konzept der Schnittstellentypen bildet die formale Grundlage fur die<br />
Typisierungder Schnittstellen von Objekten. E<strong>in</strong>eausfuhrlicheDarstellung ndet<br />
sich imdritten Teil des ODP{Referenzmodells [ODP95c], bei der jedoch imspeziellen<br />
nur operationale Schnittstellen betrachtet werden. Aufbauend auf den <strong>in</strong><br />
[CW85] und [AC91] entwickelten typtheoretischen Ansatzen erfolgt dort gleichzeitig<br />
auch die formale De nition e<strong>in</strong>er Subtypbeziehung zwischen Schnittstellentypen,<br />
die die Kompatibilitat von Schnittstellentypen de niert. E<strong>in</strong>e auf diesen<br />
beiden Arbeiten aufsetzende, ausfuhrlichere Darstellung der formalen Semantik<br />
von Schnittstellentypen und deren Subtypbeziehung ist <strong>in</strong> [NS95] vorgenommen<br />
worden. Dort wird zusatzlich zuden bereits im ODP{Referenzmodell [ODP95c]<br />
dargestellten Subtypregeln und Semantikde nitionen e<strong>in</strong> Algorithmus zur Uberprufung<br />
von Schnittstellentypen (engl. <strong>in</strong>terface type check<strong>in</strong>g) vorgestellt und<br />
se<strong>in</strong>e Korrektheit und Vollstandigkeit bewiesen.<br />
E<strong>in</strong> Schnittstellentyp wird <strong>in</strong> Anlehnung an die oben erwahnten Arbeiten im<br />
folgenden als e<strong>in</strong> Pradikat verstanden, das e<strong>in</strong>e bestimmte Klasse von operationalen<br />
Schnittstellen kennzeichnet. E<strong>in</strong> Schnittstellentyp setzt sichdabei aus e<strong>in</strong>er<br />
Menge von Operationstypen zusammen, die die an e<strong>in</strong>er Schnittstelle angebotenen<br />
Operationen kennzeichnen.IndiesemFall ist die Schnittstelle e<strong>in</strong>es konkreten<br />
Objektes von e<strong>in</strong>em bestimmten Schnittstellentyp, wenn sie das Pradikaterfullt,<br />
die im Schnittstellentyp festgelegten Operationen anzubieten.<br />
E<strong>in</strong>e Erweiterung des Schnittstellentypkonzeptes s<strong>in</strong>d sogenannte Diensttypen<br />
[ODP95a]. E<strong>in</strong> Diensttyp besteht dabei zum e<strong>in</strong>en aus e<strong>in</strong>em Schnittstellentyp<br />
undaus zusatzlichen Dienstattributtypen, die die Beschreibungvon Eigenschaften<br />
e<strong>in</strong>es Dienstes ermoglichen. Diensttypen bzw. Dienstattributtypen spielen <strong>in</strong>sbesondere<br />
bei der Vermittlung von Diensten e<strong>in</strong>e wichtige Rolle, bei der konkrete<br />
Objekt<strong>in</strong>stanzen e<strong>in</strong>es bestimmten Diensttyps aufgrund ihrer jeweiligen aktuellen<br />
Eigenschaften unterschieden werden mussen. Auf den Aspekt der Dienstvermittlung<br />
und die dortige Rolle von Diensttypen wird <strong>in</strong> Kapitel3nochausfuhrlich<br />
e<strong>in</strong>gegangen. Erganzende Darstellungen zum Diensttypkonzept nden sich au-
2.3 Typisierung von Schnittstellen und Diensten 25<br />
erdem <strong>in</strong> [Jon94], [CM95] und [IBR93].<br />
Zusammenfassend werden <strong>in</strong> dieser Arbeit funf verschiedene Arten von Typen<br />
unterschieden:<br />
Datentypen<br />
{ e<strong>in</strong>fache Datentypen (z.B. ganze Zahlen oder e<strong>in</strong>zelne alphanumerische<br />
Zeichen)<br />
{ zusammengesetzte Datentypen, die Aggregate aus e<strong>in</strong>fachen Datentypen<br />
bilden (z.B. Felder oder Mengen)<br />
Operationstypen, bestehend aus<br />
{ e<strong>in</strong>em Operationsnamen<br />
{ e<strong>in</strong>er Liste von Datentypen zur Darstellung von Parametern<br />
{ e<strong>in</strong>er Liste von Datentypen zur Darstellung von Ergebnissen<br />
{ der Semantik der Operation<br />
Schnittstellentypen, bestehend aus<br />
{ e<strong>in</strong>em Schnittstellentypnamen<br />
{ e<strong>in</strong>er Menge von Operationstypen<br />
{ der Semantik der Schnittstelle<br />
Dienstattributtypen, bestehend aus<br />
{ e<strong>in</strong>em Attributnamen<br />
{ e<strong>in</strong>em Datentyp zur Darstellung des Attributwertes<br />
{ e<strong>in</strong>er Attributkennung zur Kennzeichnung als dynamisch oder statisch<br />
Diensttypen, bestehend aus<br />
{ e<strong>in</strong>em Diensttypnamen<br />
{ e<strong>in</strong>em Schnittstellentyp<br />
{ e<strong>in</strong>er Menge von Dienstattributtypen<br />
2.3.2 Beziehungen zwischen Diensttypen<br />
Mit Hilfe der obigen Schnittstellen{ und Diensttypen lassen sich dieSchnittstellen<br />
von Objekten bzw. die dort angebotenen Dienste formalisieren. Typisierung<br />
bildet hierbei die erste Voraussetzung fur e<strong>in</strong>e wohlde nierte <strong>Dienstnutzung</strong> <strong>in</strong><br />
o enen <strong>verteilten</strong> Systemen. E<strong>in</strong> weiterer wichtiger Aspekt bei der <strong>Dienstnutzung</strong><br />
ist die Berucksichtigung der Weiterentwicklung von Diensten bzw. Diensttypen.<br />
Dieses ist <strong>in</strong>sbesondere <strong>in</strong> o enen <strong>verteilten</strong> Systemen | speziell <strong>in</strong> o enen<br />
Dienstemarkten [ML93a, GGL + 95] |von gro er Bedeutung, da dort im Pr<strong>in</strong>zip<br />
jederzeit neue Diensttypen angeboten oder bestehende weiterentwickelt werden
26 Modellierung und Beschreibung von Diensten<br />
konnen. Um <strong>in</strong> solchen dynamischen Umgebungen dennoch e<strong>in</strong>en wohlde nierten<br />
und strukturierten Umgang mit Diensten erreichen zu konnen, ist es notwendig<br />
Formalismen zu de nieren, die Beziehungen zwischen Schnittstellen{ und<br />
Diensttypen <strong>in</strong> geeigneter Art und Weise ausdrucken konnen. Unter Benutzung<br />
derartiger Beziehungen kann beispielsweise sichergestellt werden, da trotz Erweiterungen<br />
der Schnittstelle e<strong>in</strong>es Diensterbr<strong>in</strong>gers weiterh<strong>in</strong> die Typsicherheit<br />
zu den Dienstnehmern, die auf der Basis des alten Schnittstellentyps entwickelt<br />
wurden, vorhanden ist. Auchla t sich hierdurche<strong>in</strong>eVergleichbarkeit von Typen<br />
erreichen, die unter anderem fur die Dienstvermittlung von besonderem Interesse<br />
ist, bei der e<strong>in</strong>e Zuordnung potentieller Dienstnehmer zu Diensterbr<strong>in</strong>gern<br />
exibel auf der Basis von Diensttypen durchgefuhrt werden soll.<br />
Beziehungen (engl. relations) zwischen Diensten konnen pr<strong>in</strong>zipiell von verschiedenster<br />
Art se<strong>in</strong> und s<strong>in</strong>dabhangig von der beabsichtigten Zielstellung und auch<br />
dem gewollten Grad von Ausdrucksstarke [CM95]. So konnen Beziehungen beispielsweise<br />
dar<strong>in</strong> bestehen, die Zusammengehorigkeit verschiedener Diensttypen<br />
auszudrucken, die bezuglich ihrer Dienstsemantik an sich nicht <strong>in</strong> Beziehung stehen.<br />
E<strong>in</strong>e derartige Beziehung konnte beispielsweise lauten: " Die Diensttypen A<br />
und Bstehen <strong>in</strong> Beziehung, da sie im selben Software{Projekt verwendet werden\.<br />
Diese Art von " semantischer\ Beziehung ist e<strong>in</strong> Beispiel fur durch Instanzen<br />
de nierte Beziehungen, da diese nicht automatisch, sondern durch explizite<br />
adm<strong>in</strong>istrative Tatigkeiten fur jedes Paar von Diensttypen neu de niert werden<br />
mussen. Hierzu im Gegensatz stehen die durch De nitionsregeln de nierten Beziehungen,<br />
die e<strong>in</strong>e automatische systemgesteuerte Vergleichbarkeit von Diensttypen<br />
ermoglichen (siehe auch Abschnitt 3.2.2.2).<br />
E<strong>in</strong>e durch De nitionsregeln de nierte Beziehung ist auch die oben bereits<br />
erwahnte Subtypregel. Sie de niert die Beziehung von Schnittstellentypen, auf<br />
deren Grundlage e<strong>in</strong>e Uberprufung der Kompatibilitat des von e<strong>in</strong>em Diensterbr<strong>in</strong>ger<br />
angebotenen und von e<strong>in</strong>em Dienstnehmer geforderten Schnittstellentyps<br />
moglich ist. In diesem Zusammenhang wird Subtypisierung auch oft als Konformitat<br />
bezeichnet, d.h. e<strong>in</strong> Schnittstellentyp A hei t konform zu e<strong>in</strong>em anderem<br />
Schnittstellentyp B, wenn e<strong>in</strong> Objekt vom Schnittstellentyp A immer fur e<strong>in</strong> Objekt<br />
mit Schnittstellentyp B e<strong>in</strong>gesetzt werden kann [RTL + 91]. Dieses Pr<strong>in</strong>zip<br />
der Ersetzbarkeit bedeutet <strong>in</strong> praktischer Anwendung, da e<strong>in</strong> Diensterbr<strong>in</strong>ger<br />
durch e<strong>in</strong>en anderen zu se<strong>in</strong>em Schnittstellentyp konformen Diensterbr<strong>in</strong>ger ausgetauscht<br />
werden kann, ohne da sich hierdurch Anderungen fur die Dienstnehmer<br />
ergeben (Abbildung 2.4). Die Abbildung zeigt zwei Diensterbr<strong>in</strong>ger mit den<br />
Schnittstellentypen ST-A und ST-B, wobei ST-A konform zu ST-B ist. Hierdurch<br />
bed<strong>in</strong>gt kann Dienstnehmer 1 die Dienste beider Diensterbr<strong>in</strong>ger nutzen. Dieses<br />
gilt jedochnicht fur den speziell auf Grundlage von Schnittstellentyp ST-A<br />
entwickelten Dienstnehmer 2,daumgekehrt der Schnittstellentyp ST-B nichtkonform<br />
zu ST-A ist.<br />
Die im folgenden dargestellte De nition von Konformitat von Schnittstellentypen<br />
stammt aus der <strong>verteilten</strong> Programmiersprache Emerald [RTL + 91] und ndet<br />
sich <strong>in</strong>ahnlicher Darstellung auch im ersten Teil des ODP{Referenzmodells<br />
[ODP95b] und <strong>in</strong>anderen Programmiersprachen, wie beispielsweise der objekt-
2.3 Typisierung von Schnittstellen und Diensten 27<br />
Dienstnehmer<br />
Dienstnehmer<br />
1<br />
ST-B<br />
2<br />
ST-A<br />
Dienstaufruf<br />
ST-A<br />
ST-B<br />
Diensterbr<strong>in</strong>ger<br />
ST-A ist konform<br />
zu ST-B<br />
Diensterbr<strong>in</strong>ger<br />
Abbildung 2.4: Konformitat von Schnittstellen<br />
orientierten Sprache Guide [KMV + 90].<br />
De nition 2.1 (Konformitat von Schnittstellentypen) Seien S und T<br />
zwei Schnittstellentypen. S hei t konform zuT(S T), wenn e<strong>in</strong> Objekt vom<br />
Schnittstellentyp S immer fur e<strong>in</strong> Objekt vom Schnittstellentyp T ersetzt werden<br />
kann. Die Ersetzung kann statt nden, wenn die folgenden vier Voraussetzungen<br />
erfullt s<strong>in</strong>d:<br />
1. S besitzt m<strong>in</strong>destens die Operationen von T. (S kann mehr Operationen<br />
haben.)<br />
2. Fur jede Operation <strong>in</strong> T gilt, da die entsprechende Operation <strong>in</strong> S denselben<br />
Operationsnamen und dieselbe Anzahl von Parametern und von Ergebnissen<br />
besitzt.<br />
3. Fur jede Operation <strong>in</strong> S gilt, da der Typ der Ergebnisse konform zum Typ<br />
der Ergebnisse der entsprechenden Operation von T ist.<br />
4. Fur jede Operation <strong>in</strong> T gilt, da der Typ der Parameter konform zum Typ<br />
der Parameter der entsprechenden Operation von S ist.<br />
Jeder Schnittstellentyp ist zu sich selbst konform.<br />
Zwei Operationstypen s<strong>in</strong>d genau dann konform zue<strong>in</strong>ander, wenn die Punkte<br />
zwei bis vier erfullt s<strong>in</strong>d. Auch hier gilt, da jeder Operationstyp zu sich selbst<br />
konform ist.<br />
Die vierte Eigenschaft wird auch als Kontravarianz bezeichnet, da sie entgegengesetzt<br />
zur sonstigen kovarianten Beziehung der beiden Schnittstellen{ und Ergebnistypen<br />
steht. E<strong>in</strong> e<strong>in</strong>faches Beispiel fur die Anwendungder Konformitatsbeziehung<br />
ist das H<strong>in</strong>zufugen e<strong>in</strong>er neuen Operation zu e<strong>in</strong>er bestehenden Schnittstelle<br />
e<strong>in</strong>es Dienstes.<br />
Als Erweiterung zur obigen De nition 2.1 legt die folgende De nition die Konformitatsbeziehung<br />
zwischen Diensttypen fest. Sie unterscheidet sich<strong>in</strong>der Berucksichtigung<br />
der Dienstattributtypen, die e<strong>in</strong>en Dienst <strong>in</strong> se<strong>in</strong>en Eigenschaften<br />
naher beschreiben. Sie ist <strong>in</strong> ahnlicher Form auch <strong>in</strong> [IBR93] dargestellt.
28 Modellierung und Beschreibung von Diensten<br />
De nition 2.2 (Konformitat von Diensttypen) Seien S und T zwei<br />
Diensttypen. S hei t konform zu T (S T), wenn e<strong>in</strong> Objekt vom Diensttyp<br />
S immer fur e<strong>in</strong> Objekt vom Diensttyp T ersetzt werden kann. Die Ersetzung<br />
kann statt nden, wenn die folgenden vier Voraussetzungen erfullt s<strong>in</strong>d:<br />
1. Der Schnittstellentyp von S ist konform zum Schnittstellentyp von T.<br />
2. S besitzt zum<strong>in</strong>dest alle Dienstattribute, die auch T besitzt. (S kann auch<br />
mehr Dienstattribute haben.)<br />
3. Jedes Dienstattribut von S hat denselben Attributnamen wie das entsprechende<br />
Dienstattribut von T, wobei<br />
4. der Typ des Dienstattributs von S konform zu dem von T ist.<br />
Jeder Diensttyp ist zu sich selbst konform.<br />
Die Konformitat bzw. Subtypisierung von Schnittstellen{ und Diensttypen<br />
ermoglicht den Aufbau von Typhierarchien, die die Kompatibilitatsbeziehungen<br />
zwischen den Typen widerspiegeln. Typuberprufungen und {vergleiche konnen<br />
dabei weitgehend automatisch, beispielsweise durch die <strong>in</strong> [NS95] oder [AC91]<br />
vorgestellten Algorithmen, durchgefuhrt werden. Zur Verwaltung derartiger Typhierarchien<br />
existieren <strong>in</strong> <strong>verteilten</strong> Systemen relativ neuartige Ansatze <strong>in</strong> Form<br />
sogenannter Typmanager [IBR93, CM95] oder Typ{Ablagedienste (engl. type repository)<br />
[ODP95c], auf deren Funktionen Abschnitt 3.2detailliert e<strong>in</strong>geht.<br />
2.4 Formen von Dienstbeschreibungen<br />
Auf der Dienstbeschreibungsebene existieren verschiedene Ansatze, um Dienste<br />
bzw. Diensteigenschaften auf abstrakte Art und Weise darzustellen. Dabei<br />
werden die Unterschiede zwischen Dienstbeschreibungen vor allem <strong>in</strong> dem Grad<br />
ihrer Ausdrucksmachtigkeit deutlich, der sich direkt auch <strong>in</strong>den Moglichkeiten<br />
zum Vergleich von Dienstbeschreibungen au ert. Wie schon anhand der am Anfang<br />
dieses Kapitels dargestellten Interoperablitatsprobleme ersichtlich wurde,<br />
stellt die Vergleichbarkeit und Uberprufbarkeit von Dienstbeschreibungen bzw.<br />
Dienstreprasentationen e<strong>in</strong>e wesentliche Grundlage dar, auf derer die Interoperabilitat<br />
von Dienstnehmern und Diensterbr<strong>in</strong>gern <strong>in</strong> o enen <strong>verteilten</strong> Systemen<br />
sichergestellt werden kann.<br />
Ziel der folgenden Darstellung istes,verschiedene Ansatze von Dienstbeschreibungen<br />
aufzuzeigen und bezuglich ihrer Verwendbarkeit zur Beschreibung von<br />
Diensten <strong>in</strong> o enen <strong>verteilten</strong> Dienstemarkten zu untersuchen. Das untersuchte<br />
Spektrum reicht von Dienstbeschreibungen mit relativ e<strong>in</strong>fachen Beschreibungsmitteln<br />
bis h<strong>in</strong> zu Ansatzen, die aufgrund komplexer Formalismen wesentlich<br />
machtigere Ausdrucksmoglichkeiten besitzen. Es werden hierbei drei grobe<br />
Kategorien von Dienstbeschreibungen unterschieden (siehe zumVergleich auch<br />
[MML95f]):
2.4 Formen von Dienstbeschreibungen 29<br />
Namensbasierte Ansatze<br />
Strukturelle Ansatze<br />
Erweiterte Ansatze<br />
2.4.1 Benennung von Diensten<br />
Im e<strong>in</strong>fachsten Fall beschrankt sich die Beschreibung e<strong>in</strong>es Dienstes auf die Benennung<br />
des Schnittstellentyps. E<strong>in</strong> Beispiel ist der Name " 0081f128-a244-10b5-<br />
99d0-08005a921930\ zur Bezeichnungdes Schnittstellentyps e<strong>in</strong>es Druckdienstes,<br />
wie es am Beispiel der <strong>in</strong> Abbildung 2.5 gezeigten DCE{Dienstbeschreibung verdeutlicht<br />
ist. Diese sogenannte UUID (engl. universal unique identi er) ist e<strong>in</strong>e<br />
durch entsprechendeWerkzeuge generiertee<strong>in</strong>deutige Zeichenkette, die e<strong>in</strong>en bestimmten<br />
Schnittstellentyp global e<strong>in</strong>deutig bezeichnet. Sie ist elementarer Bestandteil<br />
jeder Schnittstellenbeschreibung <strong>in</strong> DCE, die <strong>in</strong> der DCE{spezi schen<br />
Schnittstellenbeschreibungssprache (engl. <strong>in</strong>terface de nition language { IDL) formuliert<br />
ist. Pr<strong>in</strong>t bezeichnet <strong>in</strong> der Abbildung e<strong>in</strong>en symbolischen Schnittstellentypnamen,<br />
der vom Benutzer fur programmiertechnische Aspekte zusatzlich<br />
gewahlt werden mu . Im Gegensatz zur UUID mu der Name jedoch nicht weltweit<br />
e<strong>in</strong>deutig se<strong>in</strong>. Weiterh<strong>in</strong> be<strong>in</strong>haltet die Schnittstellenbeschreibung die Denition<br />
der zur Pr<strong>in</strong>t{Schnittstelle gehorenden, hier jedoch nicht dargestellten<br />
Operationen <strong>in</strong> Form von Operationssignaturen, welche zur Generierung von sogenannten<br />
Kommunikationsstubs (siehe Abschnitt 3.2.2.7) verwendet werden.<br />
[<br />
uuid(0081f128-a244-10b5-99d0-08005a921930),<br />
version(1.0)<br />
]<br />
<strong>in</strong>terface Pr<strong>in</strong>t<br />
{<br />
/* <strong>in</strong>terface operation def<strong>in</strong>itions */<br />
}<br />
Abbildung 2.5: DCE{Schnittstellenname<br />
UUIDs <strong>in</strong> DCE dienen zum e<strong>in</strong>en zum Au nden geeigneter Dienste mit Hilfe<br />
e<strong>in</strong>es Namensdienstes, zum anderen ermoglichen sie e<strong>in</strong>e rudimentare Kompatibilitatsprufungder<br />
Schnittstellentypen zwischen Dienstnehmer und Diensterbr<strong>in</strong>ger<br />
zum Zeitpunkt der B<strong>in</strong>dung bzw.des ersten Operationsaufrufs 1 .E<strong>in</strong>eweitere<br />
Uberprufung des eigentlichen Operationsaufrufs anhand der <strong>in</strong> der Schnittstellenbeschreibung<br />
vorhandenen Operationssignaturen ndet nicht statt.<br />
1 Bei DCE fallen B<strong>in</strong>dung und der erste Operationsaufruf je nach verwendeter B<strong>in</strong>dungsme-<br />
thode zeitgleich zusammen.
30 Modellierung und Beschreibung von Diensten<br />
Da sich die Uberprufungder Aquivalenz zweier Schnittstellentypen auf die e<strong>in</strong>fache<br />
Gleichheit von Namen beschrankt, ist die Flexibilitat namensbasierter Typisierung<br />
von Schnittstellen <strong>in</strong>nerhalb gro er o ener heterogener verteilter Systeme<br />
nur sehr e<strong>in</strong>geschrankt nutzbar. Dieses ist dar<strong>in</strong> begrundet, da dort e<strong>in</strong> geme<strong>in</strong>sames<br />
Verstandnis uber die Semantik e<strong>in</strong>es bestimmten Namens nur sehr schwer<br />
zu erreichen ist bzw. e<strong>in</strong>e zentral gesteuerte Vergabe von Namen aufgrund der<br />
Dynamik o ener Dienstemarkte nicht oder nur <strong>in</strong> ger<strong>in</strong>gem Ma e, beispielsweise<br />
durch weltweite Standardisierung von Typbezeichnern, durchgefuhrt werden<br />
kann. So fuhrt der bei der ausschlie lichen Nutzung von Typnamen auftretende<br />
Informationsverlust beim Ubergang von der Dienstmodell{ zur Dienstbeschreibungsebene<br />
<strong>in</strong>der Regel zu den <strong>in</strong> Abschnitt 2.1 beschriebenen Interoperabilitatsproblemen.<br />
Zum Beispiel konnen verschiedenartige Dienste bzw. Schnittstellentypen<br />
unter Umstanden gleichartig benannt werden, so da die Interoperabilitat<br />
von Diensten trotz identischer Typnamen nicht gewahrleistet werden<br />
kann. Ebenso konnen gleichartige Schnittstellentypen verschiedenartig bezeichnet<br />
werden, so da e<strong>in</strong>e Typubere<strong>in</strong>stimmung auf der Grundlage e<strong>in</strong>facher Namensaquivalenz<br />
nicht ermittelt werden kann. 2<br />
E<strong>in</strong> e<strong>in</strong>fache Erweiterung namensbasierter Schnittstellentypisierung ergibt sich<br />
durch Anwendung der <strong>in</strong> Abschnitt 2.3.2 dargestellten De nition uber die Konformitat<br />
bzw. Subtypisierung zweier Schnittstellentypen, die auf der Basis der<br />
strukturellen Eigenschaften von Schnittstellentypen, d.h. der Operationssignaturen,<br />
de niert ist. Da im Fall von nur durch Namen bezeichneten Schnittstellentypen<br />
diese zusatzlichen Informationen fur e<strong>in</strong>en automatischen Vergleichsvorgang<br />
nicht verfugbar s<strong>in</strong>d, konnen Subtypbeziehungen nur durch adm<strong>in</strong>istrative<br />
Ma nahmen explizit de niert werden. Die Korrektheit dieser Beziehung anhand<br />
der Konformitatsregeln kann ebenfalls nicht uberpruft werden. Dieses explizite<br />
Pr<strong>in</strong>zip ndet beispielsweise Verwendung <strong>in</strong>nerhalb von DCE, wo durch Versionsnummern<br />
(beispielsweise version(1.0) <strong>in</strong> Abbildung 2.5) die Beziehung<br />
zweier Schnittstellentypen mit demselben Namen aufgezeigt wird. Die Konformitat<br />
<strong>in</strong>nerhalb von DCE beschrankt sich auf das H<strong>in</strong>zufugen e<strong>in</strong> oder mehrerer<br />
Operationen. Andere Beispiele s<strong>in</strong>d ANSA und CORBA, welche ebenfalls auf<br />
dem Pr<strong>in</strong>zip der expliziten Subtypisierung beruhen.<br />
Die oben gemachten Aussagen uber die namensbasierte Beschreibung von<br />
Diensten lassen sich auch direkt auf das Diensttypkonzept ubertragen, welches<br />
das Schnittstellentypkonzept umfa t.<br />
2.4.2 Strukturelle Dienstbeschreibungen<br />
In Anbetracht der Dynamik o ener Dienstemarkte mit neu h<strong>in</strong>zukommenden,<br />
sich andernden und auch verschw<strong>in</strong>denen Dienst{ und Schnittstellentypen gestaltet<br />
sich die explizite adm<strong>in</strong>istrative Verwaltung von Subtypbeziehungen im<br />
allgeme<strong>in</strong>en sehr aufwendig. Zusatzliche Probleme ergeben sich dadurch, da<br />
durch die Heterogenitat <strong>in</strong> o enen Dienstemarkten e<strong>in</strong>e global e<strong>in</strong>heitliche und<br />
2 Auf naturliche Weise wird dieses bereits durch die Nutzung verschiedener Sprachen verursacht,<br />
beispielsweise die Verwendung von " Pr<strong>in</strong>t\ imEnglischen fur " Drucken\ imDeutschen.
2.4 Formen von Dienstbeschreibungen 31<br />
wohlde nierte Namensgebung von Dienst{ und Schnittstellentypen nur sehr e<strong>in</strong>geschrankt<br />
moglich ist,soda <strong>in</strong> der Regel e<strong>in</strong>e ausschlie lich auf der Basis<br />
von Namen durchgefuhrte Vergleichbarkeit von Diensten nicht realisierbar ist.<br />
Innerhalb kle<strong>in</strong>er geschlossener Verwaltungsbereiche kann der namensbasierte<br />
Ansatz jedoch aufgrund der e zienten und e<strong>in</strong>fachen Realisierbarkeit weiterh<strong>in</strong><br />
durchaus se<strong>in</strong>e Berechtigung besitzen, da dortimallgeme<strong>in</strong>en die mit den<br />
Bezeichnern verbundene Semantik und die verschiedenartigen Beziehungen zwischen<br />
den verwendeten Typen bekannt s<strong>in</strong>d. Auf dem H<strong>in</strong>tergrund weltweiter<br />
o ener Dienstemarkte s<strong>in</strong>djedoch erweiterte Ansatze erforderlich, die das namensbasierte<br />
Konzept um die Beschreibung struktureller, kontextunabhangiger<br />
Eigenschaften von Diensten erganzen.<br />
E<strong>in</strong> erster Ansatz <strong>in</strong> diese Richtung ist die E<strong>in</strong>beziehung struktureller Eigenschaften<br />
von Diensten, wie sie beispielsweise zur De nition der Diensttypkonformitat<br />
<strong>in</strong> Abschnitt 2.3.2 benutzt werden. Der Vorteil gegenuber dem namensbasierten<br />
Ansatz liegt dar<strong>in</strong>, da durch die zusatzliche Berucksichtigung der Signaturen<br />
der Operationen und Dienstattribute e<strong>in</strong> wohlde niertes strukturelles Kriterium<br />
gegeben ist, auf dessen Grundlage Typuberprufungen und {vergleiche automatisch<br />
durch systemtechnischeVerfahren durchgefuhrt werden konnen. Die vorher<br />
verwendeten kontextabhangigen Namen nden ke<strong>in</strong>e Berucksichtigung. So werden<br />
zwei Schnittstellentypen, die dieselben Operationssignaturen besitzen, trotz<br />
beispielsweise der unterschiedlichen Namen " Pr<strong>in</strong>t\ und " Drucken\ aufgrund ihrer<br />
strukturellen Ubere<strong>in</strong>stimmung als konform zue<strong>in</strong>ander erkannt. Dieser Vorteil<br />
au ert sich auch beider Verwaltung von Dienst{ und Schnittstellentypen <strong>in</strong><br />
Typhierarchien (siehe Abschnitt 3.2), bei der die E<strong>in</strong>ordnung neuer Typen nun<br />
implizit durch Systemmechanismen erfolgen kann, wahrend h<strong>in</strong>gegen bei e<strong>in</strong>er<br />
namensbasierten Typverwaltung Beziehungen zu anderen Diensttypen explizit<br />
beschrieben werden mussen. Des weiteren werden mittels der Signatur<strong>in</strong>formationen<br />
auch genauere Kompatibilitatsuberprufungen zum Zeitpunkt der Dienstvermittlung<br />
und B<strong>in</strong>dung moglich. Zusatzlich lassen sich nun auch die Operationsaufrufe<br />
genauer untersuchen, welches mit der namensbasierten Typisierung<br />
nicht moglich war.<br />
Da Signaturen ausschlie lich zur Beschreibung struktureller Diensteigenschaften<br />
dienen, mit denen sich semantische Aspekte von Diensten nur implizit, beispielsweise<br />
durch dienstspezi sch gewahlte Operationsnamen, ausdrucken lassen,<br />
bleibt das Problem der Interoperabilitat auf Dienstmodellebene jedoch weiterh<strong>in</strong><br />
bestehen, falls an sich semantisch verschiedenartige Dienst{ bzw. Schnittstellentypen<br />
mit denselben Beschreibungsmitteln dargestellt werden. Hier mussen<br />
dann, beispielsweise im Fall der Schnittstellentypen Stack und Queue, zusatzliche<br />
adm<strong>in</strong>istrative Ma nahmen vorgenommen werden, die deren jeweilige E<strong>in</strong>deutigkeit<br />
sicherstellen. E<strong>in</strong> relativ e<strong>in</strong>facher und pragmatischer Losungsansatz<br />
hierfur ndet sich <strong>in</strong>der <strong>verteilten</strong> Systemplattform ILU [JSS95] der Xerox Corporation.<br />
Dort werden sogenannte Markenzeichen (engl. brands) vergeben, die<br />
e<strong>in</strong>en <strong>in</strong> der ILU{Schnittstellenbeschreibungssprache de nierten Schnittstellentyp<br />
e<strong>in</strong>deutig kennzeichnen. Hierdurchwerden zwei Schnittstellentypen trotz der<br />
Ubere<strong>in</strong>stimmung <strong>in</strong> strukturellen Aspekten als semantischverschieden erkannt.
32 Modellierung und Beschreibung von Diensten<br />
2.4.3 Beschreibung von Diensteigenschaften<br />
Die oben beschriebenen Ma nahmen zur Dienstbeschreibungreichen <strong>in</strong> der Regel<br />
nicht aus, um Dienste <strong>in</strong> o enen <strong>verteilten</strong> Systemen h<strong>in</strong>reichend genau charakterisieren<br />
zu konnen.Sobe<strong>in</strong>halten Namen, wie beispielsweise die der Operationstypen<br />
oder der Schnittstellentypen, im allgeme<strong>in</strong>en zwar gewisse semantische<br />
Informationen uber die Art des erbrachten Dienstes, doch lassen sich mit ihnen<br />
spezi sche Diensteigenschaften oder {merkmale nicht explizit ausdrucken.<br />
2.4.3.1 Dienstattribute<br />
E<strong>in</strong> Beschreibungsansatz ist die Erganzung der Schnittstellentyp<strong>in</strong>formationen<br />
um Dienstattributtypen. Sie s<strong>in</strong>d Bestandteil des Diensttypkonzeptes, welches bereits<br />
<strong>in</strong>Abschnitt 2.3 e<strong>in</strong>gefuhrt wurde. Abbildung 2.6 zeigt das Beispiel e<strong>in</strong>er<br />
um Dienstattribute erganzten CORBA{Schnittstellenbeschreibung, die als e<strong>in</strong>e<br />
Variante zur Beschreibung von Diensten <strong>in</strong>nerhalb von TRADE verwendet wird.<br />
Das dort de nierte Dienstattribut costPerPage besitzt den Typ float undkennzeichnet<br />
den Preis pro Druckseite.<br />
//@service type Pr<strong>in</strong>tService �<br />
//@property static float costPerPage�<br />
//@property dynamic long queueLength<br />
<strong>in</strong>terface Pr<strong>in</strong>t {<br />
void Pr<strong>in</strong>tJob (<strong>in</strong> str<strong>in</strong>g Data, out long JobNumber)�<br />
}�<br />
Abbildung 2.6: Erweiterung von Schnittstellenbeschreibungen um Dienstattribute<br />
Die De nition der Dienstattributtypen ist hierbei zusammen mit dem Schnittstellentyp<br />
Pr<strong>in</strong>t e<strong>in</strong> wesentlicher Bestandteil der Dienstbeschreibungdes Diensttyps<br />
Pr<strong>in</strong>tService. Diensterbr<strong>in</strong>ger als konkrete Instanzen dieses Diensttyps konnen<br />
nun durch geeignete Wahl von Werten fur die Dienstattribute, beispielsweise<br />
costPerPage =0.3,von anderen Diensterbr<strong>in</strong>gern unterschieden werden. Diese<br />
Eigenschaft spielt <strong>in</strong>sbesondere bei der Dienstvermittlung e<strong>in</strong>ewichtige Rolle.<br />
Generell werden statische und dynamische Dienstattribute unterschieden, wobei<br />
beispielsweise costPerPage als statisches Dienstattribut de niert ist, da sich<br />
diese Eigenschaft wahrend der Lebenszeit e<strong>in</strong>es Diensterbr<strong>in</strong>gers im allgeme<strong>in</strong>en<br />
nichtoder nur sehr selten andert. E<strong>in</strong> Beispiel fur e<strong>in</strong> dynamisches Dienstattribut<br />
fur e<strong>in</strong>en Druckdienst ware die aktuelle Warteschlangenlange, da sich diese Eigenschaft<br />
je nach Auslastung permanent andern kann. Generell existieren jedoch<br />
ke<strong>in</strong>e Regeln fur die Unterscheidung<strong>in</strong>statischund dynamisch, sondern sie ist fur<br />
jeden Diensttyp anwendungsabhangig zu de nieren, wobei auch die Konsequenzen<br />
fur den Dienstauswahlproze e<strong>in</strong>er Dienstvermittlungskomponente beruck-
2.4 Formen von Dienstbeschreibungen 33<br />
sichtigt werden mussen. Dort kann es unter Umstanden s<strong>in</strong>nvoll se<strong>in</strong>, die <strong>in</strong> der<br />
Regel recht zeitaufwendige Auswertung dynamischer Attribute moglichst weit<br />
h<strong>in</strong>auszuzogern, um sie eventuell gar nicht mehr durchfuhren zu mussen (siehe<br />
Abschnitt 3.3.2.3).<br />
Die Attributierung von Diensten im Rahmen des oben dargestellten Diensttypkonzeptes<br />
ist e<strong>in</strong> erster wesentlicher Schritt zur Beschreibungsemantischer Informationen<br />
e<strong>in</strong>es Dienstes. Attributierung ndet generell auch<strong>in</strong>anderen Bereichen<br />
ahnliche Verwendung, um Informationen strukturiert anbieten zu konnen. E<strong>in</strong><br />
Beispiel s<strong>in</strong>d die Namensdienste<strong>in</strong><strong>verteilten</strong> Systemen, wie beispielsweise X.500<br />
[Rad94] oder DCE CDS [OSF92], die das E<strong>in</strong>fugen von beschreibenden Attributen<br />
zu Namense<strong>in</strong>tragen erlauben. E<strong>in</strong> anderer Anwendungsbereich ist die strukturierte<br />
Suche nach Informationen (engl. <strong>in</strong>formation retrieval) [SM83, ANS95].<br />
Hier werden Attribute als <strong>in</strong>haltsbeschreibende Schlusselworter verwendet, die<br />
zur Indizierung von Texten dienen, die dann e zient mit Hilfe von Literaturdatenbanken<br />
verwaltet werden konnen.<br />
2.4.3.2 Konzeptgraphen<br />
E<strong>in</strong>e Fortfuhrung der Attributierung von Diensten ist e<strong>in</strong> auf sogenannten Konzeptgraphen<br />
[Sow84] aufbauender Ansatz, der <strong>in</strong> [PB96] ausfuhrlich beschrieben<br />
ist. Grundlegende Idee dieses aus dem Bereich der Wissensreprasentation stammenden<br />
Ansatzes ist die De nition von sogenannten Konzepten. Konzepte beschreiben<br />
D<strong>in</strong>ge der Vorstellungswelt des Menschen und konnen sowohl abstrakter<br />
als auch physikalischer Natur se<strong>in</strong>. In Anwendung auf Dienstbeschreibungen<br />
kann dieses beispielsweise das physikalische Konzept e<strong>in</strong>es Druckers mit dessen<br />
abstrakter Eigenschaft se<strong>in</strong>er Druckgeschw<strong>in</strong>digkeit se<strong>in</strong>. Konzepte werden hierbei<br />
durch Relationen verknupft, die die Beziehungen zwischen ihnen ausdrucken.<br />
Aus formaler Sicht iste<strong>in</strong>Konzeptgraph e<strong>in</strong> endlicher, verbundener, gerichteter,<br />
bipartiter Graph, dessen Knoten entweder Konzept{ oder Relationsknoten<br />
s<strong>in</strong>d. Abbildung 2.7 gibt e<strong>in</strong> Beispiel e<strong>in</strong>es Konzeptgraphen zur Beschreibung<br />
der Eigenschaften e<strong>in</strong>es Druckers, wobei eckige Klammern Konzepte und runde<br />
Klammern Relationen bezeichnen.<br />
[Pr<strong>in</strong>ter] -<br />
-> (IS-A) -> [HARDWARE-DEVICE],<br />
-> (CONNECTED-TO) -> [COMPUTER],<br />
-> (VISUALIZES) -> [INFORMATION] -> (CAN-BE) -> [TEXTUAL],<br />
-> [GRAPHICAL].,<br />
-> (PRINTS-ON) -> [PAPER],<br />
-> [SLIDES]..<br />
Abbildung 2.7: Konzeptgraph zur Beschreibungder Eigenschaften e<strong>in</strong>es Druckers<br />
Informell ausgedruckt bedeutet diese Beschreibung: " E<strong>in</strong> Drucker ist e<strong>in</strong> Gerat,
34 Modellierung und Beschreibung von Diensten<br />
welches an e<strong>in</strong>en Computer angeschlossen ist und Informationen entweder textuell<br />
oder graphisch auf Papier oder Folien drucken kann\. Diese Beschreibung<br />
kann anschlie endmitanderen Beschreibungen auf Ahnlichkeiten verglichen werden.<br />
E<strong>in</strong>e Ahnlichkeit zweier Beschreibungen wird auf der Grundlage e<strong>in</strong>es Ahnlichkeitsma<br />
es ermittelt, das die sogenannte semantische Distanz zweier Konzeptgraphen<br />
bestimmt [Sow84].<br />
In Anwendung auf die Dienstsuche <strong>in</strong><strong>verteilten</strong> Dienstemarkten konnen so mit<br />
Hilfe von Konzeptgraphen Anfragen nach Dienstbeschreibungen formuliert werden,<br />
die beispielsweise fur die Entwicklungvon <strong>verteilten</strong> Anwendungen benotigt<br />
werden. Durch den Vergleich mit bereits vorhandenen Konzeptgraphen konnen<br />
dann ahnliche Dienstbeschreibungen automatisiert gefunden werden. Dabei ist<br />
der Anfragevorgang<strong>in</strong>der Regel mehrstu g durchzufuhren, um den gewunschten<br />
Dienst durch e<strong>in</strong>everfe<strong>in</strong>erte Wahl von Konzepten und Relationen schrittweise<br />
e<strong>in</strong>zugrenzen [PGM95].<br />
E<strong>in</strong> grundsatzliches Problem bei der Nutzung von Konzeptgraphen zur Beschreibung<br />
von Diensten ist ahnlich wie bei den namensbasierten Typisierungsmechanismen<br />
die Wahl geeigneter Bezeichner fur die Konzepteund Relationen. Da auch<br />
hier Namen, beispielsweise die Relation CONNECTED-TO,kontextabhangig gewahlt<br />
werden, eignen sich Konzeptgraphen eher fur die Verwendung <strong>in</strong>nerhalb kle<strong>in</strong>erer<br />
geschlossener Verwaltungsbereiche, da dort e<strong>in</strong> geme<strong>in</strong>sames Verstandnis der<br />
Konzepte und Beziehungen e<strong>in</strong>facher zu erreichen ist als im Rahmen weltweiter<br />
Dienstemarkte. Um Konzeptgraphen <strong>in</strong> <strong>verteilten</strong> Dienstemarkten s<strong>in</strong>nvoll<br />
nutzen zu konnen, ist e<strong>in</strong>e Standardisierung von Konzept{ und Relationsnamen<br />
erforderlich, die dem Benutzer e<strong>in</strong>en wohlde nierten Begri srahmen fur e<strong>in</strong>e efziente<br />
Suche geeigneter Dienste bzw. Diensttypen bereitstellt. Abbildung 2.8<br />
verdeutlicht den <strong>in</strong> [PB96] dargestellten Vorschlag zur standardisierten Beschreibung<br />
von Diensttypen am Beispiel e<strong>in</strong>es Druckdienstes.<br />
[SERVICE-TYPE:{"Pr<strong>in</strong>tService"}] -<br />
-> (CONSISTS-OF) -> [INTERFACE-TYPE:{"Pr<strong>in</strong>t"}],<br />
-> (CONSISTS-OF) -> [PROPERTY-TYPE:{"Pr<strong>in</strong>terAttributes"}].<br />
[INTERFACE-TYPE:{"Pr<strong>in</strong>t"}] -<br />
-> (CONSISTS-OF) -> [SIGNATURE:{"Pr<strong>in</strong>tJob"}].<br />
[SIGNATURE:{"Pr<strong>in</strong>tJob"}] -<br />
-> (IN_PARAMETER) -> [STRING:{"Data"}],<br />
-> (OUT_PARAMETER) -> [LONG:{"JobNumber"}].<br />
[PROPERTY-TYPE:{"Pr<strong>in</strong>terAttributes"}] -<br />
-> (STATIC-ATTRIBUTE) -> [FLOAT:{"costPerPage"}],<br />
-> (DYNAMIC-ATTRIBUTE) -> [LONG:{"queueLength"}].<br />
Abbildung 2.8: Standardisierte Bezeichner fur Konzepte und Relationen
2.4 Formen von Dienstbeschreibungen 35<br />
Wie im Vergleich zur Dienstbeschreibung <strong>in</strong>Abbildung 2.6 deutlich wird, bieten<br />
Konzeptgraphen e<strong>in</strong>e mogliche Alternativezuden auf Schnittstellenbeschreibungssprachen<br />
aufsetzenden Dienstbeschreibungen. Der Vorteil von Konzeptgraphen<br />
liegt <strong>in</strong> ihrer Erweiterbarkeit, durch E<strong>in</strong>fuhrung neuer Konzepteoder Relationen<br />
die Beschreibungneuartiger Aspektenahtlos <strong>in</strong>tegrieren zu konnen. Dieses<br />
ist<strong>in</strong>Schnittstellenbeschreibungssprachen ohne tiefergehende Anderungen der<br />
Syntax im allgeme<strong>in</strong>en nicht moglich. E<strong>in</strong> Beispiel fur e<strong>in</strong>e moglicheErweiterung<br />
ist das H<strong>in</strong>zufugen von Informationen, die e<strong>in</strong>em Klienten zur Generierung e<strong>in</strong>er<br />
zum Dienst passenden graphischen Benutzerschnittstelle dienen konnen. Dieses<br />
Konzept ist beispielsweise im Generischen Klienten [ML93b, MML94a] verwirklicht<br />
worden, der den <strong>in</strong>teraktiven Zugang zu beliebigen Diensten ermoglicht.<br />
2.4.4 Beschreibung des Verhaltens von Diensten<br />
Dienstattribute und Konzeptgraphen stellen e<strong>in</strong>e erste notwendige Erweiterung<br />
dar, die e<strong>in</strong>e Beschreibung semantischer Diensteigenschaften ermoglichen, die<br />
uber die strukturellen Aspektedes Schnittstellentyps h<strong>in</strong>ausgehen. Die von ihnen<br />
gebotenen Beschreibungsmoglichkeiten reichen jedoch nicht aus, das nach au en<br />
sichtbare dynamische Verhalten e<strong>in</strong>es Dienstes (bzw. das e<strong>in</strong>er Objekt<strong>in</strong>stanz<br />
dieses Dienstes) darzustellen.<br />
2.4.4.1 Protokollspezi kationen<br />
E<strong>in</strong> erster Ansatz zur Erweiterung signaturbasierter Dienstbeschreibungen ist die<br />
Nutzung von Transitionssystemen bzw. Automatenmodellen zur Beschreibung<br />
des Verhaltens e<strong>in</strong>es diensterbr<strong>in</strong>genden Objektes. Diese dienen zur Beschreibung<br />
des Protokolls an se<strong>in</strong>er Schnittstellen und legen die moglichen Reihenfolgen<br />
von Operationsaufrufen fest, die <strong>in</strong> Abhangigkeit zum jeweiligen Zustand<br />
des Objektes de niert s<strong>in</strong>d. Aus diesem Grund werden derartige Objekte auch<br />
als aktive Objekte [Nie93] im Gegensatz zu funktionalen Objekten bezeichnet,<br />
die ausschlie lich <strong>in</strong> ihren statischen Eigenschaften, <strong>in</strong>sbesondere den Operationssignaturen<br />
der Schnittstellentypen, beschrieben werden. Begrundet wird diese<br />
Sichtweise durch E<strong>in</strong>schrankungen der Ausdrucksmachtigkeit von Signaturen<br />
[NP91]:<br />
Ke<strong>in</strong>e e<strong>in</strong>heitliche Dienstverfugbarkeit: Die Verzogerung oder Zuruckweisung<br />
von Operationsaufrufen abhangig vom Zustand des Diensterbr<strong>in</strong>gers<br />
ist nicht ausdruckbar.<br />
Mehrere nebenlau g agierende Dienstnehmer: Der nebenlau ge Dienstzugri<br />
mehrerer Dienstnehmer mit sich zumTeil bee<strong>in</strong> u enden Handlungen<br />
ist mit Signaturen nicht darstellbar.<br />
AlternativeKooperationsprotokolle: Zu Client/Server{Protokollen alternative,<br />
auf Nachrichtenaustausch beruhende Protokolle, beispielsweise Early<br />
Reply [LHG86], konnen nicht formuliert werden.
36 Modellierung und Beschreibung von Diensten<br />
Wiederverwendung: Signaturen bieten zuwenige Informationen uber das<br />
Verhalten nebenlau g agierender Diensterbr<strong>in</strong>ger, um e<strong>in</strong>esichere Wiederverwendbarkeit<br />
<strong>in</strong> e<strong>in</strong>em neuen Anwendungskontext sicherstellen zu<br />
konnen.<br />
Ziel ist es nun, zusatzlich zu den auf Signaturbeschreibungen de nierten<br />
Vergleichbarkeits{ und Subtypisierungsmechanismen Verfahren zu entwickeln,<br />
die Aussagen uber die Interaktionskonformitat (engl. <strong>in</strong>teraction conformance)<br />
bzw. Anfrageersetzbarkeit (engl. request substitutability) von Dienstnehmer und<br />
Diensterbr<strong>in</strong>ger liefern.<br />
Zentraler Begri ist hierbei das Protokoll, welches die Folge der von e<strong>in</strong>em<br />
Diensterbr<strong>in</strong>ger bedienbaren Anfragen bzw. Operationsaufrufe <strong>in</strong>Abhangigkeit<br />
von dessen jeweiligen Zustand festlegt. Zur Modellierung des Protokolls e<strong>in</strong>es<br />
Diensterbr<strong>in</strong>gers mit se<strong>in</strong>en Zustandsanderungen wird e<strong>in</strong> kantenbeschriftetes<br />
Transitionssystem [Mil89] verwendet, bestehend aus e<strong>in</strong>er endlichen Menge von<br />
Zustanden und Zustandsubergangen. E<strong>in</strong>e Zustandsanderung im Diensterbr<strong>in</strong>ger<br />
ndet hierbei durch den Aufruf e<strong>in</strong>er Operation an dessen Schnittstelle statt<br />
und au ert sich imTransitionssystem im Ubergang von e<strong>in</strong>em Zustand <strong>in</strong>e<strong>in</strong>en<br />
anderen entlang der mit der entsprechenden Operation beschrifteten Kante. E<strong>in</strong><br />
e<strong>in</strong>faches Beispiel e<strong>in</strong>es Transitionssystems zeigt Abbildung 2.9 anhand der regularen<br />
Typen Stack und Variable 3 mit jeweils denselben Operationssignaturen<br />
get und put.<br />
put<br />
get<br />
Stack<br />
put<br />
get<br />
put<br />
Variable<br />
Abbildung 2.9: Transitionssysteme fur die Diensttypen Stack und Variable<br />
Beide Typen bieten jeweils e<strong>in</strong>e Moglichkeit zur Speicherung von Informationen.<br />
Im Fall von Stack konnen mehrere Informationen abgelegt werden, wahrend der<br />
Typ Variable nur e<strong>in</strong>en Speicherplatz zur Verfugung stellt. Wie schon bei <strong>in</strong>tuitiver<br />
Betrachtung der Transitionssysteme deutlich wird, zeigen beide Typen<br />
signi kante Unterschiede <strong>in</strong> ihrem nach au en gezeigtem Verhalten. So kann bei<br />
Stack zu jeder put{Operation nur jeweils genau e<strong>in</strong>get erfolgen, wahrend h<strong>in</strong>gegen<br />
bei Variable beliebig viele get{Operationen aufgerufen werden konnen.<br />
Formal wird dieser Nachweis der Inkompatibilitat beider regularer Typen durch<br />
die Anwendungwohlde nierter Vergleichsregeln gefuhrt, die auf den Reihenfolgen<br />
(engl. traces) moglicher Operationsaufrufe formuliert s<strong>in</strong>d. Der Vergleich wird<br />
mit Hilfe e<strong>in</strong>es auf der Aquivalenz endlicher Automaten beruhenden Algorithmus<br />
[AHU74] realisiert. Mit diesem Algorithmus lassen sich auch Subtypbeziehungen<br />
zwischen regularen Typen erkennen, die jedoch aus Komplexitatsgrunden auf<br />
3 <strong>in</strong> Analogie zu Variablen <strong>in</strong> Programmiersprachen<br />
put<br />
get
2.4 Formen von Dienstbeschreibungen 37<br />
e<strong>in</strong>fache Automaten beschrankt s<strong>in</strong>d. Wird zum Beispiel der obige Typ Stack<br />
um e<strong>in</strong>e Operation swap erganzt, die alternativ zu get und put aufgerufen werden<br />
kann, so ist er als <strong>in</strong>teraktionskonform erkennbar. E<strong>in</strong>e umfassende formale<br />
Darstellung hierzu ndet sich unter anderem <strong>in</strong> [Nie93].<br />
E<strong>in</strong>e vom Ansatz her ahnliche Verwendung wie bei den regularen Typen nden<br />
Transitionssysteme auch bei dem Entwurf und der Entwicklung von Kommunikationsprotokollen<br />
<strong>in</strong> <strong>verteilten</strong> Systemen, wie sie unter anderem durch das<br />
OSI{Referenzmodell [EF86] standardisiert s<strong>in</strong>d. Bei diesem sogenannten Protocol<br />
Eng<strong>in</strong>eer<strong>in</strong>g [Sch92c] dienen Automatenmodelle als Grundlage fur formale<br />
Beschreibungstechniken (engl. formal description technique { FDT), mit deren<br />
Hilfe Protokolle spezi ziert und veri ziert werden konnen. E<strong>in</strong> Protokoll wird<br />
dabei verstanden als e<strong>in</strong>e verb<strong>in</strong>dliche Absprache zwischen zwei Protokoll<strong>in</strong>stanzen<br />
derselben Kommunikationsschicht, beispielsweise der Transportschicht des<br />
OSI{Referenzmodells. Es legt fest, welche Protokolldatene<strong>in</strong>heiten zwischen den<br />
Beteiligten ausgetauscht werden mussen, damit e<strong>in</strong>e wohlde nierte Interaktion<br />
moglich ist. Formale Beschreibungstechniken bestehen jeweils aus e<strong>in</strong>er formalen<br />
Syntax, die die Beschreibungsmittel zur Darstellung von Sprachausdrucken festlegt,<br />
und e<strong>in</strong>er formalen Semantik, die die e<strong>in</strong>deutige Interpretation der Sprachausdrucke<br />
auf der Basis e<strong>in</strong>es mathematisch de nierten semantischen Modells<br />
festlegt [VS87]. KonkreteVertreter von formalen Beschreibungsmethoden, deren<br />
Grundlage erweiterte endliche Automatenmodelle bilden, s<strong>in</strong>d die <strong>in</strong>ternational<br />
standardisierten Sprachen Estelle und SDL. Beides<strong>in</strong>dumfassend <strong>in</strong> [Hog89]dargestellt.<br />
Andere im Zusammenhang mit Kommunikationsprotokollen verwendete<br />
formale Beschreibungssprachen s<strong>in</strong>d unter anderem LOTOS [BB87], welche auf<br />
e<strong>in</strong>er Proze algebra aufbaut, und die Sprache Z [Spi89], deren formale Grundlage<br />
die Pradikatenlogik erster Ordnung bildet.<br />
Wesentlicher Unterschied der Kommunikationsprotokolle zu den durch regulare<br />
Typen dargestellten Konformitatsprotokollen ist das Verstandnis von Protokoll.<br />
So beschreiben Protokolle im Kommunikationsbereich immer die Interaktion von<br />
zwei Protokoll<strong>in</strong>stanzen, wahrend h<strong>in</strong>gegen bei regularen Typen nur das Verhalten<br />
e<strong>in</strong>er Instanz, <strong>in</strong>sbesondere des Diensterbr<strong>in</strong>gers von Interesse ist. Im ersten<br />
Fall stehen die Zustandebeider Protokoll<strong>in</strong>stanzen im engen Zusammenhang zue<strong>in</strong>ander,<br />
so da e<strong>in</strong>e Anderung des Zustands e<strong>in</strong>er Protokoll<strong>in</strong>stanz gleichzeitig<br />
auch Auswirkungen auf den Zustand der anderen besitzt. Der aktuelle Zustand<br />
e<strong>in</strong>er Interaktion ist dann abhangig von beiden Protokoll<strong>in</strong>stanzen. Bei regularen<br />
Typen h<strong>in</strong>gegen ist nur der Zustand des Diensterbr<strong>in</strong>gers von Interesse, der sich<br />
<strong>in</strong> Abhangigkeit von den Protokolldatene<strong>in</strong>heiten, d.h. den von e<strong>in</strong>em Dienstnehmer<br />
aufgerufenen Operationen, und se<strong>in</strong>em jeweiligen Zustand andern kann.<br />
Welchen E<strong>in</strong> u diese Anderungen auf den Zustand des Dienstnehmers haben,<br />
wird durch regulare Typen jedoch nicht festgelegt.<br />
2.4.4.2 Anwendung von Transitionssystemen<br />
Praktische Anwendung nden regulare Typen bzw. kantenbeschriftete Transitionssysteme<br />
beispielsweise im sogenannten Generischen Klienten [ML93b,
38 Modellierung und Beschreibung von Diensten<br />
ML93a, MML94a], wo sie zur De nition von Protokollen zur Steuerung von<br />
Operationsaufrufen dienen. Der Generische Klient realisiert e<strong>in</strong>en e<strong>in</strong>heitlichen<br />
<strong>in</strong>teraktiven Zugangdes Endbenutzers zu beliebigen Anwendungsdiensten <strong>in</strong> <strong>verteilten</strong><br />
Dienstemarkten. Zentrales Steuerungselement der <strong>Dienstnutzung</strong> ist die<br />
Dienstreprasentation (sieheauchAbschnitt 2.1). Sie ist e<strong>in</strong>e im<strong>verteilten</strong> System<br />
versendbare Reprasentation von Dienstbeschreibungs<strong>in</strong>formationen und umfa t<br />
alle wesentlichen Informationen uber den erbrachten Dienst. Sie be<strong>in</strong>haltet die<br />
Beschreibung der operationalen Schnittstelle, De nitionen zur Generierung der<br />
zur Schnittstelle passenden graphischen Benutzerschnittstelle, Protokoll<strong>in</strong>formationen<br />
zur Steuerung der <strong>Dienstnutzung</strong> und e<strong>in</strong>gebettete lokale Zustandsvariablen,<br />
die e<strong>in</strong>en Dialogzustand persistent speichern konnen. Hierbei ist sie ebenso<br />
wie die obige auf Konzeptgraphen basierende Dienstbeschreibung nahtlos um<br />
zusatzliche Beschreibungskomponenten erweiterbar, so da <strong>in</strong>krementell die Beschreibungsmoglichkeiten<br />
vergro ert werden konnen, beispielsweise durch Integration<br />
von Kosten<strong>in</strong>formationen fur die Nutzung der angebotenen Operationen<br />
[MML94a] und Ablaufbeschreibungen im Rahmen unternehmensubergreifender<br />
Geschaftsprozesse [MML95b]. E<strong>in</strong>e Dienstreprasentation wird vom Diensterbr<strong>in</strong>ger<br />
erzeugt undzumB<strong>in</strong>dungszeitpunkt an den Generischen Klienten ubertragen,<br />
der nach Interpretation der Beschreibungs<strong>in</strong>formationen fur den Benutzer e<strong>in</strong><br />
Bildschirmformular generiert, mit dessen Hilfe der Aufruf der Operationen des<br />
Diensterbr<strong>in</strong>gers moglich ist. E<strong>in</strong>e Operation wird hierbei beispielsweise durch<br />
zu den E<strong>in</strong>{ und Ausgabeparametern der Operation passenden E<strong>in</strong>{ und Ausgabefelder<br />
und e<strong>in</strong>en dazugehorigen Aktivierungsknopf reprasentiert. Die mogliche<br />
Aufrufreihenfolge der Operationen legt das Interaktionsprotokoll fest, welches<br />
Bestandteil der Dienstreprasentation ist. Unterstutzung uber die mogliche<br />
nachste Auswahl e<strong>in</strong>er ausfuhrbaren Operation erhalt der Benutzer beispielsweise<br />
durch " Ausgrauen\ der E<strong>in</strong>gabefelder e<strong>in</strong>er bestimmten Operation, das die<br />
Nichtverfugbarkeit der Operation anzeigt.<br />
Au er der Anwendung von Transitionssystemen als Grundlage fur Protokollbeschreibungen<br />
ersche<strong>in</strong>t der Ansatz des Generischen Klienten <strong>in</strong>sbesondere wegen<br />
se<strong>in</strong>er Visualierungsmoglichkeiten <strong>in</strong>teressant, die e<strong>in</strong>e benutzergerechteDarstellung<br />
der abstrakten Sachverhaltee<strong>in</strong>er Dienstbeschreibung ermoglichen und das<br />
Suchen geeigneter Dienste bzw. Diensttypen <strong>in</strong> <strong>verteilten</strong> Dienstmarkten erleichtern.<br />
Hierdurchkonnen <strong>in</strong> der Phase der Diensttyp ndung(sieheAbschnitt 3.1.2)<br />
gewunschte Diensttypen ermittelt werden und <strong>in</strong> ihrer Semantik untersuchtwerden,<br />
was zusatzlich durch die Moglichkeit zum Testen und Ausprobieren der<br />
<strong>in</strong>teraktiv aufrufbaren Operationen s<strong>in</strong>nvoll unterstutzt wird.<br />
2.4.4.3 Spezi kation von Vor{ und Nachbed<strong>in</strong>gungen<br />
Mit Hilfe von Vor{ und Nachbed<strong>in</strong>gungen werden Aussagen uber das Verhalten<br />
e<strong>in</strong>es Diensterbr<strong>in</strong>gers getro en, welches durch dessen Zustand vor und nach der<br />
Ausfuhrunge<strong>in</strong>er Operation bestimmt wird. Sie werden ausgedruckt als pradikatenlogischeFormeln,<br />
die uber den formalen Parametern der Operationen de niert<br />
s<strong>in</strong>d. Abbildung 2.10 zeigt e<strong>in</strong>en Ausschnitt e<strong>in</strong>er <strong>in</strong> Larch/CORBA [LC93] beschriebenen<br />
Spezi kation e<strong>in</strong>er Druckwarteschlange mit der Operation enqueue.
2.4 Formen von Dienstbeschreibungen 39<br />
typedef unsigned long JobID� exception QUEUE_FULL�<br />
<strong>in</strong>terface Pr<strong>in</strong>terQueue {<br />
}<br />
uses Queue(Pr<strong>in</strong>terQueue for C, JobID for E, unsigned long for Int)�<br />
const unsigned long MAX_QUEUE_SIZE = 100�<br />
void enqueue (<strong>in</strong> JobID id) raises (QUEUE_FULL) {<br />
requires true�<br />
modifies self�<br />
ensures self' = append(self!,id)<br />
except when len(self') > MAX_QUEUE_SIZE => raise(QUEUE_FULL)�<br />
}<br />
Abbildung 2.10: Beispiel e<strong>in</strong>er um Vor{ und Nachbed<strong>in</strong>gungen erweiterten COR-<br />
BA IDL<br />
Aufgabe der Operation enqueue ist die Entgegennahme neuer Druckauftrage,<br />
wobei je nach Auslastung der Warteschlange gegebenfalls der Fehler QUEUE FULL<br />
ausgelost wird. Da die Vorbed<strong>in</strong>gung (requires true) <strong>in</strong> diesem Fall immer<br />
wahr ist, kann e<strong>in</strong> Klient die Operation jederzeit aufrufen. Die Zeile modifies<br />
self legt fest, da durch die Operation ke<strong>in</strong>e anderen Objekteau er dem Warteschlangenobjekt<br />
verandert werden darf, wobei self das Objekt bezeichnet, bei<br />
dem enqueue aufgerufen wurde. Die Nachbed<strong>in</strong>gung ensures self' besagt, da<br />
e<strong>in</strong> neuer Druckauftrag nur dann entgegengenommen wird, wenn die maximale<br />
Lange der Warteschlange noch nicht uberschritten ist. Ansonsten wird e<strong>in</strong> Fehler<br />
ausgegeben. self! bzw. self' bezeichnen hierbei den Zustandder Warteschlange<br />
vor undnachdem Operationsaufruf. Der Zustand wird <strong>in</strong> diesem Kontext auch<br />
als abstrakter Wert des Objekts bezeichnet. In der obigen Spezi kation wird der<br />
abstrakte Wert Queue (Zeile uses Queue) verwendet, der formal <strong>in</strong> der Larch<br />
Shared Language (LSL) [GHG + 93] spezi ziert ist, <strong>in</strong> der unter anderem auch die<br />
Operation append de niert ist.<br />
Fur diese LSL{Spezi kationen der abstrakten Werte existiert e<strong>in</strong> semi{<br />
automatischer Theorembeweiser, der sogenannte Larch Proof Assistant, mit<br />
dessen Hilfe e<strong>in</strong> Benutzer Aussagen uber die Korrektheit der spezi zierten<br />
abstrakten Werte tre en kann. Dabei wird die Beweisfuhrung hauptsachlich<br />
<strong>in</strong>teraktiv durchden Benutzer gefuhrt, wobei der Therombeweiser ihn primar bei<br />
Standardbeweisen durch automatische Beweisverfahren unterstutzt. Verfahren<br />
oder Werkzeuge fur die Vergleichbarkeit von LSL{Spezi kationen, <strong>in</strong>sbesondere<br />
automatische Verfahren, existieren h<strong>in</strong>gegen jedoch nicht.<br />
Das wesentliche Problem bei der Spezi kation von Vor{ und Nachbed<strong>in</strong>gungen<br />
ist die Komplexitat, die derartige Spezi kationen <strong>in</strong> der Regel auszeichnen. So
40 Modellierung und Beschreibung von Diensten<br />
hei t es beispielsweise <strong>in</strong> [LC93]: " The abstract values needed to describe such<br />
application software as OMG and others hope to make available under CORBA<br />
would seem to bevery complex. An om<strong>in</strong>ous fact is thatthe size of a good user's<br />
manual is typically a small book.\ Sokonnen derartige, komplexe Spezi kationen<br />
unter Umstanden fur den Anwendungsprogrammierer sehr unubersichtlich<br />
werden. Erschwerendkommt h<strong>in</strong>zu, da bed<strong>in</strong>gt durch die Komplexitat die Uberprufunge<strong>in</strong>er<br />
Subtypbeziehung zwischen zwei Typen, d.h. ob e<strong>in</strong> Subtyp weichere<br />
Vorbed<strong>in</strong>gungen und strengere Nachbed<strong>in</strong>gungen besitzt [Ame91, LW93], nicht<br />
automatischveri zierbar ist [AL90]. So liegt es <strong>in</strong> der Regel <strong>in</strong> der Verantwortung<br />
e<strong>in</strong>es Programmierers, die Subtybeziehungen zwischen zwei Diensten selbstandig<br />
zu uberprufen, um sie dann anschlie end explizit <strong>in</strong> e<strong>in</strong>e Subtyphierarchie e<strong>in</strong>zuordnen.<br />
In [Ame87] hei t es hierzu bei der Darstellung der Programmiersprache<br />
POOL: " The behaviour of objects cannot be formalized <strong>in</strong> all its aspects, so the<br />
compiler cannot check completely thatonetype is a subtype of another ... To ensure<br />
thatasubtype really specializes its supertype with respect to itsbehaviour,<br />
a certa<strong>in</strong> discipl<strong>in</strong>e is required from the programmer: To the formal description<br />
of the available methods and their parameter and resulttypes, an <strong>in</strong>formal<br />
description of the behaviour of the elements ofthe type should be added, and<br />
whenever a programmer asserts asubtype relationship between two types, he<br />
should check the condition on the associated behaviour description himself.\<br />
Durch diese E<strong>in</strong>schrankungen s<strong>in</strong>d auf Vor{ und Nachbed<strong>in</strong>gungen basierende<br />
Dienstbeschreibungen nur bed<strong>in</strong>gt zur Uberprufung der Interoperabilitat zweier<br />
Dienste <strong>in</strong> o enen <strong>verteilten</strong> Systemen nutzbar. Sie dienen jedoch als s<strong>in</strong>nvolle<br />
erganzende Beschreibung der ansonsten nur durch Signaturen gekennzeichneten<br />
Diensttypen und konnen beispielsweise fur das Suchen geeigneter Diensttypen<br />
wahrend der Entwicklungsphase e<strong>in</strong>er <strong>verteilten</strong> Anwendung vom Benutzer zum<br />
besseren Verstandnis dessen Verhaltens genutzt werden.<br />
2.4.5 Bewertung<br />
Ausgangsbasis fur die Untersuchungverschiedener Ansatze zur Beschreibungvon<br />
Diensten stellt die Betrachtung der verschiedenen Ebenen der Interoperabilitat<br />
von Diensten <strong>in</strong> <strong>verteilten</strong> Systemen dar. Dabei hat sich <strong>in</strong>sbesondere gezeigt,<br />
da Interoperabilitatsprobleme <strong>in</strong><strong>verteilten</strong> Systemen | unter Voraussetzung<br />
e<strong>in</strong>es geme<strong>in</strong>samen Dienstmodells | im wesentlichen durch zwei Ursachen hervorgerufen<br />
werden:<br />
1. E<strong>in</strong>e Problematik besteht <strong>in</strong>der Nutzung verschiedener Diensttypmodelle,<br />
beispielsweise durch Wahl verschiedener Datentypen, durch die e<strong>in</strong>e<br />
Vergleichbarkeit von Diensten nicht durchfuhrbar ist. Zur Losung dieses,<br />
durch die Heterogenitat verschiedener Dienstbeschreibungen hervorgerufenen<br />
Problems mussen entsprechende Mechanismen de niert werden, die<br />
die Abbildung zwischen den verschiedenartigen Diensttypmodellen oder die<br />
Abbildung auf e<strong>in</strong> geme<strong>in</strong>sames, vere<strong>in</strong>heitlichendes Diensttypmodell e<strong>in</strong>deutig<br />
festlegen. Erst hierdurch kann e<strong>in</strong> Vergleich von Schnittstellentypen<br />
durchgefuhrt und somit die Typsicherheit von Dienstnehmer und Dienster-
2.4 Formen von Dienstbeschreibungen 41<br />
br<strong>in</strong>ger gewahrleistet werden.<br />
2. E<strong>in</strong>e zweite grundsatzliche Problematik betri t den Informationsverlust<br />
beim Ubergangvon der Dienstmodell{ <strong>in</strong> die Dienstbeschreibungsebene. So<br />
gehen dort <strong>in</strong> der Regel oftmals wesentlicheCharakteristika e<strong>in</strong>es Dienstes,<br />
vor allem semantische Aspekte, bei der Dienstbeschreibungverloren, so da<br />
e<strong>in</strong>e E<strong>in</strong>e<strong>in</strong>deutigkeit zwischen der Dienstbeschreibung und des hiermit beschriebenen<br />
Dienstes nicht gewahrleistet ist. Dies wurde am Beispiel der<br />
Dienste Stack und Queue deutlich, die trotz syntaktischer Gleichheit der<br />
Operationssignaturen e<strong>in</strong> verschiedenartiges Verhalten aufweisen. Aus diesem<br />
Grund wurden verschiedene Formen von Dienstbeschreibungen untersucht,<br />
beg<strong>in</strong>nend mit namensbasierten Ansatzen, die nur e<strong>in</strong>e sehr ger<strong>in</strong>ge<br />
Ausdrucksmachtigkeit besitzen, bis h<strong>in</strong> zu ausdrucksmachtigeren Beschreibungsformen,<br />
mit denen Verhaltensaspektevon Diensten ausgedruckt werden<br />
konnen.<br />
Wichtiges Kriterium beider Beurteilung dieser verschiedenen Beschreibungsansatze<br />
ist <strong>in</strong>sbesondere deren Verwendbarkeit <strong>in</strong>nerhalb o ener verteilter Systeme.<br />
So werden beispielsweise <strong>in</strong> heutigen <strong>verteilten</strong> Systemplattformen, unter<br />
anderem ANSA oder DCE, hauptsachlich die namensbasierten Formen von<br />
Dienstbeschreibungen aufgrund ihrer e<strong>in</strong>fachen Realisierung e<strong>in</strong>gesetzt. Gleichzeitig<br />
wird hiermit jedoch auch <strong>in</strong>Kauf genommen, da die Interoperabilitat von<br />
Dienstnehmer und Diensterbr<strong>in</strong>ger nur bed<strong>in</strong>gt gewahrleistet werden kann, da<br />
bis auf Namensaquivalenz ke<strong>in</strong>e weiteren Kriterien fur e<strong>in</strong>e semantische Ubere<strong>in</strong>stimmung<br />
existieren. Um namensbasierte Ansatze auch weiterh<strong>in</strong> im Rahmen<br />
verteilter Systeme e<strong>in</strong>setzen zu konnen, ist hierfur e<strong>in</strong>e weitreichende Standardisierung<br />
sowohl von Typbezeichnern, <strong>in</strong>sbesondere Diensttypbezeichnern, als<br />
auch der Subtypbeziehungen zwischen diesen notwendig.<br />
E<strong>in</strong>e exiblere Losung dieses Problems versprechen die strukturellen Beschreibungsansatze,<br />
die die e<strong>in</strong>fache Namensgebung um strukturelle Aspekte e<strong>in</strong>es<br />
Dienstes erganzen und auf die Benennung von Operationsnamen e<strong>in</strong>schranken.<br />
So werden hierbei die Signaturen der Operationen als kontextunabhangiges Vergleichskriterien<br />
h<strong>in</strong>zugezogen, welche mit existierenden Vergleichsalgorithmen<br />
automatisch auf strukturelle Aquivalenzen uberprufbar s<strong>in</strong>d.<br />
Der Automatisierbarkeit kommte<strong>in</strong>ewesentliche Bedeutung zu, da alle wesentlichen<br />
Schritte der Interaktion zwischen e<strong>in</strong>em Dienstnehmer und e<strong>in</strong>em Diensterbr<strong>in</strong>ger<br />
<strong>in</strong> vielen <strong>verteilten</strong> Anwendungen hochgradig automatisiert ablaufen. Dieses<br />
betri t vor allem die Phasen der Dienst ndung, der B<strong>in</strong>dung und des Zugri s<br />
auf die Operationen des Diensterbr<strong>in</strong>gers. Diese Anforderung stellt auch e<strong>in</strong>en<br />
wesentlichen Schwachpunkt der verhaltensbeschreibenden Dienstbeschreibungsformen<br />
dar, die zwar e<strong>in</strong>e wesentlichhohere Machtigkeit bezuglichdes Ausdrucks<br />
von verhaltensspezi schen Aspekten von Diensten besitzen, aufgrund ihrer Komplexitat<br />
jedoch <strong>in</strong>der Regel nicht automatisch vergleichbar und zumTeil auch<br />
nicht veri zierbar s<strong>in</strong>d.<br />
S<strong>in</strong>nvoll e<strong>in</strong>gesetzt werden konnen sie jedoch bei der <strong>in</strong>teraktiven Suche von<br />
Diensten bzw. Diensttypen. Hierbei konnen die Benutzer oder Programmierer
42 Modellierung und Beschreibung von Diensten<br />
durchInterpretation des formal spezi zierten Verhaltens Ruckschlusse auf die Semantik<br />
e<strong>in</strong>es Dienstes ziehen, wobei gegebenfalls automatischeTeilverfahren, beispielsweise<br />
zur Uberprufungder Aquivalenz von regularen Typen bzw. endlichen<br />
Automaten, zur Unterstutzunge<strong>in</strong>gesetzt werden konnen. Unterstutzungfur e<strong>in</strong><br />
derartiges <strong>in</strong>terpretatives,benutzergesteuertes Vorgehen bieten auch Konzeptgraphen<br />
und Dienstattribute, die spezielle Eigenschaften e<strong>in</strong>es Dienstes naher charakterisieren<br />
und dem Benutzer H<strong>in</strong>weise auf die Semantik e<strong>in</strong>es Dienstes liefern.<br />
Da beide Konzepte jedochauf e<strong>in</strong>er kontextabhangigen Namensgebungberuhen,<br />
beispielsweise Namen von Attributen, gelten fur sie dieselben E<strong>in</strong>schrankungen<br />
wie bei den namensbasierten Dienstbeschreibungen.<br />
Zusammenfassend ergibt sich hieraus, da e<strong>in</strong>e vollstandige Interoperabilitat e<strong>in</strong>es<br />
Dienstnehmers und e<strong>in</strong>es Diensterbr<strong>in</strong>gers <strong>in</strong> o enen heterogenen <strong>verteilten</strong><br />
Systemen nicht erreichbar ist, sofern nicht verb<strong>in</strong>dliche, d.h. standardisierte Absprachen<br />
uber die Semantik e<strong>in</strong>es Dienstes bzw. Diensttyps vere<strong>in</strong>bart werden.<br />
Diese Forderung wird weiter dadurch verstarkt, da | wie aus der obigen Betrachtung<br />
verschiedener Formen von Dienstbeschreibungen ersichtlich wird |<br />
e<strong>in</strong>e vollstandige Beschreibung der " Bedeutung\ e<strong>in</strong>es Dienstes nicht moglich<br />
ist. Au erdem ist die Beschreibung von Teilaspekten der Semantik, beispielsweise<br />
des Verhaltens an der Schnittstelle, bereits derartig komplex, da e<strong>in</strong>e<br />
automatische Uberprufbarkeit und Vergleichbarkeit von Diensten gegenwartig<br />
an die Grenzen der Realisierbarkeit sto t. Fragestellungen nach der generellen<br />
Entscheidbarkeit dieser Problemstellungen s<strong>in</strong>d hierbei noch unberucksichtigt.<br />
E<strong>in</strong> <strong>in</strong> diesem Zusammenhang wichtiger Aspekt zukunftiger Forschung istunter<br />
anderem, <strong>in</strong>wieweit die sich gegenseitig widerstrebenden Ziele nachAutomatisierbarkeit<br />
auf der e<strong>in</strong>en und Ausdrucksmachtigkeit auf der anderen Seite moglichst<br />
weitgehend angenahert werden konnen, so da <strong>in</strong> den meisten Anwendungsfallen<br />
die Interoperabiltat zwischen Dienstnehmern und Diensterbr<strong>in</strong>ger durchautomatisierte<br />
Uberprufungsverfahren sichergestellt werden kann. Zum gegenwartigen<br />
Zeitpunkt bietet <strong>in</strong>sbesondere die Beschreibung von Diensten mittels Dienstattributen<br />
e<strong>in</strong>e geeignete Kompromi losung, die vor allem im Umfeld der Dienstvermittlungsmechanismen,<br />
unter anderem <strong>in</strong> [ODP95a], [KW94], [BB94], [MB92]<br />
und [WT90], verwendet werden. Hierbei dienen die Dienstattribute als zusatzliches<br />
Auswahlkriterium bei der Suche nach geeigneten Diensterbr<strong>in</strong>gern.<br />
In heutigen <strong>verteilten</strong> Systemen beschrankt sich die Uberprufungvon Interoperabilitat<br />
primar auf die Untersuchung der strukturellen Aspekte der operationalen<br />
Schnittstellen von Diensten, wobei verteilte Systemplattformen, unter anderem<br />
DCE, CORBA, ANSA und ILU,vor allem namensbasierte Ansatze verwenden. 4<br />
Diese Beschrankung au ert sich unter anderem auch <strong>in</strong>den dort de nierten Subtypbeziehungen,<br />
die sich als e<strong>in</strong> Spezialfall der <strong>in</strong> Abschnitt 2.3.2 beschriebenen<br />
Konformitatsbeziehung auf das e<strong>in</strong>fache H<strong>in</strong>zufugen von Operationen zu e<strong>in</strong>em<br />
Schnittstellentyp konzentriert. Die Signaturen der Operationen nden ke<strong>in</strong>e<br />
Berucksichtigung.<br />
4 E<strong>in</strong>e genauere Betrachtung der Typisierungsaspekte aktueller verteilter Systemplattformen<br />
ndet sich unter anderem <strong>in</strong> [BIBY95].
2.5 Zusammenfassung 43<br />
E<strong>in</strong>e Grundproblematik heutiger verteilter Systemplattformen ist auch, da die<br />
De nition und Verwaltung von Typen und Beziehungen zumeist eigenstandig<br />
durch den Systembenutzer durchgefuhrt werden mu . E<strong>in</strong> markantes Beispiel ist<br />
hierbei DCE, wo dieVerantwortung uber die Korrektheit e<strong>in</strong>er de nierten Subtypbeziehung<br />
vollstandig beim Programmierer liegen. E<strong>in</strong>e weitere Uberprufung<br />
dieser Beziehung durch das DCE{Laufzeitsystem ndet nicht statt (siehe auch<br />
[MML95f]). Wunschenswert ware dort e<strong>in</strong>e Systemkomponente, welche e<strong>in</strong>ededizierte<br />
Behandlung von Typen und Typbeziehungen erlaubt. Hierdurch konnten<br />
die <strong>in</strong> der Regel im Systemkern verborgenen Typisierungsmechanismen explizit<br />
zuganglich gemacht werden. Auf diese Funktionen e<strong>in</strong>es derartigen Typmanagements<br />
geht Abschnitt 3.2 noch detailliert e<strong>in</strong>.<br />
2.5 Zusammenfassung<br />
Das <strong>in</strong> diesem Kapitel vorgestellte objektbasierte Dienstmodell mit se<strong>in</strong>em<br />
Diensttypmodell bildet die Grundlage fur die Modellierung von Diensten bzw.<br />
Dienstleistungen, die durch die Diensterbr<strong>in</strong>ger <strong>in</strong> o enen <strong>verteilten</strong> Systemen<br />
erbracht werden. Grundlegende Abstraktion hierbei ist der Begri der operationalen<br />
Schnittstelle, welche e<strong>in</strong>eAbstraktionsbarriere zwischen der nach au en<br />
gestellten Dienstleistung e<strong>in</strong>es Objektes und se<strong>in</strong>er <strong>in</strong>ternen Implementation erzw<strong>in</strong>gt.<br />
Hierdurch wird es moglich, die im <strong>verteilten</strong> System angebotenen Dienste<br />
auf abstrakteund e<strong>in</strong>heitliche Weise zu betrachten, ohne spezi schekontextspezischeAbhangigkeiten<br />
betrachten zu mussen. Die Typisierungvon Diensten durch<br />
das Diensttypmodell legt dabei die Art und Weise fest, wie auf den Dienst e<strong>in</strong>es<br />
Objektes zugegri en werden kann. So be<strong>in</strong>haltet der Schnittstellentyp alle wesentlichen<br />
Informationen, die fur e<strong>in</strong>en typsicheren Dienstzugri erforderlichs<strong>in</strong>d.<br />
Er ist selbst wiederum Bestandteil des Diensttyps, welcher den an der Schnittstelle<br />
angebotenen Dienst anhand von Dienstattributen semantisch naher charakterisiert.<br />
Ebenso wie der Schnittstellentyp dient erzumAufbau von Typhierarchien,<br />
die auf der Grundlage der Konformitatsbeziehung entwickelt werden.<br />
Diese eignen sich zur Darstellung der Dynamik o ener verteilter Dienstemarkte,<br />
<strong>in</strong>dem sie e<strong>in</strong>e s<strong>in</strong>nvolle Strukturierung der sich fortentwickelnden Dienste<br />
aufgrund wohlde nierter Ordnungskriterien ermoglichen. Wesentliche Voraussetzung<br />
hierfur bieten die im Diensttyp de nierten Signaturbeschreibungen der<br />
Operationen und der Dienstattribute.<br />
Fur die weitere Darstellung dieser Arbeit stellt das objektbasierte Dienstmodell<br />
die Ausgangsbasis dar, von der im folgenden Untersuchungen konkreter Systemtechniken<br />
durchgefuhrt werden, mit deren Hilfe e<strong>in</strong>e derartige, idealisierte<br />
Sichtweise auf Dienste und deren Nutzung <strong>in</strong> o enen heterogenen <strong>verteilten</strong><br />
Dienstemarkten realisierbar ist. Es dient gleichzeitig auch als formale Grundlage<br />
fur die <strong>in</strong> Teil II vorgestellte TRADE{Systemumgebung, die speziell fur die<br />
Unterstutzung der Dienstnehmer bei der koord<strong>in</strong>ierten Nutzung der <strong>in</strong> o enen<br />
heterogenen <strong>verteilten</strong> Dienstemarkten angebotenen Dienste entwickelt worden<br />
ist.
Kapitel 3<br />
Zugang zu Diensten <strong>in</strong><br />
heterogenen Umgebungen<br />
Im vorherigen Kapitel wurde speziell auf die Aspekte der Modellierung und Beschreibung<br />
von Diensten e<strong>in</strong>gegangen, mit denen sich e<strong>in</strong>ee<strong>in</strong>heitliche und abstrakte<br />
Sichtweise auf die <strong>in</strong> o enen heterogenen <strong>verteilten</strong> Dienstemarkten angebotenen<br />
Dienstleistungen erreichen la t, ohne da spezi sche Details der Realisierung<br />
derartiger Dienstemarkte berucksichtigt werden mussen. In dem vorliegenden<br />
Kapitel werden hierauf aufsetzend diejenigen systemtechnischen Mechanismen<br />
genauer untersucht, mit denen e<strong>in</strong>e derartige, idealisierte Sichtweise auf<br />
der Grundlage o ener heterogener verteilter Dienstemarkte verarbeitungstechnisch<br />
umgesetzt werden kann. Geme<strong>in</strong>same Aufgabe der betrachteten Systemtechniken<br />
ist die Realisierung e<strong>in</strong>es weitgehend une<strong>in</strong>geschrankten Zugangs zu<br />
den dort vorhandenen Diensten. Hierbei mussen vor allem Heterogenitatsaspekte<br />
berucksichtigt werden, die <strong>in</strong>nerhalb globaler o ener verteilter Dienstemarkte<br />
vorhanden s<strong>in</strong>d. Sie spielen bei den hier betrachteten Losungsansatzen e<strong>in</strong>e bedeutende<br />
Rolle.<br />
Im folgenden wird zuerst auf grundlegende Problemstellungen beim Zugang zu<br />
Diensten <strong>in</strong> o enen heterogenen <strong>verteilten</strong> Dienstemarkten e<strong>in</strong>gegangen und verschiedenePhasen<br />
des Dienstzugangs unterschieden. Hierauf aufbauendstellen die<br />
nachfolgenden Abschnittejeweils spezielle Systemtechniken vor, die e<strong>in</strong>e adaquate<br />
Unterstutzung dieser Dienstzugangsphasen bieten, wobei speziell die Fragen<br />
des Diensttypmanagements,der Dienstvermittlung unddes Dienstzugri s schwerpunktma<br />
ig behandelt werden.<br />
3.1 Grundlegende Problemstellungen<br />
Abbildung 3.1 gibt e<strong>in</strong>e generelle E<strong>in</strong>ordnung der <strong>in</strong> diesem Kapitel betrachteten<br />
Verarbeitungsebene, diee<strong>in</strong>e systemtechnische Umsetzung der auf Modellebene<br />
geforderten idealisierten und vere<strong>in</strong>heitlichenden Dienstabstraktion ermoglicht.<br />
Die Verarbeitungsebenestellt hierfur die Systemtechniken zur Verfugung, mit de-
46 Zugang zu Diensten <strong>in</strong> heterogenen Umgebungen<br />
Diensttyp<br />
Modellebene<br />
Diensterbr<strong>in</strong>ger<br />
ANSA<br />
Verarbeitungsebene<br />
Rechnerknoten<br />
DCE<br />
Betriebssystem-/Kommunikationsebene<br />
CORBA<br />
Abbildung 3.1: Betrachtungsebenen des Dienstzugangs<br />
ren Hilfe Diensterbr<strong>in</strong>ger realisiert werden konnen und der Zugang e<strong>in</strong>es Dienstnehmers<br />
zu den von ihnen erbrachten Diensten ermoglicht wird. Hierbei ist<br />
e<strong>in</strong>e der wesentlichen Aufgaben derartiger Systemtechniken, die Interoperabilitat<br />
der Dienstnehmer und der Diensterbr<strong>in</strong>ger zu unterstutzen. Sie bildet e<strong>in</strong>e<br />
Grundvoraussetzung fur e<strong>in</strong>e wohlde nierte <strong>Dienstnutzung</strong> <strong>in</strong> o enen <strong>verteilten</strong><br />
Dienstemarkten.<br />
Die Umsetzungvon auf Modellebene abstrakt betrachteten Diensttypen auf konkrete<br />
Diensterbr<strong>in</strong>ger <strong>in</strong> der Verarbeitungsebene ist <strong>in</strong> der Abbildung durch<br />
Pfeile zwischen der Modell{ und Verarbeitungsebene angedeutet. Grundannahme<br />
dieser Umsetzung ist das Vorhandense<strong>in</strong> e<strong>in</strong>es e<strong>in</strong>heitlichen Dienstmodells<br />
auf Modellebene, welches die abstrakte Sichtweise auf die <strong>in</strong> o enen <strong>verteilten</strong><br />
Dienstemarkten angebotenen Dienstleistungen festlegt. Pr<strong>in</strong>zipiell kann die Umsetzung<br />
e<strong>in</strong>es abstrakten Diensttyps durch mehrere verschiedene Diensterbr<strong>in</strong>ger<br />
realisiert se<strong>in</strong>, die auch auf der Grundlage verschiedener verteilter Systemplattformen,<br />
beispielsweise ANSA, DCE und CORBA, entwickelt worden s<strong>in</strong>d.<br />
Die Diensttypen werden mit Hilfe der plattformspezi schen Ausdrucksmittel beschrieben,<br />
die beispielsweise bei den drei genannten <strong>in</strong> Form von Schnittstellenbeschreibungssprachen<br />
angeboten werden. Aufgrund moglicher e<strong>in</strong>geschrankter<br />
Ausdrucksmoglichkeiten kann es hierbei unter Umstanden notwendig se<strong>in</strong>,<br />
Erweiterungen der Beschreibungsmittel vorzunehmen, um beispielsweise die Beschreibung<br />
von Dienstattributen h<strong>in</strong>zufugen zu konnen.<br />
Ausgangslage fur die Realisierung verteilter Systemplattformen auf der Verarbeitungsebene<br />
bildet die Betriebssystem{ und Kommunikationsebene. Sie bietet<br />
neben den Betriebssystemdiensten vor allem die notwendige Kommunikations<strong>in</strong>frastruktur,<br />
die die im o enen <strong>verteilten</strong> System vorhandenen Rechnerknoten<br />
mite<strong>in</strong>ander verknupft. Voraussetzung hierfur ist die E<strong>in</strong>igung auf geme<strong>in</strong>same<br />
Kommunikationsprotokolle, wie sie beispielsweise durch dieMechanismen
3.1 Grundlegende Problemstellungen 47<br />
des OSI{Referenzmodells [EF86] oder durch den " de{facto\{Standard TCP/IP<br />
[Com88] bereitgestellt werden. Auf dieser Grundlage konnen anschlie end verteilte<br />
Systemplattformen entwickelt werden, mit deren Hilfe die Diensterbr<strong>in</strong>ger<br />
und Dienstnehmer entwickelt und auf die vorhandenen Rechnerknoten verteilt<br />
werden konnen. Diese Verteilung ist <strong>in</strong> der Abbildung durch entsprechende von<br />
der Verarbeitungsebene ausgehende Pfeile verdeutlicht.<br />
3.1.1 Heterogenitat auf Verarbeitungsebene<br />
Abbildung 3.2 zeigt e<strong>in</strong>e verfe<strong>in</strong>erte Darstellung der Verarbeitungsebene.<br />
Verwaltungsdomäne A<br />
(CORBA)<br />
Trader<br />
Typmanager<br />
Server<br />
Interzeptor<br />
Verwaltungsdomäne C<br />
(DCE)<br />
Server<br />
Klient<br />
Interzeptor<br />
Trader<br />
Verwaltungsdomäne B<br />
(DCE)<br />
Klient<br />
Server<br />
Typmanager<br />
Typmanager<br />
Trader<br />
Abbildung 3.2: Heterogenitatsgrenzen beim Zugang zu Diensten<br />
Hauptgesichtspunkt ist die Betrachtung unterschiedlicher Verwaltungs{<br />
Domanen, die jeweils durch die <strong>in</strong> o enen <strong>verteilten</strong> Systemen agierenden<br />
Organisationen de niert werden. Domanen konnen selbst wiederum Unterdomanen<br />
besitzen, so da mit ihnen organisationelle und auch geographische<br />
Strukturen widergespiegelt werden konnen 1 . Innerhalb der Domanen konnen<br />
verschiedene Dienste angeboten werden, die sowohl von domanen<strong>in</strong>ternen als<br />
auch von domanenexternen Dienstnehmern <strong>in</strong> Anspruch genommen werden<br />
konnen. In ihrer Gesamtheit bilden die angebotenen Dienste e<strong>in</strong>en o enen<br />
<strong>verteilten</strong> und domanenubergreifenden Dienstemarkt.<br />
Als Konsequenz der Aufteilung o ener verteilter Dienstemarkte <strong>in</strong>verschiedene<br />
1 E<strong>in</strong> detailliert ausgefuhrtes Domanenkonzept unter Berucksichtigung dieser Aspekte ndet<br />
sich beispielsweise <strong>in</strong> [Tsc94].
48 Zugang zu Diensten <strong>in</strong> heterogenen Umgebungen<br />
Verwaltungsdomanen ergeben sich Heterogenitatsgrenzen beim domanen{ bzw.<br />
plattformubergreifenden Dienstzugang, die sich <strong>in</strong>zwei grobe Heterogenitatskategorien<br />
e<strong>in</strong>ordnen lassen:<br />
1. Technische Heterogenitat<br />
2. Adm<strong>in</strong>istrative Heterogenitat<br />
Beide Arten werden im folgenden zusammenfassendauch als organisationelle Heterogenitat<br />
bezeichnet, da sichtechnische und adm<strong>in</strong>istrative Unterschiede zumeist<br />
als Konsequenz der unterschiedlichen Anforderungen der am Dienstmarkt<br />
beteiligten Organisationen, beispielsweise Dienstleistungsunternehmen, ergeben.<br />
Die <strong>in</strong> der Abbildung 3.2 grauschattierten Komponenten (Trader, Typmanager<br />
und Interzeptor) deuten bereits auf konkrete, <strong>in</strong> dieser Arbeit entwickelte<br />
Losungsansatze h<strong>in</strong>, mit denen e<strong>in</strong> weitgehend une<strong>in</strong>geschrankter Dienstzugang<br />
<strong>in</strong> o enen heterogenen <strong>verteilten</strong> Dienstemarkten erreicht werden kann.<br />
Technische Heterogenitat Wie oben bereits angedeutet wurde, ist aufgrund<br />
der Autonomie der beteiligten Organisationen davon auszugehen, da bei der<br />
Realisierung o ener verteilter Dienstemarkte verschiedenartige verteilte Systemplattformen<br />
zum E<strong>in</strong>satz kommen. Welche verteilte Systemplattform dabei <strong>in</strong>nerhalb<br />
e<strong>in</strong>er Verwaltungsdomane generell genutzt wird, hangt ma geblich von<br />
den dort verfolgten Zielen ab, die beispielsweise e<strong>in</strong>e bestimmte Plattform fur<br />
die spezi schen Belange der jeweiligen Verwaltungsdomaneamgeeignetesten ersche<strong>in</strong>en<br />
lassen.<br />
E<strong>in</strong>e direkte Folgerung aus der Existenz unterschiedlicher verteilter Systemplattformen<br />
ist e<strong>in</strong>e technische Heterogenitat, die sichprimar durch die von den Plattformen<br />
angebotenen unterschiedlichen Dienstaufrufmechanismen ergibt. Im allgeme<strong>in</strong>en<br />
s<strong>in</strong>d derartige Kommunikationsmechanismen, wie beispielsweise die<br />
RPC{Mechanismen von ANSA, CORBA oder DCE, nicht zue<strong>in</strong>ander kompatibel,<br />
so da e<strong>in</strong>e gegenseitige <strong>Dienstnutzung</strong> ohne weiteres plattformubergreifend<br />
nicht moglich ist. Ebenso zeigen sich Unterschiede h<strong>in</strong>sichtlich der Ausfuhrungssemantik<br />
von Operationsaufrufen, die sich <strong>in</strong>e<strong>in</strong>em unterschiedlichen Verhalten<br />
beim Operationsaufruf auswirken konnen. Beispielsweise konnen Operationsaufrufe<br />
nur e<strong>in</strong>mal (engl. at{most{once semantics [CDK94]) oder bei Fehlschlagen<br />
auch mehrfach wiederholt werden. Weitere technische Problemstellungen ergeben<br />
sich auch aufgrund unterschiedlicher Adressierungsverfahren, mit denen<br />
Diensterbr<strong>in</strong>ger angesprochen werden konnen.<br />
Zur Uberw<strong>in</strong>dungtechnischer Heterogenitatsgrenzen mussen zusatzlicheSystemtechniken<br />
angeboten werden, die e<strong>in</strong>e Abbildung der verschiedenartigen technischen<br />
Aspekte der <strong>verteilten</strong> Systemplattformen untere<strong>in</strong>ander erlauben. Hierdurch<br />
wird es moglich, e<strong>in</strong>e domanenubergreifende <strong>Dienstnutzung</strong> zu realisieren<br />
und somit e<strong>in</strong>e technische Interoperabilitat zu gewahrleisten.<br />
Adm<strong>in</strong>istrative Heterogenitat Zusatzlich zu den technischen Heterogenitatsgrenzen<br />
s<strong>in</strong>d au erdem adm<strong>in</strong>istrative Heterogenitatsprobleme zuberuck-
3.1 Grundlegende Problemstellungen 49<br />
sichtigen, die <strong>in</strong> engem Zusammenhang mit den im vorherigen Kapitel beschriebenen<br />
Interoperabilitatsaspekten bei der Beschreibung von Diensten stehen. Die<br />
Gewahrleistung der Interoperabilitat von Dienstnehmern und Diensterbr<strong>in</strong>ger <strong>in</strong><br />
o enen <strong>verteilten</strong> Dienstemarkten ist e<strong>in</strong>e der Hauptaufgabenstellungen der Verarbeitungsebene.<br />
Vollstandige Interoperabilitat la t sich hierbei nur durch Standardisierung<br />
von Diensttypen erreichen, so da sowohl deren Syntax als auch<br />
Semantik auf e<strong>in</strong>deutige Art und Weise von vornhere<strong>in</strong> festgelegt ist. Aufgrund<br />
der Dynamik o ener verteilter Dienstemarkte mit standig neu h<strong>in</strong>zukommenden<br />
und sich andernden Diensttypen ist e<strong>in</strong>e derartige globale Standardisierung jedoch<br />
nur zum Teil fur bestimmte grundlegende Systemdienste oder bestimmte<br />
Anwendungsbereiche s<strong>in</strong>nvoll durchfuhrbar. Generell ist deshalb davon auszugehen,<br />
da vor der Nutzung von Diensten anderer Verwaltungsdomanen e<strong>in</strong>e<br />
Uberprufung erforderlich ist, mit der die Ubere<strong>in</strong>stimmung des vom Dienstnehmer<br />
gewunschten und des von Diensterbr<strong>in</strong>gerseite angebotenen Diensttyps<br />
durchgefuhrt wird. Als Grundlage hierfur dienen die Dienstbeschreibungen, die<br />
mit den jeweiligen Beschreibungsmitteln der Realisierungsplattformen formuliert<br />
s<strong>in</strong>d. Bei der Uberprufung mussen gegebenfalls die unterschiedlichen Dienstbeschreibungen<br />
aufe<strong>in</strong>ander abgebildet werden. Aufgrund der <strong>in</strong> Abschnitt 2.4.5<br />
beschriebenen E<strong>in</strong>schrankungen der Ausdrucksmachtigkeit von Dienstbeschreibungen<br />
mussen sichautomatisierteVerfahren jedochauf die Untersuchung struktureller<br />
Eigenschaften, <strong>in</strong>sbesondere der Schnittstellensignaturen, beschranken,<br />
da die semantische Ubere<strong>in</strong>stimmung von Diensten mit den heute verfugbaren<br />
Methoden nicht uberpruft werden kann.<br />
3.1.2 Dienstzugangsphasen<br />
Bevor im folgenden die <strong>in</strong> der Abbildung 3.2 bereits angedeuteten Systemtechniken<br />
zur Uberw<strong>in</strong>dung der technischen und adm<strong>in</strong>istrativen Heterogenitat genauer<br />
vorgestelltwerden, ist die Unterscheidungverschiedener Dienstzugangsphasen<br />
s<strong>in</strong>nvoll:<br />
1. Diensttyp ndung,<br />
2. Dienstauswahl und<br />
3. Dienstzugri .<br />
Diese Aufteilung ermoglicht es, den verschiedenen Phasen jeweils bestimmte<br />
Ansatze zuzuordnen, die e<strong>in</strong>e adaquate Losung der dortigen spezi schen Anforderungen<br />
versprechen.<br />
3.1.2.1 Au nden von Diensttypen<br />
Voraussetzung fur jegliche Art von <strong>Dienstnutzung</strong> ist das Vorhandense<strong>in</strong> e<strong>in</strong>er<br />
Vorstellung uber die Art des Dienstes, der <strong>in</strong> e<strong>in</strong>em bestimmten Anwendungskontext<br />
verwendet werden soll. Wie konkret diese Vorstellung ausgepragt ist,
50 Zugang zu Diensten <strong>in</strong> heterogenen Umgebungen<br />
d.h. ob bereits e<strong>in</strong> bestimmter Diensttyp gefordert oder e<strong>in</strong> passender Diensttyp<br />
erst gefunden werden mu , hangt von der jeweiligen Anwendungssituation ab.<br />
E<strong>in</strong> <strong>in</strong>sbesondere fur die vorliegende Arbeit<strong>in</strong>teressanter Anwendungsbereichist<br />
der Entwurf und die Entwicklung verteilter Anwendungen, auf den <strong>in</strong> Kapitel<br />
4noch genauer e<strong>in</strong>gegangen wird. Initialer Schritt der Entwicklung verteilter<br />
Anwendungen ist die Modularisierung der geplanten Anwendung <strong>in</strong>verschiedene<br />
Problembereiche. Ziel dieser elementaren software{technischen Methodik [Par72]<br />
ist, die vorhandene Komplexitat des Gesamtsystems derartig zu reduzieren, da<br />
e<strong>in</strong>e dedizierte Behandlung von Teilproblemen moglich ist.Fur diese Teilprobleme<br />
konnen modulare Losungsansatze entworfen und entwickelt werden, die anschlie<br />
end derartig mite<strong>in</strong>ander komb<strong>in</strong>iert werden, da sie <strong>in</strong> Kooperation das<br />
anwendungsspezi sche Gesamtproblem behandeln. Diese spezielle Sichtweise, die<br />
von e<strong>in</strong>igen Autoren auchalskomponentenbasiert bezeichnet wird [ND95, Ber95],<br />
ndet sich auch <strong>in</strong>dem <strong>in</strong> dieser Arbeit gewahlten Ansatz der Dienstmodellierung.<br />
Die im vorherigen Kapitel vorgestellte objektbasierte Modellierung bietet<br />
hierfur bereits diewesentlichen Voraussetzungen, um e<strong>in</strong>emodul{ bzw. komponentenbasierte<br />
Entwicklung verteilter Anwendungen durchfuhren zu konnen. So<br />
konnen Dienste bzw. Diensttypen auch als Module oder Komponenten verstanden<br />
werden, die zu neuen <strong>verteilten</strong> Anwendungen komb<strong>in</strong>iert werden konnen.<br />
Dabei bestimmtder jeweilige Diensttyp bzw. die Dienstbeschreibung die Art und<br />
Weise, wie e<strong>in</strong> Dienst dieses Diensttyps genutzt werden kann. E<strong>in</strong> Hauptziel der<br />
Entwicklung verteilter Anwendungen ist es, moglichst die <strong>in</strong> o enen <strong>verteilten</strong><br />
Dienstemarkten vorhandenen Diensttypen wiederzuverwenden, die bereits wesentliche<br />
zur Realisierung der Gesamtanwendung nutzbare Teillosungsansatze<br />
zur Verfugung stellen. Durch diesen dienstorientierten Ansatz kann e<strong>in</strong>e hohe<br />
E zienz bei der Softwareentwicklung erreicht werden. Idealvorstellung ist, die<br />
Entwicklung und Realisierung von <strong>verteilten</strong> Anwendungen ausschlie lich unter<br />
Nutzung extern angebotener Dienste durchzufuhren (siehe Abschnitt 4.1.1). Als<br />
Konsequenz hieraus ergibt sich, da nicht mehr primar der Entwurf und die<br />
Entwicklung neuer, anwendungsspezi scher Dienste imVordergrund der Anwendungsentwicklung<br />
steht, sondern <strong>in</strong> zunehmenden Ma e die Koord<strong>in</strong>ation bestehender,<br />
unter Umstanden standardisierter Anwendungsdienste <strong>in</strong>den Kern der<br />
Betrachtungen ruckt.<br />
E<strong>in</strong> derartig dienstorientiertes Vorgehen erfordert die Unterstutzung durch systemtechnischeMechanismen,<br />
sogenannte Diensttypmanager,die<strong>in</strong>Abschnitt 3.2<br />
vorgestellt werden. Ihre Funktion umfa t unter anderem auch die Unterstutzung<br />
des Anwendungsentwicklers beim Au nden und der Auswahl der fur se<strong>in</strong> Anwendungsproblem<br />
am besten geeigneten Diensttypen. Zur Abgrenzung zur anschlie<br />
enden Phase der Dienstauswahl bzw. Dienstvermittlung (engl. trad<strong>in</strong>g), <strong>in</strong><br />
der konkrete diensttypkonforme Diensterbr<strong>in</strong>ger ermittelt werden, wird die Phase<br />
der Diensttyp ndung deshalb auch als sogenanntes Meta{Trad<strong>in</strong>g [PB96] oder<br />
Service Mediation [MML94a] bezeichnet. Kennzeichnend fur diese Phase ist vor<br />
allem die <strong>in</strong>teraktive Form der Dienstsuche, die <strong>in</strong> diesem Zusammenhang auch<br />
oft als " Blattern\ (engl. brows<strong>in</strong>g) bezeichnet wird.
3.1 Grundlegende Problemstellungen 51<br />
3.1.2.2 Dienstauswahl<br />
Nachdem e<strong>in</strong> geeigneter Diensttyp wahrend der Entwicklungssphase e<strong>in</strong>er <strong>verteilten</strong><br />
Anwendung gefunden wurde, stellt sich die Frage nach Diensterbr<strong>in</strong>gern,<br />
die e<strong>in</strong>en entsprechenden Dienst zum Ausfuhrungszeitpunkt e<strong>in</strong>er <strong>verteilten</strong> Anwendung<br />
anbieten. Durch die Moglichkeiten der Konformitat von Diensttypen<br />
konnen auch die Dienste mitberucksichtigt werden, die e<strong>in</strong>em zum angegebenen<br />
Diensttyp konformen Diensttyp besitzen. Da <strong>in</strong> o enen <strong>verteilten</strong> Dienstemarkten<br />
unter Umstanden e<strong>in</strong>e gro e Anzahl moglicher diensttypkonformer Diensterbr<strong>in</strong>ger<br />
existieren kann, reicht der Diensttyp als alle<strong>in</strong>iges Suchkriterium im<br />
allgeme<strong>in</strong>en nicht aus, um e<strong>in</strong>eangemessene Dienstauswahl tre en zu konnen.<br />
Erganzende Suchkriterien s<strong>in</strong>d hierbei beispielsweise die statischen Dienstattribute,<br />
deren Spezi kation Bestandteil des Diensttypkonzeptes ist. Mit ihnen lassen<br />
sich die Diensterbr<strong>in</strong>ger nach ihren jeweiligen Eigenschaften unterscheiden,<br />
beispielsweise <strong>in</strong> den Kosten pro Seite bei Druckdiensterbr<strong>in</strong>gern, so da die<br />
Dienstauswahl durchAngabe gewunschter Dienstattributwertedurchden Dienstnehmer<br />
naher e<strong>in</strong>gegrenzt werden kann. Sie stellen jedochnur e<strong>in</strong>en ersten Schritt<br />
dar, um e<strong>in</strong>eAuswahl des " am besten geeigneten\ Diensterbr<strong>in</strong>gers tre en zu<br />
konnen. So wird beispielsweise nicht berucksichtigt, ob der Diensterbr<strong>in</strong>ger auch<br />
tatsachlich verfugbar ist oder die momentane Auslastung e<strong>in</strong>eAuswahl uberhaupt<br />
s<strong>in</strong>nvoll ersche<strong>in</strong>en la t. Weitere Probleme bei der Dienstauswahl ergeben<br />
sich auchaufgrundder moglichen Gro e verteilter Dienstemarkte, die zusatzliche<br />
Strukturierungsmoglichkeiten zur E<strong>in</strong>grenzungdes Suchraums erfordern. E<strong>in</strong>e <strong>in</strong>tegrierte<br />
Behandlung dieser Problemstellungen ndet <strong>in</strong> Abschnitt 3.3 statt, wo<br />
verschiedene Ansatze zur Dienstvermittlung <strong>in</strong> o enen <strong>verteilten</strong> Dienstemarkten<br />
ausfuhrlich dargestellt werden.<br />
3.1.2.3 Dienstzugri<br />
Nachdem der Dienstnehmer Kenntnis uber e<strong>in</strong>en geeigneten diensttypkonformen<br />
Diensterbr<strong>in</strong>ger erhalten hat, mu vor dem eigentlichen Aufruf e<strong>in</strong>er gewunschten<br />
Operation e<strong>in</strong>e B<strong>in</strong>dung zum Diensterbr<strong>in</strong>ger erfolgen, welche die kommunikationstechnischeVerknupfung<br />
zwischen ihnen aufbaut. Diese Art von B<strong>in</strong>dung wird<br />
<strong>in</strong> diesem Zusammenhangauch als spate B<strong>in</strong>dung bezeichnet, da sie erst zur Laufzeit<br />
hergestellt wird und nicht beim Entwurf der Anwendung bereitsvorgegeben<br />
ist. Bed<strong>in</strong>gt durch diespate B<strong>in</strong>dung ergeben sich jedoch unter Umstanden Probleme<br />
h<strong>in</strong>sichtlich der Interoperabilitat. So kann es beispielsweise durch Fehler<br />
beim Dienstauswahlproze vorkommen, da e<strong>in</strong>e B<strong>in</strong>dungzue<strong>in</strong>em Diensterbr<strong>in</strong>ger<br />
e<strong>in</strong>gegangen wird, der nicht diensttypkonform ist. Generell solltedeshalbauch<br />
hier e<strong>in</strong>e Uberprufung der Konformitat des vom Dienstnehmer gewunschten und<br />
des vom Diensterbr<strong>in</strong>ger realisierten Diensttyps durchgefuhrt werden, um die<br />
Typsicherheit der Interaktion zu gewahrleisten.<br />
In heutigen <strong>verteilten</strong> Systemplattformen ndet <strong>in</strong> den meisten Fallen nur e<strong>in</strong>e<br />
e<strong>in</strong>fache Uberprufung der Konformitat von Dienstnehmer und Diensterbr<strong>in</strong>ger<br />
zum B<strong>in</strong>dungszeitpunkt statt. Zum Beispiel im Fall von DCE beschrankt<br />
sich die Uberprufung auf die e<strong>in</strong>fache Namensaquivalenz von Schnittstellentyp-
52 Zugang zu Diensten <strong>in</strong> heterogenen Umgebungen<br />
namen, die jedoch | wie bereits imvorherigen Kapitel verdeutlicht wurde |<br />
ke<strong>in</strong> h<strong>in</strong>reichendes Kriterium fur die Interoperabilitat von Dienstnehmer und<br />
Diensterbr<strong>in</strong>ger bieten, da wesentliche strukturelle Eigenschaften, beispielsweise<br />
die Signaturen der Operationen, nicht berucksichtigt werden.<br />
Nachdem alle obigen Vorbereitungsphasen abgeschlossen s<strong>in</strong>d, kann die eigentliche<br />
Nutzung der Dienstfunktionalitat an der operationalen Schnittstelle des<br />
Diensterbr<strong>in</strong>gers statt nden. Dabei sollten bei jedem Operationsaufruf die Werte<br />
fur die E<strong>in</strong>gabe{ und Ruckgabeparameter der entsprechenden Schnittstellenoperation<br />
uberpruft werden, ume<strong>in</strong>e Ubere<strong>in</strong>stimmungder Wertezum<strong>in</strong>der Dienstbeschreibung<br />
de nierten Typ zu gewahrleisten. Je nach Typde nition kann beispielsweise<br />
auch die Zugehorigkeit zu e<strong>in</strong>em bestimmten Wertebereich nachgepruft<br />
werden. Die Typ{ bzw. Wertuberprufung ist besonders dann <strong>in</strong>teressant,<br />
wenn der Operationsaufruf erst zur Laufzeit dynamisch erzeugt worden ist, wie<br />
es beispielsweise durch Nutzung des sogenannten Dynamic Invocation Interface<br />
(DII) von CORBA oder TRADE moglich ist. Hierbei eventuell auftretendeFehler<br />
konnen ohne weitere Prufungen zur Laufzeit zumeist nur schwer entdeckt<br />
werden und au ern sich zumeist <strong>in</strong> der fehlerhaften Ausfuhrung e<strong>in</strong>er Operation.<br />
Diese Aspekte gelten <strong>in</strong> e<strong>in</strong>geschranktem Ma e auch fur die RPC{basierten<br />
Ansatze, die durch Generierung sogenannter Stubs Typfehler zum<strong>in</strong>dest bei der<br />
Anwendungsentwicklung e<strong>in</strong>grenzen. Wie derartige Typuberprufungen bei beiden<br />
Varianten sowohl zum Zeitpunkt der B<strong>in</strong>dung als auch beim Operationsaufruf<br />
durchgefuhrt werden konnen, wird <strong>in</strong> Abschnitt 3.2.2.7 genauer betrachtet.<br />
Erfolgt der Dienstzugri dabei domanenubergreifend, so s<strong>in</strong>d zusatzlich auch die<br />
technischen und adm<strong>in</strong>istrativen Heterogenitatsaspekte bei der B<strong>in</strong>dungunddem<br />
Operationsaufruf zu berucksichtigen. Die hierfur notwendigen Unterstutzungsmechanismen,<br />
die durch sogenannte Interzeptoren erbracht werden, betrachtet<br />
Abschnitt 3.4.<br />
3.2 Diensttypmanagement<br />
Dienstbeschreibungen kommt e<strong>in</strong>e bedeutende Rolle bei der Kooperation von<br />
Dienstnehmern und Diensterbr<strong>in</strong>gern <strong>in</strong> <strong>verteilten</strong> Dienstemarkten zu. Sie bieten<br />
die notwendigen Voraussetzungen, auf deren Grundlage Interoperabilitat und<br />
somit auch Typsicherheit <strong>in</strong> den oben genannten Dienstzugangssphasen gewahrleistet<br />
werden kann. Auf dem H<strong>in</strong>tergrund dieser elementaren Bedeutung von<br />
Dienstbeschreibungen stellt sich die Frage nach geeigneten Systemtechniken,<br />
welche e<strong>in</strong>e adaquate Unterstutzung zur Verwaltung von Dienstbeschreibungen<br />
bereitstellen. Die Verwaltung umfa t dabei verschiedene Aufgabenstellungen,<br />
die von der strukturierten Speicherung von Dienstbeschreibungen, <strong>in</strong>sbesondere<br />
Diensttypbeschreibungen, bis h<strong>in</strong> zu Typvergleichen reichen, mit deren<br />
Hilfe beispielsweise wahrend der Phase der Dienstauswahl diensttypkonforme<br />
Diensterbr<strong>in</strong>ger gefunden werden konnen. In der Literatur wird diese Art von<br />
Verwaltung imRahmen verteilter Systeme im allgeme<strong>in</strong>en als Typmanagement<br />
[ODP95c, IBR93] bezeichnet. In Anwendung auf die <strong>in</strong> dieser Arbeit speziell betrachteten<br />
Diensttypen wird im folgenden auch alternativ der Begri des Dienst-
3.2 Diensttypmanagement 53<br />
typmanagements verwendet (siehe auch [CM95]). Konkrete Systemkomponenten<br />
werden entsprechend als sogenannte Typmanager [CM95, IBR93] oder Typrepositories<br />
[ODP95c, ISO95] genannt.<br />
In der aktuellen Forschung ist die Thematik des Typmanagements<strong>in</strong>o enen <strong>verteilten</strong><br />
Systemen zumeist eng mit der Betrachtung von Dienstvermittlungskomponenten,<br />
den Tradern, verknupft, die als wichtige Klienten e<strong>in</strong>es Typmanagers<br />
gesehen werden und e<strong>in</strong>en wesentlichen E<strong>in</strong> u auf die Entwicklung von Typmanagementkomponenten<br />
ausuben. Diese Bee<strong>in</strong> u ung zeigtsich <strong>in</strong>sbesondere<br />
<strong>in</strong> den <strong>in</strong> [IBR93] beschriebenen Ansatzen, <strong>in</strong> denen erste Vorschlage fur e<strong>in</strong>e<br />
mogliche Grundfunktionalitat e<strong>in</strong>er Typmanagementkomponente untersucht<br />
werden, wobei Typmanagement vor allem unter dem Gesichtspunkt der Unterstutzung<br />
des ODP{Traders [ODP95a] untersucht wird. Die Ergebnisse der<br />
dort durchgefuhrten Untersuchungen lassen sich jedoch auchunabhangig von der<br />
spezi schen Betrachtung von Dienstvermittlungskomponenten zur Entwicklung<br />
weitgehend generischer Typverwaltungsmechanismen fur verteilte Dienstemarkte<br />
verwenden. Weitere Beispiele fur diese enge Betrachtung von Trad<strong>in</strong>g und<br />
Typmanagement s<strong>in</strong>dunter anderem <strong>in</strong> [BR92b] und [PB96] zu nden. Auch<br />
<strong>in</strong> der <strong>in</strong>ternationalen Standardisierung imRahmen des ODP{Referenzmodells<br />
wird Typmanagement zur Zeit noch primar im Zusammenhang mit der ODP{<br />
Trad<strong>in</strong>g{Funktion [ODP95a] betrachtet. Erst vor kurzem s<strong>in</strong>d dort neuere Arbeiten<br />
begonnen worden, die Typmanagement als eigenstandiges Themengebiet<br />
behandeln [ISO94, ISO95].<br />
Im folgenden wird Typmanagement als e<strong>in</strong>e anwendungsunabhangige, generische<br />
Systemfunktion gesehen, die von zahlreichen <strong>in</strong> o enen <strong>verteilten</strong> Systemen<br />
vorhandenen Komponenten genutzt und zur Losung deren spezi schen Problemstellungen<br />
e<strong>in</strong>gesetzt werden kann (siehe Abbildung 3.3).<br />
Typmanager<br />
Trader Browser Interzeptor Typmanager ...<br />
Abbildung 3.3:Mogliche Klienten e<strong>in</strong>es Typmanagers<br />
So s<strong>in</strong>d neben den genannten Tradern auch graphische Suchwerkzeuge (Browser)<br />
potentielle Klienten e<strong>in</strong>es Typmanagements, die im Rahmen von Software{<br />
Entwicklungs{Frameworks bzw. CASE{Tools [Ber95] angeboten werden, um<br />
beispielsweise den Programmierer <strong>in</strong> der Phase der Diensttyp ndung zuunterstutzen.<br />
E<strong>in</strong> anderes Beispiel s<strong>in</strong>d die oben bereits genannten Interzeptoren,<br />
die die Funktionen des Typmanagements als e<strong>in</strong>e wesentliche Unterstutzungsfunktion<br />
zur Uberw<strong>in</strong>dung der Heterogenitat benotigen. Weitere wichtige Klienten<br />
von Typmanagern s<strong>in</strong>d auch andere Typmanager, die beispielsweise zur
54 Zugang zu Diensten <strong>in</strong> heterogenen Umgebungen<br />
Unterstutzung e<strong>in</strong>er domanenubergreifenden <strong>Dienstnutzung</strong> mite<strong>in</strong>ander <strong>in</strong>teragieren<br />
mussen.<br />
3.2.1 Typmanagement <strong>in</strong> heutigen <strong>verteilten</strong> Systemplattformen<br />
Die Entwicklung dedizierter Managementkomponenten zur Verwaltung von<br />
Dienstbeschreibungen <strong>in</strong> o enen <strong>verteilten</strong> Systemen be ndet sich gegenwartig<br />
erst <strong>in</strong> ihren Anfangen. So verfugen die heutigen <strong>verteilten</strong> Systemplattformen<br />
zumeist uber gar ke<strong>in</strong>e Systemkomponenten zur Unterstutzung von<br />
Typmanagement, beispielsweise DCE und ILU, oder nur uber e<strong>in</strong>fache Typverwaltungskonzepte,<br />
wie beispielsweise das Schnittstellenrepository <strong>in</strong> CORBA<br />
oder die namensbasierte Verwaltung von Diensttypen <strong>in</strong> ANSA. Beide werden<br />
im folgenden kurz beschrieben.<br />
3.2.1.1 Schnittstellenrepository <strong>in</strong> CORBA<br />
Das Schnittstellenrepository (engl. <strong>in</strong>terface repository) ist e<strong>in</strong> Basisdienst der<br />
Common Object Request Broker Architecture (CORBA) [OMG91]. Es bietet<br />
e<strong>in</strong>en Ablagedienst (engl. repository) fur Schnittstellentypbeschreibungen, die<br />
von den Anwendungsentwicklern mit Hilfe der CORBA{spezi schen Schnittstellenbescheibungssprache<br />
dargestellt werden. Die Ablage erfolgt dabei durch fest<br />
vorgegebene Strukturierungskriterien, die sich aus den syntaktischen Regeln der<br />
Erstellung von Schnittstellentypbeschreibungen ergeben. So werden hier unter<br />
anderem Module, Schnittstellen, Operationen, Attribute und Datentypen unterschieden.<br />
Hierbei bildet das Repository die oberste Strukturierungse<strong>in</strong>heit, <strong>in</strong><br />
der unter anderem Datentypen und Schnittstellen sowie Module de niert werden<br />
konnen. Die dort de nierten Module setzen sich selbst wiederum aus verschiedenen<br />
Typde nitionen zusammen. Unterste Ebenebilden die Schnittstellen, die<br />
auch die De nition von Operationen umfassen. Hierdurch bed<strong>in</strong>gt ergibt siche<strong>in</strong>e<br />
hierarchische Struktur, die die Sichtbarkeitsbereiche von Typde nitionen widerspiegelt.<br />
Abbildung 3.4 verdeutlicht die Beziehungen der Strukturierungse<strong>in</strong>heiten<br />
untere<strong>in</strong>ander. E<strong>in</strong>e E<strong>in</strong>schrankungdes Schnittstellenrepositories ist, da sich<br />
die <strong>in</strong> der CORBA{Spezi kation de nierte Zugri sschnittstelle ausschlie lich auf<br />
Funktionen zum Lesen der dort gespeicherten Typ<strong>in</strong>formationen beschrankt. Die<br />
Art undWeise, wie die Schnittstellenbeschreibungen im Repository abgelegt werden,<br />
wird den jeweiligen CORBA{Implementierungen uberlassen und wird nicht<br />
weiter spezi ziert. Pr<strong>in</strong>zipiell ergibt sich die E<strong>in</strong>ordnung e<strong>in</strong>er Typbeschreibung<br />
durch den explizit vom Programmierer gewahlten Typnamen, der die Zuordnung<br />
<strong>in</strong>e<strong>in</strong>en bestimmten durch Modul{ und Schnittstellende nitionen vorgegebenen<br />
Typsichtbarkeitsbereich bestimmt. So kennzeichnet beispielsweise der Name<br />
iwt module::trader <strong>in</strong>terface::ServicePropertyOfInterestType e<strong>in</strong>en<br />
Datentyp ServicePropertyOfInterestType <strong>in</strong>nerhalb des Schnittstellentyps<br />
trader <strong>in</strong>terface, der selbst <strong>in</strong>nerhalb des Moduls iwt module de niert ist.<br />
Der gesamte Name ist im Repository e<strong>in</strong>deutig, wobei es pr<strong>in</strong>zipiell moglich ist,<br />
Teile dieser Namen, beispielsweise trader <strong>in</strong>terface,auch<strong>in</strong>anderen Modulen
3.2 Diensttypmanagement 55<br />
Repository<br />
ModuleDef<br />
InterfaceDef<br />
OperationDef<br />
ExceptionDef ConstantDef<br />
InterfaceDef TypedefDef<br />
ConstantDef<br />
TypedefDef<br />
ExceptionDef ModuleDef<br />
TypedefDef<br />
ConstantDef<br />
ExceptionDef<br />
ParameterDef<br />
AttributeDef<br />
ExceptionDef<br />
Abbildung 3.4: Hierarchie von Typde nitionen im CORBA{Schnittstellenrepository<br />
wiederzuverwenden.<br />
E<strong>in</strong>e der moglichen Aufgaben des Schnittstellenrepositories ist unter anderem<br />
die Unterstutzung der dynamischen Dienstaufrufschnittstelle. Dieser als sogenannter<br />
Dynamic Invocation Interface (DII) bezeichnete Mechanismus erlaubt<br />
die Konstruktion von Operationsaufrufen zur Laufzeit, mit dem Anfragen (engl.<br />
requests) durch Zusammenfugen von Operationsnamen, Operationsparametern<br />
und Platzhaltern fur Ruckgabeparameter und Fehlermeldungen erzeugt und an<br />
den Diensterbr<strong>in</strong>ger uber den Object Request Broker (ORB) geschickt werden<br />
konnen. Hierbei kann dann der ORB die Lesefunktionen des Schnittstellenrepositories<br />
nutzen, um die notwendigen Schnittstellentyp<strong>in</strong>formationen zu erhalten,<br />
die fur e<strong>in</strong>e Uberprufung der Korrektheit des konstruierten Aufrufs notwendig<br />
s<strong>in</strong>d 2 . Die eigentliche Uberprufung erfolgt dann durch den ORB auf der Grundlage<br />
der entsprechenden zum Aufruf gehorigen Operationssignatur.<br />
Das CORBA{Schnittstellenrepository stellt e<strong>in</strong>en ersten Ansatz fur Diensttypmanagement<br />
<strong>in</strong><strong>verteilten</strong> Systemen dar, wobei sich die Aufgaben hauptsachlich<br />
auf die Speicherungsaspekte von Dienstbeschreibungen konzentrieren und ausschlie<br />
lich Funktionen zum Lesenund zumNavigieren angeboten werden.<br />
3.2.1.2 Typverwaltung <strong>in</strong> ANSA<br />
E<strong>in</strong> zum CORBA{Schnittstellenrepository ahnlicher Ansatz ndet sich <strong>in</strong> ANSA<br />
[Mar91]<strong>in</strong>Form e<strong>in</strong>er mit TrType bezeichneten Typmanagementschnittstelle, die<br />
als e<strong>in</strong>e von <strong>in</strong>sgesamt vier Schnittstellen von dem dortigen Trader angeboten<br />
wird. Diese Schnittstelle bietet hierbei unter anderem verschiedene Operationen<br />
zum E<strong>in</strong>fugen, Loschen und Au isten von namensbasierten Diensttypbeschreibungen.<br />
Die <strong>in</strong>terne Verwaltung der Diensttypnamen erfolgt dabei als direkter<br />
2 Die CORBA{Spezi kation [OMG91] legt den Gebrauch des Schnittstellenrepositories beim<br />
DII jedoch nicht zw<strong>in</strong>gend fest.
56 Zugang zu Diensten <strong>in</strong> heterogenen Umgebungen<br />
Diensttypname<br />
Diensttypname<br />
Diensttypname<br />
Diensttypname<br />
Diensttypname<br />
Abbildung 3.5: Namensbasierter Diensttypgraph <strong>in</strong> ANSA<br />
azyklischer Graph, den Diensttypgraph (Abbildung 3.5), der die hierarchische<br />
Subtypbeziehungen zwischen den Diensttypen widerspiegelt. Da deren Verwaltung<br />
ausschlie lich auf der Grundlage von Namen durchgefuhrt wird, mu beim<br />
E<strong>in</strong>fugen neuer Diensttypen die Menge aller Supertypen explizit angegeben werden.<br />
E<strong>in</strong>e grundsatzliche Problematik ist hierbei, da die Korrektheit der vom<br />
Programmierer spezi zierten E<strong>in</strong>ordnungaufgrundder E<strong>in</strong>schrankungen von Namen<br />
nicht uberpruft werden kann. So kann es unter Umstanden durch die Denition<br />
fehlerhafter Typbeziehungen auch zur Mehrfachverwendung von Namen<br />
kommen, sofern nicht vorab e<strong>in</strong>fache Uberprufungsmechanismen durchgefuhrt<br />
werden, die die E<strong>in</strong>deutigkeit der vom Programmierer vorgegebenen Namen sicherstellen.<br />
Ebenso wie bei CORBA basiert die Subtypbeziehung <strong>in</strong>ANSAauf<br />
dem Pr<strong>in</strong>zip der <strong>in</strong> Abschnitt 2.3.2 dargestellten Schnittstellentypkonformitat,<br />
wobei bei beiden sich die Konformitat auf das H<strong>in</strong>zufugen von neuen Operationen<br />
zu e<strong>in</strong>er bestehenden Schnittstelle beschrankt und vorhandene Operationssignaturen<br />
nicht nach den Ko{ bzw. Kontravarianzregeln verandert werden<br />
durfen.<br />
Anwendung ndet die TrType{Typmanagementschnittstelle hauptsachlich beim<br />
Suchen nach konformen Diensttypen, die mit Hilfe der Operation zum Au isten<br />
der Diensttyphierachie ermittelt werden konnen. Dabei erhalt der Suchende den<br />
gesamten Subtypbaum zuruck, der dann selbstandig ausgewertet werden mu .<br />
Wie beim CORBA{Schnittstellenrepository ubernimmtauch hier die Typmanagementfunktion<br />
hauptsachlich dieAufgabe der strukturierten Speicherung von<br />
Typ<strong>in</strong>formationen, die hier jedoch nur aus e<strong>in</strong>fachen Namen bestehen.<br />
3.2.2 Aufgaben des Diensttypmanagements<br />
Die obigen beiden Beispiele verdeutlichen die ersten Anforderungen an Typmanagement<br />
<strong>in</strong><strong>verteilten</strong> Systemen. So umfa t die Aufgabe des Typmanagements<br />
zum<strong>in</strong>dest die dort beschriebene, strukturierte Ablage von Dienstbeschreibungen<br />
bzw. Diensttypbeschreibungen. Hierdurch ist es dann moglich, strukturiert<br />
auf Typ<strong>in</strong>formationen von vorhandenen Dienstbeschreibungen zuzugreifen, wobei<br />
im obigen Fall nur CORBA den Zugri auf die Operationssignaturen der
3.2 Diensttypmanagement 57<br />
Schnittstellentypen erlaubt, wahrend h<strong>in</strong>gegen ANSA nur e<strong>in</strong>fache Namen von<br />
Diensttypen verwaltet. Ebenso sollten die Beziehungen zwischen Diensttypen<br />
verwaltet werden konnen, wobei im Fall von ANSA ausschlie lich Subtypbeziehungen<br />
berucksichtigt werden. Im CORBA{Schnittstellenrepository spiegeln<br />
sich die Subtypbeziehungen im allgeme<strong>in</strong>en nicht durch die hierarchische Struktur<br />
wider, da beispielsweise bei Schnittstellende nitionen auch auf De nitionen<br />
von Schnittstellen <strong>in</strong> anderen Modulen verwiesen werden kann.<br />
E<strong>in</strong>schrankungen beider Ansatze zeigen sichunter anderem beim E<strong>in</strong>fugen neuer<br />
Diensttypen bzw. Dienstbeschreibungen. Wahrend bei CORBA diese Funktionalitat<br />
zum gegenwartigen Zeitpunkt nicht spezi ziert ist, mu bei ANSA e<strong>in</strong>e<br />
explizite E<strong>in</strong>ordnung des neuen Diensttyps <strong>in</strong> den vorhandenen Diensttypgraphen<br />
vorgenommen werden, da bed<strong>in</strong>gt durch die ger<strong>in</strong>ge Ausdrucksmachtigkeit<br />
von Namen e<strong>in</strong> systemgesteuertes E<strong>in</strong>fugen nicht moglich ist. E<strong>in</strong>e weitere<br />
wesentliche E<strong>in</strong>schrankung beider Ansatze ist auch, da Heterogenitatsaspekte,<br />
die sich beispielsweise bei der Kooperation mit anderen Verwaltungsbereichen<br />
ergeben, nicht ausreichend berucksichtigt werden. Zwar wird durch die Lese{<br />
Schnittstelle des CORBA{Schnittstellenrepositories e<strong>in</strong> sogenanntes Conta<strong>in</strong>er{<br />
Objekt [OMG91] als Transferformat fur Schnittstellentypbeschreibungen de -<br />
niert, so existieren jedoch ke<strong>in</strong>e weiteren Mechanismen, die e<strong>in</strong>en Vergleich zweier<br />
derartiger Dienstreprasentationen (siehe Abschnitt 2.1) erlauben. Im Fall von<br />
ANSA ist der Austauschvon Typ<strong>in</strong>formationen im Pr<strong>in</strong>zip auch moglich, so s<strong>in</strong>d<br />
diese jedoch aufgrund der ger<strong>in</strong>gen Ausdrucksmachtigkeit von Namen nur e<strong>in</strong>geschrankt<br />
nutzbar.<br />
Auf dem H<strong>in</strong>tergrundder e<strong>in</strong>fachen Typverwaltungsmechanismen von ANSA und<br />
CORBA sollen im folgenden grundlegende Aufgaben des Typmanagements <strong>in</strong><br />
o enen <strong>verteilten</strong> Dienstemarkten herausgearbeitet werden, wobei <strong>in</strong>sbesondere<br />
die Verwaltung von Diensttypen im Vordergrund der Betrachtung steht.<br />
3.2.2.1 Anforderungen an Dienstbeschreibungen<br />
Die von e<strong>in</strong>em Typmanager verwaltbaren Dienstbeschreibungen sollten zum<strong>in</strong>dest<br />
die Beschreibung der Schnittstellentypen mit ihren Operationssignaturen<br />
umfassen, die die grundlegenden Informationen fur e<strong>in</strong>etypsichere <strong>Dienstnutzung</strong><br />
darstellen. Zusatzlich zu diesen strukturellen Aspekten ist auch die Semantik e<strong>in</strong>es<br />
Dienstes genauer zu beschreiben, die Aufschlu uber die Art der erbrachten<br />
Dienstleistung gibt. Welche Beschreibungsmittel konkret gewahlt werden, hangt<br />
unter anderem davon ab, fur welche Zwecke die <strong>in</strong> der Dienstbeschreibung vorhandenen<br />
Informationen verwendet werden sollen.<br />
Wie bereits <strong>in</strong>der Bewertung verschiedener Ansatze von Dienstbeschreibungen<br />
im vorherigen Kapitel deutlich wurde, ist e<strong>in</strong> wichtiger Aspekt der der Automatisierbarkeit<br />
von Typuberprufungen und Typvergleichen. Automatisierbarkeit ist<br />
<strong>in</strong>sbesondere fur diejenigen <strong>verteilten</strong> Anwendungen von Wichtigkeit, bei denen<br />
die Interaktionen zwischen den Dienstnehmern und den Diensterbr<strong>in</strong>gern hochgradig<br />
autonom ablaufen, ohne da E<strong>in</strong>gri e e<strong>in</strong>es Benutzers, beispielsweise bei<br />
der Dienstauswahl, erforderlich s<strong>in</strong>d. Hierbei mussen unter anderem Typverglei-
58 Zugang zu Diensten <strong>in</strong> heterogenen Umgebungen<br />
[Diensttypname]<br />
Diensttypbeschreibung<br />
[Schnittstellentypname]<br />
Operationsname Parametertyp Parametertyp<br />
Operationsname Parametertyp Parametertyp<br />
... ... ...<br />
( + Beschreibung der Semantik jeder Operation)<br />
( + Beschreibung der Semantik der Schnittstelle)<br />
Attributname Attributtyp<br />
Attributname Attributtyp<br />
... ...<br />
...<br />
...<br />
...<br />
Abbildung 3.6: Bestandteile e<strong>in</strong>er Diensttypbeschreibung<br />
che und {uberprufungen <strong>in</strong> den Phasen der Dienstauswahl, der B<strong>in</strong>dung und des<br />
Operationsaufrufs automatisch durch die Infrastruktur vorgenommen werden,<br />
um die Interoperabilitat bzw. Typsicherheit von Dienstnehmer und Diensterbr<strong>in</strong>ger<br />
gewahrleisten zu konnen. In diesen Phasen s<strong>in</strong>d beispielsweise verhaltensbeschreibende<br />
Dienstbeschreibungsformen, wie <strong>in</strong> Abschnitt 2.4.4 gezeigt wurde,<br />
nicht oder nur sehr e<strong>in</strong>geschrankt fur derartig autonom ablaufende Systemmechanismen<br />
zu verwenden.<br />
E<strong>in</strong>en geeigneten Losungsansatz zur Erfullung der Anforderung nach Automatisierbarkeit<br />
bieten zum gegenwartigen Zeitpunkt die Dienstattribute, mit denen<br />
die charakteristischen Eigenschaften von Diensten auf e<strong>in</strong>fache Art undWeise beschrieben<br />
werden konnen. Sie stellen e<strong>in</strong>en geeigneten Kompromi zwischen der<br />
automatisierten Uberprufung und Vergleichbarkeit auf der e<strong>in</strong>en und der e<strong>in</strong>geschrankten<br />
Ausdrucksmachtigkeit auf der anderen Seite dar. Dieser Ansatz wird<br />
deshalb auch <strong>in</strong>der vorliegenden Arbeit verfolgt. Im folgenden werden Dienstbeschreibungen<br />
aus diesem GrundauchalsDiensttypbeschreibungen bezeichnet, um<br />
explizit auf den Diensttypbegri Bezug zu nehmen, der <strong>in</strong> Abschnitt 2.3.1 de -<br />
niert ist. E<strong>in</strong>e Diensttypbeschreibung besteht somit aus der Spezi kation der operationalen<br />
Schnittstelle und der Dienstattribute. Sie kann erganzt werden durch<br />
zusatzliche semantische Beschreibungen, beispielsweise <strong>in</strong>formelle textuelle Anmerkungen<br />
oder formale Verhaltenbeschreibungen <strong>in</strong> Form von Protokollspezi -<br />
kationen, die jedoch bei automatischen Typvergleichen und Typuberprufungen<br />
nicht weiter verwendet werden. Die Bestandteile e<strong>in</strong>er Diensttypbeschreibung<br />
s<strong>in</strong>d <strong>in</strong>Abbildung 3.6 zusammenfassend dargestellt.<br />
3.2.2.2 Arten von Typbeziehungen<br />
Aus Grunden der Flexibilitat und Erweiterbarkeit sollte e<strong>in</strong> Typmanager die Verwaltung<br />
beliebiger Arten von Beziehungen (engl. relations) erlauben. Hierdurch
3.2 Diensttypmanagement 59<br />
lassen sich fur verschiedene Anwendungsbereiche jeweils spezielle Beziehungen<br />
de nieren, die den dortigen Anforderungen am besten gerecht werden. Zum Beispiel<br />
ist es bei der Software{Entwicklung oftmals s<strong>in</strong>nvoll, die Zusammengehorigkeit<br />
verschiedener Diensttypen auszudrucken, die bezuglich ihrer Dienstsemantik<br />
an sich nicht <strong>in</strong>Beziehung stehen. E<strong>in</strong>e solche Beziehung konnte beispielsweise<br />
lauten: " Die DiensttypenAund Bstehen <strong>in</strong> Beziehung, da sie im selben<br />
Software{Projekt verwendet werden\. In diesem Zusammenhangware auch e<strong>in</strong>e<br />
Beziehung s<strong>in</strong>nvoll, die Versionsbeziehungen zwischen verschiedenen Diensttypen<br />
ausdruckt, um deren Weiterentwicklung beim Software{Entwicklungsproze zu<br />
dokumentieren. Dabei mussen die Diensttypen nicht unbed<strong>in</strong>gt <strong>in</strong> e<strong>in</strong>er Konformitatsbeziehung<br />
stehen.<br />
Auch sollten Beziehungen, die zum Zeitpunkt der Entwicklungdes Typmanagers<br />
noch nicht bekannt waren, nachtraglich de niert werden konnen. Grundsatzlich<br />
sollte auch moglich se<strong>in</strong>, bereits vorhandene De nitionen von Beziehungen<br />
zu verandern, um beispielsweise die dort beschriebenen Anforderungen zu<br />
verscharfen, die festlegen, ob zwei Typen <strong>in</strong> Beziehung stehen oder nicht.<br />
Generell lassen sich zwei Arten von Beziehungen unterscheiden:<br />
1. Durch Instanzen de nierte Beziehungen:<br />
E<strong>in</strong> Beispiel hierfur ist die obige Beziehung bei der Software{Entwicklung.<br />
Sie kennzeichnet e<strong>in</strong>e " semantische\ Beziehung zwischen Diensttypen, fur<br />
die im allgeme<strong>in</strong>en ke<strong>in</strong>e expliziten Regeln angegeben werden konnen, die<br />
systemseitig fur e<strong>in</strong> automatisches E<strong>in</strong>fugen neuer Diensttypen genutzt<br />
werden konnen. Dadurch ist es erforderlich, neue Diensttypen durch adm<strong>in</strong>istrative<br />
Tatigkeiten mit vorhandenen Diensttypen explizit <strong>in</strong> Beziehung<br />
zu setzen.<br />
E<strong>in</strong> anderes Beispiel fur durch Instanzen de nierteBeziehungen ist auch die<br />
oben dargestellte Subtypbeziehung <strong>in</strong> ANSA, die ebenfalls explizit durch<br />
adm<strong>in</strong>istrative Tatigkeiten verwaltet werden mu . Obwohl pr<strong>in</strong>zipiell automatische<br />
Verfahren fur die dort verwendete Beziehung existieren (siehe<br />
beispielsweise die <strong>in</strong> [NS95] oder [AC91] beschriebenen Algorithmen), ist<br />
dieses <strong>in</strong> ANSA nicht moglich, da dort ausschlie lich Diensttypnamen fur<br />
die Beschreibung von Diensttypen verwendet werden.<br />
2. Durch De nitionsregeln de nierte Beziehungen<br />
Sie ermoglichen im Gegensatz zu den durch Instanzen de nierten Beziehungen<br />
e<strong>in</strong>e automatische, systemgesteuerte Vergleichbarkeit von Diensttypen.<br />
Hierfur s<strong>in</strong>d <strong>in</strong>der Beziehungsbeschreibung entsprechende De nitionsregeln<br />
auzugeben, auf deren Grundlage der Typmanager automatisch<br />
Typbeschreibungen e<strong>in</strong>ordnen, vergleichen und uberprufen kann.<br />
E<strong>in</strong> Beispiel hierfur s<strong>in</strong>d die <strong>in</strong> der Konformitatsbeziehung de nierten Regeln,<br />
die <strong>in</strong> Abschnitt 2.3.2 <strong>in</strong>formell dargestellt wurden.<br />
Formalisierung von Beziehungen Beziehungen konnen formal durch Beziehungstypen<br />
beschrieben und somit <strong>in</strong> Analogie zu Diensten als Typen behandelt
60 Zugang zu Diensten <strong>in</strong> heterogenen Umgebungen<br />
werden. Dieser Ansatz ndet sich unter anderem im ISO General Relationship<br />
Model [ISO] und dem CORBA Object Relationship Service, der Bestandteil der<br />
Common Object Services Speci cations (COSS) [Gro94] ist. Im folgenden soll<br />
speziell e<strong>in</strong>e <strong>in</strong> Anlehnung an [BIBY95] gewahlte Darstellung von Beziehungstypen<br />
verwendet werden, die auf dem obigen Modell der ISO aufbaut und mit<br />
Hilfe der objektorientierten Spezi kationssprache Z [Spi89] de niert wird. E<strong>in</strong>en<br />
zusammenfassenden Uberblick uber Beziehungstypen zeigt Abbildung 3.7.<br />
Beziehungstyp<br />
Charakteristika<br />
Def<strong>in</strong>itionsregeln<br />
Rolle<br />
Name<br />
Typ<br />
...<br />
Rolle<br />
Kard<strong>in</strong>alität<br />
gefordert erlaubt<br />
Rolle<br />
Homogener b<strong>in</strong>ärer Beziehungstyp<br />
Charakteristika<br />
Def<strong>in</strong>itionsregeln<br />
Rolle 1<br />
DT-1<br />
Typ-A<br />
Rolle 2<br />
DT-2<br />
Typ-A<br />
Abbildung 3.7: Struktureller Aufbau von Beziehungstypen<br />
Beziehungen werden ebenso wie andere Typen als e<strong>in</strong>e bestimmte Typart (engl.<br />
type k<strong>in</strong>d) [Car89] verstanden.<br />
Type Defn<br />
k<strong>in</strong>d : TypeK<strong>in</strong>d<br />
TypeK<strong>in</strong>d ::= Datatype | Operation | Interface<br />
| Relationship | Service| ... (andere Typen)<br />
E<strong>in</strong> Beziehungstyp setzt sich aus e<strong>in</strong>em syntaktischen und e<strong>in</strong>em semantischen<br />
Teil zusammen. Die syntaktischen Aspekte von Beziehungen werden durch sogenannte<br />
Rollen ausgedruckt. Jede Rolle modelliert e<strong>in</strong>en Beteiligten e<strong>in</strong>er Beziehung<br />
und hat e<strong>in</strong>en Namen, e<strong>in</strong>en Rollentyp und e<strong>in</strong>e geforderte und erlaubte<br />
Kard<strong>in</strong>alitat. Die erforderte Kard<strong>in</strong>alitat legt die m<strong>in</strong>imale Anzahl anderer Teilnehmer<br />
der Beziehung fest,woh<strong>in</strong>gegen die erlaubte Kard<strong>in</strong>alitat die maximale<br />
Teilnehmeranzahl e<strong>in</strong>schrankt. Zusatzlich ist mit jeder Rolle e<strong>in</strong>e semantische<br />
Beschreibung verknupft, die hier jedoch nicht dargestellt ist.
3.2 Diensttypmanagement 61<br />
RoleSignature<br />
rolename : Name<br />
roletype : TypeId<br />
required_card<strong>in</strong>ality : N<br />
permitted_card<strong>in</strong>ality : N<br />
(N = Menge der natürlichen Zahlen)<br />
Der semantische Teil e<strong>in</strong>es Beziehungstyps setzt sich aus zwei Teilaspekten zusammen.<br />
Er be<strong>in</strong>haltet zum e<strong>in</strong>en die Beschreibung der Charakteristika e<strong>in</strong>er<br />
Beziehung und zumzweiten die oben bereits genannten De nitionsregeln, mit<br />
deren Hilfe die Zugehorigkeit zu e<strong>in</strong>er Beziehung bestimmt werden kann. Charakteristika,diefur<br />
samtliche Beziehungstypen anwendbar s<strong>in</strong>d, umfassen unter<br />
anderem die Art und Weise, wie Rollen aus e<strong>in</strong>er Beziehung geloscht werden, ob<br />
beispielsweise andere Rollen ebenfalls geloscht oder freigegeben werden mussen.<br />
RelationshipSignature<br />
TypeDefn<br />
roles : F RoleSignature<br />
delete_all_<strong>in</strong>_roles : RoleSignature --> F RoleSignature<br />
release_all_<strong>in</strong>_roles : RoleSignature --> F RoleSignature<br />
only_if_none_<strong>in</strong>_roles : RoleSignature --> F RoleSignature<br />
k<strong>in</strong>d = Relationship<br />
#roles > 0<br />
dom delete_all_<strong>in</strong>_roles roles ran delete_all_<strong>in</strong>_roles roles<br />
dom release_all_<strong>in</strong>_roles roles ran release_all_<strong>in</strong>_roles roles<br />
dom only_if_none_<strong>in</strong>_roles roles ran only_if_none_<strong>in</strong>_roles roles<br />
E<strong>in</strong> Spezialfall s<strong>in</strong>d die nachfolgend gezeigten homogenen, b<strong>in</strong>aren Beziehungen.<br />
Sie s<strong>in</strong>d dadurch gekennzeichnet, da sie aus genau zwei Rollen mit demselben<br />
Rollentyp bestehen. Ihnen konnen zusatzliche Charakteristika zugeordnet<br />
werden, die beispielsweise Aussagen uber die Re exivitat, Antisymmetrie oder<br />
Transitivitat der Beziehung liefern. E<strong>in</strong> Beispiel e<strong>in</strong>er homogenen b<strong>in</strong>aren Beziehung<br />
ist die Konformitatsbeziehung, die jeweils Instanzen desselben Typs,<br />
beispielsweise Dienstattribut{ und Operationstypen, <strong>in</strong> Beziehung setzt. Neben<br />
den drei oben genannten Charakteristika ist e<strong>in</strong> weiteres Charakteristikumauch<br />
der H<strong>in</strong>weis darauf, da beim E<strong>in</strong>fugen e<strong>in</strong>es Diensttyps <strong>in</strong> e<strong>in</strong>e Konformitatsbeziehung<br />
die Zugehorigkeit automatisch uberpruft werden kann (typematch<strong>in</strong>g<br />
: B). Die Uberprufung durch den Typmanager erfolgt dabei auf der Grundlage<br />
der mit der Beziehung assoziierten De nitionsregeln.
62 Zugang zu Diensten <strong>in</strong> heterogenen Umgebungen<br />
B<strong>in</strong>aryRelationshipSignature<br />
RelationshipSignature<br />
R : Reflexivity ::= Reflexive | Irreflexive | Antireflexive<br />
S : Symmetry ::= Symmetric | Asymmetric | Antisymmetric<br />
T : Transitivity ::= Transitive | Intransitive | Antitransitive<br />
type_match<strong>in</strong>g : B<br />
#roles = 2<br />
r1, r2 . roles<br />
r1 = r2 r1.roletype = r2.roletype<br />
Generell sollten beim E<strong>in</strong>fugen neuer Typen <strong>in</strong> e<strong>in</strong>e Beziehung die dort de -<br />
nierten Charakteristika uberpruft werden. Kann diese Uberprufung jedoch, im<br />
Gegensatz beispielsweise zur Konformitatsbeziehung, nicht automatisch durch<br />
den Typmanager ausgefuhrt werden, ist es s<strong>in</strong>nvoll, die Entscheidung dem Adm<strong>in</strong>istrator<br />
zu ubergeben, der dann aufgrund der De nitionsregeln selbst e<strong>in</strong>e<br />
Beurteilung abgeben und die Beziehung der neuen Instanz explizit angeben mu .<br />
E<strong>in</strong> Beispiel fur e<strong>in</strong>e derartige, durch Instanzen de nierte 3 Beziehung ist die <strong>in</strong><br />
Abschnitt 2.4.4.1 vorgestellte Interaktionskonformitat, die auf der Grundlage erweiterter<br />
endlicher Transitionssystem de niert ist. Automatische Vergleiche von<br />
Dienstbeschreibungen s<strong>in</strong>d dort nur bei relativ e<strong>in</strong>fachen Spezi kationen moglich,<br />
so da bei komplexen Transitionssystemen im allgeme<strong>in</strong>en e<strong>in</strong>e explizite adm<strong>in</strong>istrative<br />
Unterstutzung notwendig ist. Grundsatzlich sollten dem Benutzer geeignete<br />
Werkzeuge, beispielsweise Browser, angeboten werden, die ihn <strong>in</strong> se<strong>in</strong>en<br />
Entscheidungsprozessen e ektiv unterstutzen.<br />
Zusammenfassend ergibt sich, da die Automatisierbarkeit beim E<strong>in</strong>fugen neuer<br />
Dienstbeschreibungen zum e<strong>in</strong>en von dem Beziehungstyp und zumanderen<br />
von der Form der Dienstbeschreibung abhangt. Beziehungstyp und Dienstbeschreibung<br />
mussen dabei derartig aufe<strong>in</strong>ander abgestimmt se<strong>in</strong>, da die Dienstbeschreibungallewesentlichen<br />
Beschreibungselementebe<strong>in</strong>haltet, die fur die Anwendung<br />
der im Beziehungstyp beschriebenen De nitionsregeln notwendig s<strong>in</strong>d.<br />
In Anwendungauf die Konformitatsregeln bedeutet dies, da die Dienstbeschreibung<br />
zum<strong>in</strong>dest die <strong>in</strong> Abbildung 3.6 dargestellten strukturellen Informationen<br />
des Dienst{ und Schnittstellentyps umfassen mu . E<strong>in</strong>fache Namen, wie im Beispiel<br />
von ANSA, s<strong>in</strong>d hierfur nicht ausreichend.<br />
3 Auch durch Instanzen de nierte Beziehungen konnen wie <strong>in</strong> diesem Fall De nitionsregeln<br />
besitzen. Ausschlaggebend ist jedoch, ob diese fur e<strong>in</strong> vollstandig automatisches Uberprufungsverfahren<br />
geeignet s<strong>in</strong>d.
3.2 Diensttypmanagement 63<br />
3.2.2.3 Ablage von Beziehungen und Typen<br />
Durch die obige Betrachtungvon Dienst{ und Beziehungstypen wird e<strong>in</strong>e orthogonale<br />
Behandlung von Dienst{ und Beziehungsbeschreibungen im Typmanager<br />
moglich. Insofern ersche<strong>in</strong>t es s<strong>in</strong>nvoll, beide Typarten durch den Typmanager<br />
<strong>in</strong>tegriert verwalten zu lassen. Zu diesem Zweck wird deshalb <strong>in</strong> [BIBY95]<br />
e<strong>in</strong>e separate Speicherungskomponente, das sogenannte Typrepository oder Typbeschreibungsrepository,<br />
zur Ablage von Dienst{ und Beziehungstypen vorgeschlagen.<br />
Zusatzlichund hiervon getrenntwerden <strong>in</strong> e<strong>in</strong>er anderen Speicherungskomponente,<br />
dem Beziehungsrepository (engl. relationship repository), konkrete<br />
Instanzen von solchen Beziehungen zwischen Typen gespeichert. Abbildung 3.8<br />
verdeutlicht die Zusammenhange zwischen beiden Arten von Repositories.<br />
Typbezeichner1 Typbezeichner2<br />
Instanzbezeichner<br />
Typbeschreibung<br />
Beziehungstypbeschreibung<br />
Typbeschreibungs-Repository<br />
Rolle<br />
Beziehungs<strong>in</strong>stanz<br />
Beziehungs-Repository<br />
Abbildung 3.8:Verwaltung von Typen und Instanzen<br />
E<strong>in</strong>e Beziehungs<strong>in</strong>stanz verweist auf ihre eigene Typbeschreibung, die im Typbeschreibungsrepository<br />
verwaltet wird. Dies gilt auch fur alle an der Beziehung<br />
beteiligten Rollen, die ebenfalls auf ihre jeweiligen Typbeschreibungen verweisen.<br />
Typbeschreibungen konnen auchmehrfach referenziert werden, beispielsweise <strong>in</strong>nerhalb<br />
verschiedener Beziehungs<strong>in</strong>stanzen oder anderen Typbeschreibungen.<br />
3.2.2.4 Typbezeichner und Aliasnamen<br />
Jede Typbeschreibung imTypbeschreibungsrepository wird durch e<strong>in</strong>en Typbezeichner<br />
identi ziert, der <strong>in</strong>nerhalb des Typbeschreibungsrepositories e<strong>in</strong>deutig<br />
ist. In der Abbildung s<strong>in</strong>d diese Verweise durch Pfeile gekennzeichnet. Analog<br />
hierzu kennzeichnen entsprechende e<strong>in</strong>deutige Instanzbezeichner konkrete Beziehungs<strong>in</strong>stanzen<br />
im Beziehungsrepository.<br />
Um die E<strong>in</strong>deutigkeit von Typbezeichnern sicherzustellen ist deren automatische<br />
Generierung s<strong>in</strong>nvoll. E<strong>in</strong> Beispiel s<strong>in</strong>d die UUIDs (universial unique<br />
identi er) <strong>in</strong> DCE, die bei der Untersuchung namensbasierter Dienstbeschreibungen<br />
<strong>in</strong> Abschnitt 2.4.1 vorgestellt worden s<strong>in</strong>d. Sie dienen <strong>in</strong>nerhalb<br />
von DCE unter anderem zur e<strong>in</strong>deutigen Benennung von Schnittstellentypen.<br />
Sie werden durch e<strong>in</strong> spezielles Programmierwerkzeug uuid gen
64 Zugang zu Diensten <strong>in</strong> heterogenen Umgebungen<br />
[OSF93a] als textuelle Reprasentation erzeugt. E<strong>in</strong> Beispiel e<strong>in</strong>er UUID ist<br />
0081f128-a244-10b5-99d0-08005a921930.<br />
Um den Umgang mitderartigen, fur den Programmierer unhandlichen und " bedeutungslosen\<br />
Bezeichnern zu vere<strong>in</strong>fachen, ist zusatzlich dieVerwaltung von<br />
Aliasnamen s<strong>in</strong>nvoll, die auf die UUIDs abgebildet werden. Hierdurch wird es<br />
moglich, Typbezeichner exibel an bestimmteAnwendungsbereiche anzupassen,<br />
um den Verwendungszweck e<strong>in</strong>es Typs besser zu verdeutlichen. Ihre E<strong>in</strong>deutigkeit<br />
mu jedoch weiterh<strong>in</strong> sichergestellt werden.<br />
Generell kann das Konzept der Aliasnamen alternativ auch als e<strong>in</strong>e homogene,<br />
b<strong>in</strong>are, durch Instanzen de nierte Aquivalenzbeziehung angesehen werden, die jeweils<br />
zwei unterschiedlich benannte Typen explizit <strong>in</strong> Beziehung stellt. Sie wird<br />
<strong>in</strong> anderen Arbeiten deshalb auch als Renam<strong>in</strong>g [LW93] bezeichnet. Aquivalenzbeziehungen<br />
spielen <strong>in</strong>sbesondere zur Erhohung der Flexibilitat beim Vergleich<br />
von Typen e<strong>in</strong>e wichtige Rolle. Mit ihnen konnen beispielsweise Diensttypen verglichen<br />
werden, die sich nur <strong>in</strong> der Benennung der Operationen unterscheiden,<br />
ansonsten aber syntaktisch und semantisch konform zue<strong>in</strong>ander s<strong>in</strong>d.<br />
3.2.2.5 Typverwaltungsdomanen<br />
Bed<strong>in</strong>gt durch die gro e Anzahl von Typbezeichnern und Aliasnamen ist der Zugri<br />
auf die im Typmanager abgelegten Informationen fur den Programmierer im<br />
allgeme<strong>in</strong>en zu unubersichtlich. Aus diesem Grund ist die E<strong>in</strong>fuhrung lokaler Verwaltungsdomanen<br />
ahnlich der am Anfang dieses Kapitels e<strong>in</strong>gefuhrten s<strong>in</strong>nvoll,<br />
die e<strong>in</strong>e Strukturierung von Typ<strong>in</strong>formationen nach organisatorischen Gesichtspunkten<br />
erlauben. Beispielsweise konntee<strong>in</strong>e Domanesamtliche Diensttyp{ oder<br />
Beziehungstypbeschreibungen e<strong>in</strong>es bestimmten Software{Projektes umfassen,<br />
so da von den Projektteilnehmern e zient auf die Typbeschreibungen zugegriffen<br />
werden kann.<br />
E<strong>in</strong>emogliche Realisierung e<strong>in</strong>es derartigen Domanenkonzeptes s<strong>in</strong>d die oben genannten<br />
Module im CORBA{Schnittstellenrepository, die neben der Strukturierung<br />
gleichzeitig auch Typsichtbarkeitsbereichede nieren, mit denen die jeweilige<br />
Domanenachau en h<strong>in</strong> abgegrenzt wird. Inwieweit generell die Zugehorigkeit<br />
e<strong>in</strong>es Typbezeichners zu e<strong>in</strong>er bestimmten Domane auch deren Sichtbarkeit e<strong>in</strong>schranken<br />
sollte, hangt von den beabsichtigten Zielstellungen e<strong>in</strong>es Typmanagers<br />
ab. Alternativ zu dem <strong>in</strong>tegrierten Ansatz von CORBA ist pr<strong>in</strong>zipiell auch e<strong>in</strong>e<br />
vollstandige Trennung beider Aspekte<strong>in</strong>zwei separate Komponenten e<strong>in</strong>es Typmanagers<br />
denkbar. E<strong>in</strong>e Komponente konnte beispielsweise <strong>in</strong> Anlehnung an<br />
das CORBA{Schnittstellenrepository die Verwaltung der Typde nitionen und<br />
deren Verknupfungen untere<strong>in</strong>ander sowie der jeweiligen Sichtbarkeitsbereiche<br />
ubernehmen. Organisationelle Domanen werden dann <strong>in</strong> e<strong>in</strong>er anderen Systemkomponente<br />
verwaltet, mit der ubergreifend uber diese typverwaltungsspezi -<br />
schen E<strong>in</strong>schrankungen e<strong>in</strong>e separate Organisationsstruktur auf die im Typbeschreibungsrepository<br />
vorhandenen Typbeschreibungen de niert werden kann.<br />
Sie ermoglichen, da beispielsweise auch Typbeschreibungen, die <strong>in</strong> verschiedenen<br />
Sichtbarkeitsbereichen de niert s<strong>in</strong>d, geme<strong>in</strong>sam verwaltet werden konnen.
3.2 Diensttypmanagement 65<br />
Auf dem Domanenkonzept aufsetzend konnen des weiteren auch Sicherheitskonzepte<br />
entwickelt werden, mit denen der Zugri auf Typbeschreibungen fur bestimmte<br />
Nutzergruppen e<strong>in</strong>geschrankt werden kann.<br />
3.2.2.6 Diensttyphierarchien<br />
Im folgenden wird speziell auf die Verwaltung von Konformitatsbeziehungen e<strong>in</strong>gegangen,<br />
da ihnen <strong>in</strong>nerhalb o ener verteilter Dienstemarkte e<strong>in</strong>e wichtige Bedeutung<br />
sowohl fur die Gewahrleistungder Interoperabilitat zwischen Dienstnehmer<br />
und Diensterbr<strong>in</strong>ger als auch fur die Systemfortentwicklung und das Au nden<br />
von Diensterbr<strong>in</strong>gern zukommt.<br />
Grundlage fur die weitere Betrachtung ist die Modellierung der Konformitatsbeziehung<br />
als homogener b<strong>in</strong>arer Beziehungstyp. Die zwei beteiligten Rollen verweisen<br />
jeweils auf Diensttypbeschreibungen, wie sie <strong>in</strong> Abbildung 3.6 dargestellt<br />
s<strong>in</strong>d. Die mit dem Konformitatsbeziehungstyp assoziierten De nitionsregeln entsprechen<br />
den <strong>in</strong> Abschnitt 2.3.2 de nierten.<br />
Mit Hilfe der e<strong>in</strong>zelnen Instanzen derartiger Konformitatsbeziehungen, die jeweils<br />
zwei Diensttypen mite<strong>in</strong>ander <strong>in</strong> Beziehung stellen, lassen sich Diensttyphierarchien<br />
aufbauen. Als geeignete Realisierungsform erweisen sich gerichtete<br />
Graphen, die sich aus e<strong>in</strong>er Menge von Knoten und Kanten zusammensetzen.<br />
Knoten reprasentieren die Rollen e<strong>in</strong>er Beziehungs<strong>in</strong>stanz, wahrend die Kanten<br />
die Beziehung zwischen den Rollen verdeutlichen. Abbildung 3.9 zeigt das an<br />
[IBR93] angelehnte Beispiel e<strong>in</strong>er Hierarchie von Diensttypen, die jeweils verschiedene<br />
Dienste zumUmgang mit Dateien (engl. le service) beschreiben.<br />
Virtual Root<br />
Other (virtual) service types<br />
File transfer( NULL: Inttype,<br />
cost: <strong>in</strong>teger,<br />
access control: enum,<br />
transfer rate: range,<br />
transfer mode: enum)<br />
FTP(<strong>in</strong>ttype-1: Inttype,<br />
cost: <strong>in</strong>teger,<br />
access control: enum,<br />
transfer rate: range,<br />
transfer mode: enum)<br />
File service( NULL: Inttype,<br />
cost: <strong>in</strong>teger,<br />
access control: enum)<br />
File access( NULL: Inttype,<br />
cost: <strong>in</strong>teger,<br />
access control: enum,<br />
response time: range,<br />
access mode: enum)<br />
FTAM( <strong>in</strong>ttype-3: Inttype,<br />
cost: <strong>in</strong>teger,<br />
access control: enum,<br />
response time: range,<br />
access mode: enum)<br />
FTAM transfer( <strong>in</strong>ttype-2: Inttype,<br />
cost: <strong>in</strong>teger,<br />
access control: enum,<br />
transfer rate: range,<br />
transfer mode: enum)<br />
File management<br />
( NULL: Inttype,<br />
cost: <strong>in</strong>teger,<br />
access control: enum)<br />
NFS( <strong>in</strong>ttype-4: Inttype,<br />
cost: <strong>in</strong>teger,<br />
access control: enum,<br />
response time: range,<br />
access mode: enum)<br />
Abbildung 3.9: Beispiel e<strong>in</strong>er Diensttyphierarchie mit virtuellen Diensttypen
66 Zugang zu Diensten <strong>in</strong> heterogenen Umgebungen<br />
Die Knoten im Baum bezeichnen die verschiedenen Diensttypen, die durch entsprechende<br />
Pfeile zue<strong>in</strong>ander <strong>in</strong> Beziehung gestellt s<strong>in</strong>d. So s<strong>in</strong>d beispielsweise<br />
die Diensttypen NFS 4 und FTAM 5 File access konforme Diensttypen. E<strong>in</strong> besonderes<br />
Merkmal des Diensttyps File access ist dabei, da ke<strong>in</strong> Schnittstellentyp<br />
(NULL: Inttype)sondern nur e<strong>in</strong>e Menge von Dienstattributtypen de niert<br />
wird. Aus diesem Grund wird dieser Diensttyp auch als als sogenannter virtueller<br />
Diensttyp [IBR93] bezeichnet, da e<strong>in</strong>e Instanziierung des Diensttyps durch<br />
konkrete Diensterbr<strong>in</strong>ger nicht moglich ist.<br />
E<strong>in</strong> wesentlicher Vorteil von virtuellen Diensttypen ist die Strukturierung von<br />
Diensttyphierarchien. So konnen auch Diensttypen <strong>in</strong> Beziehung gestellt werden,<br />
die aufgrund unterschiedlicher Schnittstellentypen ansonsten mit Hilfe der Konformitatsregeln<br />
nicht vergleichbar waren. Erreicht wird dieses, <strong>in</strong>dem geme<strong>in</strong>same<br />
Diensteigenschaften bzw. Dienstattributtypen realer Diensttypen zu e<strong>in</strong>em<br />
virtuellen Diensttyp zusammengefa t werden, wie es beispielsweise bei NFS und<br />
FTAM gezeigt ist. Verschiedene virtuelle Diensttypen konnen auch wiederum <strong>in</strong><br />
Konformitatsbeziehungzue<strong>in</strong>em anderen geme<strong>in</strong>samen virtuellen Diensttyp stehen.<br />
Letztendlich fuhrt diese Hierarchiebildung zur De nition e<strong>in</strong>er virtuellen<br />
Wurzel (engl. virtual root), von der aus samtliche Diensttypde nitionen erreichbar<br />
s<strong>in</strong>d. Von dieser Wurzel aus kann e<strong>in</strong> Benutzer oder Programmierer bei der<br />
Diensttypsuche <strong>in</strong>verschiedene Zweige der Diensttyphierarchie absteigen, um<br />
die von ihm gesuchten Diensttypen zu nden. Dazu mu er sich bisauf die auf<br />
unterster Ebene be ndlichen Blatter des Hierarchiebaumes navigieren, um reale<br />
Diensttypen mit de nierten Schnittstellentypen zu erhalten. Die realen Diensttypen<br />
bilden wiederum dieWurzel fur weitere, <strong>in</strong> Konformitatsbeziehung stehende<br />
reale Diensttypen, wie <strong>in</strong> Abbildung 3.10 dargestellt ist.<br />
FTAM( <strong>in</strong>ttype-6: (read,write,extend),<br />
cost: <strong>in</strong>teger,<br />
access control: enum,<br />
response time: range,<br />
access mode: enum)<br />
FTAM( <strong>in</strong>ttype-3: (read,write),<br />
cost: <strong>in</strong>teger,<br />
access control: enum,<br />
response time: range,<br />
access mode: enum)<br />
FTAM( <strong>in</strong>ttype-7: (read,write,extend),<br />
cost: <strong>in</strong>teger,<br />
access control: enum,<br />
response time: range,<br />
access mode: enum,<br />
shared access: enum)<br />
FTAM( <strong>in</strong>ttype-5: (read,write),<br />
cost: <strong>in</strong>teger,<br />
access control: enum,<br />
response time: range,<br />
access mode: enum,<br />
shared access: enum)<br />
Abbildung 3.10: Konformitatsbeziehungen zwischen realen Diensttypen<br />
4 Das Network File System (NFS) von Sun iste<strong>in</strong>verteilter Dateidienst, der den Zugri auf<br />
Dateien uber Rechnergrenzen h<strong>in</strong>weg ermoglicht [Sun90, Cor91].<br />
5 Das File Transfer and Access Management (FTAM) ermoglicht ebenso wie NFS den Zugri<br />
auf entfernt verwaltete Dateien. FTAM ist als sogenanntes Application Service Element auf<br />
Schicht sieben des OSI{Referenzmodells [EF86] de niert.
3.2 Diensttypmanagement 67<br />
Die dort am Beispiel des Diensttyps FTAM gezeigten Konformitatsbeziehungen<br />
beruhen zum e<strong>in</strong>en auf der Erweiterung e<strong>in</strong>es Schnittstellentyps um e<strong>in</strong>e zusatzliche<br />
Operation extend und zumanderen auf dem H<strong>in</strong>zufugen neuer Dienstattributtypen,<br />
beispielsweise shared access.<br />
Speicherstrategien Im Zusammenhang mit der Verwaltung von Typhierarchien<br />
konnen zum e<strong>in</strong>en speichere ziente und zumanderen zugri se ziente<br />
Speicherstrategien unterschieden werden. Beide Varianten s<strong>in</strong>d <strong>in</strong>Abbildung 3.11<br />
zusammenfassend dargestellt.<br />
Beziehungs<strong>in</strong>stanz<br />
Diensttyp Diensttyp<br />
A A<br />
Diensttyp<br />
B<br />
Diensttyp Diensttyp<br />
C<br />
D<br />
Speichereffiziente Ablage<br />
Diensttyp Diensttyp<br />
Diensttyp<br />
C B<br />
D<br />
Diensttyp Diensttyp<br />
C D<br />
Zugriffseffiziente Ablage<br />
Abbildung 3.11: Strategien bei der Speicherung von Diensttyphierarchien<br />
Speichere ziente Strategien zeichnen sich dadurch aus, da mit Hilfe der <strong>in</strong> der<br />
Konformitatsbeziehungde nierten Charakteristika das Duplizieren von Informationen<br />
<strong>in</strong> der Diensttyphierarchie vermieden werden kann. Aufgrund der re exiven,<br />
antisymmetrischen und transitiven Charakteristika von Konformitatsbeziehungen<br />
konnen neu h<strong>in</strong>zugefugte Beziehungs<strong>in</strong>stanzen aus bereits vorhandenen<br />
erschlossen werden. Besteht beispielsweise zwischen den Diensttypen A und B<br />
sowie zwischen B und Ce<strong>in</strong>e Konformitatsbeziehung, ist das E<strong>in</strong>fugen e<strong>in</strong>er neuen<br />
Beziehungs<strong>in</strong>stanz zwischen A und C <strong>in</strong> den Diensttypgraphen wegen der<br />
Transitivitat der Beziehung uber ussig. Bezogen auf die Abbildung e<strong>in</strong>er derartigen<br />
Typhierarchie auf gerichtete Graphen bedeutet dies, da nur der den<br />
Graphen aufspannende Baum gespeichert wird. Samtliche, nicht explizit gespeicherten<br />
Beziehungs<strong>in</strong>stanzen mussen durch Berechnung der transitiven Hulle des<br />
Diensttypgraphens ermittelt werden. Dies wurde beispielsweise bei e<strong>in</strong>er Anfrage,<br />
ob die obigen Diensttypen A und C <strong>in</strong> Konformitatsbeziehungstehen, der Fall<br />
se<strong>in</strong>. Diese explizit durchgefuhrte Berechnung ist der wesentliche Unterschied<br />
zur zugri se zienten Speicherung, die gerade die oben vermiedene Redundanz<br />
von Beziehungs<strong>in</strong>stanzen explizit ausnutzt. Hierdurch kann beispielsweise beim<br />
Suchen nach konformen Diensttypen auf die unter Umstanden aufwendige Berechnung<br />
der transitiven Hulle verzichtet werden.
68 Zugang zu Diensten <strong>in</strong> heterogenen Umgebungen<br />
3.2.2.7 Typuberprufungen und {vergleiche<br />
Die im vorherigen Abschnitt beschriebenen Aspekte der strukturierten und persistenten<br />
Ablage von Typbeschreibungen und Beziehungs<strong>in</strong>stanzen bilden die<br />
Grundlage, auf derer Uberprufungen und Vergleiche von Typen und Beziehungen<br />
durchgefuhrt werden konnen. Sie s<strong>in</strong>d vor allem bei der B<strong>in</strong>dungsphase von<br />
Dienstnehmer und Diensterbr<strong>in</strong>ger und den anschlie enden Operationsaufrufen<br />
s<strong>in</strong>nvoll, um dieTypsicherheit der Interaktion zu gewahrleisten.<br />
Uberprufung von B<strong>in</strong>dungen In der B<strong>in</strong>dungsphase ist zu untersuchen,<br />
ob der vom Dienstnehmer angebotene Diensttyp mit dem vom Dienstnehmer<br />
gewunschten ubere<strong>in</strong>stimmt. Ist dies nicht der Fall, kann ke<strong>in</strong>e B<strong>in</strong>dung zum<br />
Diensterbr<strong>in</strong>ger e<strong>in</strong>gegangen werden. Um e<strong>in</strong>en Typvergleich durchfuhren zu<br />
konnen, mussen vom Typmanager Operationen angeboten werden, mit deren Hilfe<br />
zwei Diensttypbeschreibungen verglichen werden konnen. Dabei s<strong>in</strong>d sowohl<br />
die beiden zu vergleichenden Diensttypbeschreibungen als auch die Beziehungstypbeschreibung<br />
anzugeben. Aufgrund der im Beziehungstyp de nierten Charakteristika<br />
und De nitionsregeln wird die Vergleichsoperation gesteuert. Wie<br />
bereits <strong>in</strong>Abschnitt 3.2.2.2 erlautert wurde, ist es unter Umstanden erforderlich,<br />
da diese Entscheidung durch explizite adm<strong>in</strong>istrativeTatigkeiten getro en werden<br />
mu , falls die De nitionsregeln e<strong>in</strong>e automatische Uberprufung durch den<br />
Typmanager nicht zulassen.<br />
Grundvoraussetzung fur Typuberprufungen und {vergleiche zumZeitpunkt der<br />
spaten B<strong>in</strong>dung ist die Verfugbarkeit der Diensttypbeschreibungen der Kooperationspartner<br />
und der mit der B<strong>in</strong>dung assoziierten Beziehungstypbeschreibung.<br />
Vor E<strong>in</strong>gehen der B<strong>in</strong>dung werden diese Typbeschreibungen dem Typmanager<br />
ubergeben, der die Zugehorigkeit beider Diensttypbeschreibungen <strong>in</strong> die durch<br />
die Beziehungstypbeschreibung de nierte Beziehung uberpruft. Innerhalb o ener<br />
verteilter Dienstemarkte s<strong>in</strong>d als Beziehungstypen vor allem Aquivalenz{<br />
und Konformitatsbeziehungen <strong>in</strong>teressant, mit denen die Typsicherheit der Beteiligten<br />
sichergestellt wird. Welche Art von Typbeziehung fur die aktuelle B<strong>in</strong>dung<br />
jeweils von Interesse ist, mu vor Uberprufungder B<strong>in</strong>dung festgelegt werden.<br />
Dies kann beispielsweise <strong>in</strong> der Dienstauswahlphase bestimmt werden und<br />
hangt unter anderem auch davon ab, welche Beziehungen durch das Laufzeitsystem,<br />
das die Infrastruktur fur Dienstaufrufe zur Verfugung stellt, unterstutzt<br />
werden. In DCE oder CORBA beispielsweise s<strong>in</strong>d nur e<strong>in</strong>fache Konformitatsbeziehungen<br />
erlaubt, mit denen Operationen zu bestehenden Schnittstellentypen<br />
h<strong>in</strong>zugefugt werden konnen, wobei die Parameter der bestehenden Operationen<br />
nicht verandert werden durfen. Um auch dort e<strong>in</strong>e Konformitatsbeziehung zu<br />
unterstutzen, s<strong>in</strong>d zusatzliche Systemdienste erforderlich, die e<strong>in</strong> uber die vorhandenen<br />
Plattformkonzepte h<strong>in</strong>ausgehende Umsetzung und Anpassung der Parameterwerte<br />
vornehmen. Diese Aufgabe kann durch sogenannte Interzeptoren<br />
erfullt werden, die <strong>in</strong> Abschnitt 3.4 vorgestellt werden.<br />
E<strong>in</strong>e e<strong>in</strong>fache Artder Realisierung von Typuberprufungen und {vergleichen zum<br />
B<strong>in</strong>dungszeitpunkt kann durch Verwendung der vom Typmanager vergebenen
3.2 Diensttypmanagement 69<br />
Typbezeichner erreichtwerden. Diese Variante ist <strong>in</strong> Abbildung 3.12 verdeutlicht.<br />
Dienstnehmer<br />
TypeId<br />
Typmanager<br />
CheckRelationship<br />
RelTypeId<br />
Laufzeitsystem<br />
TypeId<br />
Diensterbr<strong>in</strong>ger<br />
Abbildung 3.12: Typuberprufung zum B<strong>in</strong>dungszeitpunkt<br />
Mit Hilfe der beiden Typbezeichner und des, <strong>in</strong>dem dargestellten Fall vom Laufzeitsystem<br />
bereitgestellten Beziehungstypbezeichners wird uberpruft, ob beide<br />
Diensttypen <strong>in</strong> der gegebenen Beziehung stehen. Gegebenenfalls kann die neue<br />
Beziehungs<strong>in</strong>stanz anschlie end auch im Beziehungsrepository des Typmanagers<br />
abgelegt werden, falls sie dort noch nicht vorhanden war.<br />
Variationen dieses e<strong>in</strong>fachen Verfahrens ergeben sich, falls alternativ zu Typbezeichnern<br />
Dienstreprasentationen verwendet werden, die samtliche Diensttyp<strong>in</strong>formationen<br />
be<strong>in</strong>halten. Das kann unter anderem der Fall se<strong>in</strong>, falls e<strong>in</strong> Diensterbr<strong>in</strong>ger<br />
e<strong>in</strong>en Dienst e<strong>in</strong>es neuartigen Diensttyps anbietet, der nochnichtimTypmanager<br />
registriert und somit noch ke<strong>in</strong>en Typbezeichner besitzt. Aus diesem<br />
Grund werden derartige Dienste <strong>in</strong> dieser Arbeit auch als unklassi ziert bezeichnet.<br />
Im Gegensatz hierzu stehen klassi zierte Dienste, deren Diensttypen registriert<br />
und somit a{priori bekanntund durche<strong>in</strong>en Typbezeichner identi zierbar<br />
s<strong>in</strong>d. Dieser Aspekt der Klassi kation von Diensten spielt <strong>in</strong>sbesondere bei der<br />
<strong>in</strong> diesem Kapitel betrachteten ODP{basierten Dienstvermittlung [ODP94b] e<strong>in</strong>e<br />
wichtige Rolle, bei der die Ubergabe von Diensttypbeschreibungen auf der<br />
Basis von Typbezeichnern erfolgt (siehe Abschnitt 3.3.2.2).<br />
Uberprufung von Operationsaufrufen Nachdem die B<strong>in</strong>dung erfolgreich<br />
abgeschlossen und dieTypsicherheit sichergestellt ist, konnen die Operationen<br />
des Diensterbr<strong>in</strong>gers von Seiten des Dienstnehmers aufgerufen werden. Beim<br />
Operationsaufruf ist es s<strong>in</strong>nvoll, zusatzlich die Ubere<strong>in</strong>stimmung der Parameterwerte<br />
mit den <strong>in</strong> den Operationssignaturen de nierten Datentypen zu uberprufen.<br />
E<strong>in</strong> e<strong>in</strong>faches Beispiel hierfur ist die falschliche Verwendung von reellen<br />
Zahlen bei e<strong>in</strong>em Parameter, der e<strong>in</strong>en ganzzahligen Datentyp besitzt. Ob derartige<br />
Fehler uberhaupt auftreten konnen, hangt vor allem davon ab, wie exibel<br />
von Seiten des Dienstnehmers Operationen aufgerufen werden konnen.<br />
Die exibelste Moglichkeit stellt e<strong>in</strong>e dynamische Aufrufschnittstelle zur<br />
Verfugung, wie sie bereits <strong>in</strong> ihrer Grundfunktion im Zusammenhang mit dem<br />
CORBA{Schnittstellenrepository <strong>in</strong> Abschnitt 3.2.1.1 vorgestellt worden ist.
70 Zugang zu Diensten <strong>in</strong> heterogenen Umgebungen<br />
Mit ihr konnen Operationsaufrufe zur Laufzeit aus den hierfur notwendigen<br />
Bestandteilen erzeugt und anschlie endanden Diensterbr<strong>in</strong>ger gesendet werden.<br />
In CORBA werden hierfur neben anderen die drei Operationen create request,<br />
add arg und send angeboten. Mit create request wird das Grundgerust e<strong>in</strong>er<br />
Operation mit e<strong>in</strong>em bestimmten Namen erzeugt, dem anschlie end mit add arg<br />
Parameter und deren Werte sowie auch vorerst leere Ruckgabeparameter, die<br />
erst bei Beend<strong>in</strong>gung des Operationsaufrufs belegt werden, h<strong>in</strong>zugefugt werden<br />
konnen. Das abschlie ende Versenden der Operation erfolgt mit send. Bei<br />
komplexen Operationen kann es hier leicht zuFehlern im Aufbau der Operation<br />
kommen, die im ungunstigsten Fall erst auf Diensterbr<strong>in</strong>gerseiteerkanntwerden.<br />
Um dies zu vermeiden ist e<strong>in</strong>e vorherige Uberprufung des Operationsaufbaus<br />
durch den Typmanager notwendig. Abbildung 3.13 zeigt e<strong>in</strong>en moglichen Ansatz<br />
e<strong>in</strong>er derartigen Uberprufung.<br />
create_request<br />
add_arg<br />
...<br />
send<br />
Dienstnehmer<br />
TypeId<br />
Typmanager<br />
CheckOperation<br />
Operation( Name, List (Parameter), ...)<br />
Laufzeitsystem<br />
Diensterbr<strong>in</strong>ger<br />
Abbildung 3.13: Typ{ undWertuberprufung beim dynamischen Operationsaufruf<br />
Bevor die Operation an den Diensterbr<strong>in</strong>ger gesendet wird, ubergibt das Laufzeitsystem<br />
dem Typmanager den Diensttypbezeichner, der auf die Diensttypbeschreibung<br />
imTypbeschreibungsrepository verweist. Gleichzeitig wird auch das<br />
komplette Operationsgerust e<strong>in</strong>schlie lich der Werte der Parameter beigefugt,<br />
so da der Typmanager sowohl dessen korrekten Aufbau als auch dieParameterwerte<br />
bezuglich der geforderten Parametertypen uberprufen kann. Erst bei<br />
Korrektheit der gemachten Angaben wird die Operation beim Diensterbr<strong>in</strong>ger<br />
aufgerufen.<br />
Das obige Pr<strong>in</strong>zip der Typuberprufung dynamischer Operationsaufrufela t sich<br />
auch auf statische Varianten ubertragen, wie sie durch das Pr<strong>in</strong>zip der entfernten<br />
Prozeduraufrufe (engl. remote procedure call { RPC) realisiert werden. Der<br />
wesentliche Unterschied zum dynamischen Aufruf besteht dort <strong>in</strong> der Generierung<br />
von sogenannten Stubs, die statischzum Dienstnehmer und Diensterbr<strong>in</strong>ger<br />
h<strong>in</strong>zugebunden werden und alle zur Typuberprufung notwendigen Funktionen<br />
bereitstellen. Grundlage fur deren Generierung bildet im allgeme<strong>in</strong>en, beispielsweise<br />
auch bei DCE, ANSA und CORBA, die Schnittstellentypbeschreibung. Sie<br />
wird e<strong>in</strong>em Sprachubersetzer (engl. compiler) ubergeben, der die entsprechenden
3.2 Diensttypmanagement 71<br />
Stubs erzeugt (siehe Abbildung 3.14).<br />
Schnittstellentypbeschreibung<br />
Stub-<br />
Generator<br />
Dienstnehmer<br />
Stub<br />
...<br />
Operationsname<br />
(Parameterliste)<br />
CheckOperation<br />
Laufzeitsystem<br />
Diensterbr<strong>in</strong>ger<br />
Abbildung 3.14: Typ{ und Wertuberprufung beim statischen, generierten Operationsaufruf<br />
Fur den Programmierer des Dienstnehmers bedeutet dies, da er sich mit spezi<br />
schen Details des <strong>in</strong>ternen Aufbaus von Operationen nicht ause<strong>in</strong>andersetzen<br />
mu , sondern entfernte Operationen ahnlich wie Prozeduren <strong>in</strong> prozeduralen<br />
Programmiersprachen aufrufen kann. Die Stubs verbergen hierbei samtlichekommunikationstechnischen<br />
Details. Bed<strong>in</strong>gt durch die automatische Generierungaus<br />
der Schnittstellentypbeschreibung werden au erdem Fehler im Operationsaufbau<br />
von vornhere<strong>in</strong> vermieden und fehlerhafte Ubergaben von Parameterwerten bei<br />
der Programmierungbereitserkannt. Ob die <strong>in</strong> der Abbildung dargestellte Operation<br />
CheckOperation <strong>in</strong> den Stubs selbst oder wie im dynamischen Fall durch<br />
e<strong>in</strong>en separaten Typmanager realisiert wird, hangt unter anderem von den sich<br />
gegenuberstehenden Anforderungen nach E zienz auf der e<strong>in</strong>en und Generizitat<br />
auf der anderen Seite ab.<br />
3.2.3 Grundlagen e<strong>in</strong>es <strong>verteilten</strong> Diensttypmanagements<br />
Im vorherigen Abschnitt s<strong>in</strong>d die grundlegenden Aufgaben des Typmanagementsvorgestelltworden,<br />
die wohlde nierte Grundkonzeptefur den Umgangmit<br />
Diensttypen und Beziehungstypen sowie von Beziehungs<strong>in</strong>stanzen bereitstellen.<br />
Der Darstellung wurde dabei e<strong>in</strong>e idealisierte Sichtweise von Typmanagement<br />
zugrunde gelegt, bei der zunachst Verteilungs{ und Heterogenitatsaspekte unberucksichtigt<br />
geblieben s<strong>in</strong>d. Aufgrund der Autonomie der an o enen <strong>verteilten</strong><br />
Dienstemarkten beteiligten Verwaltungsdomanen, die sich vor allem bei der Gestaltung<strong>in</strong>terner<br />
Verwaltungsstrukturen ausdruckt, ist <strong>in</strong> der Regel jedochdavon<br />
auszugehen, da auch die Aspektedes Typmanagements<strong>in</strong>der jeweiligen lokalen<br />
Verantwortlichkeit der Domanen liegen. E<strong>in</strong>e der direkten Konsequenzen dieser<br />
Autonomie ist das Vorhandense<strong>in</strong> verschiedener Typmanager, die jeweils die <strong>in</strong>nerhalb<br />
e<strong>in</strong>er Verwaltungsdomane de nierten Beschreibungen von Diensttypen<br />
und Beziehungstypen sowie konkreten Beziehungs<strong>in</strong>stanzen verwalten. Zur besonderen<br />
Betonung der Autonomieaspekte wird <strong>in</strong> dieser Arbeit die Zusammenarbeit<br />
von Typmanagern zweier Verwaltungsdomanen auch als Typmanagerfoderation<br />
bezeichnet. Die Abbildung 3.15 zeigt e<strong>in</strong>en verfe<strong>in</strong>erten Ausschnitt der zu<br />
Beg<strong>in</strong>n dieses Kapitels gezeigten Abbildung 3.2, <strong>in</strong> der die moglichen Hetero-
72 Zugang zu Diensten <strong>in</strong> heterogenen Umgebungen<br />
Verwaltungsdomäne A<br />
Verwaltungsdomäne B<br />
Typmanager<br />
Typmanager<br />
A B<br />
Typmanagerföderation<br />
DienstDienstnehmer<br />
Heterogenitätsgrenze<br />
erbr<strong>in</strong>ger<br />
Abbildung 3.15: Verteiltes Diensttypmanagement<br />
genitatsgrenzen beim Zugang zu Diensten <strong>in</strong> o enen <strong>verteilten</strong> Dienstemarkten<br />
verdeutlichtworden s<strong>in</strong>d. Die Abbildung beschrankt sich hierbei zunachst auf die<br />
Darstellung adm<strong>in</strong>istrativer Heterogenitatsgrenzen. Bei der Typmanagerfoderation<br />
uber technische Heterogenitatsgrenzen h<strong>in</strong>weg ware zusatzlich der E<strong>in</strong>satz<br />
e<strong>in</strong>es Interzeptors erforderlich. Hierauf geht Abschnitt 3.4 noch genauer e<strong>in</strong>.<br />
Im folgenden werden die grundlegenden Systemmechanismen vorgestellt, die fur<br />
die Kooperation von Typmanagern zweier heterogener Verwaltungsdomanen notwendig<br />
s<strong>in</strong>d. Hierbei wird zum e<strong>in</strong>en das Problem der bisher nur lokal gultigen<br />
Typbezeichner erortert. Zum anderen wird der ebenfalls bisher nur lokal betrachtete<br />
Aspekt der B<strong>in</strong>dungsuberprufung wieder aufgegri en und e<strong>in</strong> moglicher<br />
Ansatz vorgestellt, der unter Berucksichtigungder Beteiligung mehrerer Typmanager<br />
Typuberprufungen und {vergleiche ermoglicht. Dieser basiert im wesentlichen<br />
auf dem Austauschvon Typbeschreibungen zwischen den Typmanagern. Die<br />
hierfur vorgeschlagenen Konzepte der global e<strong>in</strong>deutigen Typbezeichner und des<br />
Austauschs von Typbeschreibungen bilden gleichzeitig auch die systemtechnischen<br />
Voraussetzungen fur die Realisierung von Trader{Kooperationsprotokollen, wie<br />
sie<strong>in</strong>Abschnitt 3.3.3.3 detailliert betrachtet werden.<br />
3.2.3.1 Global e<strong>in</strong>deutige Typbezeichner<br />
Wie auch im lokalen Fall ist e<strong>in</strong>e Grundvoraussetzung fur verteiltes Typmanagement<br />
die e<strong>in</strong>deutige Bezeichnung von Typbeschreibungen und Beziehungs<strong>in</strong>stanzen.<br />
Da bei der Typmanagerfoderation die Bezeichnung von Typen jeweils<br />
<strong>in</strong> der Verantwortung des lokalen Typmanagers liegt, ist e<strong>in</strong>e Erweitertung von<br />
Typ{ und Instanzbezeichnern notwendig, so da weiterh<strong>in</strong> die globale E<strong>in</strong>deutigkeit<br />
der Bezeichner gewahrleistet ist. Die verwendeten e<strong>in</strong>deutigen Bezeichner<br />
sollten dabei auch Informationen uber ihre Herkunft be<strong>in</strong>halten, mit denen<br />
der Bezug zum dazugehorigen Typmanager hergestellt wird. Wird beispielsweise<br />
davon ausgegangen, da die Adresse e<strong>in</strong>es Typmanagers weltweit e<strong>in</strong>deutig
3.2 Diensttypmanagement 73<br />
ist, konnte e<strong>in</strong>Typbezeichner das <strong>in</strong> Abbildung 3.16 gezeigte Format besitzen.<br />
Die Typmanageradresse mu hierbei von jedem Teilnehmer <strong>in</strong> e<strong>in</strong>em o enen<br />
Typmanageradresse <strong>in</strong>terner Bezeichner Bezeichnertyp<br />
Abbildung 3.16: Format e<strong>in</strong>es Typbezeichners<br />
Dienstemarkt <strong>in</strong>terpretiert werden konnen, um auf den Typmanager zuzugreifen.<br />
Die Interpretation des zweiten Teils des globalen Typbezeichners h<strong>in</strong>gegen<br />
ist jedoch nur im Kontext des adressierten Typmanagers s<strong>in</strong>nvoll und sollte <strong>in</strong><br />
der Regel ansonsten nichtweiter <strong>in</strong>terpretiert werden. Mit Hilfe der dritten Komponente,<br />
dem Bezeichnertyp, lassen sich zusatzlich Aussagen uber die Art des<br />
Bezeichners machen, beispielsweise ob es sich nur um e<strong>in</strong>en lokal gultigen oder<br />
um e<strong>in</strong>en standardisierten, global gultigen Bezeichner handelt. Der letzte Fall<br />
ist besonders im Kontext <strong>in</strong>ternationaler Standardisierung nutzbar, bei der fur<br />
alle im o enen <strong>verteilten</strong> Dienstemarkt agierenden Teilnehmer e<strong>in</strong>e verb<strong>in</strong>dliche<br />
Absprache uber Diensttypbezeichner und die damit verknupften Diensttypbeschreibungen<br />
getro en wird. Beispielsweise kann so der <strong>in</strong> Abbildung 3.9 gezeigte<br />
Diensttyp FTAM <strong>in</strong> se<strong>in</strong>er Syntax und Semantik standardisiert und mit e<strong>in</strong>em<br />
weltweit e<strong>in</strong>heitlichen Diensttypbezeichner identi ziert werden. Standardisierte<br />
Typbezeichner eignen sich <strong>in</strong>sbesondere fur die e<strong>in</strong>fache Realisierung e<strong>in</strong>er <strong>verteilten</strong><br />
Dienstvermittlung, wie sich<strong>in</strong>Abschnitt 3.3.3.3 als e<strong>in</strong>emoglicheVariante<br />
e<strong>in</strong>es Trader{Kooperationsprotokolles vorgestellt werden.<br />
3.2.3.2 Austausch von Typbeschreibungen<br />
Die oben vorgestellten global e<strong>in</strong>deutigen Bezeichner bieten die wesentliche<br />
Grundvoraussetzung fur den domanenubergreifenden Zugri auf die Informationen<br />
e<strong>in</strong>es Typmanagers. Um diese Informationen zwischen den Typmanagern<br />
austauschen zu konnen, mussen Mechanismen fur ihren Transport zur Verfugung<br />
gestellt werden. Dabei s<strong>in</strong>d <strong>in</strong>sbesondere die Heterogenitatsaspekte zuberucksichtigen,<br />
die sich aus der Autonomie der Verwaltungsdomanen ergeben und sich<br />
beispielsweise konkret <strong>in</strong> der Wahl unterschiedlicher Typbeschreibungssprachen<br />
au ern. In Abschnitt 2.1 wurde hierfur das Konzept der Dienstreprasentation<br />
vorgestellt, welches e<strong>in</strong> Transferformat zur Reprasentation von Typ<strong>in</strong>formationen<br />
der Dienstbeschreibungsebene zur Verfugung stellt.<br />
Auf dieser Grundlage kann unter anderem die bisher nur fur den lokalen Fall<br />
betrachtete B<strong>in</strong>dungsuberprufung beim Dienstzugri uber adm<strong>in</strong>istrative Heterogenitatsgrenzen<br />
realisiert werden. Die Abbildung 3.17 zeigt hierzu e<strong>in</strong>e Erweiterung<br />
der <strong>in</strong> Abbildung 3.12 dargestellten Uberprufung e<strong>in</strong>er B<strong>in</strong>dung, wobei<br />
<strong>in</strong> diesem Fall die vom Laufzeitsystem benutzten globalen Typbezeichner auf<br />
Typbeschreibungen <strong>in</strong> den lokalen Typmanagern der Verwaltungsdomanen verweisen.<br />
Die B<strong>in</strong>dungsuberprufung (CheckRelationship) wird <strong>in</strong> der Domane<br />
des Dienstnehmers vorgenommen, <strong>in</strong> der auch der Beziehungstypbezeichner<br />
RelTypeId-TM-A gultig ist. Um an die zur Uberprufung notwendigen Typ<strong>in</strong>formationen<br />
zu gelangen, greift der dortige Typmanager A mit Hilfe der Opera-
74 Zugang zu Diensten <strong>in</strong> heterogenen Umgebungen<br />
Dienstnehmer<br />
Verwaltungsdomäne A<br />
RelTypeId-TM-A<br />
TypeId-TM-A<br />
Typmanager A<br />
CheckRelationship<br />
Laufzeitsystem<br />
Verwaltungsdomäne B<br />
GetTypeDescr<br />
(TypeId-TM-B)<br />
TypeId-TM-B<br />
Typmanager B<br />
Diensterbr<strong>in</strong>ger<br />
Abbildung 3.17: Austausch von Dienstbeschreibungen zum B<strong>in</strong>dungszeitpunkt<br />
tion GetTypeDesc auf die Typbeschreibung des mit TypeId-TM-B referenzierten<br />
Typbezeichners <strong>in</strong> Typmanager B zu. GetTypeDesc erfordert hierbei auch die<br />
Angabe e<strong>in</strong>er bestimmten Typbeschreibungssprache, mit der die Typbeschreibung<br />
von Typmanager B ausgedruckt werden soll, damit die Typ<strong>in</strong>formationen<br />
von Typmanager A verstanden werden konnen. Nach Erhaltder Typbeschreibung<br />
erfolgt die B<strong>in</strong>dungsuberprufung durch den Typmanager.<br />
Der Austauschvon Typ<strong>in</strong>formationen ist generell nicht nur auf den Informationsaustauschzwischen<br />
Typmanagern beschrankt, sondern umfa t samtlicheInteraktionen<br />
des Typmanagers mit se<strong>in</strong>en Klienten, beispielsweise mit Dienstvermittlungskomponenten<br />
beim Diensttypvergleich oder Browsern zur Unterstutzung<br />
der Diensttypsuche. Insbesondere im letzten Fall mussen unter Umstanden zahlreiche<br />
Typmanager verschiedener Verwaltungsdomanen kontaktiert werden. Bei<br />
jedem Zugri ist ebenso wie im obigen Fall der B<strong>in</strong>dungsuberprufung vorher die<br />
geme<strong>in</strong>same Typbeschreibungssprache und Typreprasentation abzustimmen.<br />
Weiterh<strong>in</strong> s<strong>in</strong>d beim Austausch von Typ<strong>in</strong>formationen von Seiten der Typmanager<br />
auch Sicherheitsaspektezuberucksichtigen, die den Umgang mit den dort<br />
abgelegten Typ<strong>in</strong>formationen festlegen. Generelle Fragestellungen s<strong>in</strong>d beispielsweise,<br />
welche Typ<strong>in</strong>formationen fur wen nach au en h<strong>in</strong> sichtbar se<strong>in</strong> sollen oder<br />
welche Operationen durch e<strong>in</strong>en Klienten genutzt werden durfen. Die Beantwortung<br />
dieser Fragen hangt ma geblich von den lokalen Rahmenbed<strong>in</strong>gungen ab,<br />
die <strong>in</strong> der jeweiligen Verwaltungsdomane de niert s<strong>in</strong>d. In der Literatur werden<br />
diese Rahmenbed<strong>in</strong>gungen generell auch als Verwaltungsvorschriften (engl.<br />
policies) [ODP95c] bezeichnet, deren Festlegung beispielsweise durch den Typmanager<br />
selbst oder domanenubergreifend getro en wird. E<strong>in</strong> Beispiel fur e<strong>in</strong>e<br />
Verwaltungsvorschrift im Rahmen des Typmanagements ist die <strong>in</strong> [IBR93]vorgeschlagene<br />
Unterscheidung von universellen, standardisierten und privaten Typbeschreibungen,<br />
wobei der Zugri von au en nur auf die ersten beiden moglich<br />
ist, wahrendprivateTypbeschreibungen nur im Sichtbarkeitsbereich der lokalen<br />
Verwaltungsdomane zuganglich s<strong>in</strong>d.
3.3 Vermittlung und Verwaltung von Dienstangeboten 75<br />
3.3 Vermittlung und Verwaltung von Dienstangeboten<br />
Angesichts der moglichen Vielfalt und Vielzahl von angebotenen Diensten <strong>in</strong> <strong>offenen</strong><br />
<strong>verteilten</strong> Dienstemarkten ergibt sich fur potentielle Dienstnehmer die Frage<br />
nach geeigneten Unterstutzungsmechanismen, mit denen geeignete Diensterbr<strong>in</strong>ger<br />
e<strong>in</strong>es gewunschten Diensttyps gefunden werden konnen. Wie auch <strong>in</strong><br />
herkommlichen kommerziellen Warenmarkten s<strong>in</strong>d hierbei vor allem diejenigen<br />
Dienstangebote von Interesse, die fur den Dienstnehmer das <strong>in</strong> se<strong>in</strong>em spezi -<br />
schen Anwendungskontext " am besten geeignete\ darstellen.<br />
In diesem Abschnitt sollen Systemtechniken untersucht werden, die den Dienstnehmern<br />
e<strong>in</strong>e adaquate Unterstutzung fur die zweite wichtige <strong>Dienstnutzung</strong>sphase,<br />
die Dienstauswahl, bereitstellen. Im Betrachtungsschwerpunkt steht das<br />
sogenannte Trad<strong>in</strong>g, welches e<strong>in</strong>en geeigneten Losungsansatz fur die Dienst{<br />
bzw. Dienstangebotsvermittlung 6 sowohl <strong>in</strong> lokalen als auch <strong>in</strong>weltweit <strong>verteilten</strong><br />
Dienstemarkten bietet. Hierbei wird <strong>in</strong>sbesondere auch auf aktuelle Arbeiten<br />
e<strong>in</strong>gegangen, die im Rahmen der <strong>in</strong>ternationalen Standardisierung des<br />
ODP{Referenzmodells [ODP95b] unter dem Begri der ODP trad<strong>in</strong>g function<br />
[ODP95a] durchgefuhrt worden s<strong>in</strong>d. Hieruber h<strong>in</strong>ausgehend werden auch noch<br />
e<strong>in</strong>mal verschiedene Heterogenitatsprobleme erortert, die sich aus der Autonomie<br />
der <strong>in</strong> e<strong>in</strong>em o enen <strong>verteilten</strong> Dienstemarkt kooperierenden Verwaltungsdomanen<br />
ergeben und ma geblichen E<strong>in</strong> u auf den Dienstvermittlungsproze<br />
ausuben.<br />
3.3.1 Mechanismen zur Dienstauswahl<br />
Wesentliches Unterscheidungsmerkmal verschiedener Dienstauswahlmechanismen<br />
s<strong>in</strong>d die Moglichkeiten, die e<strong>in</strong>em Dienstnehmer, d.h. Dienstnehmern im<br />
systemtechnischen S<strong>in</strong>ne und menschlichen Endbenutzern, zur Unterstutzung<br />
se<strong>in</strong>er Dienstauswahl zur Verfugung stehen. Generell lassen sich drei verschiedene<br />
Dienstauswahlmechanismen unterscheiden, die im folgenden naher erlautert<br />
werden:<br />
1. Namens{ und attributbasierte Dienstauswahl<br />
2. Brows<strong>in</strong>g{basierte Dienstauswahl<br />
3. Diensttypbasierte Dienstauswahl<br />
3.3.1.1 Namens{ und attributbasierte Dienstauswahl<br />
Die Aufgabe der Verwaltung von Ressourcen <strong>in</strong> o enen <strong>verteilten</strong> Systemumgebungen<br />
wurde bisher zumeist durch Namensdienste [Sch92a] erbracht, die den<br />
6 Die Begri e Dienst und Dienstangebot werden im folgenden im Kontext der hier betrachteten<br />
Vermittlung und Auswahl von Dienstangeboten synonym verwendet.
76 Zugang zu Diensten <strong>in</strong> heterogenen Umgebungen<br />
Dienstnehmern e<strong>in</strong>fache Moglichkeiten zur Ablage und zumSuchen von Ressourcen<br />
bereitstellen. Durch ihre Generizitat lassen sie sich somit auch fur die<br />
Verwaltungvon Diensten bzw. Diensterbr<strong>in</strong>gern nutzen, die <strong>in</strong> diesem S<strong>in</strong>ne spezielle<br />
Formen von Ressourcen darstellen. Die wesentliche Hauptaufgabe derartiger<br />
Namensdienste liegt <strong>in</strong> der Verwaltung von Abbildungen zwischen logischen<br />
Namen auf physikalische Adressen, die den konkreten Ort der Diensterbr<strong>in</strong>gung<br />
darstellen. Bed<strong>in</strong>gt durch diese Indirektionsstufe ergibt sich fur den Dienstnehmer<br />
der Vorteil der Ortsabstraktion, da nur der logische Name, beispielsweise der<br />
Dienstname Pr<strong>in</strong>tService, und nicht die unter Umstanden sich andernde physikalische<br />
Adresse des Diensterbr<strong>in</strong>gers berucksichtigt werden mu . Neben dieser<br />
re<strong>in</strong>en Abbildungsfunktionalitat unterstutzen Namensdienste zumTeil auch<br />
attributbasierte Anfragen, so da e<strong>in</strong>e Auswahl von Diensten uber Eigenschaften<br />
der registrierten Dienste durchgefuhrt werden kann. E<strong>in</strong> bekanntes Beispiel<br />
hierfur ist der standardisierte globale Namensdienst X.500 [Neu89, Rad94], der<br />
ahnlich zuden Dienstattributtypen im Diensttypkonzept zu jedem Namense<strong>in</strong>trag<br />
die Angabe von Attributen erlaubt. Diese konnen spater als Suchkriterien<br />
fur e<strong>in</strong>e Dienstauswahl benutzt werden, auf deren Grundlage der Namensdienst<br />
passende Dienstangebote <strong>in</strong> se<strong>in</strong>em verwalteten Namensraum sucht.<br />
E<strong>in</strong> wesentliches Merkmal von Namensdiensten ist der Determ<strong>in</strong>ismus, mit dem<br />
Suchanfragen beantwortet werden. So ist <strong>in</strong> der Regel davon auszugehen, da<br />
e<strong>in</strong>e bestimmte Anfrage immer mit denselben Resultaten beantwortet wird, so<br />
da beispielsweise unter der Attributanfrage Pr<strong>in</strong>terSpeed > 20 immer dieselben<br />
Diensterbr<strong>in</strong>ger zuruckgeliefert werden. Begrundet liegt dieses dar<strong>in</strong>, da die<br />
Auswahlprozesse <strong>in</strong>nerhalb von Namensdiensten ausschlie lich auf der Berucksichtigung<br />
statischer Informationen beruhen, die unveranderlich mit den Namense<strong>in</strong>tragen<br />
abgelegt s<strong>in</strong>d. Hier ist auch der wesentliche Unterschied zum nachfolgend<br />
dargestellten Trad<strong>in</strong>g zusehen, das durch Berucksichtigung zusatzlicher<br />
Auswahlkriterien generell nichtdeterm<strong>in</strong>istische Resultate zuruckliefert. Dieses<br />
wird <strong>in</strong>sbesondere beim Vorgang der gesta elten Auswertung deutlich, der <strong>in</strong><br />
Abschnitt 3.3.2.3 beschrieben ist. Pr<strong>in</strong>zipiell ist dort ebenfalls e<strong>in</strong> determ<strong>in</strong>istisches<br />
Verhalten erzielbar, sofern sich der Auswahlproze beim Trad<strong>in</strong>g ausschlie<br />
lich auf statische Dienstangebots<strong>in</strong>formationen beschrankt. Von e<strong>in</strong>igen<br />
Autoren werden Namensdienste <strong>in</strong> diesem Zusammenhangauch als Vorlaufer von<br />
Trad<strong>in</strong>g{Diensten verstanden [AA91, Dud90, Kel93], was sich zumTeil auch <strong>in</strong><br />
der Wahl von Namensdiensten zur Dienstangebotsverwaltung <strong>in</strong>Tradern widerspiegelt<br />
(siehe beispielsweise <strong>in</strong> [BKS91, WB95]). E<strong>in</strong> ahnlicher Ansatz ist auch<br />
<strong>in</strong>nerhalb von TRADE gewahlt worden, da Namensdienste zahlreiche Trad<strong>in</strong>g{<br />
unterstutzende Funktionen bereits anbieten (siehe Abschnitt 5.2).<br />
E<strong>in</strong> anderer attributbasierter Dienstauswahlmechanismus ndet sich imCygnus{<br />
System [CR91], <strong>in</strong> dem Dienstangebote durch e<strong>in</strong>eunterliegende verteilte Datenbank<br />
verwaltet werden. Dienstnehmer konnen sich unter Angabe von Attributlisten,<br />
beispielsweise ((category, compile), (source, C), (target,<br />
PowerPC)) zur Suche nach e<strong>in</strong>em Programmubersetzungsdienst, B<strong>in</strong>dungs<strong>in</strong>formationen<br />
von passenden Diensterbr<strong>in</strong>gern zuruckgeben lassen. Ebenso wie bei<br />
den attributierten Namensdiensten werden auch hier jedoch nur die statischen<br />
Eigenschaften der Diensterbr<strong>in</strong>ger berucksichtigt.
3.3 Vermittlung und Verwaltung von Dienstangeboten 77<br />
3.3.1.2 Brows<strong>in</strong>g{basierte Dienstauswahl<br />
Als zweite Form von Dienstauswahlmechanismen existieren <strong>in</strong>teraktive Verfahren,<br />
wie sie bereits schon <strong>in</strong> Kapitel 2 bei der Darstellung verschiedener Moglichkeiten<br />
von Dienstbeschreibungen angesprochen wurden:<br />
Zum e<strong>in</strong>en ist dieses der <strong>in</strong> Abschnitt 2.4.4.2 beschriebene Generische<br />
Klient, der den <strong>in</strong>teraktiven Systembenutzer bei der Diensttypsuche und<br />
der Dienstauswahl unterstutzt. Da dort konzeptionell Diensterbr<strong>in</strong>ger und<br />
Dienstbeschreibung e<strong>in</strong>e<strong>in</strong>deutig mite<strong>in</strong>ander verknupft s<strong>in</strong>d [MML94a],<br />
bietet der Generische Klient gleichzeitig die Moglichkeit, die am Bildschirm<br />
des Benutzers visualierten Dienstbeschreibungselemente, die beispielsweise<br />
Operationsaufrufe reprasentieren, zu aktivieren. Hierdurchkannder von<br />
e<strong>in</strong>em Diensterbr<strong>in</strong>ger bereitgestellte Dienst <strong>in</strong>teraktiv getestet werden, um<br />
beispielsweise dessen Semantik besser zu verstehen.<br />
E<strong>in</strong> anderer Ansatz s<strong>in</strong>d die <strong>in</strong> Abschnitt 2.4.3.2 beschriebenen Konzeptgraphen.<br />
Obwohl dort im Vergleich zum Generischen Klienten ke<strong>in</strong>e explizite<br />
Verknupfung von Dienstbeschreibung und Diensterbr<strong>in</strong>ger vorgegeben<br />
ist, lassen sich Konzeptgraphen auch zur Beschreibung der Dienste konkreter<br />
Diensterbr<strong>in</strong>ger nutzen, so da dort zwischen Dienstbeschreibung<br />
und Diensterbr<strong>in</strong>ger ebenfalls e<strong>in</strong>e enge Beziehung herrscht. Anschlie end<br />
konnen durch benutzerseitige Spezi kation e<strong>in</strong>es Konzeptgraphens geeignete<br />
Dienstbeschreibungen mit Hilfe e<strong>in</strong>es auf e<strong>in</strong>em Ahnlichkeitsma basierenden<br />
Vergleichsverfahrens ermittelt werden.<br />
Da beide Verfahren die Dienstzugangsphasen der Diensttyp ndung und der<br />
Dienstauswahl verb<strong>in</strong>den, ist neben den eigentlichen Vergleichsmechanismen<br />
zusatzlich auch der Zugri auf e<strong>in</strong>e explizite Dienstangebotsverwaltung erforderlich,<br />
die die Abbildungen von Dienstbeschreibungen auf konkrete Dienstangebote<br />
mit den dort enthaltenen B<strong>in</strong>dungs<strong>in</strong>formationen der Diensterbr<strong>in</strong>ger verwaltet.<br />
Im Fall der Konzeptgraphen kann dieses beispielsweise durch Integration mit<br />
der nachfolgend beschriebenen ODP{Trad<strong>in</strong>g{Funktion erreicht werden, <strong>in</strong> dem<br />
die dort vorhandene Dienstangebotsverwaltung implizit mit benutzt wird [PB96].<br />
Beim Generischen Klienten wird hierfur e<strong>in</strong> erweitertes Dienstrepository vorgeschlagen<br />
[Vol95], welches Dienstbeschreibungen|und somit gleichzeitig konkrete<br />
Diensterbr<strong>in</strong>ger | verwaltet und e<strong>in</strong>e uber Dienstbeschreibungselemente<br />
gesteuerte Suche anbietet.<br />
Beide Verfahren setzen au erdem e<strong>in</strong>e hohe Interaktion des Benutzers beim<br />
Dienstauswahlproze voraus, so da sie fur e<strong>in</strong>e Anzahl verteilter Anwendungen,<br />
wie beispielsweise den <strong>in</strong> dieser Arbeit speziell betrachteten Kooperationsanwendungen<br />
(siehe Abschnitt 4.2.1), nicht geeignet s<strong>in</strong>d, da dort <strong>in</strong> der Regel e<strong>in</strong>e<br />
automatisch ablaufende Dienstvermittlung gefordert wird.
78 Zugang zu Diensten <strong>in</strong> heterogenen Umgebungen<br />
3.3.1.3 Diensttypbasierte Dienstauswahl<br />
Im Gegensatz zu den obigen generischen Namensdiensten, die pr<strong>in</strong>zipiell beliebige<br />
Arten von Informationen verwalten konnen, stellt das Trad<strong>in</strong>g e<strong>in</strong>en speziell<br />
auf die Verwaltung und Vermittlung von Dienstangeboten spezialisierten Unterstutzungsdienst<br />
dar. Herausragendes Merkmal des im folgenden speziell betrachteten<br />
ODP{Trad<strong>in</strong>gs [ODP95a] ist der Diensttypbegri , der als e<strong>in</strong> Hauptkriterium<br />
zur strukturierten Verwaltung von Dienstangeboten dient. Aus diesem<br />
Grund wird Trad<strong>in</strong>g zur Abgrenzung zuherkommlichen Namensdiensten auch<br />
explizit als diensttypbasiert gekennzeichnet, um den spezi schen, auf Diensttypen<br />
basierenden formalistischen Ansatz der Dienstverwaltung und {vermittlung<br />
zu betonen.<br />
3.3.2 ODP{basiertes Trad<strong>in</strong>g<br />
Der vorliegende Abschnitt stellt die ODP{Trad<strong>in</strong>g{Funktion vor, die zur Zeit<br />
auf <strong>in</strong>ternationaler Ebene durch die International Standardization Organisation<br />
(ISO) standardisiert wird. Grundlage fur die folgende Darstellung bildet das im<br />
Juli 1994 vero entlichte Standarddokument [ODP94b]. Weitere erganzende Beschreibungen<br />
des ODP{Trad<strong>in</strong>gs nden sich unter anderem im Tutorial des oben<br />
genannten Standarddokuments und <strong>in</strong> [Bea95], [Pop95], [PSW96] und [SPM94],<br />
wobei die drei letztgenannten auf e<strong>in</strong>em alteren Standarddokument [ODP94a]<br />
beruhen, wodurch sichUnterschiede vor allem bei der Darstellung der Kooperation<br />
von Tradern, dem sogenannten Trader Interwork<strong>in</strong>g bzw. der Trader Federation,<br />
und der Darstellung der operationalen Schnittstelle des ODP{Traders<br />
ergeben 7 . Grundlegende Anmerkungen zum Trad<strong>in</strong>g nden sich auch <strong>in</strong>der <strong>verteilten</strong><br />
Systemarchitektur ANSA [ANS87, Her89], <strong>in</strong> der ursprunglich der Begri<br />
des Trad<strong>in</strong>gs gepragt wurde.<br />
An dieser Stelle ist anzumerken, da das Trader{Standarddokumente<strong>in</strong>Schnittstellenstandard<br />
darstellt, bei dem nur der Diensttyp des Traders mit se<strong>in</strong>em extern<br />
sichtbaren Verhalten an der operationalen Schnittstelle de niert ist. Aspekte<br />
konkreter Losungsansatze und Realisierungsvorschlage werden nur <strong>in</strong>formell im<br />
Anhang des Dokuments erortert. Sie betre en jedoch nur allgeme<strong>in</strong>e Vorgehensweisen,<br />
beispielsweise zur Durchfuhrung der Dienstauswahl.<br />
3.3.2.1 Export und Import von Dienstangeboten<br />
Zentrale Aufgabe e<strong>in</strong>es Traders ist die VermittlungundVerwaltungvon Dienstangeboten.<br />
Er bietet hierzu Mechanismen an, die e<strong>in</strong>e Strukturierungder verschiedenartigen<br />
Dienstangebote ermoglichen und den Dienstnehmer beim Au nden<br />
geeigneter unterstutzen. Se<strong>in</strong>e Funktionalitat la t sich am besten mit der e<strong>in</strong>es<br />
" Gelbe Seiten\{Dienstes vergleichen, der Dienste kategorisiert und e<strong>in</strong>eSuche<br />
uber Diensteigenschaften anbietet. Das formale Konzept fur die Kategorisierung<br />
7 E<strong>in</strong>e endgultige Verabschiedung des ODP{Trader{Standards ist fur Mitte 1996 vorgesehen.
3.3 Vermittlung und Verwaltung von Dienstangeboten 79<br />
von Diensten ist der <strong>in</strong> Kapitel 2 bereits e<strong>in</strong>gefuhrte Diensttyp, der sich aus e<strong>in</strong>em<br />
Schnittstellentyp und den Dienstattributtypen zusammensetzt. E<strong>in</strong> weiteres<br />
Strukturierungsmittel des Traders s<strong>in</strong>d sogenannte Kontexte, die die geordnete<br />
Ablage von Dienstangeboten, beispielsweise <strong>in</strong> e<strong>in</strong>er hierarchisch organisierten<br />
Form, ermoglichen.<br />
Die Interaktionen der zu verwaltenden Diensterbr<strong>in</strong>ger und der Dienstnehmer<br />
mit dem Trader verdeutlicht Abbildung 3.18.<br />
Trader<br />
ImportOffer 2 3<br />
1 ExportOffer<br />
Dienst-<br />
4<br />
Dienstnehmer<br />
Dienstaufruf erbr<strong>in</strong>ger<br />
Abbildung 3.18: Der Trader und se<strong>in</strong>e Nutzer<br />
E<strong>in</strong> Diensterbr<strong>in</strong>ger, der sogenannte Exporteur, registriert se<strong>in</strong> Dienstangebot<br />
beim Trader (Schritt 1). Hierzu gibt er unter anderem den Diensttyp, die aktuellen<br />
Werte der Dienstattribute und moglicherweise e<strong>in</strong>en Kontext an, <strong>in</strong> den das<br />
Dienstangebot exportiert werden soll. E<strong>in</strong> Dienstnehmer, der sogenannte Importeur,<br />
richtet se<strong>in</strong>e Suchanfrage nach e<strong>in</strong>en bestimmten Diensterbr<strong>in</strong>ger an den<br />
Trader (Schritt 2). Sie setzt sich unter anderem aus dem gewunschten Diensttyp<br />
und den gewunschten Diensteigenschaften zusammen. Zusatzlich konnen auch<br />
bestimmte Suchvorschriften (engl. search policies) angegeben werden, mit denen<br />
beispielsweise der Suchkontext genauer bestimmtund e<strong>in</strong>geschrankt werden<br />
kann. Aufgrund dieser Suchkriterien ermitteltder Trader passende Dienstangebote,<br />
wahlt gegebenfalls das am besten geeignete aus und ubermittelt dem Dienstnehmer<br />
die fur die anschlie ende Interaktion mit dem Diensterbr<strong>in</strong>ger notwendigen<br />
B<strong>in</strong>dungs<strong>in</strong>formationen (Schritt 3). Anschlie end kann der Dienstnehmer die<br />
Operationen des Diensterbr<strong>in</strong>gers aufrufen (Schritt 4). Weiterh<strong>in</strong> kann e<strong>in</strong> Exporteur<br />
auch se<strong>in</strong> Dienstangebot spater wieder zuruckzuziehen oder verandern.<br />
Importeur und Exporteur nehmen bei der Interaktion mit dem Trader die Rolle<br />
der Dienstnehmer e<strong>in</strong>, die <strong>in</strong> diesem Fall den vom Trader erbrachten Trad<strong>in</strong>g{<br />
Dienst <strong>in</strong> Anspruch nehmen. Ebenso wie beim Diensttyp der Dienste der Exporteure<br />
besitzt auch der Trader e<strong>in</strong>en Diensttyp, der im Standarddokument<br />
beschrieben ist. Dort spezi zierte Operationen s<strong>in</strong>d e<strong>in</strong>em sogenannten trad<strong>in</strong>g<br />
service <strong>in</strong>terface oder e<strong>in</strong>em trad<strong>in</strong>g management <strong>in</strong>terface zugeordnet, welche<br />
die Schnittstellen zume<strong>in</strong>en fur die Importeure und Exporteure undzumanderen<br />
fur adm<strong>in</strong>istrative Aufgaben de nieren. Erstere umfa t unter anderem die Operationen<br />
exportOffer, importOffer, withdrawOffer und describeOffer,mit<br />
denen auf die im Trader verwalteten Dienstangebote zugegri en werden kann.<br />
Die zweiteSchnittstelle bietet Operationen fur das sogenannte L<strong>in</strong>k{Management
80 Zugang zu Diensten <strong>in</strong> heterogenen Umgebungen<br />
an, mit denen Trader{Kooperationen 8 verwaltet werden. Weiterh<strong>in</strong> werden auch<br />
Operationen zur Verwaltung von Trader{Eigenschaften (engl. trader properties)<br />
angeboten, mit denen spezi sche Charakteristika bzw. Verwaltungsvorschriften,<br />
beispielsweise die Zugehorigkeit zu e<strong>in</strong>em bestimmten Typmanager oder die maximale<br />
Anzahl an e<strong>in</strong>en Importeur zuruckgebbarer Dienstangebote, bestimmt<br />
werden.<br />
3.3.2.2 Verwaltung von Dienstangeboten<br />
Grundlage fur die Dienstangebotsauswahl durch e<strong>in</strong>en Trader ist die Verwaltung<br />
der an ihn exportierten Dienstangebote. Zu diesem Zweck werden beim ODP{<br />
Trad<strong>in</strong>g sogenannte Kontexte als mogliches Strukturierungsmittel de niert (siehe<br />
auch [BR93]). Sie bezeichnen bestimmte Teilbereiche des von e<strong>in</strong>em Trader verwalteten<br />
Dienstangebotsraums (engl. service o er space), <strong>in</strong> die Dienstangebote<br />
beim Exportieren e<strong>in</strong>geordnet werden konnen. Abbildung 3.19 zeigt e<strong>in</strong> Beispiel<br />
e<strong>in</strong>er Kontextstruktur, die auch als direkter azyklischer Graph reprasentiert werden<br />
kann.<br />
B<br />
A<br />
C<br />
D<br />
E<br />
Abbildung 3.19: Trader{Kontexte<br />
B<br />
A<br />
C E<br />
A,B,C,D und E bezeichnen jeweils die Kontexteund die dort e<strong>in</strong>geordneten Dienstangebote.<br />
D ist hierbei Subkontext von C und E. Kontexte konnen generell nach<br />
den verschiedenartigsten Kriterien gebildet werden, die <strong>in</strong> der Regel vom beabsichtigten<br />
E<strong>in</strong>satzbereich e<strong>in</strong>es Traders abhangen. E<strong>in</strong>e e<strong>in</strong>fache und generischverwendbare<br />
Moglichkeit ist beispielsweise die Bildung von Kontexten nach<br />
Diensttypen. In diese konnen die Dienstangebote entsprechend ihrem jeweiligen<br />
Diensttyp e<strong>in</strong>geordnet werden. E<strong>in</strong> Dienstangebot e<strong>in</strong>es Exporteurs setzt sich<br />
dabei aus mehreren E<strong>in</strong>zelteilen zusammen, die <strong>in</strong> Abbildung 3.20 zusammenfassend<br />
dargestellt s<strong>in</strong>d. Im e<strong>in</strong>zelnen werden dabei folgende Bestandteile unterschieden:<br />
Diensttypbeschreibung zur Kategorisierungdes exportierten Dienstangebotes.<br />
Sie umfa t die Beschreibung des Schnittstellentyps und der Dienstattributtypen.<br />
8 Die Kooperation zweier Trader wird alternativ auch als Trader{Interwork<strong>in</strong>g [Vog94] bzw.<br />
<strong>in</strong> alteren Trader{Standarddokumenten [ODP93, ODP94b, BR92a] als Trader{Foderation<br />
bezeichnet.<br />
D
3.3 Vermittlung und Verwaltung von Dienstangeboten 81<br />
Dienstangebot<br />
Dienstangebotseigenschaften<br />
Dienstzugangs-<br />
Schnittstelle<br />
Dienstangebotsauswertungs-<br />
Schnittstelle<br />
Werte statischer<br />
Dienstattribute<br />
Diensttypbeschreibung<br />
- Dienstattributtypen<br />
- Schnittstellentyp<br />
- Semantikbeschreibung<br />
Abbildung 3.20: Bestandteile e<strong>in</strong>es Dienstangebotes<br />
Werte statischer Dienstattribute zur genaueren Charakterisierung des<br />
Dienstangebots<br />
Schnittstellenkennung der Dienstangebotsauswertungsschnittstelle (engl.<br />
service o er evaluation <strong>in</strong>terface { SOEI), uber die der Trader bei e<strong>in</strong>er<br />
spateren Dienstangebotssuche auf die aktuellen Werte der dynamischen<br />
Dienstattribute zugreifen kann. Pr<strong>in</strong>zipiell gilt dieses jedoch auch fur<br />
statische Dienstattribute.<br />
Schnittstellenkennung der operationalen Schnittstelle des Diensterbr<strong>in</strong>gers,<br />
uber die e<strong>in</strong> spaterer Dienstzugri durchgefuhrt wird.<br />
Attributwerte fur Dienstangebotseigenschaften (engl. service o er properties),<br />
mit denen der im Trader verwaltete Dienstangebotse<strong>in</strong>trag naher<br />
beschrieben wird, so da beispielweise das Entstehungsdatum oder auch<br />
e<strong>in</strong> mogliches Ablaufdatum des Dienstangebots imTrader verwaltet werden<br />
kann. Diese konnen zu statistischen Zwecken oder auch zur Steuerung<br />
Trader{<strong>in</strong>terner Verwaltungsvorgange genutzt werden.<br />
Die genannten Dienstangebotsbestandteile bilden e<strong>in</strong>schlie lich e<strong>in</strong>er zusatzlichen<br />
Exporteurskennung und e<strong>in</strong>em Kontext, <strong>in</strong> den das Dienstangebot im<br />
Dienstangebotsraum e<strong>in</strong>geordnet werden soll, die wesentlichen von der Export{<br />
Operation geforderten E<strong>in</strong>gabeparameter.<br />
Zur Reprasentation und Darstellung der Diensttypbeschreibung existieren pr<strong>in</strong>zipiell<br />
drei verschiedene Moglichkeiten, die auf dem <strong>in</strong> Abschnitt 3.2.2.4 vorgestellten<br />
Konzept der Typbezeichner beruhen 9 :<br />
9 Insofern stellt dieseForm von Diensttypreprasentation im S<strong>in</strong>ne des <strong>in</strong> Abschnitt 2.1vorgestellten<br />
Begri s nur e<strong>in</strong>e sehr e<strong>in</strong>fache Moglichkeit zur Reprasentation von Typbeschreibungen<br />
dar, da auf deren eigentliche Bestandteile nur verwiesen wird.
82 Zugang zu Diensten <strong>in</strong> heterogenen Umgebungen<br />
1. Die e<strong>in</strong>fachste Form ist die Angabe e<strong>in</strong>es Diensttypbezeichners, der auf die<br />
dazugehorige Diensttypbeschreibung imTypmanager verweist.<br />
2. Die zweite Moglichkeit ist die Aufsplittung der Bestandteile e<strong>in</strong>es Diensttyps<br />
<strong>in</strong> e<strong>in</strong>en Schnittstellentypbezeichner und e<strong>in</strong>eMenge an Dienstattributtypbezeichnern.<br />
3. E<strong>in</strong>edritteVarianteistdiedetaillierte Darstellungvon Diensttypen <strong>in</strong> Form<br />
e<strong>in</strong>es Signaturbezeichners und e<strong>in</strong>er Menge von Dienstattributtypbezeichnern.<br />
Der Signaturbezeichner verweist auf e<strong>in</strong>en E<strong>in</strong>trag im Typmanager,<br />
der die Beschreibung der Operationssignaturen und gegebenfalls der semantischen<br />
Beschreibung der Schnittstelle und der Operationen be<strong>in</strong>haltet<br />
(siehe zumVergleich auch Abbildung 3.6).<br />
Insgesamt ergibt sich unter Berucksichtigung aller <strong>in</strong>nerhalb e<strong>in</strong>es Dienstangebotes<br />
vorhandenen Informationen das <strong>in</strong> Abbildung 3.21 gezeigte Gesamtbild,<br />
welches die <strong>in</strong> Abbildung 3.18 gezeigte Grundstruktur des Trad<strong>in</strong>gs weiter verfe<strong>in</strong>ert.<br />
Typmanager<br />
SO<br />
Trader<br />
ImportOffer<br />
Importeur<br />
Dienstangebotsauswertung<br />
ExportOffer<br />
Dienstaufruf<br />
S<br />
O<br />
E<br />
I<br />
Exporteur<br />
Dienstaufruf-<br />
Schnittstelle<br />
Abbildung 3.21: Rolle des Dienstangebots beim Trad<strong>in</strong>g<br />
Das Dienstangebot (SO) bzw. die dort enthaltenen Informationen verwaltet der<br />
Trader <strong>in</strong> se<strong>in</strong>er Dienstangebotsverwaltung. Dort werden die Verweise auf die<br />
Dienstaufrufschnittstelle und die Dienstangebotsauswertungsschnittstelle (SOEI)<br />
gespeichert. In dem dargestellten Fall wird die Dienstangebotsauswertungsschnittstelle<br />
vom Exporteur selbst realisiert. Sie kann alternativ aber auch durch<br />
andere Komponenten, beispielsweise e<strong>in</strong>em Attributmanagementsystem [Spr96],<br />
bereitgestellt werden. Weiterh<strong>in</strong> werden <strong>in</strong> der Dienstangebotsverwaltung auch<br />
die Diensttyp<strong>in</strong>formationen gespeichert, die <strong>in</strong> e<strong>in</strong>er der drei oben genannten Varianten<br />
beschrieben se<strong>in</strong> konnen und imwesentlichen aus Typbezeichnern bestehen,<br />
die auf die entsprechenden Typbeschreibungen im Typmanager verweisen.<br />
Die operationale Schnittstelle des Typmanagers wird jedoch durch das Trader-
3.3 Vermittlung und Verwaltung von Dienstangeboten 83<br />
standarddokument nicht festgelegt. 10 Dieses tri t auchauf die Art undWeise der<br />
Benutzung der Dienstangebotsauswertungsschnittstelle, der Dienstangebotsverwaltungoder<br />
des Typmanagers zu, die den jeweiligen Trader{Implementierungen<br />
uberlassen ist.<br />
3.3.2.3 Dienstangebotsauswahl<br />
Mit dem Aufruf der ImportO er{Operation durch e<strong>in</strong>en Importeur wird e<strong>in</strong>e<br />
Dienstanfrage (engl. service request) an den angesprochenen Trader gestellt (siehe<br />
auch Abbildung 3.21). Die Dienstanfrage setzt sich aus den folgenden E<strong>in</strong>zelteilen<br />
zusammen:<br />
Importeurskennung (engl. client identi cation) fur Zwecke der Authentisierung<br />
und Autorisierung<br />
E<strong>in</strong> oder mehrere Kontextnamen zur E<strong>in</strong>schrankung der Dienstangebotssuche<br />
<strong>in</strong>der Dienstangebotsverwaltung des Traders<br />
Diensttypbeschreibung zur Bezeichnung des gewunschten Diensttyps<br />
Suchvorschriften (engl. importer policies) zur Steuerung des Dienstauswahlmechanismus<br />
des Traders, beispielsweise zur Festlegung e<strong>in</strong>er maximalen<br />
Suchzeit oder e<strong>in</strong>er bestimmten Suchstrategie<br />
Geforderte Auswahlkriterien (engl. match<strong>in</strong>g constra<strong>in</strong>ts), die <strong>in</strong> Form von<br />
geschachtelten logischen Ausdrucken uber Werten von Dienstattributen,<br />
beispielsweise costPerPage < 1.0 AND queueLength < 4 bei e<strong>in</strong>er Anfrage<br />
nach e<strong>in</strong>em Druckdienstangebot, formuliert werden.<br />
Bevorzugte Auswahlkriterien (engl. selection preferences), die h<strong>in</strong>ausgehend<br />
uber die geforderten Auswahlkriterien e<strong>in</strong>e weitere Optimierung<br />
der Dienstauswahl erlauben. Derartige Optimierungskriterien werden<br />
ebenfalls <strong>in</strong> Form geschachtelter logischer Ausdrucke, beispielsweise<br />
MAX(paperQuality) AND MIN(queueLength), ubergeben.<br />
Gewunschte Dienstattribute (engl. service properties of <strong>in</strong>terest), fur die<br />
aktuelle Attributwerte zuruckgegeben werden sollen.<br />
Gewunschte Dienstangebotseigenschaften (engl. service o er properties of<br />
<strong>in</strong>terest), fur die aktuelle Werte zuruckgegeben werden sollen.<br />
Mit Hilfe dieser von e<strong>in</strong>em Importeur gemachten Angaben ermittelt der Trader<br />
passende Dienstangebote, wobei der Vorgang der Dienstangebotsauswahl durch<br />
das Trader{Standarddokument nicht spezi ziert ist.<br />
E<strong>in</strong>e mogliche, durch die Bestandteile e<strong>in</strong>es Dienstangebots naheliegende Realisierungsvariante<br />
ist die der gesta elten Auswertung [Kel93]. Grundlegende Idee<br />
10 Zur Zeit be ndet sich dieStandardisierung e<strong>in</strong>er Typrepository{Funktion [ODP95c, ISO95]<br />
<strong>in</strong> Entwicklung, die auf den <strong>in</strong> Abschnitt 3.2 dargestellten Typverwaltungskonzepten basiert.
84 Zugang zu Diensten <strong>in</strong> heterogenen Umgebungen<br />
dieses Auswertungspr<strong>in</strong>zips ist die Unterteilung des Dienstauswahlvorgangs <strong>in</strong><br />
verschiedene Auswertungsschritte. Ziel ist hierbei die Optimierung der Auswahl<br />
des am besten\ geeigneten Dienstangebotes zu e<strong>in</strong>er gegebenen Dienstanfrage.<br />
"<br />
Optimierungsaspekte s<strong>in</strong>dvor allem die zeitliche Dauer der Auswahl und die<br />
" Qualitat\ desgefundenen Dienstangebots, die sich anhand der Dienstattribute,<br />
<strong>in</strong>sbesondere der dynamischen, anwendungsspezi sch fur jeden Diensttyp festlegen<br />
la t. Abbildung 3.22 verdeutlicht das Grundpr<strong>in</strong>zip der gesta elten Auswertung.<br />
Nicht dargestellt s<strong>in</strong>ddie vom Importeur vorgebbaren Suchvorschriften,<br />
die den Dienstauswahlproze <strong>in</strong> se<strong>in</strong>er Gesamtheit bee<strong>in</strong> u en konnen.<br />
Dienstanfrage<br />
Diensttyp Kontexte<br />
Suche<br />
konformer<br />
Diensttypen<br />
Auswahl<br />
diensttypkonformer<br />
Dienstangebote<br />
Geforderte<br />
Auswahlkriterien<br />
Auswertung<br />
statischer<br />
Dienstattribute<br />
Auswertung<br />
dynamischer<br />
Dienstattribute<br />
Abbildung 3.22: Pr<strong>in</strong>zip der gesta elten Auswertung<br />
Optimierungskriterien<br />
Festlegung<br />
e<strong>in</strong>er qualitativen<br />
Ordnung<br />
In e<strong>in</strong>em ersten Schritt wird mit Hilfe des dem Trader zugeordneten Typmanagers<br />
die Menge aller diensttypkonformen Diensttypen ermittelt. Diese dienen anschlie<br />
end zur Suche nach passenden Dienstangeboten im Dienstangebotsraum,<br />
wobei die Suche durch die bei der Dienstanfrage angebbaren Kontexte e<strong>in</strong>geschrankt<br />
werden kann. Anschlie end wertet der Trader die statischen und dynamischen<br />
Dienstattributeder gefundenen Dienstangebotedanachaus, ob diese den<br />
geforderten Auswahlkriterien entsprechen. Weiterh<strong>in</strong> werden abschlie end gegebenfalls<br />
die Optimierungskriterien ausgewertet, die die nachgebliebenen Dienstangebote<br />
nach den gewunschten Qualitatskriterien ordnen.<br />
Durch die Berucksichtung dynamischer, sich hau g verandernder Dienstattribute,<br />
beispielsweise der Warteschlangenlange bei e<strong>in</strong>em Druckdienstanbieter, ist die<br />
Dienstauswahl zu e<strong>in</strong>er gegebenen Dienstanfrage nicht immer identisch, so da e<strong>in</strong>em<br />
Importeur zumeist unterschiedliche Dienstangebote vermittelt werden. Hier<br />
ergibt sich auch der wesentliche Unterschied zu attributierten Namensdiensten,<br />
die e<strong>in</strong>e Dienstsucheausschlie lich aufgrundstatischer Kriterien durchfuhren und<br />
somit immer dieselben Dienstangebote zuruckliefern. Der Unterschied von Tradern<br />
zu Namensdiensten wird weiterh<strong>in</strong> auchdadurchdeutlich, da beim Trad<strong>in</strong>g<br />
verschiedene Dienstauswahlstrategien zum E<strong>in</strong>satz kommen konnen. Beispiele
3.3 Vermittlung und Verwaltung von Dienstangeboten 85<br />
hierfur s<strong>in</strong>d die <strong>in</strong> [TWW92, WT90] genannte zufallige Wahl, bei der aus e<strong>in</strong>er<br />
Menge geeigneter Dienstangebote e<strong>in</strong> e<strong>in</strong>ziges zufallig ausgewahlt wird,oder die<br />
beste Wahl, bei der <strong>in</strong>sbesondere die dynamischen Dienstattribute herangezogen<br />
werden.<br />
E<strong>in</strong> grundsatzliches Problem der Nutzung dynamischer Dienstattribute ist die<br />
Aktualitat der bei der Dienstauswahl genutzten Attributwerte. Da sie sich unter<br />
Umstanden hau g andern konnen, ist die Aktualitat nur unter bestimmten e<strong>in</strong>schrankenden<br />
Kriterien, den sogenannten Aktualitatspradikaten [Kov92], gewahrleistet.<br />
E<strong>in</strong> Beispiel e<strong>in</strong>es derartigen Aktualitatspradikates ist die sogenannte<br />
Anderungsbed<strong>in</strong>gung, die die obere Grenze nicht berucksichtigter Anderungen<br />
e<strong>in</strong>es Dienstattributes festlegt. Da e<strong>in</strong> Zugri auf dynamische Dienstattribute <strong>in</strong><br />
der Regel mit erhohtem Aufwand verbunden ist, kann hiermit die Anzahl notwendiger<br />
Zugri e verr<strong>in</strong>gert werden, wobei jedoch der Verlust hochstmoglicher<br />
Aktualitat ( " Beste{Moglichkeit{Bed<strong>in</strong>gung\) akzeptiert werden mu . Welches<br />
Aktualitatspradikat beim Trad<strong>in</strong>gverwendet wird, hangt unter anderem von den<br />
<strong>in</strong>ternen Verwaltungsvorschriften e<strong>in</strong>es Traders undden vorhandenen systemtechnischen<br />
Unterstutzungsmechanismen zum Zugri auf dynamische Dienstattribute<br />
ab. Die oben genannte, vom ODP Trader{Standarddokument vorgeschlagene<br />
Dienstangebotsauswertungsschnittstelle bietet hierfur e<strong>in</strong>e Moglichkeit der Realisierung<br />
e<strong>in</strong>er standardisierten Zugri sschnittstelle. E<strong>in</strong>e konkrete Realisierung<br />
unter Berucksichtigunge<strong>in</strong>es auf Aktualitatspradikaten basierenden Attributmanagementsystems<br />
[Spr96] zum Zugri auf Dienstattribute wird im Zusammenhang<br />
mit dem TRADEr <strong>in</strong> Abschnitt 5.2.2.2 vorgestellt.<br />
3.3.3 Verteilte Dienstangebotsvermittlung<br />
Aufgrund der Gro e o ener, moglicherweise weltweit verteilter Dienstemarkte<br />
ist die Annahme e<strong>in</strong>er zentralisierten Dienstvermittlung aus Grunden der Skalierbarkeit<br />
unrealistisch und auch angesichts der Existenz unterschiedlicher Verwaltungsdomanen<br />
<strong>in</strong> dieser Form nicht durchfuhrbar. Ebenso wie das Diensttypmanagement<br />
ist generell davon auszugehen, da auch die Dienstvermittlung<br />
im allgeme<strong>in</strong>en <strong>in</strong> der lokalen Verantwortlichkeit e<strong>in</strong>er bestimmten Verwaltungsdomane<br />
liegt, so da jede Domane m<strong>in</strong>destens e<strong>in</strong>en eigenen Trader zur Verwaltung<br />
und Vermittlung der dort vorhandenen Dienstangebote besitzt, wie es<br />
bereits amAnfang dieses Kapitels <strong>in</strong> Abbildung 3.2 angedeutet wurde.<br />
Als Konsequenz der Autonomie der Verwaltungsdomanen ergibt sich ohnee<strong>in</strong>e<br />
domanenubergreifende Zusammenarbeit der Trader e<strong>in</strong>e lokale E<strong>in</strong>geschranktheit<br />
der Dienstvermittlung, die sich dar<strong>in</strong> au ert, da dort verwaltete Dienstangebote<br />
nur <strong>in</strong>nerhalb e<strong>in</strong>er Domane zuganglich s<strong>in</strong>d. Dieses betri t gleichermaen<br />
die Importeure, die Dienstanfragen an den lokalen Trader stellen, und die<br />
Exporteure, die ihre Dienste uber den lokalen Trader anbieten.Umauch Dienstangebote<br />
anderer Verwaltungsdomanen nutzen bzw. dort anbieten zu konnen,<br />
ergeben sich fur beide pr<strong>in</strong>zipiell zwei Moglichkeiten.<br />
Zum e<strong>in</strong>en konnen sie sich explizit an Trader anderer Verwaltungsdomanen wenden,<br />
wodurch sichdas primare Problem der Lokalisierung ergibt. Da dieses e<strong>in</strong>
86 Zugang zu Diensten <strong>in</strong> heterogenen Umgebungen<br />
allgeme<strong>in</strong>es Wissen uber das Vorhandense<strong>in</strong> und den genauen Ort anderer Tradern<br />
erfordert, ersche<strong>in</strong>t dieser Ansatz aus Grunden der Komplexitat und auch<br />
aufgrund der Gro e verteilter Dienstemarkte und der dadurch zuerwartenden<br />
Unubersichtlichkeit <strong>in</strong> der Regel jedoch als nicht praktikabel. Zusatzlich konnen<br />
auch domanen<strong>in</strong>terne Verwaltungsvorschriften e<strong>in</strong>en direkten Zugri externer<br />
Importeure und Exporteure auf den dortigen Trader verh<strong>in</strong>dern.<br />
Als e<strong>in</strong> geeigneter Losungsansatz ergibt sich die Zusammenarbeit der <strong>in</strong> den Verwaltungsdomanen<br />
vorhandenen Trader. In diesem Fall erfolgt der Zugri auf die<br />
Dienstangebote der Trader anderer Domanen durch den lokalen Trader selbst,<br />
so da der Vorgang der Dienstvermittlung weitgehend verborgen werden kann.<br />
Fur den Importeur bedeutet dieses, da ihm nun trotz der ausschlie lichen Nutzung<br />
des lokalen Traders auch Dienstangebotevon Tradern anderer Verwaltungsdomanen<br />
vermittelt werden konnen, ohne da er uber die Kooperation Kenntnis<br />
besitzen mu . Aus der Sicht e<strong>in</strong>es Exporteurs bedeutet dies gleichzeitig e<strong>in</strong>e Erweiterung<br />
se<strong>in</strong>er Sichtbarkeit, so da nun auch Importeure anderer Domanen<br />
se<strong>in</strong> Dienstangebot nutzen konnen.<br />
3.3.3.1 Kooperationsformen von Tradern<br />
Im folgenden werden als zwei Grundformen domanenubergreifender Trader{<br />
Kooperationen die sogenannte <strong>in</strong>direkte und direkte Kooperation vorgestellt (siehe<br />
zumVergleich auch [Mul96, MMaTT96]). Ausgangspunkt fur diese Unterscheidung<br />
bildet die <strong>in</strong> Abbildung 3.23 dargestellte Struktur.<br />
Typ-<br />
Manager 1<br />
Trader 1<br />
Typ-<br />
Manager 2<br />
Trader 2<br />
import(...,ServiceTypeId_Y,...) export(...,ServiceTypeId_X,...)<br />
Importeur Exporteur<br />
Abbildung 3.23: Komponenten e<strong>in</strong>er Trader{Kooperation<br />
Sie zeigt die potentiell an e<strong>in</strong>er Trader{Kooperation beteiligten Systemkomponenten.<br />
Im e<strong>in</strong>zelnen s<strong>in</strong>d dieses die Trader und dieihnen zugeordneten Dienstangebotsverwaltungen<br />
und Typmanager. Die Dienstangebotsverwaltung ist hierbei<br />
durch e<strong>in</strong> Symbol dargestellt, die je nach beabsichtigter Kooperationsform
3.3 Vermittlung und Verwaltung von Dienstangeboten 87<br />
grundsatzlichsowohl durch die Trader selbst oder durche<strong>in</strong>e externeKomponente<br />
bereitgestellt werden kann. Die gestrichelte L<strong>in</strong>ie <strong>in</strong> der Mitte der Abbildung<br />
verdeutlicht die bereits schon am Anfang dieses Kapitels beschriebene Heterogenitatsgrenze<br />
zwischen den Verwaltungsdomanen. Hierbei werden im folgenden<br />
vor allem die adm<strong>in</strong>istrativen Fragestellungen der dort auftretenden Heterogenitatsproblemeerortert,<br />
die das Verstandnis und den Austauschvon Typ<strong>in</strong>formationen<br />
zwischen den Tradern der kooperierenden Verwaltungsdomanen betre en.<br />
Aus diesem Grund spielt <strong>in</strong>sbesondere das <strong>in</strong> der Abbildung dargestellte Typmanagement<br />
e<strong>in</strong>e zur Unterstutzung von Trader{Kooperationen grundlegende<br />
Komponente, mit deren Hilfe trotz der adm<strong>in</strong>istrativen Heterogenitatsprobleme<br />
zwischen zwei Verwaltungsdomanen die Interoperabilitat auf der Verarbeitungsebene<br />
gewahrleistet werden kann (siehe Abschnitte 3.1.1 und 3.2). Dieses gilt<br />
auch fur die Uberw<strong>in</strong>dung der technischen Heterogenitatsprobleme, auf die Abschnitt<br />
3.4 separat e<strong>in</strong>geht.<br />
E<strong>in</strong>e hier bereits sichtbare Problematik der <strong>verteilten</strong> Dienstvermittlung ist die<br />
Gultigkeit von Typbezeichnern, die bereits <strong>in</strong>Abschnitt 3.2.3.1 im Rahmen des<br />
<strong>verteilten</strong> Typmangements angesprochen wurde. Da Typbezeichner nur jeweils<br />
<strong>in</strong>nerhalb e<strong>in</strong>er Verwaltungsdomanefur e<strong>in</strong>en bestimmten Typmanager e<strong>in</strong>e Bedeutung<br />
besitzen, mussen dementsprechend Vere<strong>in</strong>barungen getro en werden,<br />
auf deren Grundlage e<strong>in</strong> geme<strong>in</strong>sames Typverstandnis erreicht wird. Fur die<br />
weitere Darstellung wirddavon ausgegangen, da der durch ServiceTypeId X<br />
bezeichnete Diensttyp konform zu dem durch ServiceTypeId Y bezeichneten<br />
ist, so da als Resultat e<strong>in</strong>er moglichen Kooperation beider Trader das vom Exporteur<br />
bei Trader 2 registrierte Dienstangebot dem Importeur bei Trader 1<br />
vermittelt werden kann.<br />
Indirekte Kooperation E<strong>in</strong>e Variante e<strong>in</strong>er Trader{Kooperation bildet die<br />
<strong>in</strong> Abbildung 3.24 dargestellte <strong>in</strong>direkte Kooperation.<br />
Trader 1<br />
Typ-<br />
Manager<br />
Trader 2<br />
import(...,ServiceTypeId_Y,...) export(...,ServiceTypeId_X,...)<br />
Importeur Exporteur<br />
Abbildung 3.24: Indirekte Trader{Kooperation
88 Zugang zu Diensten <strong>in</strong> heterogenen Umgebungen<br />
Hauptkennzeichen dieser Kooperationsform ist die Nutzung geme<strong>in</strong>samer<br />
Dienstangebotsraume, auf die von den beteiligten Tradern gleicherma en lesend<br />
und schreibend zugegri en werden kann und uber die sie <strong>in</strong>direkt kooperieren.<br />
Als direkte Konsequenz dieser Indirektion ergibt sich, da nur die Nutzung e<strong>in</strong>es<br />
standardisierten Ablageformats fur Dienstangebote vere<strong>in</strong>bart werden mu , so<br />
da diese auf e<strong>in</strong>heitliche Art und Weise im Dienstangebotsraum gelesen und<br />
gespeichert werden konnen. Da ke<strong>in</strong>e direkte Interaktion zwischen den Tradern<br />
selbst statt ndet, konnen diese <strong>in</strong> den sonstigen Aspekten der Implementierung<br />
vone<strong>in</strong>ander di erieren. So ist es nicht zw<strong>in</strong>gend notwendig, sich bei der<br />
Realisierung der nach au en angebotenen operationalen Schnittstellen an e<strong>in</strong>en<br />
geme<strong>in</strong>samen Schnittstellenstandard zu halten, wie er beispielsweise durch das<br />
ODP{basierte Trad<strong>in</strong>g de niert wird.<br />
E<strong>in</strong> weiterer notwendiger Gegenstand der Standardisierung ist die Festlegung<br />
e<strong>in</strong>es e<strong>in</strong>heitlichen Diensttypverstandnisses, da ansonsten die im geme<strong>in</strong>samen<br />
Dienstangebotsraum abgelegten Dienstangebote nicht s<strong>in</strong>nvoll von den beteiligten<br />
Tradern genutzt werden konnen. E<strong>in</strong> moglicher Losungsansatz ist <strong>in</strong> der<br />
Abbildung durch die Nutzung e<strong>in</strong>es geme<strong>in</strong>samen Typmanagers dargestellt. Bezogen<br />
auf die e<strong>in</strong>leitend angefuhrte Problematik der Gultigkeit von Typbezeichnern<br />
bedeutet dieses, da <strong>in</strong> diesem Fall alle Trader bzw. Importeure und Exporteure<br />
dieselben Typbezeichner benutzen, wodurch implizit e<strong>in</strong> e<strong>in</strong>heitliches<br />
Typverstandnis gewahrleistet ist.<br />
Aufgrund der beiden e<strong>in</strong>schrankenden Voraussetzungen eignet sich der Ansatz<br />
der <strong>in</strong>direkten Kooperation vor allem fur die Kooperation von Tradern <strong>in</strong>nerhalb<br />
e<strong>in</strong>er Verwaltungsdomane. Hierdurch konnen beispielsweise aus Grunden<br />
der Lastverteilung auf e<strong>in</strong>fache Art und Weise neue Trader h<strong>in</strong>zugefugt werden,<br />
ohne da weitgehende adm<strong>in</strong>istrative Ma nahmen notwendig s<strong>in</strong>d. Der Ansatz<br />
ist jedochauchfur zwei verschiedeneVerwaltungsdomanen <strong>in</strong>teressant, wenn von<br />
vornhere<strong>in</strong> die mogliche Anzahl von Diensttypen, zu denen konkrete Dienstangebote<br />
vermittelbar s<strong>in</strong>d, e<strong>in</strong>geschrankt ist. In diesem Fall ist der vorherige Austausch<br />
der geme<strong>in</strong>sam genutzten Typbezeichner s<strong>in</strong>nvoll, so da auf diese Weise<br />
e<strong>in</strong> e<strong>in</strong>heitliches Typverstandnis erreicht wird. In diesem Zusammenhangmussen<br />
auch mogliche Sicherheitsfragen geklart werden, die beispielsweise die Speicherung<br />
von Dienstangeboten <strong>in</strong> bestimmten Kontexten oder aber das Loschen von<br />
Dienstangeboten betre en.<br />
E<strong>in</strong> moglicher Losungsansatz fur die geme<strong>in</strong>same Ablage von Dienstangeboten<br />
s<strong>in</strong>d die <strong>in</strong> Abschnitt 3.3.1.1 vorgestellten Namensdienste, die sich <strong>in</strong>sbesondere<br />
durch dieMoglichkeit der Verwaltung von Kontexten auszeichnen, <strong>in</strong><br />
denen Dienstangebote strukturiert verwaltet werden konnen. Vor allem X.500<br />
[Rad94] bietet hierfur e<strong>in</strong>e geeignete Verwaltungs<strong>in</strong>frastruktur, die auch e<strong>in</strong>e<br />
globale Verteilung von Dienstangebots<strong>in</strong>formationen und somit e<strong>in</strong>e <strong>in</strong>direkte<br />
Trader{Kooperation uber gro e Distanzen h<strong>in</strong>weg erlaubt. Architekturelle<br />
Grundkonzepte fur X.500{basierteTrader{Kooperationen nden sich <strong>in</strong> [AA91],<br />
[PM93], [RH95] und [WB95], wobei die letztgenannte Arbeitdas im Trader{<br />
Standarddokument [ODP94b] festgelegte X.500{Speicherformatfur Dienstangebote<br />
verwendet. E<strong>in</strong> alternativer X.500{basierter Ansatz ndet sich auch <strong>in</strong>dem
3.3 Vermittlung und Verwaltung von Dienstangeboten 89<br />
<strong>in</strong> dieser Arbeit entwickelten und realisierten TRADEr, der <strong>in</strong> Abschnitt 5.2.2<br />
beschrieben wird.<br />
Alternativ zu globalen Namensdiensten eignet sich fur eher lokal zusammenhangende<br />
Verwaltungsdomanen auch der E<strong>in</strong>satz verteilter Datenbanken,<br />
wie er beispielsweise <strong>in</strong> [CR91] beschrieben ist.<br />
Direkte Kooperation Wesentlicher Unterschied zur <strong>in</strong>direkten, auf der Nutzung<br />
geme<strong>in</strong>samer Dienstangebotsraume basierenden Kooperationsform ist die<br />
direkte Interaktion der Trader untere<strong>in</strong>ander. Damit diese Kooperation geordnet<br />
ablaufen kann, ist die De nition e<strong>in</strong>es standardisierten Kooperationsprotokolls<br />
erforderlich, das sowohl die fur die Kooperation relevanten operationalen Aufrufschnittstellen<br />
der Trader und ihrer Semantik als auch die Art und Weise festlegt,<br />
wie der Kooperationsvorgang genau durchzufuhren ist.<br />
Wird hierbei zunachst wie bei der oben vorgestellten <strong>in</strong>direkten Kooperationsform<br />
von e<strong>in</strong>em geme<strong>in</strong>samen Typverstandnis ausgegangen, ergibt sich die <strong>in</strong><br />
Abbildung 3.25 gezeigte Struktur, wobei beide Trader wiederum auf e<strong>in</strong>en geme<strong>in</strong>samen<br />
Typmanager zugreifen.<br />
Trader 1<br />
Typ-<br />
Manager<br />
Trader 2<br />
import(...,ServiceTypeId_Y,...) export(...,ServiceTypeId_X,...)<br />
Importeur Exporteur<br />
Abbildung 3.25: Protokollgesteuerte, direkte Trader{Kooperation<br />
Anstelle der Nutzunge<strong>in</strong>es geme<strong>in</strong>samen Dienstangebotsraumes kooperieren Trader<br />
1 und 2 unmittelbar mite<strong>in</strong>ander, um Dienstangebote gegenseitig auszutauschen.<br />
Als Konsequenz ergibt sich, da jeder Trader uber se<strong>in</strong>e eigene Dienstangebotsverwaltung<br />
verfugen kann und somit auch e<strong>in</strong> geme<strong>in</strong>sames Ablageformat<br />
fur Dienstangebote nicht mehr zw<strong>in</strong>gend verwendet werden mu .<br />
Wie der direkte Austausch von Dienstangebots<strong>in</strong>formationen zwischen den kooperierenden<br />
Tradern konkret ablauft, hangt von dem gewahlten Kooperationsprotokoll<br />
ab. Generell kann hierbei e<strong>in</strong>e Import{ oder e<strong>in</strong>e Export{orientierte<br />
Sichtweise zugrunde gelegtwerden. Im ersten Fall agiert der Trader 1 als Impor-
90 Zugang zu Diensten <strong>in</strong> heterogenen Umgebungen<br />
teur des Traders 2, anden er die ursprunglich bei ihm gestellte Dienstanfrage<br />
weitergibt. Im zweiten Fall exportiert Trader 2 die bei ihm registrierten Dienstangebote<br />
automatisch bei Trader 1, der sie dort <strong>in</strong> se<strong>in</strong>en Dienstangebotsraum<br />
e<strong>in</strong>fugt und den Importeuren se<strong>in</strong>er Verwaltungsdomane zur Verfugung stellt.<br />
Trader 1 kann nun se<strong>in</strong>erseits ebenfalls das Dienstangebot an andere ihm bekannte<br />
Trader weitergeben. Dies gilt im Pr<strong>in</strong>zip auch fur die Dienstanfrage im<br />
Import{orientierten Fall. E<strong>in</strong> sich aus der Export{orientierten Variante ergebender<br />
Nachteil ist jedoch, da beim Zuruckziehen e<strong>in</strong>es Dienstangebots wiederum<br />
samtliche Trader kontaktiert werden mussen, welches angesichts e<strong>in</strong>er moglichen<br />
Vielzahl beteiligter Trader <strong>in</strong> der Regel recht aufwendig ist. Desweiteren<br />
ist e<strong>in</strong>e explizite Verwaltungsfunktion erforderlich, die Buch uber die an andere<br />
Trader exportierten Dienstangebote fuhrt, damit diese spater ordnungsgema<br />
zuruckgezogen werden konnen. Demgegenuber steht beider Import{orientierten<br />
Vorgehensweise der Verwaltungsaufwand, der fur das spatere E<strong>in</strong>sammeln der<br />
weitergereichten Dienstanfragen notwendig ist.<br />
3.3.3.2 Aufbau direkter Trader{Kooperationen<br />
Damit e<strong>in</strong>e direkteTrader{Kooperation zwischen zwei Tradern statt nden kann,<br />
mu vorher e<strong>in</strong>e Verknupfung zwischen ihnen aufgebaut werden. Das ODP{<br />
Standarddokument [ODP94b]de niert hierzu L<strong>in</strong>ks, die unidirektionale Verweise<br />
auf andere Trader darstellen. Sie werden <strong>in</strong> jedem Trader <strong>in</strong> se<strong>in</strong>em L<strong>in</strong>k{Raum<br />
(engl. trader l<strong>in</strong>k space) lokal verwaltet und be<strong>in</strong>halten unter anderem die B<strong>in</strong>dungs<strong>in</strong>formationen<br />
zum verknupften Trader. E<strong>in</strong> L<strong>in</strong>k ist weiterh<strong>in</strong> beschrieben<br />
durch sogenannte L<strong>in</strong>k{Eigenschaften (engl. l<strong>in</strong>k properties), mit denen bestimmte<br />
Informationen, beispielsweise uber den Typmanager des anderen Traders, abgelegt<br />
werden konnen. KonkreteAuspragungen von L<strong>in</strong>k{Eigenschaften s<strong>in</strong>d zur<br />
Zeit jedoch nicht explizit im Standardddokument festgelegt. Nach Aufbau e<strong>in</strong>es<br />
L<strong>in</strong>ks kann der damit bezeichnete Trader von Seiten des diesen L<strong>in</strong>k verwaltenden<br />
Traders im Rahmen e<strong>in</strong>er Trader{Kooperation genutzt werden. Hierbei<br />
tritt der <strong>in</strong>itiierende Trader dem im L<strong>in</strong>k bezeichneten Trader <strong>in</strong> der Rolle e<strong>in</strong>es<br />
Importeurs gegenuber, <strong>in</strong>dem er dort die entsprechende Operation importOffer<br />
aufruft. Diese Import{orientierte 11 Sichtweise ist <strong>in</strong> Abbildung 3.26verdeutlicht.<br />
Der gestrichelte Pfeil bezeichnet e<strong>in</strong>en von Trader A ausgehenden L<strong>in</strong>k zu Trader<br />
B. Uber diesen L<strong>in</strong>k wird die vom Importeur an Trader A gestellte Dienstanfrage<br />
zu Trader B weitergegeben. Anschlie end erhalt Trader A die gewunschten<br />
Dienstangebote zuruck und ubergibt sie letztendlich unter H<strong>in</strong>zufugen der von<br />
ihm selbst <strong>in</strong> se<strong>in</strong>em Angebotsraum gefundenen Dienstangebote anden Importeur.<br />
Bed<strong>in</strong>gt durch die Dezentralisierung der L<strong>in</strong>k{Verwaltung kann sich bei der Kooperation<br />
mehrerer Trader e<strong>in</strong> vermaschtes Netz ergeben, wie es beispielsweise<br />
<strong>in</strong> Abbildung 3.27 verdeutlicht ist. Das entstandene Netz wird auch als Trad<strong>in</strong>g{<br />
Graph bezeichnet. L<strong>in</strong>ks kennzeichnen e<strong>in</strong>en moglichen Weg im Trad<strong>in</strong>g{Graph,<br />
11 Pr<strong>in</strong>zipiell la t sich mit L<strong>in</strong>ks auch e<strong>in</strong> Export{orientierter Ansatz realisieren. Dieser ndet<br />
im Trader{Standarddokument jedoch ke<strong>in</strong>e Erwahnung.
3.3 Vermittlung und Verwaltung von Dienstangeboten 91<br />
L<strong>in</strong>k<br />
Trader A Trader B<br />
ImportOffer<br />
ImportOffer<br />
Importeur<br />
Abbildung 3.26: Verknupfung von Tradern durch L<strong>in</strong>ks<br />
auf dem e<strong>in</strong>e ane<strong>in</strong>en Trader gestellte Dienstanfrage an andere Trader weitergereicht<br />
werden kann. Ob und auf welche Art und Weise L<strong>in</strong>ks bei der Dienstangebotsvermittlungdurch<br />
e<strong>in</strong>en Trader verwendet werden, hangt unter anderem von<br />
den jeweiligen Verwaltungsvorschriften des Traders selbst und <strong>in</strong>sbesondere auch<br />
von den durch den Importeur vorgegebenen Suchvorschriften ab. Beispielsweise<br />
kann hierdurch die moglicheSuchtiefe e<strong>in</strong>geschrankt werden, so da die <strong>in</strong> Abbildung<br />
3.27durch fett gezeichnete Pfeile angedeutete Dienstanfrage bei Trader B<br />
endet und nicht anTrader E weitergegeben wird. E<strong>in</strong> derartiges Vorgehen ist im<br />
Trader{Standarddokument jedoch nicht explizit spezi ziert, sondern den jeweiligen<br />
Trader{Implementierungen uberlassen. Dieses betri t grundsatzlich auch<br />
die Behandlung von moglicherweise vorhandenen Zyklen im Trad<strong>in</strong>g{Graphen.<br />
Ebenso das Weiterreichen e<strong>in</strong>er Dienstanfrage an mehrere Trader gleichzeitig<br />
(beispielsweise von Trader C an A und E) und das spatere Zusammenfugen der<br />
Teilergebnisse s<strong>in</strong>d durch dieTrader{Implementierungen selbst zu losen.<br />
ImportOffer<br />
Trader B<br />
ImportOffer<br />
Trader A<br />
Trader D<br />
Trader C<br />
Trader E<br />
Abbildung 3.27: Weiterreichen e<strong>in</strong>er Dienstanfrage
92 Zugang zu Diensten <strong>in</strong> heterogenen Umgebungen<br />
3.3.3.3 Kooperationsprotokolle<br />
Die Nutzung e<strong>in</strong>es geme<strong>in</strong>samen Typmanagers, wie es <strong>in</strong> der obigen Abbildung<br />
3.25 dargestellt wurde, ist <strong>in</strong> o enen <strong>verteilten</strong> Dienstemarkten aufgrund der adm<strong>in</strong>istrativen<br />
Heterogenitat der beteiligten Verwaltungsdomanen <strong>in</strong> der Regel<br />
nicht realisierbar. Im allgeme<strong>in</strong>en ist deshalb von der <strong>in</strong> Abbildung 3.28 gezeigten<br />
Struktur auszugehen, <strong>in</strong> der jede Verwaltungsdomane fur die Aspekte der<br />
Dienstvermittlung, des Typmanagements und der Dienstangebotsverwaltung eigenstandig<br />
und weitestgehend autonom verantwortlich ist.<br />
Typ-<br />
Manager 1<br />
Trader 1<br />
Typ-<br />
Manager 2<br />
Trader 2<br />
import(...,ServiceTypeId_Y,...) export(...,ServiceTypeId_X,...)<br />
Importeur Exporteur<br />
Abbildung 3.28: Typmanager{unterstutzte Trader{Kooperation<br />
E<strong>in</strong> Exporteur registriert se<strong>in</strong> Dienstangebot beim Trader 2 mit dem durch den<br />
Typbezeichner ServiceTypeId X bezeichneten Diensttyp ServiceType X, dessen<br />
dazugehorige Diensttypbeschreibung <strong>in</strong>Typmanager 2 verwaltet wird. Anschlie<br />
end stellt e<strong>in</strong> Dienstnutzer, der Importeur, e<strong>in</strong>e Dienstanfrage an den Trader<br />
1, wobei der gewunschte Diensttyp ServiceType Y durch ServiceTypeId Y<br />
bezeichnet ist, welcher se<strong>in</strong>erseits auf die entsprechende Diensttypbeschreibung<br />
<strong>in</strong> Typmanager 1 verweist. Dabei wird im folgenden davon ausgegangen, da<br />
beide Diensttypen ServiceType X und ServiceType Y entweder aquivalents<strong>in</strong>d<br />
oder ServiceType X konform zu ServiceType Y ist. Weiterh<strong>in</strong> besteht von Trader<br />
1 zu Trader 2 e<strong>in</strong> unidirektionaler L<strong>in</strong>k, wobei von e<strong>in</strong>er Import{orientierten<br />
Sichtausgegangenwird,<strong>in</strong>der Trader 1 wahrenddes Kooperationsvorganges vom<br />
Importeur an ihn gerichtete Dienstanfragen an Trader 2 stellvertretend weitergibt.<br />
Generell konnen <strong>in</strong> Anlehnung an [VBB95] mehrere verschiedene Moglichkeiten<br />
zur Durchfuhrung e<strong>in</strong>er derartigen Import{orientierten Trader{Kooperation unterschieden<br />
werden, wobei die hier zuletzt vorgestelltee<strong>in</strong>e Erweiterungder dort<br />
beschriebenen Varianten darstellt (siehe zumVergleich auch [CM95]):
3.3 Vermittlung und Verwaltung von Dienstangeboten 93<br />
Ignorante Vorgehensweise:<br />
In diesem Fall ignoriert Trader 1 die Heterogenitatsgrenze und verwendet<br />
bei der Dienstanfrage an Trader 2 den <strong>in</strong>nerhalb se<strong>in</strong>er Verwaltungsdomane<br />
gultigen Bezeichner ServiceTypeId Y. Damit Trader 2 diesen Bezeichner<br />
<strong>in</strong>nerhalb se<strong>in</strong>er eigenen Verwaltungsdomanenutzen kann, mu er diesen <strong>in</strong><br />
e<strong>in</strong>en dort gultigen Bezeichner ServiceTypeId X umwandeln. Erst danach<br />
kann er geeignete Dienstangebote ermitteln und gegebenfalls an Trader 1<br />
zuruckgeben.<br />
Bewu te Vorgehensweise:<br />
Im Unterschied zum ersten Fall ist Trader 1 das Vorhandense<strong>in</strong> e<strong>in</strong>er Heterogenitatsgrenze<br />
bewu t, soda er vor dem Weiterreichen der Dienstanfrage<br />
als erstes den <strong>in</strong>nerhalb se<strong>in</strong>er Verwaltungsdomane gultigen Bezeichner<br />
ServiceTypeId Y <strong>in</strong> e<strong>in</strong>en <strong>in</strong>nerhalb der Verwaltungsdomane von Trader<br />
2 gultigen Bezeichner ServiceTypeId X umwandelt.<br />
Standardisierte Vorgehensweise:<br />
E<strong>in</strong> dritte Moglichkeit ist die domanenubergreifendeStandardisierung von<br />
Typbezeichnern und Diensttypbeschreibungssprachen bzw. {reprasentationen.<br />
Standardisierte Typbezeichner besitzen hierbei uberall dieselbe Bedeutung,<br />
so da sie unmittelbar weitergegeben werden konnen. E<strong>in</strong>e Alternative<br />
zuden Typbezeichnern stellt die Verwendung e<strong>in</strong>er e<strong>in</strong>heitlichen<br />
Diensttypbeschreibung dar (siehe auch Abschnitt 2.1), mit denen Diensttypen<br />
auf e<strong>in</strong>heitliche Art und Weise beschrieben werden konnen. Hierdurch<br />
wirdesmoglich, Dienstbeschreibungen mit ihren samtlichen Beschreibungsbestandteilen<br />
zu ubergeben, die anschlie end ohne weitere Umwandlungen<br />
unmittelbar durchden domanen<strong>in</strong>ternen Typmanager <strong>in</strong>terpretiert<br />
werden konnen.<br />
Sowohl im ignoranten als auch im bewu ten Fall 12 mu der vom Importeur vorgegebene<br />
Typbezeichner ServiceTypeId Y <strong>in</strong> e<strong>in</strong>en vom Typmanager 2 <strong>in</strong>terpretierbaren<br />
umgewandelt werden. Dies geschieht generell <strong>in</strong> zwei Schritten:<br />
Der erste Schritt besteht <strong>in</strong>der Au osung bzw.Umwandlung des Typbezeichners<br />
ServiceTypeId Y <strong>in</strong> die dazugehorige Diensttypbeschreibung<br />
ServiceTypeDesc Y. Dieser wird von Typmanager 1 durchgefuhrt.<br />
Im zweiten Schritt dient diese dem Typmanager 2 zur Suche nach<br />
e<strong>in</strong>em <strong>in</strong> se<strong>in</strong>er Verwaltungsdomane konformen Diensttyp, <strong>in</strong> diesem<br />
Fall ServiceType X, so da letztendlich der Diensttypbezeichner<br />
ServiceTypeId X der entsprechenden Diensttypbeschreibung gefunden<br />
wird.<br />
In Abhangigkeit von den beteiligten Systemkomponenten kann dieser Umwandlungsvorgang<br />
<strong>in</strong>zwei unterschiedlichen Varianten erfolgen:<br />
12 Diese beiden Falle konnen im Englischen <strong>in</strong> Analogie zur Term<strong>in</strong>ologie bei der Netzwerkkommunikation<br />
pragnant auch als " Receiver makes it right\ bzw. " Sender makes it right\<br />
bezeichnet werden.
94 Zugang zu Diensten <strong>in</strong> heterogenen Umgebungen<br />
Trader{gesteuerte Kooperation:<br />
In dieser Variante s<strong>in</strong>d die Trader, im bewu ten Fall Trader 1 und<br />
im ignoranten Fall Trader 2, fur die Steuerung des Umwandlungsvorganges<br />
verantwortlich. Die Trader erhalten zunachst von Typmanager<br />
1 die zum Typbezeichner ServiceTypeId Y zugehorige Typbeschreibung<br />
ServiceTypeDesc Y, die anschlie end anTypmanager 2 ubergeben wird.<br />
Typmanager{gesteuerte Kooperation:<br />
Im Unterschied zur Trader{gesteuerten Variante ubernehmen hier die den<br />
Tradern zugeordneten Typmanager die Steuerung des Umwandlungsvorganges.<br />
In diesem Fall ist e<strong>in</strong>e von der Trader{Kooperation unabhangige<br />
Typmanager{Kooperation bzw. Typmanagerfoderation (siehe auch Abschnitt<br />
3.2.3) notwendig.<br />
In beiden Fallen mu e<strong>in</strong>e E<strong>in</strong>igung auf e<strong>in</strong>e geme<strong>in</strong>same Diensttypbeschreibung<br />
erfolgen, damit die vom Typmanager 1 erzeugten Typ<strong>in</strong>formationen vom Typmanager<br />
2 <strong>in</strong>terpretiert werden kann. Im zweiten Fall ist hierbei e<strong>in</strong>e Absprache<br />
zwischen den Typmanagern erforderlich, wahrend im ersten Fall sich Trader<br />
und Typmanager verstandigen mussen. GrundlegendeVoraussetzungistauchdie<br />
Nutzung global e<strong>in</strong>deutiger Typbezeichner, beispielsweise <strong>in</strong> der <strong>in</strong> Abschnitt<br />
3.2.3.1 vorgeschlagenen Form, so da fur jeden Typbezeichner e<strong>in</strong>e e<strong>in</strong>deutige<br />
Zuordnung zudem diesen Bezeichner verwaltenden Typmanager gewahrleistet<br />
ist.<br />
Bei Komb<strong>in</strong>ation der oben beschriebenen Falle ergeben sich <strong>in</strong>sgesamtsechs verschiedene<br />
Varianten zur Realisierung domanenubergreifender, direkter Trader{<br />
Kooperationen. Diese werden im folgenden genauer beschrieben und mite<strong>in</strong>ander<br />
verglichen, wobei auch die Operationen herausgestellt werden, die vom Typmanagement<br />
zur Unterstutzungderartiger Trader{Kooperationen zur Verfugung zu<br />
stellen s<strong>in</strong>d.<br />
Variante 1: Ignorante, Typmanager{gesteuerte Kooperation<br />
Trader 1 (siehe Abbildung 3.29) ignoriert <strong>in</strong> diesem Fall das Vorhandense<strong>in</strong> der<br />
Heterogenitatsgrenze und reicht die vom Importeur gestellte Dienstanfrage, die<br />
unter anderem den geforderten, durch den Typbezeichner ServiceTypeId Y bezeichneten<br />
Diensttyp enthalt, unverandert an Trader 2 weiter. Wahrenddes darau<br />
olgenden Dienstauswahlproze es ubergibt Trader 2 diesen Typbezeichner an<br />
den ihm lokal <strong>in</strong> se<strong>in</strong>er Verwaltungsdomane zugeordneten Typmanager 2, um<br />
weitere konforme Diensttypen ermitteln zu lassen, die anschlie end zur Suche<br />
nach geeigneten Dienstangeboten genutzt werden. Anhand der im globalen Typbezeichner<br />
vorhandenen TypmanagerkennungerkenntTypmanager 2, da es sich<br />
um e<strong>in</strong>en von Typmanager 1 erzeugten Bezeichner handelt. Als erstes wendet er<br />
sichdeshalb anTypmanager 1,um die von ihm unterstutzten Diensttypbeschreibungssprache<br />
zuerfahren. Anschlie end wahlt ere<strong>in</strong>eder von beiden Typmanagern<br />
unterstutzten Beschreibungssprachen aus und fordert die zum Diensttypbezeichner<br />
ServiceTypeId Y gehorige Diensttypbeschreibung ServiceTypeDesc Y
3.3 Vermittlung und Verwaltung von Dienstangeboten 95<br />
Typmanager<br />
1<br />
Trader 1<br />
4. GetTypeDescLanguages(...)<br />
2.<br />
1. import(...,ServiceTypeId_Y,...)<br />
5. ServiceTypeDesc_Y=<br />
GetTypeDesc(ServiceTypeId_Y,...)<br />
import(...,ServiceTypeId_Y,...)<br />
Typmanager<br />
2<br />
F<strong>in</strong>dAllRelatedTypes<br />
(ServiceTypeId_Y,...)<br />
Trader 2<br />
Importeur Exporteur<br />
3.<br />
export(...,ServiceTypeId_X,...)<br />
Abbildung 3.29: Ignorante, Typmanager{gesteuerte Trader{Kooperation<br />
an. Hiermit ermittelt der Typmanager 2 samtliche <strong>in</strong> se<strong>in</strong>em De nitionsbereich<br />
vorhandenen konformen Diensttypen, unter denen e<strong>in</strong>er ServiceType X<br />
ist. Letztendlich wirddas Dienstangebot des <strong>in</strong> der Abbildung dargestellten Exporteurs<br />
als e<strong>in</strong> Teilresultat der Dienstanfrage an Trader 1 zuruckgegeben, der<br />
es se<strong>in</strong>erseits anden Importeur weitergibt.<br />
Variante 2: Ignorante, Trader{gesteuerte Kooperation<br />
Typ- Typmanager<br />
1 manager 2<br />
Trader 1 Trader 2<br />
Importeur<br />
4. GetTypeDescLanguages(...)<br />
5. ServiceTypeDesc_Y =<br />
GetTypeDesc(ServiceTypeId_Y,...)<br />
2. import(...,ServiceTypeId_Y,...)<br />
3. GetTypeDescLanguages(...)<br />
6. F<strong>in</strong>dAllRelatedTypes<br />
(ServiceTypeDesc_Y,...)<br />
1. import(...,ServiceTypeId_Y,...)<br />
export(...,ServiceTypeId_X,...)<br />
Exporteur<br />
Abbildung 3.30: Ignorante, Trader{gesteuerte Trader{Kooperation
96 Zugang zu Diensten <strong>in</strong> heterogenen Umgebungen<br />
In diesem Fall wird im Vergleich zur vorherigen Variante die Umwandlung<br />
des von Trader 1 bei der Dienstanfrage verwendeten Typbezeichners<br />
ServiceTypeId Y anstelle von Typmanager 2 durch Trader 2 selbst durchgefuhrt.<br />
Hierzu ermittelt er die Dienstbeschreibungssprachen, die sowohl von<br />
Typmanager 1 als auch von se<strong>in</strong>em eigenen Typmanager unterstutzt werden.<br />
Anschlie end fordert er von Typmanager 1 die zu ServiceTypeId Y gehorende<br />
Diensttypbeschreibung ServiceTypeDesc Y <strong>in</strong> e<strong>in</strong>er der gefundenen Beschreibungssprachen<br />
an. Diese ubergibt er Typmanager 2, der auf dieser Grundlage<br />
konforme Diensttypen sucht. Der weitere Ablauf erfolgt analog zum obenbereits<br />
beschriebenen.<br />
Variante 3: Bewu te, Trader{gesteuerte Kooperation<br />
Typ- Typ-<br />
Manager 1<br />
Manager 2<br />
2. GetTypeDescLanguages(...)<br />
3. GetTypeDescLanguages(...) 5. ServiceTypeId_X =<br />
4. ServiceTypeDesc_Y =<br />
GetTypeId(ServiceTypeDesc_Y,...)<br />
GetTypeDesc(ServiceTypeId_Y,...)<br />
1.<br />
6. import(...,ServiceTypeId_X,...)<br />
Trader 1 Trader 2<br />
import(...,ServiceTypeId_Y,...)<br />
export(...,ServiceTypeId_X,...)<br />
Importeur Exporteur<br />
Abbildung 3.31: Bewu te, Trader{gesteuerte Trader{Kooperation<br />
Im Gegensatz zu den obigen ignoranten Varianten wird die Umwandlungdes vom<br />
Importeur bei der Dienstanfrage verwendeten, nur <strong>in</strong> Verwaltungsdomane1gultigen<br />
Typbezeichners ServiceTypeId Y von Trader 1 vor dem Weiterreichen der<br />
Dienstanfrage an Trader 2 durchgefuhrt. Hierzu bestimmt er als erstes e<strong>in</strong>e von<br />
beiden Typmanagern unterstutzte Typbeschreibungssprache und la t sich von<br />
Typmanager 1 die Diensttypbeschreibung ServiceTypeDesc Y zuruckgeben 13 .<br />
Diese wird anschlie end dem Typmanager 2 weitergereicht, der aufgrund dieser<br />
Typbeschreibung <strong>in</strong>se<strong>in</strong>em De nitionsbereich konforme Diensttypen sucht. Bei<br />
erfolgreicher Suche wird e<strong>in</strong> dort gultiger Diensttypbezeichner, <strong>in</strong> diesem Fall<br />
beispielsweise ServiceTypeId X, anTrader 1 zuruckgereicht, der nachfolgend<br />
diesen Typbezeichner bei der Dienstanfrage an Trader 2 verwendet.<br />
13 In systemtechnischer Betrachtung erfolgt die Ruckgabe der Diensttypbeschreibung mit<br />
Hilfe e<strong>in</strong>er geeigneten Diensttypreprasentation (siehe Abschnitt 2.1), die durch das Kooperationsprotokoll<br />
vorab festgelegt ist.
3.3 Vermittlung und Verwaltung von Dienstangeboten 97<br />
Der von Typmanager 2 als Resultat dieser Anfrage gelieferte Diensttyp<br />
ServiceType X sollte hierbei generell mit dem geforderten Diensttyp moglichst<br />
weitgehend ubere<strong>in</strong>stimmen, d.h. entweder aquivalent oder e<strong>in</strong> direkter Subtyp<br />
<strong>in</strong> der Hierarchie der zu diesem Diensttyp konformen Diensttypen se<strong>in</strong>. Anderenfalls<br />
wurde beider spateren Anfrage nach konformen Diensttypen von<br />
Trader 2 an se<strong>in</strong>en Typmanager nur e<strong>in</strong> Teil der zum ursprunglich geforderten<br />
Diensttyp ServiceType Y konformen Diensttypen gefunden werden. Dieses<br />
konnte dann unter Umstanden bedeuten, da das Dienstangebot des <strong>in</strong> der<br />
Abbildung dargestellten Exporteurs nicht vermittelt wird, falls ServiceType X<br />
e<strong>in</strong> Supertyp des zuruckgegebenen Diensttyps ist.<br />
Variante 4: Bewu te, Typmanager{gesteuerte Kooperation<br />
Typ- 3. GetTypeDescLanguages(...)<br />
Typ-<br />
Manager 1<br />
Manager 2<br />
2. ServiceTypeId_X =<br />
4. ServiceTypeId_X=<br />
GetTypeID(ServiceTypeDesc_Y,...)<br />
GetForeignTypeId(ServiceTypeId_Y,TM2,...)<br />
5. import(...,ServiceTypeId_X,...)<br />
Trader 1 Trader 2<br />
1. import(...,ServiceTypeId_Y,...)<br />
export(...,ServiceTypeId_X,...)<br />
Importeur Exporteur<br />
Abbildung 3.32: Bewu te, Typmanager{gesteuerte Trader{Kooperation<br />
Im Vergleich zurbewuten, Trader{gesteuerten Variante ubernimmt hier der<br />
Typmanager 1 die Steuerung des Umwandlungsproze es. Hierzu ubergibt<br />
Trader 1 ihm zuerst den Diensttypbezeichner ServiceTypeId Y und die Schnittstellenkennung<br />
von Typmanager 2. Nach Abstimmung e<strong>in</strong>er geme<strong>in</strong>samen<br />
Typbeschreibungssprache reicht erTypmanager 2 die Diensttypbeschreibung<br />
ServiceTypeDesc Y weiter, der wie schon im Trader{gesteuerten Fall e<strong>in</strong>en<br />
Typbezeichner ServiceTypeId X e<strong>in</strong>es zu dieser Typbeschreibung konformen<br />
Dienststyps zuruckgibt. 14 Dieser wird anschlie end Trader 1 weitergereicht, der<br />
ihn bei der Dienstanfrage an Trader 2 verwendet. Anschlie end wird dieser zur<br />
Ermittlung konformer Diensttypen durch Typmanager 2 genutzt.<br />
14 Alternativ konnte Typmanager 2 auch samtliche von ihm gefundene Diensttypbezeichner<br />
zuruckreichen, wodurch sich die erneute Suche nach konformen Diensttypen durch Trader 2<br />
nach Ubergabe der Dienstanfrage von Trader 1 vermeiden la t. Dieses gilt ebenfalls fur den<br />
Trader{gesteuerten Fall.
98 Zugang zu Diensten <strong>in</strong> heterogenen Umgebungen<br />
Variante 5:Standardisierte Diensttypbeschreibung<br />
Typ- Typ-<br />
Manager 1<br />
Manager 2<br />
2. CanonicalDesc_Y =<br />
GetTypeDesc(ServiceTypeId_Y,<br />
CanoncialTypeDescLanguage)<br />
4. F<strong>in</strong>dAllRelatedTypes<br />
(CanonicalDesc_Y,...)<br />
3. import(...,CanonicalDesc_Y,...)<br />
Trader 1 Trader 2<br />
1. import(...,ServiceTypeId_Y,...)<br />
export(...,ServiceTypeId_X,...)<br />
Importeur Exporteur<br />
Abbildung 3.33: Trader{Kooperation basierend auf standardisierten Diensttypbeschreibungen<br />
Bei dieser Variante unterstutzen alle beteiligten Typmanager und Trader e<strong>in</strong>e<br />
vorab festgelegte Typbeschreibungssprache. Diese wird von Trader 1 an Trader<br />
2 zum Austausch von Diensttypbeschreibungen, <strong>in</strong> diesem Fall CanonicalDesc<br />
Y, bei der Dienstanfrage genutzt, wodurch die Umwandlung von Diensttypbezeichner<br />
beim Uberschreiten der Heterogenitatsgrenze beider Trader entfallt.<br />
Innerhalbder Verwaltungsdomanen kann jedoch weiterh<strong>in</strong> von Seiten der Importeure<br />
und Exporteure mit den dort gultigen Typbezeichner gearbeitet werden.<br />
Im Vergleich zuden obigen ignoranten und bewu ten Varianten gestaltet sich<br />
die Abwicklung e<strong>in</strong>er auf standardisierten Diensttypbeschreibungen basierenden<br />
Trader{Kooperation relativ e<strong>in</strong>fach, da au er dem Weiterreichen der Dienstanfrage<br />
von Trader 1 an Trader 2 ke<strong>in</strong>e weiteren domanenubergreifenden Interaktionen<br />
zwischen den Typmanagern notwendig s<strong>in</strong>d. Dieses tri t auchfur den Fall<br />
zu, <strong>in</strong> dem ahnlich wie bei den bewu ten Kooperationsvarianten e<strong>in</strong>e zusatzliche<br />
dynamische Abstimmung der geme<strong>in</strong>samen Typbeschreibungssprache vorab<br />
erfolgt. Konkret wurde dieses e<strong>in</strong>e zusatzliche Anfrage von Trader 1 bei Typmanager<br />
1 und 2verursachen, wobei anschlie end e<strong>in</strong>evon beiden unterstutzte<br />
Beschreibungssprache gewahlt werden wurde.<br />
Variante 6:Standardisierte Diensttypbezeichner<br />
E<strong>in</strong>e weitere Moglichkeit zur Durchfuhrung von Trader{Kooperationen ist die <strong>in</strong><br />
Abbildung 3.34 gezeigteVerwendungstandardisierter Diensttypbezeichner, die <strong>in</strong><br />
allen Verwaltungsdomanen dieselbe Bedeutung besitzen bzw. denselben Diensttyp<br />
bezeichnen. Trader 1 kann <strong>in</strong> diesem Fall die vom Importeur ankommende<br />
Dienstanfrage ohne weitere Umwandlungen des Diensttypbezeichners an Trader
3.3 Vermittlung und Verwaltung von Dienstangeboten 99<br />
Typ- Typ-<br />
Manager 1<br />
Manager 2<br />
Trader 1<br />
1. import(...,CanonicalTypeId,...)<br />
2. import(...,CanonicalTypeId,...)<br />
3.<br />
F<strong>in</strong>dAllRelatedTypes<br />
(CanonicalTypeId,...)<br />
Trader 2<br />
export(...,ServiceTypeId_X,...)<br />
Importeur Exporteur<br />
Abbildung 3.34: Trader{Kooperation basierend auf standardisierten Diensttypbezeichnern<br />
2 weitergeben, wodurch sich wie beim obigen Fall der standardisierten Diensttypbeschreibung<br />
diefur die Trader{Kooperation notwendigen Interaktionen auf<br />
e<strong>in</strong> M<strong>in</strong>imum beschranken.<br />
Die De nition der entsprechenden Diensttypbeschreibung und die Vergabe des<br />
dazugehorigen Bezeichners mu fur die beteiligten Verwaltungsdomanen verb<strong>in</strong>dlich<br />
durche<strong>in</strong>e ubergeordneteAutoritat bestimmtwerden. Dabei sollten standardisierte<br />
Bezeichner explizit kenntlich gemacht werden, um sie von den sonstigen<br />
Typbezeichnern unterscheiden zu konnen. Beim Weiterreichen an e<strong>in</strong>en Trader<br />
oder Typmanager konnen diese hierdurch sofort erkannt werden. E<strong>in</strong> hierfur geeigneter<br />
Losungsansatz zur Identi zierung standardisierter Typbezeichner s<strong>in</strong>d<br />
die<strong>in</strong>Abschnitt 3.2.3.1 beschriebenen global e<strong>in</strong>deutigen Typbezeichner, die<br />
die Festlegung e<strong>in</strong>es Bezeichnertyps erlauben. Da die Menge der zukunftig zu<br />
standardisierenden Diensttypen bzw. der dazugehorigen Diensttypbezeichner von<br />
vornhere<strong>in</strong> nicht vorbestimmt ist, ist generell zu erwarten, da e<strong>in</strong> Typmanager<br />
die zu e<strong>in</strong>em standardisierten Typbezeichnern gehorende Diensttypbeschreibung<br />
nicht kennt. Fur diesen Fall sollte e<strong>in</strong> durch die Standardisierungsautoritat<br />
e<strong>in</strong> wohlbekannter Ablageort de niert werden, bei dem die zu standardisierten<br />
Dienstttypbezeichnern gehorigen Typbeschreibungen abrufbar s<strong>in</strong>d.<br />
Berucksichtigung von Beziehungstypen<br />
Bei der obigen Darstellung der sechs verschiedenen Trader{Kooperationsprotokolle<br />
wurde <strong>in</strong>sbesondere die Konformitatsbeziehung zwischen Diensttypen<br />
implizit zugrundegelegt und davon ausgegangen, da diese <strong>in</strong> den an der<br />
Trader{Kooperation beteiligten Verwaltungsdomanen uberall dieselbe Semantik
100 Zugang zu Diensten <strong>in</strong> heterogenen Umgebungen<br />
besitzt 15 . Wird zusatzlichberucksichtigt, da Typmanager generell die De nition<br />
beliebiger Beziehungstypen erlauben sollten, ersche<strong>in</strong>t es bei e<strong>in</strong>er Dienstanfrage<br />
s<strong>in</strong>nvoll, neben der Diensttypbeschreibung auch e<strong>in</strong>e Beziehungstypbeschreibung<br />
anzugeben, die im weiteren Auswahlproze zur Suche nach | <strong>in</strong> Bezug<br />
auf die De nition des Beziehungstyps | kompatiblen Diensttypen durch den<br />
Typmanager verwendet wird. So konnen unter anderem auch e<strong>in</strong>geschranktere<br />
Konformitatsbeziehungen, wie beispielsweise die von CORBA oder DCE, bei<br />
der Dienstauswahl genutzt werden. Unter Berucksichtigung von Beziehungstypbezeichnern<br />
ergibt sich die <strong>in</strong> Abbildung 3.35 dargestellte Struktur.<br />
4. RelationId_B =TranslateRelation<br />
(RelationId_A,TM2)<br />
Typ- Typ-<br />
Manager 1 5.<br />
6.<br />
Manager 2<br />
GetTypeDescLanguages(...)<br />
ServiceTypeDesc_Y =<br />
GetTypeDesc(ServiceTypeId_Y,...)<br />
Trader 1<br />
2. import(...,ServiceTypeId_Y, Trader 2<br />
1. import(...,ServiceTypeId_Y,RelationId_A,...)<br />
RelationId_A,...)<br />
3. F<strong>in</strong>dAllRelatedTypes<br />
(ServiceTypeId_Y,<br />
RelationId_A,...)<br />
export(...,ServiceTypeId_X,...)<br />
Importeur Exporteur<br />
Abbildung 3.35: Berucksichtigung von Beziehungstypen bei der Trader{<br />
Kooperation<br />
Die Abbildung zeigt e<strong>in</strong>e um Beziehungsstypen erweiterte Darstellung der<br />
ignoranten, Typmanager{gesteuerten Trader{Kooperation. Als zusatzlicher Parameter<br />
der ursprunglichen Import{Operation gibt der Importeur gleichzeitig<br />
auch den gewunschten Beziehungstyp <strong>in</strong> Form des Beziehungstypbezeichners<br />
RelationId A an, der <strong>in</strong> dem gezeigten Fall zum Zugri auf die dazugehorige<br />
<strong>in</strong> Typmanager 1 verwaltete Beziehungstypbeschreibung dient. Der<br />
RelationId A entsprechende Beziehungstypbezeichner <strong>in</strong> Typmanager 2 ist hierbei<br />
als RelationId B bezeichnet.<br />
Wesentlicher Unterschied zur oben beschriebenen ignoranten, Typmanager{<br />
gesteuerten Trader{Kooperation ist zum e<strong>in</strong>en die explizite Ubergabe des Beziehungstypbezeichners<br />
von Trader 2 an Typmanager 2. Da dieser RelationId A<br />
als globalen Typbezeichner von Typmanager 1 erkennt, mu er diesen vor der<br />
spateren Suche nach kompatiblen Diensttypen <strong>in</strong> e<strong>in</strong>en <strong>in</strong> se<strong>in</strong>em De nitionsbe-<br />
15 Hiervon wird beispielsweise auch bei der Standardisierung des ODP{Traders<br />
[ODP94b] ausgegangen, wobei die dort zugrundeliegende Konformitatsbeziehung im ODP{<br />
Referenzmodell [ODP95c] de niert ist (siehe auch Abschnitt 2.3.2).
3.4 Domanenubergreifender Dienstzugri 101<br />
reichgultigen Beziehungstypbezeichner umwandeln. Dies geschieht pr<strong>in</strong>zipiell auf<br />
die gleiche Art und Weise wie bei den Diensttypbezeichnern, <strong>in</strong>dem er von Typmanager<br />
1 e<strong>in</strong>e entsprechende Beziehungstypbeschreibung <strong>in</strong>e<strong>in</strong>er von ihm verstandenen<br />
Beschreibungssprache anfordert und anschlie end e<strong>in</strong>en aquivalenten<br />
Beziehungstyp, beispielsweise den durch RelationId B bezeichneten, ermittelt.<br />
In der Abbildung s<strong>in</strong>d diese E<strong>in</strong>zelschritte <strong>in</strong>der Operation TranslateRelation<br />
zusammengefa t.<br />
Damit Beziehungstypbeschreibungen ausgetauschtwerden konnen, ist ebenso wie<br />
bei den Diensttypbeschreibungen e<strong>in</strong>e geme<strong>in</strong>same Beschreibungssprache erforderlich.<br />
Hiermit s<strong>in</strong>dunter anderem die beteiligten Rollen, deren Typen sowie die<br />
Charakteristika und De nitionsregeln des Beziehungstyps zu beschreiben (siehe<br />
Abschnitt 3.2.2.2).ImVergleich zu Diensttypbeschreibungen existieren zur Zeit<br />
jedochnochke<strong>in</strong>e konkreten Vorschlage fur e<strong>in</strong>e derartige Beschreibungssprache.<br />
Erschwerendkommtau erdem h<strong>in</strong>zu, da fur e<strong>in</strong>e durch Instanzen de nierte Beziehung<br />
ke<strong>in</strong>e Beschreibung angebbar ist, die fur e<strong>in</strong>en anschlie enden automatisierten<br />
Typvergleich genutzt werden kann. Hierbei wird es notwendig, durch<br />
adm<strong>in</strong>istrativeMa nahmen Abbildungen zwischen den <strong>in</strong> den verschiedenen Verwaltungsdomanen<br />
vorhandenen Beziehungstypen vorab explizit zu de nieren, wobei<br />
die Korrektheit der Abbildungdurchden Adm<strong>in</strong>istrator gewahrleistet werden<br />
mu . E<strong>in</strong>e mogliche Erweiterung dieses Verfahrens stellen standardisierte Beziehungstypbezeichner<br />
dar, die ahnlich wie die standardisierten Diensttypbezeichner<br />
die Semantik von Beziehungstypen e<strong>in</strong>deutig festlegen.<br />
3.4 Domanenubergreifender Dienstzugri<br />
Die <strong>in</strong> den letzten beiden Abschnitten beschriebenen Funktionen des Diensttypmanagementsund<br />
der darauf basierenden Dienstvermittlung bilden die Grundlage,<br />
auf derer e<strong>in</strong>e geme<strong>in</strong>same und wohlde nierte Nutzung der <strong>in</strong> o enen <strong>verteilten</strong><br />
Dienstmarkten vorhandenen Dienstangebote moglich ist. Hierdurch wird das<br />
am Anfang dieses Kapitels geforderteZielder Umsetzung der auf Dienstmodell{<br />
und Dienstbeschreibungsebene vorhandenen idealisierten Dienstabstraktion <strong>in</strong><br />
heterogene verteilte Systemumgebungen erreicht. Dabei spielt <strong>in</strong>sbesondere das<br />
(verteilte) Diensttypmanagement e<strong>in</strong>e wichtige Rolle, da mit dessen Hilfe e<strong>in</strong>e<br />
e<strong>in</strong>heitliche Behandlung von Diensttypen und Beziehungstypen trotz technischer<br />
und adm<strong>in</strong>istrativer Heterogenitatsprobleme zwischen Verwaltungsdomanen, die<br />
diese Dienstemarkte <strong>in</strong>Kooperation realisieren, ermoglicht wird.<br />
Die Forderung nach Dienstabstraktion bedeutet somit gleichzeitig auch, da<br />
die Existenz organisationeller Heterogenitatsgrenzen zwischen den kooperierenden<br />
autonomen Verwaltungsdomanen weitgehend vor dem Dienstnehmer verborgen<br />
werden soll. Bis zu welchem Grad diese, aus der Sicht der Dienstnehmer<br />
wunschenswerte Abstraktion bei der anschlie enden Dienstb<strong>in</strong>dung und dem<br />
Dienstaufruf gewahrt werden soll und kann, hangt zum e<strong>in</strong>en von den technischen<br />
Heterogenitatsproblemen zwischen den Verwaltungsdomanen ab, die e<strong>in</strong>e<br />
vollstandige Abstraktion unter Umstanden verh<strong>in</strong>dern. Zum anderen s<strong>in</strong>d auch<br />
die <strong>in</strong> der jeweiligen Domane vorhandenen lokalen Gegebenheiten und adm<strong>in</strong>i-
102 Zugang zu Diensten <strong>in</strong> heterogenen Umgebungen<br />
strativen Verwaltungsvorschriften zu berucksichtigen. So kann es beispielsweise<br />
aus Sicherheitsgrunden s<strong>in</strong>nvoll se<strong>in</strong>, die <strong>Dienstnutzung</strong> von au en bewu t e<strong>in</strong>zuschranken,<br />
so da <strong>in</strong> diesem Fall die Grenzen zwischen den Verwaltungsdomanen<br />
explizit sichtbar werden. Diese adm<strong>in</strong>istrativen Beschrankungen konnen pr<strong>in</strong>zipiell<br />
<strong>in</strong> allen Phasen des Dienstzugangs aufgestelltwerden, wobei|imVergleich<br />
zu den Phasen der Diensttyp ndung und der Dienstauswahl | die Dienstb<strong>in</strong>dungundder<br />
Dienstaufruf letztlich die entscheidenen Hurden fur e<strong>in</strong>e erfolgreiche<br />
<strong>Dienstnutzung</strong> darstellen, da erst <strong>in</strong> diesen beiden Phasen e<strong>in</strong>e explizite Kooperationsbeziehung<br />
zwischen Dienstnehmer und Diensterbr<strong>in</strong>ger aufgebaut wird.<br />
Schwerpunkt der Betrachtung s<strong>in</strong>d<strong>in</strong>diesemAbschnitt deshalb vor allem diejenigen<br />
Systemtechniken, die e<strong>in</strong>en Dienstzugri , d.h. die Dienstb<strong>in</strong>dung und<br />
den Dienstaufruf, uber Domanengrenzen h<strong>in</strong>weg ermoglichen. Derartige Systemtechniken<br />
werden <strong>in</strong> dieser Arbeit <strong>in</strong> Anlehnung andas ODP{Referenzmodell<br />
[ODP95c] als sogenannte Interzeptoren bezeichnet. Der durch e<strong>in</strong>en Interzeptor<br />
geleistete Dienst wird entsprechend als Interzeption (engl. to <strong>in</strong>tercept: ab{, auffangen)<br />
bezeichnet und kennzeichnet die wesentliche allgeme<strong>in</strong>e Eigenschaft des<br />
Interzeptors, als Mittler zwischen Dienstnehmern und Diensterbr<strong>in</strong>gern zweier<br />
Verwaltungsdomanen zu fungieren. Funktionell kann der Interzeptor als Erweiterungder<br />
Laufzeitsystemeder zu verb<strong>in</strong>denden Verwaltungsdomanen verstanden<br />
werden, wobei er durchse<strong>in</strong>e Mittlerfunktionalitat konzeptionell fur jedeDomane<br />
sowohl die Rolle e<strong>in</strong>es Diensterbr<strong>in</strong>gers als auch die e<strong>in</strong>es Dienstnehmers vere<strong>in</strong>t<br />
(siehe Abbildung 3.36).<br />
Verwaltungsdomäne A<br />
Dienstnehmer<br />
Interzeptor<br />
Laufzeitsystem A Laufzeitsystem B<br />
Organisationelle Heterogenitätsgrenze<br />
Verwaltungsdomäne B<br />
Diensterbr<strong>in</strong>ger<br />
Abbildung 3.36: Dienstzugri uber organisationelle Heterogenitatsgrenzen h<strong>in</strong>weg<br />
3.4.1 Aufgaben von Interzeption<br />
Ob und <strong>in</strong>welcher Form e<strong>in</strong> Interzeptor zur Unterstutzung des Dienstzugri s<br />
benotigt wird, hangt ma geblich von der Art der Kooperation von Verwaltungsdomanen<br />
<strong>in</strong>nerhalb o ener verteilter Dienstemarkte untere<strong>in</strong>ander und den damit<br />
verbundenen, am Anfang dieses Kapitels dargestellten organisationellen, d.h.<br />
technischen und adm<strong>in</strong>istrativen Heterogenitatsproblemen, ab. Pr<strong>in</strong>zipiell las-
3.4 Domanenubergreifender Dienstzugri 103<br />
sen sich vier wesentliche Aufgaben von Interzeption unterscheiden (siehe auch<br />
[GML96]):<br />
1. Uberw<strong>in</strong>dung technischer Heterogenitatsgrenzen<br />
2. Uberwachung und Kontrolle adm<strong>in</strong>istrativer Heterogenitatsgrenzen<br />
3. Erweiterung von Plattformkonzepten<br />
4. Kompensation fehlender Domanenkonzepte<br />
Bei dieser Unterscheidung wird im folgenden davon ausgegangen, da die Phasen<br />
der Diensttyp ndung und der Dienstauswahl bereits abgeschlossen s<strong>in</strong>d und die<br />
Interoperabilitat zwischen Dienstnehmer und Diensterbr<strong>in</strong>ger sichergestellt ist.<br />
E<strong>in</strong>e ahnliche Unterteilung der Aufgaben von Interzeption ndet sich auch <strong>in</strong><br />
[Hof96], wo die ersten beiden Aspekte berucksichtigt werden: " Interception is<br />
the process which creates and <strong>in</strong>serts the appropriate gateways when a b<strong>in</strong>d<strong>in</strong>g<br />
between a client andaserver is created across doma<strong>in</strong> boundaries. The <strong>in</strong>serted<br />
gateways can perform the required transformations <strong>in</strong> case of technical di erences,<br />
the check<strong>in</strong>g andvett<strong>in</strong>g <strong>in</strong> cases where adm<strong>in</strong>istrative boundaries are<br />
necessary, andthe monitor<strong>in</strong>g where audit<strong>in</strong>g isnecessary.\ Alternativ zu diesen<br />
Gateways wird bei der primaren Betrachtung der technischen Heterogenitatsprobleme<br />
von e<strong>in</strong>igen Autoren alternativ auch der Begri der Bridge verwendet<br />
[YV96, MZP96]. In dieser Arbeit soll jedochausschlie lichder Begri Interzeptor<br />
benutzt werden, der alle oben genannten Aspekte ganzheitlich erfa t.<br />
3.4.1.1 Uberw<strong>in</strong>dung technischer Heterogenitatsgrenzen<br />
Hauptursache fur die technische Heterogenitat ist die bereits am Anfang dieses<br />
Kapitels beschriebene Existenz verschiedener verteilter Systemplattformen, die<br />
<strong>in</strong> den jeweiligen Verwaltungsdomanen zur Realisierung und zumAblauf von<br />
Diensterbr<strong>in</strong>gern genutzt werden. Diese besitzen <strong>in</strong> der Regel zue<strong>in</strong>ander <strong>in</strong>kompatible<br />
Systemmechanismen zur B<strong>in</strong>dung und zum Operationsaufruf, so da e<strong>in</strong>e<br />
technische Interoperabilitat nur durch gegenseitige Abbildung der verschiedenen<br />
Verfahren untere<strong>in</strong>ander erreicht werden kann.<br />
B<strong>in</strong>dung Vor dem eigentlichen Dienstaufruf ist die B<strong>in</strong>dung zwischen Dienstnehmer<br />
und Diensterbr<strong>in</strong>ger der beiden Verwaltungsdomanen notwendig, um die<br />
Kooperationsbeziehung zwischen beiden aufzubauen. Wie schon bei den Aufgaben<br />
des Diensttypmanagements beschrieben wurde, ist e<strong>in</strong>e der Hauptaufgaben<br />
der B<strong>in</strong>dungsphase, die Interoperabilitat beider Kooperationspartner zu uberprufen.<br />
Im Fall e<strong>in</strong>es plattformubergreifenden Dienstzugri s s<strong>in</strong>d <strong>in</strong>sbesondere<br />
die Problemstellungen zu berucksichtigen, die sich aufgrund der Verteilung<br />
des Diensttypmangements, d.h. dem Vorhandense<strong>in</strong> jeweils eigener Typmanager<br />
<strong>in</strong> den Verwaltungsdomanen, ergeben und gegebenfalls Protokolle erfordern,<br />
mit denen Diensttypbeschreibungen auf e<strong>in</strong>heitliche Art und Weise ausgetauscht
104 Zugang zu Diensten <strong>in</strong> heterogenen Umgebungen<br />
werden konnen. Auf moglicheLosungsansatze <strong>in</strong> Form von Diensttypreprasentationen<br />
wurde beider Betrachtunge<strong>in</strong>es <strong>verteilten</strong> Diensttypmanagements<strong>in</strong>Abschnitt<br />
3.2.3 e<strong>in</strong>gegangen. Interzeptoren konnen als Konkretisierung des <strong>in</strong> Abbildung<br />
3.17 abstrakt dargestellten Laufzeitsystems verstanden werden, das die<br />
Uberprufungsfunktionen <strong>in</strong>itiiert, mit denen die Interoperabilitat von Dienstnehmern<br />
und Diensterbr<strong>in</strong>gern beim Dienstzugri uber technische Domanengrenzen<br />
h<strong>in</strong>weg uberpruft werden kann. Dieses ist <strong>in</strong> Abbildung 3.37 dargestellt, wobei<br />
der Interzeptor zwischen den beiden Verwaltungsdomanen auf der geme<strong>in</strong>samen<br />
Domanengrenze lokalisiert ist.<br />
Dienstnehmer<br />
Typmanagerföderation<br />
CheckRelationship<br />
TypeId RelTypeId TypeId<br />
Interzeptor<br />
Organisationelle Heterogenitätsgrenze<br />
Diensterbr<strong>in</strong>ger<br />
Abbildung 3.37: B<strong>in</strong>dungsuberprufung durch e<strong>in</strong>en Interzeptor<br />
Die Typuberprufungen fuhrt er unter Zuhilfenahme des Diensttypmanagements<br />
aus, welches <strong>in</strong> der Abbildung durch e<strong>in</strong>eTypmanagerfoderation angedeutet ist.<br />
Da auch <strong>in</strong>nerhalb e<strong>in</strong>er derartigen Typmanagerfoderation e<strong>in</strong> domanenubergreifender<br />
Dienstzugri der Typmanager untere<strong>in</strong>ander erforderlich ist (siehe Abbildung<br />
3.17), s<strong>in</strong>d dort ebenfalls entsprechende Interzeptionsmechanismen zur<br />
Verfugung zustellen, so da <strong>in</strong> Verfe<strong>in</strong>erung wiederum das <strong>in</strong> Abbildung 3.36<br />
dargestellte Grundmodell gilt.<br />
Dienstaufruf Die Problematik des Dienstaufrufs uber technische Heterogenitatsgrenzen<br />
h<strong>in</strong>weg ist eng verknupft mit den <strong>in</strong> den Plattformen vorhandenen<br />
Mechanismen zur Typisierung von Diensten bzw. Operationen. Im e<strong>in</strong>fachsten<br />
Fall konnen hierbei e<strong>in</strong>fache Datentypen, beispielsweise Integer und<br />
Int, direkt wechselseitig aufe<strong>in</strong>ander abgebildet werden. Komplizierter wird<br />
diese Abbildung, falls sich Typkonzepte e<strong>in</strong>er Systemplattform nicht direkt <strong>in</strong><br />
der anderen widerspiegeln lassen und stattdessen Umwandlungen durchgefuhrt<br />
werden mussen. Abbildung 3.38verdeutlicht diese Problematik anhand e<strong>in</strong>er<br />
CORBA{ und e<strong>in</strong>er DCE{Dienstbeschreibung, bei der e<strong>in</strong>e <strong>in</strong>DCEIDLspe-
3.4 Domanenubergreifender Dienstzugri 105<br />
zi zierte Zeigerliste <strong>in</strong>e<strong>in</strong>e aquivalente CORBA IDL Deklaration e<strong>in</strong>er Sequenz<br />
umgewandelt wird. E<strong>in</strong>e umfangreiche Abbildung von DCE{ und CORBA{<br />
Dienstbeschreibungen und der dabei auftretenden Problemstellungen ndet sich<br />
<strong>in</strong> [CM95].<br />
/* DCE IDL */ // CORBA IDL<br />
typedef struct foo { struct foo_1 {<br />
long value1� long value1�<br />
long value2� long value2�<br />
[ptr] struct foo *next� sequence next�<br />
} foo� }�<br />
Abbildung 3.38: Ausschnitt e<strong>in</strong>er Abbildung e<strong>in</strong>er DCE{ auf e<strong>in</strong>e CORBA{<br />
Dienstbeschreibung<br />
Die Entscheidung, welche Konzepte zwischen Dienstbeschreibungen zweier verschiedener<br />
Systemplattformen abbildbar s<strong>in</strong>d, hangt ma geblich von dem geme<strong>in</strong>sam<br />
gewahlten Diensttypmodell ab, das unter anderem auch die Festlegung<br />
e<strong>in</strong>facher und komplexer Datentypen umfa t. Bezogen auf die <strong>in</strong> Kapitel<br />
2 vorgestellten Interoperabilitatsebenen wird durch diese E<strong>in</strong>igung die Interoperabilitat<br />
auf Dienstbeschreibungsebene sichergestellt, so da h<strong>in</strong>sichtlich der<br />
strukturellen bzw. syntaktischen Aspekte die Typsicherheit zwischen heterogenen<br />
Dienstbeschreibungen auf dieser Ebene gewahrleistet ist. In der Regel lassen<br />
sich hierbei nicht alle Konzepte der Systemplattformen untere<strong>in</strong>ander abbilden,<br />
so da meistens e<strong>in</strong> kanonisches Typmodell gewahlt wird, da zum<strong>in</strong>dest e<strong>in</strong>e<br />
Schnittmenge der <strong>in</strong> den verschiedenen <strong>verteilten</strong> Systemplattformen vorhandenen<br />
Typisierungskonzepte umfa t. Dieser Ansatz ndet sich auch <strong>in</strong>der <strong>in</strong> Teil<br />
II vorgestellten TRADE{Systemarchitektur, bei der auf Grundlage des <strong>in</strong> Abschnitt<br />
2.3 vorgestellten Diensttypmodells e<strong>in</strong> kanonisches Typmodell fur DCE{<br />
und CORBA{basierte Diensterbr<strong>in</strong>ger entwickelt worden ist. E<strong>in</strong> ahnlicher Abbildungsansatz<br />
ist beispielsweise auch <strong>in</strong> CORBA [OMG91] oder ILU [JSS95]<br />
durch sogenannte Sprachabbildungen (engl. language mapp<strong>in</strong>gs) realisiert, bei<br />
denen die Typsysteme verschiedener Programmiersprachen auf das kanonische<br />
CORBA{ bzw. ILU{Typmodell abgebildet werden. Dadurch wird es anschlie end<br />
moglich, Dienstnehmer und Diensterbr<strong>in</strong>ger <strong>in</strong> verschiedenen Programmiersprachen<br />
zu entwickeln, die uber das geme<strong>in</strong>same Typverstandnis des kanonischen<br />
Modells zue<strong>in</strong>ander typkompatibel s<strong>in</strong>d.<br />
Neben der Abbildung der unterschiedlichen Typmodelle ist e<strong>in</strong> weiterer wichtiger<br />
Gesichtspunkt beim Dienstaufruf auch die Umsetzung der <strong>in</strong> den Systemplattformen<br />
verwendeten Dienstaufrufmechanismen. E<strong>in</strong> Beispiel hierfur s<strong>in</strong>d die<br />
Systemplattformen DCE, ANSA, CORBA und ILU, die jeweils unterschiedliche,<br />
zue<strong>in</strong>ander <strong>in</strong>kompatible Verfahren zur Ausfuhrung von Operationsaufrufen besitzen.<br />
So ist es beispielsweise nicht moglich, mittels e<strong>in</strong>es DCE{RPCs die Ope-
106 Zugang zu Diensten <strong>in</strong> heterogenen Umgebungen<br />
rationen e<strong>in</strong>es ANSA{ oder CORBA{Diensterbr<strong>in</strong>gers aufzurufen. E<strong>in</strong> moglicher<br />
Losungsansatz hierfur ware die E<strong>in</strong>igung auf e<strong>in</strong> geme<strong>in</strong>sames Transferformatfur<br />
Operationsaufrufe bei der Netzwerkubertragung, wie es beispielsweise durch das<br />
Internet <strong>in</strong>teroperability protocol (IIOP) <strong>in</strong> CORBA 2.0 [OMG95] de niert ist.<br />
Alternativ existieren auch Losungsansatze auf Anwendungsebene, wie sie auch<br />
auch <strong>in</strong>nerhalb von TRADE verwendet werden. Letztere Variante wird mit ihren<br />
Vor{ und Nachteilen bei der Untersuchung verschiedener Implementierungsvarianten<br />
von Interzeptoren <strong>in</strong> Abschnitt 3.4.2 noch genauer beschrieben.<br />
Unmittelbare Aufgabe e<strong>in</strong>es Interzeptors ist es nun, e<strong>in</strong>en Dienstaufruf e<strong>in</strong>es<br />
Dienstnehmers der Domane A <strong>in</strong> e<strong>in</strong>en aquivalenten Aufruf <strong>in</strong> der Domane B<br />
umzuwandeln. Hierbei kann gleichzeitig auch e<strong>in</strong>e Uberprufung des Operationsaufrufs<br />
h<strong>in</strong>sichtlich der Korrekheit der Parameter{ und Resultatwerte durchgefuhrt<br />
werden. Der pr<strong>in</strong>zipielle Ablauf e<strong>in</strong>er derartigen Interzeptor{basierten<br />
Interaktion von Dienstnehmer und Diensterbr<strong>in</strong>ger ist <strong>in</strong> Abbildung 3.36durch<br />
entsprechende Pfeileangedeutet, wobei im Interzeptor die verschiedenartigen<br />
Typmodelle und Dienstaufrufmechanismen umgesetzt werden. Die speziell fur<br />
die Typtransformation notwendigen Informationen erhalt der Interzeptor durch<br />
das Diensttypmanagement schon wahrend der B<strong>in</strong>dungsphase, bei der diese Informationen<br />
fur die dortigen Typvergleiche und {uberprufungen benotigt werden.<br />
Der Interzeptor ubernimmt beim Interzeptionsvorgangsowohl die Rolle des<br />
Diensterbr<strong>in</strong>gers als auch des Dienstnehmers. So ist er beispielsweise nach Umsetzung<br />
des Dienstaufrufs stellvertretender Dienstnehmer des Diensterbr<strong>in</strong>gers<br />
der Zieldomane.<br />
3.4.1.2 Uberwachung und Kontrolle adm<strong>in</strong>istrativer Heterogenitatsgrenzen<br />
Unabhangig von den technischen Heterogenitatsproblemen zeichnen sich die kooperierenden<br />
Verwaltungsdomanen aufgrund ihrer Autonomie durchverschiedenartige<br />
adm<strong>in</strong>istrative Vorgehensweisen aus, die durch die dort de nierten Verwaltungsvorschriften<br />
(engl. policies) bee<strong>in</strong> u t werden. Bei der Kooperation mit<br />
anderen Verwaltungsdomanen s<strong>in</strong>d vor allem Vorschriften h<strong>in</strong>sichtlich der Uberwachung<br />
und Protokollierung von Interaktionen zwischen Dienstnehmern und<br />
Diensterbr<strong>in</strong>ger von Interesse, mit denen den speziellen Sicherheitsanforderungen<br />
der Verwaltungsdomanen Rechnung getragen wird. Ebenso lassen sich durch adm<strong>in</strong>istrative<br />
Grenzen auch Zugri sbeschrankungen auf bestimmte Dienste festlegen.<br />
Diese Ma nahmen gehen e<strong>in</strong>her mit den bereits beim Diensttypmanagement<br />
und bei der Dienstvermittlung genannten Vorschriften, mit denen unter anderem<br />
die Sichtbarkeit auf bestimmte Diensttypbeschreibungen bzw. Diensterbr<strong>in</strong>ger<br />
e<strong>in</strong>geschrankt wird. Zusammengenommen kann der Interzeptionsdienst somit<br />
auch als e<strong>in</strong> Kontrolldienst verstanden werden, mit denen der generelle Zugang<br />
zu e<strong>in</strong>er Verwaltungsdomane uberwacht und geregelt werden kann. Er ist <strong>in</strong><br />
dieser Funktion vergleichbar mit den Komponenten von sogenannten Fire Walls<br />
[CZ96], die auf Netzwerkebeneden Zugri auf e<strong>in</strong> lokales Rechnernetz von au en<br />
regeln. Pr<strong>in</strong>zipiell konnen Interzeptoren auch <strong>in</strong>nerhalbvon Verwaltungsdomanen<br />
e<strong>in</strong>gesetzt werden. E<strong>in</strong>e mogliche Anwendung ware beispielsweise die Uberwa-
3.4 Domanenubergreifender Dienstzugri 107<br />
chung samtlicher Interaktionen zwischen Dienstnehmern und Diensterbr<strong>in</strong>gern <strong>in</strong><br />
e<strong>in</strong>er Domane, wobei alle Dienstzugri e uber e<strong>in</strong>en domanen<strong>in</strong>ternen Interzeptor<br />
abgewickelt werden mussen.<br />
3.4.1.3 Erweiterung von Plattformkonzepten<br />
Aufgrund der " Mittler\{Funktionalitat konnen Interzeptoren im allgeme<strong>in</strong>en<br />
auch fur Aufgaben herangezogen werden, die uber die oben genannten Aufgaben<br />
der Uberw<strong>in</strong>dungtechnischer Heterogenitatsproblemeund der Uberwachung<br />
h<strong>in</strong>ausgehen. E<strong>in</strong>e mogliche Erweiterung ist die Gewahrleistung zuverlassiger<br />
Dienstaufrufe zwischen Dienstnehmern und Diensterbr<strong>in</strong>gern e<strong>in</strong>er bzw. zwischen<br />
zwei verschiedenen Verwaltungsdomanen. E<strong>in</strong> Beispiel hierfur ist der sogenannte<br />
Logger im Cygnus{System [CR91], der moglicheAufru ehler beim Diensterbr<strong>in</strong>ger<br />
vor dem Dienstnehmer verbirgt und gegebenfalls e<strong>in</strong>en Aufruf bei e<strong>in</strong>em<br />
anderen Diensterbr<strong>in</strong>ger <strong>in</strong>itiiert.<br />
Generell konnen Interzeptoren somit auch als Moglichkeit zur Erweiterung von<br />
Plattformkonzepten genutzt werden, <strong>in</strong>dem zusatzliche Systemfunktionen beim<br />
Dienstaufruf ausgefuhrt werden. E<strong>in</strong>e <strong>in</strong>teressante Anwendung ist im Zusammenhang<br />
mit den Typisierungskonzepten verteilter Systemplattformen die Unterstutzung<br />
erweiterter und exibler Beziehungstypen. So lie en sich beispielsweise<br />
die <strong>in</strong> CORBA und DCE vorhandenen Subtypisierungskonzepte, die bisher<br />
nur das H<strong>in</strong>zufugen neuer Operationen zu e<strong>in</strong>em bestehenden Schnittstellentyp<br />
erlauben, durch die <strong>in</strong> Abschnitt 2.3.2 de nierte Konformitatsbeziehung<br />
ersetzen, so da auch Diensterbr<strong>in</strong>ger mit veranderten Parameter{ und Resultattypen<br />
aufrufbar waren. Da dieses durch die Laufzeitsysteme der beiden Systemplattformen<br />
nicht unterstutzt wird, mu te der Interzeptor die Dienstaufrufe<br />
entgegennehmen und mitentsprechenden Typumwandlungen an den diensttypkonformen<br />
Diensterbr<strong>in</strong>ger weitersenden. Derartige Typumwandlungen konnten<br />
auch zur Anpassung von beliebigen Diensten genutzt werden, die nicht <strong>in</strong><br />
expliziter Konformitatsbeziehung stehen. In [Kon93] ist dies beispielsweise anhand<br />
zweier Diensterbr<strong>in</strong>ger veranschaulicht, die e<strong>in</strong>en semantisch aquivalenten<br />
Dienst erbr<strong>in</strong>gen, sich jedoch <strong>in</strong>den an der Schnittstelle angebotenen Operationen<br />
unterscheiden. Abbildung 3.39 zeigt das dort angefuhrte Beispiel e<strong>in</strong>es<br />
Fensterkontrolldienstes (engl. w<strong>in</strong>dow manager), wobei die sogenannten Membrane<br />
e<strong>in</strong>e technische und adm<strong>in</strong>istrative Heterogenitatsgrenze bilden. CooL und<br />
Hybrid bezeichnen jeweils verschiedene Programmiersprachsysteme, <strong>in</strong> denen die<br />
Schnittstellentypen spezi ziert s<strong>in</strong>d. Interzeption wird <strong>in</strong> dem dortigen Zusammenhang<br />
als sogenanntes Object Mapp<strong>in</strong>g bezeichnet, bei dem die Operationen<br />
der Schnittstellentypen durch De nitionsregeln aufe<strong>in</strong>ander abgebildet werden.<br />
Dieses ist vom unterliegenden Konzept her vergleichbar mit den durch Instanzen<br />
de nierten Beziehungstypen, die <strong>in</strong> Abschnitt 3.2.2.2 beim Diensttypmanagemente<strong>in</strong>gefuhrt<br />
wurden. Um die Interzeption durchfuhren zu konnen, wird systemseitig<br />
durche<strong>in</strong>en Object Mapper e<strong>in</strong> w<strong>in</strong>dowServer Inter-Object erzeugt,<br />
welches zur Laufzeit die notwendigen Zuordnungen der Operationen aufe<strong>in</strong>ander<br />
vornimmt.
108 Zugang zu Diensten <strong>in</strong> heterogenen Umgebungen<br />
newW<strong>in</strong>dow<br />
newSquareW<strong>in</strong><br />
refreshDisplay<br />
readCoord<strong>in</strong>ates<br />
w<strong>in</strong>dowSelected<br />
Hybrid Cell CooL Cell<br />
w<strong>in</strong>dowServer<br />
Inter-Object<br />
Membrane<br />
Membrane<br />
Abbildung 3.39: Object Mapp<strong>in</strong>g<br />
3.4.1.4 Kompensation fehlender Domanenkonzepte<br />
create_w<strong>in</strong><br />
redisplay_all<br />
get_Position<br />
select_W<strong>in</strong>dow<br />
Ebenso wie bei den erstgenannten Moglichkeiten der Erweiterung des Aufgabenspektrums<br />
von Interzeptoren bzgl. Plattformkonzepten konnen diese auch<br />
dazu e<strong>in</strong>gesetzt werden, fehlende Konzepte <strong>in</strong>der Zieldomane zukompensieren.<br />
E<strong>in</strong> Beispiel, auf das <strong>in</strong>nerhalb von TRADE noch genauer e<strong>in</strong>gegangen wird,<br />
ist das E<strong>in</strong>fuhren des Diensttypkonzeptes <strong>in</strong> e<strong>in</strong>e auf CORBA basierende Verwaltungsdomane,<br />
der orig<strong>in</strong>ar nur das Schnittstellentypkonzept unterliegt. Der<br />
<strong>in</strong> TRADE entwickelte Interzeptor ubernimmt <strong>in</strong> diesem Zusammenhang unter<br />
anderem gewisse Trad<strong>in</strong>g{Funktionalitat, <strong>in</strong>dem den CORBA{Diensterbr<strong>in</strong>gern<br />
der Zieldomane bestimmte Diensttypen zugeordnet werden, die anschlie end<br />
fur e<strong>in</strong>e Dienstvermittlung benutzt werden konnen. Er kompensiert damit die<br />
dort zur Zeit fehlende Trader{Komponente. Hierdurch wird es <strong>in</strong> der Ausgangsdomane<br />
moglich, auf der Grundlage des dort verwendeten Diensttypkonzeptes<br />
auf Diensterbr<strong>in</strong>ger der Zieldomane zuzugreifen, die ursprunglich unabhangig<br />
von diesem Konzept entwickelt worden s<strong>in</strong>d (siehe auch [GML96]).<br />
3.4.2 Entwurfsvarianten von Interzeptoren<br />
Zur Realisierung von Interzeptoren s<strong>in</strong>d verschiedenartige Entwurfsvarianten<br />
moglich, die im folgenden naher beschrieben werden sollen. Generell lassen sich<br />
statische und dynamische Ansatze unterscheiden.<br />
3.4.2.1 Statische Interzeption<br />
Bei dieser Art von Interzeption ist die Abbildung bestimmter Dienstaufrufe zwischen<br />
den verschiedenen Verwaltungsdomanen fest im Interzeptor <strong>in</strong>tegriert. Statisch<br />
bedeutet <strong>in</strong> diesem Zusammenhang, da die im Interzeptor realisierten<br />
Abbildungsprozesse wahrend se<strong>in</strong>er Lebenszeit nicht veranderlich s<strong>in</strong>d. Dieses
3.4 Domanenubergreifender Dienstzugri 109<br />
betri t <strong>in</strong>sbesondere die Festlegung auf bestimmte, zwischen den Verwaltungsdomanen<br />
aufe<strong>in</strong>ander abzubildenen Schnittstellen{ bzw. Diensttypen. Pr<strong>in</strong>zipiell<br />
ergibt sich die <strong>in</strong> Abbildung 3.40 gezeigte Grundstruktur bei der Instanziierung<br />
e<strong>in</strong>es statischen Interzeptors.<br />
Dienstnehmer<br />
S<br />
T<br />
U B<br />
Interzeptor-<br />
Generator<br />
Abbildungskomponente<br />
Verwaltungsdomäne A Verwaltungsdomäne B<br />
Heterogenitätsgrenze<br />
Abbildung 3.40: Statischer, generierter Interzeptor<br />
S<br />
T<br />
U B<br />
Dienst-<br />
erbr<strong>in</strong>ger<br />
Der Interzeptor wird durch e<strong>in</strong>en Generator erzeugt, wobei die entsprechenden<br />
Stubs fur die Dienstnehmer{ und Diensterbr<strong>in</strong>gerseite und die zur Abbildung<br />
zwischen den Operationsaufrufen notwendige Abbildungskomponente <strong>in</strong>den Interzeptor<br />
statisch<strong>in</strong>tegriert werden. Die Stub{Generierung erfolgt aus den <strong>in</strong> den<br />
beiden Verwaltungsdomanen jeweils verwendeten Dienstbeschreibungen, wie es<br />
bereits <strong>in</strong>Abbildung 3.14dargestellt wurde. Hierbei ist es unter Umstanden<br />
aufgrund technischer Heterogenitatsgrenzen notwendig, da die unterschiedlichen<br />
Dienstbeschreibungen der beiden Verwaltungsdomanen aufe<strong>in</strong>ander abgebildet<br />
werden mussen. Dieses bedeutet auch, da jeweils die domanenspezi -<br />
schen Dienstaufrufmechanismen <strong>in</strong> den Interzeptor <strong>in</strong>tegriert werden mussen, so<br />
da beispielsweise auf Dienstnehmerseite e<strong>in</strong> Diensterbr<strong>in</strong>ger{Stub mittels DCE<br />
RPC und auf Diensterbr<strong>in</strong>gerseite e<strong>in</strong> Dienstnehmer{Stub mittels des CORBA<br />
RPCs (des sogenannten Skeletons [OMG91]) genutzt werden mu . Neben der<br />
Umwandlungvon Operationsaufrufen kann die Abbildungskomponenteauchweitere<br />
Aufgaben ubernehmen, die unter anderem die oben genannte Erweiterung<br />
von Plattformkonzepten oder die Kompensation fehlender Domanenkonzeptebetre<br />
en.<br />
Der Vorgang der Generierung von Interzeptoren kann pr<strong>in</strong>zipiell zu zwei verschiedenen<br />
Zeitpunkten statt nden. Zum e<strong>in</strong>en kann der Interzeptor bei der Instanziierung<br />
e<strong>in</strong>es Diensterbr<strong>in</strong>gers gleichzeitig mit generiert werden, so da jedem<br />
Diensterbr<strong>in</strong>ger jeweils e<strong>in</strong> Interzeptor zugeordnet ist. Als Alternativekann<br />
auch nur e<strong>in</strong> Interzeptor fur e<strong>in</strong>e Mehrzahl diensttypaquivalenter Diensterbr<strong>in</strong>ger<br />
erzeugt werden. 16 Zum anderen kann e<strong>in</strong>e Interzeptor auch erst zur Laufzeit<br />
zu dem Zeitpunkt erzeugt werden, wenn e<strong>in</strong> domanenubergreifender Dienstzu-<br />
16 In [Hof96] wird die erste Variante auch als privat, die zweite alstypspezi sch bezeichnet.
110 Zugang zu Diensten <strong>in</strong> heterogenen Umgebungen<br />
gri erwunscht ist. Auf welche Art die Generierung bei beiden Varianten durchgefuhrt<br />
wird, beispielsweise manuell durch den Adm<strong>in</strong>istrator der Diensterbr<strong>in</strong>gerdomaneoder<br />
automatischdurch das Laufzeitsystem (sogenannte On{demand<br />
bridge [YV96]), hangt von den jeweiligen Implementierungsvarianten und auch<br />
Verwaltungsvorschriften der Domanen ab.<br />
3.4.2.2 Dynamische Interzeption<br />
Wesentliche Eigenschaft dynamischer Interzeptoren ist der hohe GradanTypunabhangigkeit.<br />
ImVergleich zumstatischen Ansatz mit jeweils fest vorgegebener<br />
Typbeziehung zwischen Dienstnehmer und Diensterbr<strong>in</strong>ger ist e<strong>in</strong> dynamischer<br />
Interzeptor unabhangig von e<strong>in</strong>em bestimmten Dienst{ bzw. Schnittstellentyp,<br />
wodurchverschiedenartigste Dienstaufrufe an Diensterbr<strong>in</strong>ger mit beliebigen<br />
Diensttypen ubermittelt werden konnen.<br />
Um e<strong>in</strong>e derartige Generizitat zu erreichen, ist von Seiten des Interzeptors zum<br />
e<strong>in</strong>en e<strong>in</strong>e dynamische Dienstschnittstelle zur Verfugung zustellen, die e<strong>in</strong>e Entgegennahme<br />
und Interpretation beliebiger Dienstaufrufe von Dienstnehmern erlaubt.<br />
In der Abbildung 3.41 ist diese als sogenanntes Dynamic Service Interface<br />
(DSI) bezeichnet. 17<br />
Dienstnehmer<br />
D SI<br />
Generische<br />
Abbildungskomponente<br />
Verwaltungsdomäne A Verwaltungsdomäne B<br />
Heterogenitätsgrenze<br />
Abbildung 3.41: Dynamischer Interzeptor<br />
D II<br />
Diensterbr<strong>in</strong>ger<br />
Das DSI stellt das Komplement zur dynamischen Aufrufschnittstelle (engl. Dynamic<br />
Invocation Interface {DII)dar. Das DSI ermoglicht es, e<strong>in</strong>gehende Operationsaufrufe<br />
beliebiger Art <strong>in</strong> ihre E<strong>in</strong>zelbestandteile zu zerlegen. Diese Informationen<br />
nutzt anschlie end der Interzeptor fur die weitere Umwandlungs{ und<br />
Abbildungsschritte, so da letztendlichder Operationsaufruf an den Diensterbr<strong>in</strong>ger<br />
der Zieldomane weitergeleitet werden kann. Hierfur wird das DII verwendet,<br />
welches das dynamische Kreieren von Operationsaufrufen ermoglicht(siehe auch<br />
Abbildung 3.13).<br />
3.4.3 Ubermittlung von Fremdkonzepten<br />
E<strong>in</strong>e grundsatzliche Problematik bei der Interzeption zwischen verschiedenen<br />
Verwaltungsdomanen ist die Ubermittlung von Fremdkonzepten. Fremdkonzepte<br />
17 <strong>in</strong> Anlehnung an das <strong>in</strong> CORBA 2.0 [OMG95] de nierte DSI
3.4 Domanenubergreifender Dienstzugri 111<br />
bezeichnen Informationen, die nur <strong>in</strong>nerhalb e<strong>in</strong>er Verwaltungsdomane e<strong>in</strong>e Bedeutung<br />
besitzen und somit <strong>in</strong> anderen Domanen nicht <strong>in</strong>terpretierbar s<strong>in</strong>d. E<strong>in</strong><br />
<strong>in</strong>sbesondere fur den Dienstzugri wichtiges Beispiel e<strong>in</strong>es derartigen Fremdkonzeptes<br />
s<strong>in</strong>d B<strong>in</strong>dungs<strong>in</strong>formationen, mitdenen Diensterbr<strong>in</strong>ger <strong>in</strong>nerhalb bestimmter<br />
verteilter Systemplattformen e<strong>in</strong>deutig adressiert werden konnen. Sie<br />
stellen <strong>in</strong> e<strong>in</strong>er anderen <strong>verteilten</strong> Systemplattform opake Informationen dar, die<br />
mit den dort vorhandenen, orig<strong>in</strong>aren Werkzeugen nicht weiter <strong>in</strong>terpretierbar<br />
und somit verarbeitbar s<strong>in</strong>d. E<strong>in</strong> konkretes Beispiel e<strong>in</strong>er B<strong>in</strong>dungs<strong>in</strong>formation<br />
(engl. <strong>in</strong>terface references) ist e<strong>in</strong> im DCE Cell Directory Service (CDS)<br />
[OSF92] de nierter Kontextname, der e<strong>in</strong>en Verweis auf DCE{spezi sche B<strong>in</strong>d<strong>in</strong>g<br />
Handles darstellt, mit denen die DCE{Diensterbr<strong>in</strong>ger adressiert werden<br />
konnen. Beispielsweise kennzeichnet der Name /.:/trade/services/TRADEr<br />
e<strong>in</strong>en Trad<strong>in</strong>g{Dienst, wie er im Rahmen der TRADE{Systemarchitektur implementiert<br />
worden ist. In e<strong>in</strong>er CORBA{ oder ANSA{basierten Systemumgebung<br />
kann dieser Namejedoch nicht s<strong>in</strong>nvoll <strong>in</strong>terpretiert werden, da dieseselbst<br />
andere Adressierungsverfahren verwenden.<br />
E<strong>in</strong>e Situation, bei der B<strong>in</strong>dungs<strong>in</strong>formationen als Fremdkonzepte ubertragen<br />
werden, ist die <strong>in</strong> Abschnitt 3.3.3 vorgestellte verteilte Dienstvermittlung, bei<br />
der Dienstangebots<strong>in</strong>formationen zwischen den kooperierenden Tradern ausgetauscht<br />
werden. Da diese Trader aufgrund der Autonomie der ihnen zugeordneten<br />
Verwaltungsdomanen moglicherweise auf verschiedenen <strong>verteilten</strong> Systemplattformen<br />
ablaufen, be<strong>in</strong>halten die zuruckgelieferten Dienstangebote jeweils die<br />
plattformspezi schen B<strong>in</strong>dungs<strong>in</strong>formationen der <strong>in</strong> ihrer Domane verwalteten<br />
Diensterbr<strong>in</strong>ger, wodurch sichdas obige Interpretationsproblem <strong>in</strong> der anderen<br />
Domane ergibt. Diese Situation ist <strong>in</strong> Abbildung 3.42noch e<strong>in</strong>mal verdeutlicht.<br />
Trader 1<br />
I<br />
n<br />
t<br />
e<br />
r<br />
Trader 2<br />
import(...) ==> InterfaceId_B<br />
z<br />
e<br />
p<br />
t<br />
export(...,InterfaceId_B,...)<br />
Importeur ? o<br />
r<br />
Exporteur<br />
Verwaltungsdomäne A Verwaltungsdomäne B<br />
Abbildung 3.42: Ubertragung von Fremdkonzepten<br />
Die Abbildung zeigt die Kooperation zweier Trader uber e<strong>in</strong>e technische Heterogenitatsgrenze<br />
h<strong>in</strong>weg. Die von dem Dienstnehmer <strong>in</strong> der Domane A <strong>in</strong>itiierte<br />
Dienstanfrage wird uber den Interzeptor zum kooperierenden Trader B der anderen<br />
Domane propagiert. Dieser gibt anschlie end die Informationen e<strong>in</strong>es <strong>in</strong> se<strong>in</strong>em<br />
Verwaltungsbereich vorhandenen Dienstangebots anden Trader A zuruck.
112 Zugang zu Diensten <strong>in</strong> heterogenen Umgebungen<br />
Letztendlich erhalt der Dienstnehmer die enthaltenen B<strong>in</strong>dungs<strong>in</strong>formationen,<br />
die fur ihn <strong>in</strong> se<strong>in</strong>er lokalen Verwaltungsdomane jedoch nicht weiter verwendet<br />
werden konnen, da siedorte<strong>in</strong>Fremdkonzept darstellen.<br />
Generell konnen zwei verschiedeneStrategien zur Behandlung von Fremdkonzepten<br />
beim Ubergang zwischen zwei Verwaltungsdomanen unterschieden werden:<br />
1. Ke<strong>in</strong>e Ubermittlung von Fremdkonzepten:<br />
Aufgrund der Autonomie von Verwaltungsdomanen ist oftmals das<br />
E<strong>in</strong>fuhren von Fremdkonzepten nicht moglich oder beispielsweise aus<br />
Grunden der Sicherheit nicht erwunscht. Hierdurch bed<strong>in</strong>gt s<strong>in</strong>d beider<br />
Interzeption Ma nahmen durchzufuhren, die e<strong>in</strong>e vorherige Umwandlung<br />
der zu ubermittelnden Fremdkonzepte <strong>in</strong> Konzepte der Zieldomane<br />
ermoglichen. Innerhalb der Domanen werden somit ausschlie lich die<br />
dort bereits vorhandenen, orig<strong>in</strong>aren Konzepte zugelassen, ohne da<br />
Anderungen der unterliegenden Systemtechniken notwendig s<strong>in</strong>d.<br />
E<strong>in</strong> moglicher, <strong>in</strong> dieser Arbeit vorgeschlagener Losungsansatz ist die Generierung<br />
sogenannter Stellvertreter (engl. proxies), die <strong>in</strong> der Zieldomane<br />
<strong>in</strong>stanziiert werden. Dabei s<strong>in</strong>d sie eng mit dem orig<strong>in</strong>alen Diensterbr<strong>in</strong>ger<br />
der Ausgangsdomane verknupft, dessen Stellvertretung sieubernommen<br />
haben.<br />
2. Kennzeichnung von Fremdkonzepten bei der Ubermittlung:<br />
Bei diesem Verfahren werden bei der Interzeption die Fremdkonzepte vor<br />
ihrer eigentlichen Ubertragung <strong>in</strong>e<strong>in</strong>eandere Domane besonders gekennzeichnet,<br />
so da diese <strong>in</strong>nerhalbder Zieldomane explizit als Fremdkonzepte<br />
erkanntwerden konnen. In diesem Fall ist es anschlie end notwendig, e<strong>in</strong>e<br />
weitere Verarbeitung und Interpretation der domanenfremden Informationen<br />
vorzunehmen, um auf die Orig<strong>in</strong>al<strong>in</strong>formationen zugreifen zu konnen.<br />
Beide Ansatze erfordern, da Fremd<strong>in</strong>formationen bei der Interaktion zwischen<br />
kooperierenden Partnern zweier Verwaltungsdomanen durch e<strong>in</strong>en Interzeptor<br />
erkannt bzw. ihm im voraus explizit bekannt gegeben werden. Da derartige<br />
Fremd<strong>in</strong>formation neben den oben genannten, plattformspezi schen B<strong>in</strong>dungs<strong>in</strong>formationen<br />
pr<strong>in</strong>zipiell beliebiger, anwendungsspezi scher Art se<strong>in</strong> konnen, ist<br />
Interzeption hierbei jeweils auf die spezi schen Bedurfnisse bestimmter Anwendungsfelder<br />
abzustimmen.<br />
3.5 Zusammenfassung<br />
Zielstellung des vorliegenden Kapitels war die Identi zierung und Beschreibung<br />
von Techniken, die e<strong>in</strong>e adaquateUnterstutzungdes Zugangs zu Diensten <strong>in</strong> o enen<br />
<strong>verteilten</strong> Dienstemarkten erlauben. Hierbei wurden <strong>in</strong>sbesondere die Heterogenitatsprobleme<br />
erortert, die sich aus der Kooperation verschiedener Verwaltungsdomanen<br />
<strong>in</strong>nerhalb von <strong>verteilten</strong> Dienstemarkten ergeben und die den Zugange<strong>in</strong>es<br />
Dienstnehmers zu den Dienstangeboten anderer Verwaltungsdomanen
3.5 Zusammenfassung 113<br />
ma geblich erschweren. Als geeignete Losungsansatze wurden das Diensttypmanagement,dieDienstvermittlung{<br />
und verwaltung (Trad<strong>in</strong>g) und die Interzeption<br />
<strong>in</strong> ihren wesentlichen Konzepten vorgestellt. Diese ermoglichen <strong>in</strong> gegenseitiger<br />
Kooperation e<strong>in</strong>en weitestgehendune<strong>in</strong>geschrankten Dienstzugangunter Berucksichtigung<br />
der <strong>in</strong> o enen <strong>verteilten</strong> Dienstemarkten vorhandenen Heterogenitatsprobleme.<br />
Zusammenfassend ergibt sich somit das <strong>in</strong> Abbildung 3.43dargestellte Gesamtbild,<br />
welches die verschiedenen, <strong>in</strong> diesem Kapitel genauer betrachteten Kooperationsbeziehungen<br />
zwischen Typmanagern, Tradern und Interzeptoren schematisch<br />
wiedergibt.<br />
Typ-<br />
Manager 1<br />
Trader 1<br />
I<br />
n terze<br />
p tor<br />
Typ-<br />
Manager 2<br />
Trader 2<br />
Importeur Exporteur<br />
Abbildung 3.43: Kooperationsbeziehungen beim Dienstzugang<br />
Unter der Voraussetzung technischer und adm<strong>in</strong>istrativer Heterogenitatsgrenzen<br />
zwischen den Verwaltungsdomanen kommtdem Interzeptor e<strong>in</strong>e zentrale Bedeutung<br />
beim Dienstzugri zu, danur uber ihn domanenubergreifende Dienstaufrufe<br />
ablaufen konnen. Dieses gilt auch fur die <strong>in</strong> diesem Kapitel betrachteten Typmanager<br />
und Trader, die den Dienst e<strong>in</strong>es Interzeptors als notwendige Voraussetzung<br />
fur e<strong>in</strong>e domanenubergreifende Kooperation benotigen. Zur Uberw<strong>in</strong>dung<br />
der Heterogenitat nutzt der Interzeptor se<strong>in</strong>erseits die Dienste des Typmanagements,<br />
um die beim domanenubergreifenden Dienstzugri notwendigen Abbildungen<br />
bzw. Umwandlungen der Typisierungs{ und Kommunikationskonzepte<br />
der Ausgangsdomane<strong>in</strong>dieder Zieldomane vorzunehmen. Auf Grundlage dieser<br />
Interzeptionvorgange ist die Realisierung e<strong>in</strong>er <strong>verteilten</strong>, domanenubergreifenden<br />
Dienstvermittlung moglich, die potentiellen Dienstnutzern adaquate Dienstauswahlmechanismen<br />
zum Au nden von " am besten geeigneten Dienstangeboten\<br />
bietet. Dieses geschieht <strong>in</strong>enger Kooperation mit dem Typmanagement,<br />
welches die Suchenachzue<strong>in</strong>em bestimmten Beziehungstyp kompatiblen Diensttypen<br />
unterstutzt und somit die Anzahl potentieller Dienstangebote erhoht. Auerdem<br />
behandelt das Typmanagement die aus der Autonomie der Verwaltungs-
114 Zugang zu Diensten <strong>in</strong> heterogenen Umgebungen<br />
domanen resultierenden Unterschiededer jeweils verwendeten Diensttypbeschreibungssprachen<br />
und Typbezeichnerkonzepte, so da trotzdem auch e<strong>in</strong>Vergleich<br />
von Dienstangeboten heterogener Verwaltungsdomanen moglich ist.<br />
Durch das kooperative Zusammenspiel aller drei Systemkomponenten ergibt sich<br />
somit fur Dienstnehmer e<strong>in</strong> | ohne Berucksichtigung von domanenspezi schen<br />
Restriktionen | weitestgehendune<strong>in</strong>geschrankter Zugang zu Diensten <strong>in</strong> o enen<br />
heterogenen <strong>verteilten</strong> Dienstemarkten.
Kapitel 4<br />
Koord<strong>in</strong>ation von Diensten<br />
Die im vorherigen Kapitel beschriebenen Systemtechniken ermoglichen den Aufbau<br />
e<strong>in</strong>er Dienst<strong>in</strong>frastruktur, die e<strong>in</strong>en weitgehend une<strong>in</strong>geschrankten Zugang<br />
zu den <strong>in</strong> o enen <strong>verteilten</strong> Dienstemarkten vorhandenen Dienstangeboten zur<br />
Verfugung stellt. Mit ihr ero net sich fur e<strong>in</strong>en Dienstnehmer die Moglichkeit,<br />
aus e<strong>in</strong>er gro en Menge verschiedenartigster Dienstangebotezuwahlen, um diese<br />
anschlie end zumErreichen se<strong>in</strong>er beabsichtigten Anwendungsziele zu nutzen.<br />
Durch die Unterstutzung domanenubergreifender Typmanagement{, Trad<strong>in</strong>g{<br />
und Interzeptions{Mechanismen konnen die Dienstangebote sogar auf der Basis<br />
unterschiedlicher verteilter Systemplattformen mit unterschiedlichen Typmodellen<br />
und Dienstaufrufmechanismen realisiert werden, ohne da diese Aspekte der<br />
Heterogenitat von Seiten des Dienstnehmers im besonderen Ma e berucksichtigt<br />
werden mussen. Fur den Dienstnehmer bzw. den Anwendungsentwickler ergibt<br />
sich hierdurch e<strong>in</strong>ee<strong>in</strong>heitliche und abstrakte Sicht auf die <strong>in</strong> o enen <strong>verteilten</strong><br />
Dienstemarkten vorhandenen Dienstangebote. Um diese nun e ektiv nutzen zu<br />
konnen, s<strong>in</strong>d jedochzusatzlich zuden oben genannten Systemtechniken weitere<br />
Unterstutzungsmechanismen erforderlich. Dieses betri t vor allem geeignete<br />
Ausdrucksmittel, mit denen die Nutzung von Diensten im Rahmen verteilter<br />
Anwendungen beschrieben werden kann. Auf dieser Grundlage konnen dann<br />
Steuerungsmechanismen entwickeltwerden, die die Kontrolle der anschlie enden<br />
Anwendungsausfuhrung realisieren.<br />
In e<strong>in</strong>em ersten Schritt stellt dieses Kapitel zunachst verschiedene Arten verteilter<br />
Anwendungen vor, die sich durch ihren ausgepragten dienstnutzungsorientierten<br />
Charakter auszeichnen. Aus ihrer Betrachtung ergeben sich generelle<br />
Anforderungen an Beschreibungskonzepte, die zur Beschreibung koord<strong>in</strong>ierter<br />
<strong>Dienstnutzung</strong> <strong>in</strong> o enen <strong>verteilten</strong> Dienstemarkten notwendig s<strong>in</strong>d. Vor dem<br />
H<strong>in</strong>tergrund der gestellten Anforderungen wird anschlie end der im Rahmen<br />
dieser Arbeit entwickelte Beschreibungsansatz vorgestellt. Er bietet e<strong>in</strong>e vorgangsorientierte<br />
Sicht auf die koord<strong>in</strong>ierte Nutzung von Diensten <strong>in</strong> o enen <strong>verteilten</strong><br />
Dienstemarkten. Formale Grundlage bildet e<strong>in</strong> erweitertes Petri{Netz, das<br />
e<strong>in</strong>e <strong>in</strong>tegrierte Darstellung sowohl der strukturellen als auch der verhaltensbezogenen<br />
Aspekte koord<strong>in</strong>ierter <strong>Dienstnutzung</strong> erlaubt. Hierdurch bed<strong>in</strong>gt eignet<br />
sich dieser Ansatz nicht nur zur Beschreibung von Anwendungsvorgangen, son-
116 Koord<strong>in</strong>ation von Diensten<br />
dern bietet gleichzeitig auch die Grundlage fur ihre Ausfuhrung. Desweiteren<br />
ermoglicht ere<strong>in</strong>eweitgehend direkte Umsetzung <strong>in</strong>e<strong>in</strong>ekonkrete Programmiersprache<br />
und e<strong>in</strong>eSteuerungskomponente zur Ausfuhrung von Anwendungsvorgangen.<br />
Dieses ist am Beispiel der Koord<strong>in</strong>ationssprache PAMELA und des<br />
sogenannten Koord<strong>in</strong>ationsmanagers verdeutlicht, die bei der Darstellung der<br />
TRADE{Systemumgebung <strong>in</strong>TeilIIvorgestellt werden.<br />
4.1 <strong>Dienstnutzung</strong> <strong>in</strong><strong>verteilten</strong> Anwendungen<br />
Verteilte Anwendungen konnen pr<strong>in</strong>zipiell vielfaltigste Formen annehmen, die<br />
von der vergleichsweise e<strong>in</strong>fachen <strong>in</strong>teraktiven Nutzung e<strong>in</strong>zelner Dienste bis h<strong>in</strong><br />
zu komplexen Anwendungssystemen reichen, die sich aus der Komb<strong>in</strong>ation e<strong>in</strong>er<br />
gro en Menge kooperierender Dienste zusammensetzen (siehe auch Abschnitt<br />
1.2). E<strong>in</strong> <strong>in</strong>sbesondere sich aus dem zweiten Fall ergebender <strong>in</strong>teressanter Gesichtspunkt<br />
betri t die Entwicklung neuer verteilter Anwendungen. Hier la t<br />
sich durch dieWiederverwendung [Ber95] bereits vorhandener Dienste e<strong>in</strong>ehohe<br />
E zienz erreichen. Wesentliche Voraussetzung hierfur ist jedoch e<strong>in</strong> gro es<br />
und vielfaltiges Angebot von Diensten, die sowohl generischverwendbare Diensttypen<br />
als auch <strong>in</strong>dividuelle, anwendungsspezi sche Diensttypen realisieren. E<strong>in</strong><br />
o ener verteilter Dienstemarkt kann dann als e<strong>in</strong>e Art Systembaukasten verstanden<br />
werden, dessen Bauste<strong>in</strong>e, die Dienstangebote, beliebig im Rahmen verteilter<br />
Anwendungen komb<strong>in</strong>iert werden konnen [MML95d, MML95e].<br />
4.1.1 Ubergang zur weitestgehenden Nutzung externer Dienste<br />
Generell ist diese Sichtweise der Komb<strong>in</strong>ation von Teildiensten zu e<strong>in</strong>er neuen<br />
Gesamtanwendungauch auf andere Anwendungsbereiche ubertragbar. Insbesondere<br />
<strong>in</strong> H<strong>in</strong>blick auf kommerzielle Gesichtspunkte <strong>in</strong> Dienstemarkten s<strong>in</strong>d sogenannte<br />
Mehrwertdienste [Mer96, Pop95] von zunehmenden Interesse. Mehrwertdienste<br />
zeichnen sich dadurch aus, da sie bereits vorhandene Dienstleistungen<br />
derartig komb<strong>in</strong>ieren, da sich aus der koord<strong>in</strong>ierten Zusammenfuhrungder E<strong>in</strong>zeldienste<br />
und e<strong>in</strong>er hierauf aufsetzenden Anwendungslogik e<strong>in</strong>e neue Art von<br />
Dienst ergibt. E<strong>in</strong> e<strong>in</strong>faches Beispiel hierfur s<strong>in</strong>d Reisevermittlungsdienste, die<br />
die Dienstangebote e<strong>in</strong>zelner Reiseanbieter gesammelt anbieten und zusatzlich<br />
eigene Sonderleistungen anbieten, <strong>in</strong>dem beispielsweise die Suche und Auswahl<br />
geeigneter Reisen unterstutzt wird. Hierbei trittder Kunde nur <strong>in</strong>direkt mit dem<br />
eigentlichen Reiseanbieter uber den Vermittler <strong>in</strong> Kontakt.<br />
Wahrend Mehrwertdienste wiederum herkommliche Dienste mite<strong>in</strong>em neuem<br />
Diensttyp darstellen, s<strong>in</strong>d auch lose gekoppelteFormen von <strong>Dienstnutzung</strong> denkbar.<br />
E<strong>in</strong> <strong>in</strong> letzter Zeit aktuelles Schlagwort s<strong>in</strong>d sogenannte Intelligente Agenten<br />
bzw. Mobile Agenten [Way94, MML96, MLML96], die eigenstandig von e<strong>in</strong>em<br />
Dienstangebot zum anderen wandern und die dortigen Dienstleistungen nutzen.<br />
E<strong>in</strong> oftmals angefuhrtes Beispiel fur die Verwendungvon Agenten s<strong>in</strong>dBuchungsanwendungen,<br />
die aus e<strong>in</strong>er Anzahl von E<strong>in</strong>zelbuchungen, beispielsweise zur Bestellung<br />
von Theaterkarten oder Blumen, bestehen. Hierbei ist es nicht mehr
4.1 <strong>Dienstnutzung</strong> <strong>in</strong><strong>verteilten</strong> Anwendungen 117<br />
erforderlich, da der Initiator des Agenten warten mu , bis das Ergebnis e<strong>in</strong>tri<br />
t. Vielmehr wird hierbei von e<strong>in</strong>em asynchronen Ablauf ausgegangen, bei<br />
dem der Agent nach Erfullung se<strong>in</strong>er Aufgabe, die unter Umstanden recht lange<br />
dauern kann, dem Initiator e<strong>in</strong>e Mitteilung zusendet. Die Art undWeise sowie die<br />
Reihenfolge der <strong>Dienstnutzung</strong> durche<strong>in</strong>en Agenten ist vorabdurch se<strong>in</strong>e Aufgabenbeschreibung<br />
festgelegt. Hierfur werden oftmals sogenannte Skriptsprachen,<br />
beispielsweise Telescript [Whi94], verwendet, mit denen e<strong>in</strong>e e<strong>in</strong>fache Beschreibung<br />
von Ablaufen moglich ist.<br />
AgentenbasierteAnwendungen s<strong>in</strong>dvom Ansatz der <strong>Dienstnutzung</strong>her vergleichbar<br />
mit der ebenfalls <strong>in</strong> der letzten Zeit <strong>in</strong>tensiv untersuchten Klasse der sogenannten<br />
Work ow Management{Anwendungen [Jab95, Rei93],beidenen ebenfalls<br />
die Art und Weise der <strong>Dienstnutzung</strong> durch vorde nierte Proze beschreibungen<br />
von vornhere<strong>in</strong> festgelegt ist. Sie dienen zur Unterstutzung und Optimierung<br />
von unternehmens<strong>in</strong>ternen Arbeitsablaufen, mit dem globalen Ziel, die<br />
Wirtschaftlichkeit e<strong>in</strong>es Unternehmens zu erhohen. Diese wird <strong>in</strong> der Regel durch<br />
die Automatisierung von Arbeitsablaufen erreicht, die durch das Work ow{<br />
Management{System koord<strong>in</strong>iert und uberwachtwerden. Bei der Ausfuhrungder<br />
Arbeitsablaufe werden auch Dienste <strong>in</strong> Anspruch genommen, die durch menschliche<br />
Tatigkeiten erbrachtwerden, um bestimmtezumeist nicht automatisierbare<br />
Aufgaben, wie beispielsweise die Genehmigung oder Ablehnung e<strong>in</strong>es Bankdarlehens,<br />
zu ubernehmen. Konzeptionell werden derartige Diensteaber von sonstigen<br />
Diensten, beispielsweise autonom ablaufenden Datenbank- oder Druckdiensten,<br />
nicht unterschieden.<br />
Trotz der anwendungsspezi schen Unterschiede der oben genannten <strong>verteilten</strong><br />
Anwendungen ist deren geme<strong>in</strong>sames Hauptmerkmal die weitgehende Verwendung<br />
von externen Dienstleistungen, um diese zur Realisierung der Gesamtanwendung<br />
derartig e<strong>in</strong>zusetzen, da sie auf koord<strong>in</strong>ierte Art und Weise das beabsichtigte<br />
Anwendungsziel erreichen. Wird sich auf diesen Aspekt der <strong>Dienstnutzung</strong><br />
konzentriert, lassen sich derartige dienstnutzungsorientierte verteilte Anwendungen<br />
weiter nach dem Grad ihrer <strong>Dienstnutzung</strong> unterscheiden:<br />
1. Partielle <strong>Dienstnutzung</strong>, d.h. im Verlaufe der Anwendungwerden gelegentlich<br />
externe Dienste <strong>in</strong> Anspruch genommen, um gewisse Teilfunktionen<br />
erfullen zu lassen. Die eigentliche Hauptverarbeitung ndet jedoch <strong>in</strong>der<br />
Klientenanwendung statt, die den Anwendungsablauf steuert. E<strong>in</strong> Beispiel<br />
hierfur ist e<strong>in</strong>e Reisebuchungsanwendung, bei der auf verschiedene Datenbankdienste<br />
zur Buchung von Flugen und Hotels zugegri en wird, die Berechnungdes<br />
Gesamtpreises und der Ausdruckder Kundenrechnungjedoch<br />
durch die lokale Klientenanwendung durchgefuhrt wird. Sie ubernimmt<br />
auch die Uberwachung der Ausfuhrung der Dienstzugri e und die Steuerung<br />
der Kooperation der sequentiell oder nebenlau g genutzten Dienste.<br />
2. Weitestgehende <strong>Dienstnutzung</strong>, d.h. die anwendungsspezi sche Verarbeitung<br />
ndet weitestgehendoder sogar vollstandig <strong>in</strong> den genutzten Diensten<br />
bzw. Diensterbr<strong>in</strong>gern statt. In der Gesamtanwendung zu erbr<strong>in</strong>gende Teilaufgaben<br />
und deren Verarbeitung s<strong>in</strong>ddabei so weit wie moglich aus der
118 Koord<strong>in</strong>ation von Diensten<br />
Klientenanwendung <strong>in</strong> externe Dienste ausgelagert. In Ubertragungauf die<br />
Reisebuchungsanwendung bedeutet dieses, da auch die Preisberechnung<br />
und der Belegausdruck durch extern genutzte Dienste erbracht wird.<br />
DurchdieseExternalisierungvon Berechnungsfunktionalitat verandert sich<br />
die Rolle und Aufgabe der Klientenanwendung, die bei e<strong>in</strong>er partiellen<br />
<strong>Dienstnutzung</strong> selbst noch zusatzlich zur Steuerungder <strong>Dienstnutzung</strong> wesentliche<br />
Verarbeitungsaufgaben ubernommen hat. In diesem Fall spielen<br />
die Verarbeitungsaspekte <strong>in</strong>der Klientenanwendung nur noch e<strong>in</strong>euntergeordnete<br />
Rolle, wahrend h<strong>in</strong>gegen die Steuerung und Koord<strong>in</strong>ation der<br />
genutzten Dienste <strong>in</strong>den Vordergrund ruckt.<br />
Beide Arten von <strong>Dienstnutzung</strong> s<strong>in</strong>d<strong>in</strong>Abbildung 4.1 veranschaulicht, wobei<br />
die Kastchen die Ausfuhrung bestimmter Anwendungsfunktionen verdeutlichen,<br />
die entweder durch die Klientenanwendung selbst oder durch externe Dienste<br />
realisiert werden. Die Kanten zwischen den Kastchen deuten den Kontroll u<br />
<strong>in</strong>nerhalb der Klientenanwendungen an.<br />
Klientenanwendung Dienste Klientenanwendung Dienste<br />
Partielle <strong>Dienstnutzung</strong> Weitestgehende <strong>Dienstnutzung</strong><br />
Abbildung 4.1: Grad der <strong>Dienstnutzung</strong><br />
Die oben dargestellteTrennungvon partieller und weitestgehender <strong>Dienstnutzung</strong><br />
zeigt gleichzeitig auch e<strong>in</strong>en moglichen Weg auf, wie zukunftig verteilte Anwendungen<br />
entworfen und realisiert werden konnen. Die ausschlie liche <strong>Dienstnutzung</strong><br />
kann generell als e<strong>in</strong> Idealziel verstanden werden, da jedoch angesichts<br />
der zu erwartenden Vielfalt und Vielzahl verschiedenster Dienstangebote gerade<br />
bei der Anwendungsentwicklung <strong>in</strong> o enen <strong>verteilten</strong> Dienstemarkten zunehmend<br />
realistischer wird. Jedoch auch unabhangig von dem Vorhandense<strong>in</strong> nutzbarer<br />
Dienstangebote <strong>in</strong> o enen <strong>verteilten</strong> Dienstemarkten la t sich das Pr<strong>in</strong>zip weitestgehender<br />
<strong>Dienstnutzung</strong> allgeme<strong>in</strong>gultig bei der Anwendungsentwicklungverwenden.<br />
Ziel ist es dann, schon <strong>in</strong> der Entwurfsphase neue verteilteAnwendungen<br />
derartig modular zu entwerfen, da e<strong>in</strong>e spatere Realisierung der E<strong>in</strong>zelmodule<br />
durch eigenstandige, wiederverwendbare und funktional abgeschlossene Dienste<br />
erfolgen kann. Hierbei sollte jedochvor allem die Wiederverwendung bereitsvor-
4.1 <strong>Dienstnutzung</strong> <strong>in</strong><strong>verteilten</strong> Anwendungen 119<br />
handener, unter Umstanden generischer Anwendungsdienste angestrebt werden,<br />
so da letztendlich nur <strong>in</strong> Ausnahmefallen die Neuentwicklung modulspezi scher<br />
Dienste notwendig ist.<br />
4.1.2 Benotigte Beschreibungs{ und Modellierungskonzepte<br />
Bei dieser Art des Anwendungsentwurfs wird ersichtlich, da sichmitdem Ubergang<br />
zur weitestgehenden <strong>Dienstnutzung</strong> e<strong>in</strong>eWandlung imStil der Realisierung<br />
verteilter Anwendungen vollzieht, bei der zukunftig vor allem die Aspekte der<br />
Koord<strong>in</strong>ation von Diensten adaquat berucksichtigt werden mussen. Dieses bedeutet<br />
<strong>in</strong>sbesondere, da ausdrucksmachtige Modellierungs{ und Beschreibungsmittel<br />
zur Verfugung stehen mussen, mit denen unter anderem der eigentliche<br />
Dienstzugri sowie sequentielle und nebenlau ge <strong>Dienstnutzung</strong>sfolgen ausgedruckt<br />
werden konnen.<br />
Die Moglichkeit der Beschreibung der Koord<strong>in</strong>ation von Diensten ist jedoch nur<br />
e<strong>in</strong>e Anforderung, die an die Ausdrucksmachtigkeit e<strong>in</strong>er Beschreibungssprache<br />
gestellt wird. Insgesamtsollten die folgenden Beschreibungskonzepteunterstutzt<br />
werden:<br />
Datenkonzept: Zur Darstellung der <strong>in</strong> <strong>verteilten</strong> Anwendungen vorhandenen,<br />
<strong>in</strong> der Regel komplex strukturierten Daten mussen geeignete Typkonzepte<br />
unterstutzt werden. Das Datentypkonzept steht hierbei im engen Zusammenhang<br />
mitdem gewahlten Diensttypkonzept, mit dem die strukturellen<br />
Aspekte der <strong>in</strong> den <strong>Dienstnutzung</strong>sfolgen genutzten Dienste beschrieben<br />
werden.<br />
Dienstorientiertes Aktionskonzept: Die beabsichtigte Nutzung von externen<br />
Diensten, die <strong>in</strong> o enen <strong>verteilten</strong> Dienstemarkten angeboten werden,<br />
erfordert Beschreibungsmittel, mit denen die Dienstauswahl und der<br />
Dienstzugri ausgedruckt werden kann. Hierzu ist die Unterstutzung des<br />
Diensttypkonzeptes erforderlich, das die wesentliche Grundlage fur den<br />
Dienstzugang darstellt (siehe hierzu auch die ausfuhrlichen Erlauterungen<br />
im vorherigen Kapitel).<br />
Kontroll u konzept: Zur Beschreibung des Ablaufs verteilter Anwendungen<br />
ist die Bereitstellung e<strong>in</strong>es Kontroll u konzeptes erforderlich, mit dem e<strong>in</strong>e<br />
zustandsabhangige Steuerung ihrer Ausfuhrung moglich ist. Dabei sollten<br />
die <strong>in</strong> Programmiersprachen ublichen Kontroll u konstrukte wie beispielsweise<br />
Verzweigungen, bed<strong>in</strong>gte Auswahl und Schleifen zur Verfugung stehen.<br />
Nebenlau gkeitskonzept: Verteilte Systeme ermoglichen durch ihre <strong>in</strong>harenten<br />
Eigenschaften die nebenlau ge Ausfuhrung von Diensten. Um dieses<br />
optimal ausnutzen zu konnen, ist die Beschreibung von Nebenlau gkeitsaspekten<br />
erforderlich, mit denen sowohl sequentielle als auch nebenlau ge<br />
<strong>Dienstnutzung</strong>sfolgen ausgedruckt werden konnen. Hierbei s<strong>in</strong>d zusatzlich
120 Koord<strong>in</strong>ation von Diensten<br />
auch Synchronisationsaspekte zuberucksichtigen, um beispielsweise e<strong>in</strong>en<br />
konsistenten Zugri auf geme<strong>in</strong>sam genutzte Ressourcen sicherzustellen.<br />
Transaktionskonzept: Bei der sequentiellen und nebenlau gen Nutzung von<br />
Diensten ist es oftmals notwendig, ihre logische Zusammengehorigkeit und<br />
gegenseitigen Abhangigkeiten <strong>in</strong> Form von Transaktionen beschreiben zu<br />
konnen. Hiermit lassen sich dann bestimmte Anforderungen verknupfen,<br />
die die Nutzung e<strong>in</strong>zelner oder auch aller Dienste betre en. E<strong>in</strong> <strong>in</strong> diesem<br />
Zusammenhang oft verwendetes Konzept ist das der bekannten ACID{<br />
Transaktionen [GR93], mit dem die Eigenschaften der Atomaritat, Konsistenz,<br />
Isolation undDauerhaftigkeit bei der sequentiellen undnebenlau gen<br />
Ausfuhrung von Teilschritten e<strong>in</strong>er Gesamttransaktion sicherstellt werden.<br />
Fehlerbehandlungskonzept: Die Nutzung von Diensten, die pr<strong>in</strong>zipiell beliebig<br />
raumlich verteilt se<strong>in</strong> konnen, erfordert die Berucksichtigung spezieller<br />
Fehlerfalle, die bei e<strong>in</strong>er ausschlie lich lokalen Ausfuhrung nicht auftreten.<br />
Dieses s<strong>in</strong>d <strong>in</strong>sbesondere Fehler, die sich aus der Abhangigkeit von<br />
der Kommunikations<strong>in</strong>frastruktur ergeben und sichgegebenfalls direkt bis<br />
auf die Anwendungsebene auswirken und sogar zum Abbruch der gesamten<br />
Anwendung fuhren konnen. Des weiteren mussen auch Fehler bei der<br />
der Dienstauswahl berucksichtigt werden, so da beispielsweise beim Nichtvorhandense<strong>in</strong><br />
e<strong>in</strong>es geeigneten Dienstangebotes geeigneteFehlererholungsma<br />
nahmen <strong>in</strong>itiiert werden konnen.<br />
Interaktionskonzept: Je nach beabsichtigter Zielstellung e<strong>in</strong>er <strong>verteilten</strong><br />
Anwendung mussen Interaktionen von Benutzern bei der Anwendungsausfuhrung<br />
berucksichtigt werden. Im e<strong>in</strong>fachsten Fall kann e<strong>in</strong> Benutzer<br />
hierbei als e<strong>in</strong> Dienst aufgefa t werden, der uber e<strong>in</strong>en Diensttyp formal<br />
de niert ist. Somit werden die Leistungen e<strong>in</strong>es Benutzers und die<br />
der sonstigen, automatisiert ablaufenden Diensterbr<strong>in</strong>ger homogen und<br />
orthogonal behandelbar (siehe auch [MML95d, MML95d]). Zusatzlich ist<br />
jedoch auch die umgekehrte Situation zu berucksichtigen, da externe<br />
Benutzere<strong>in</strong>gaben unabhangig vom konkreten Ausfuhrungszustand der<br />
Anwendung getatigt werden konnen. Hierfur mussen explizite Zugangspunkte<br />
de nierbar se<strong>in</strong>, an denen die Interaktion statt nden kann. Diese<br />
konnen pr<strong>in</strong>zipiell auch anderen Anwendungen als Interaktionsschnittstelle<br />
dienen.<br />
Strukturierungskonzept: Initialer Schritt der Entwicklung jeder geplanten<br />
<strong>verteilten</strong> Anwendung sollte dar<strong>in</strong> bestehen, die vorhandene Komplexitat<br />
des Gesamtanwendungsproblems zu reduzieren, so da e<strong>in</strong>e dedizierte<br />
Behandlung von Teilproblemen moglich ist. Hierfur ist e<strong>in</strong> Strukturierungskonzept<br />
anzubieten, welches neben der Modularisierung der <strong>verteilten</strong><br />
Anwendung auch die anschlie ende Komb<strong>in</strong>ation der E<strong>in</strong>zelmodule<br />
unterstutzt. Begleitend zu diesem strukturierten Entwurf verteilter<br />
Anwendungen ist auch die Unterstutzung durch analytische Verfahren<br />
wunschenswert. Hiermit la t sich der voraussichtliche Anwendungsablauf<br />
unter Umstanden bereits vor der eigentlichen Realisierung auf bestimmte
4.2 Beschreibung und Modellierung koord<strong>in</strong>ierter <strong>Dienstnutzung</strong> 121<br />
Eigenschaften, beispielsweise se<strong>in</strong>e Lebendigkeit oder Verklemmungsfreiheit<br />
bei der nebenlau gen Nutzung von Diensten, untersuchen. In diesem<br />
Zusammenhang ist auch der E<strong>in</strong>satz simulativer Methoden [Pag91] s<strong>in</strong>nvoll,<br />
mit denen e<strong>in</strong>e praxisnahe Erprobung vorhandener Entwurfs{ und<br />
Realisierungsergebnisse moglich ist.<br />
4.2 Beschreibung und Modellierung koord<strong>in</strong>ierter<br />
<strong>Dienstnutzung</strong><br />
Auf dem H<strong>in</strong>tergrund der im vorherigen Abschnitt geforderten Beschreibungs{<br />
und Modellierungskonzepte stellt dieser Abschnitt e<strong>in</strong>en Ansatz vor, der e<strong>in</strong>e<br />
abstrakte Sicht auf koord<strong>in</strong>ierte Nutzung von Diensten <strong>in</strong> o enen <strong>verteilten</strong><br />
Dienstemarkten ermoglicht. Zuvor werden jedoch zuerst grundlegende Begriffe<br />
de niert, die e<strong>in</strong>e durchgangige und e<strong>in</strong>heitliche Darstellung des Ansatzes<br />
ermoglichen. Des weiteren wird auch die Wahl von Petri{Netzen motiviert, die<br />
dem Beschreibungsansatz als formale Grundlage dienen.<br />
4.2.1 Kooperationsanwendungen und Anwendungsvorgange<br />
Zur besonderen Betonung der spezi schen Eigenschaft der koord<strong>in</strong>ierten Nutzung<br />
von Diensten, die im Rahmen e<strong>in</strong>er Anwendungsausfuhrung mite<strong>in</strong>ander<br />
kooperieren, werden die hier betrachteten <strong>verteilten</strong> Anwendungen im folgenden<br />
als Kooperationsanwendungen bezeichnet. Kooperationsanwendungen unterstreichen<br />
den <strong>in</strong> Abschnitt 4.1.1 beschriebenen Ubergang zur weitestgehenden Verwendung<br />
extern angebotener Dienste. Sie s<strong>in</strong>d vergleichbar mit den <strong>in</strong> [Tsc94]<br />
vorgestellten kooperativen Anwendungen, die als " (:::)permanenteoder zeitweilige<br />
Zusammenschlusse von Benutzern und Komponenten zumZweckkoord<strong>in</strong>ierter,<br />
zielgerichteter Aktivitaten (:::)\ de niert s<strong>in</strong>d.<br />
De nition 4.1 (Kooperationsanwendungen) Kooperationsanwendungen<br />
bezeichnen e<strong>in</strong>e Klasse verteilter Anwendungen, die durch ihren ausgepragten<br />
dienstnutzungsorientierten Charakter gekennzeichnet s<strong>in</strong>d. Dieser au ert sich<br />
dar<strong>in</strong>, da bei ihrer Ausfuhrung ausschlie lich externe Dienste verwendet<br />
werden, auf die im Rahmen von Anwendungsvorgangen zugegri en wird.<br />
De nition 4.2 (Anwendungsvorgang) E<strong>in</strong> Anwendungsvorgang beschreibt<br />
die Handlungen, die ausgefuhrt werden mussen, um das beabsichtigte Anwendungsziel<br />
zu erreichen. Er ist identi ziert durch e<strong>in</strong>en Namen und besteht aus<br />
e<strong>in</strong>er Folge sequentiell oder parallel ausgefuhrter Aktivitaten, die partiell geordnet<br />
s<strong>in</strong>d.<br />
De nition 4.3 (Aktivitat) E<strong>in</strong>e Aktivitat beschreibt e<strong>in</strong>en Block von Aktionen,<br />
die geme<strong>in</strong>sam ausgefuhrt werden. Sie wird identi ziert durch e<strong>in</strong>en Namen<br />
und besteht aus e<strong>in</strong>er Aktionsbeschreibung sowie e<strong>in</strong>er e<strong>in</strong>schrankenden Bed<strong>in</strong>gung,<br />
die spezi ziert, wann sie ausgefuhrt werden kann. Die Aktionsbeschreibung
122 Koord<strong>in</strong>ation von Diensten<br />
besteht entweder aus e<strong>in</strong>er elementaren Aktion oder e<strong>in</strong>er Menge elementarer<br />
Aktionen, die sequentiell oder parallel ausgefuhrt werden.<br />
De nition 4.4 (Aktion) E<strong>in</strong>e elementare Aktion entspricht dem Aufruf e<strong>in</strong>er<br />
e<strong>in</strong>zelnen Operation an der Schnittstelle e<strong>in</strong>es Diensterbr<strong>in</strong>gers. Der genutzte<br />
Dienst wird beschrieben durch se<strong>in</strong>en Diensttyp und ihn e<strong>in</strong>grenzende Dienstattribute,<br />
die die gewunschten Eigenschaften des Dienstes festlegen.<br />
Insgesamt ergibt sich somit e<strong>in</strong>e hochgradig nebenlau ge Ausfuhrung von Kooperationsanwendungen.<br />
Dieses ist <strong>in</strong> Abbildung 4.2 schematisch verdeutlicht.<br />
Aktivitität<br />
Anwendungsvorgang<br />
Aktivitität<br />
Aktivitität<br />
Aktion<br />
Aktivitität<br />
Aktion<br />
Aktion<br />
Dienst<br />
Aktion<br />
Abbildung 4.2:Nebenlau gkeit von Aktivitaten und Aktionen<br />
Je nach betrachtetem Anwendungsbereich nden sich<strong>in</strong>der Literatur e<strong>in</strong>e Anzahl<br />
alternativer Benennungen fur Kooperationsanwendungen bzw. von Anwendungsvorgangen,<br />
die je nach betrachtetem Anwendungsumfeld beispielsweise als geregelte<br />
arbeitsteilige Anwendungssysteme [Rei93], Auftragssysteme [JV87] bzw.als<br />
Work ows [LA94, Jab95] oder ConTracts [WR91] bezeichnet werden. Entsprechend<br />
wirddieSteuerung von Anwendungsvorgangen unter anderem als Worow<br />
Management, Activity Management [Jab93] und Ablaufsteuerung [W<strong>in</strong>93]<br />
bezeichnet. In dieser Arbeit wird hierfur zusammenfassendauch der Begri Koord<strong>in</strong>ationsmanagement<br />
verwendet.<br />
4.2.2 Petri{Netze als Beschreibungsgrundlage<br />
Petri{Netze [Pet62] s<strong>in</strong>d e<strong>in</strong> <strong>in</strong> den sechziger Jahren von C.A. Petri entwickeltes<br />
Beschreibungskonzept, mit dem e<strong>in</strong>e naturliche und ausdrucksstarkeDarstellung<br />
von Informations- und Kontroll ussen <strong>in</strong> Systemen mit asynchronen und<br />
nebenlau gen Prozessen ermoglicht wird. Petri{Netze besitzen e<strong>in</strong>e wohlde -<br />
nierte mathematische Basis, auf derer e<strong>in</strong>e formale Analyse statischer und dynamischer<br />
Netzeigenschaften moglich ist (siehe beispielsweise [Pet81, Rei86]).<br />
Durch diese Eigenschaft und auch durch ihre anschauliche Darstellungsweise<br />
<strong>in</strong> Form e<strong>in</strong>er graphischen Netzdarstellung haben Petri{Netze mittlerweile<br />
<strong>in</strong> zahlreichen Anwendungsbereichen Verwendung gefunden. Dieses betri t<br />
unter anderem auch Entwicklungsprojekte im Bereich verteilter Anwendungen,
4.2 Beschreibung und Modellierung koord<strong>in</strong>ierter <strong>Dienstnutzung</strong> 123<br />
wo Petri{Netze vor allem wegen ihrer Analysemethoden h<strong>in</strong>sichtlich der Verikation<br />
komplexer Anwendungsablaufe e<strong>in</strong>gesetzt werden (siehe beispielsweise<br />
<strong>in</strong> [Ric83, SV89,Mur89]). Die breite Basis ihrer Verwendung hat auch dazu<br />
gefuhrt, da dem Anwendungsentwickler mittlerweile verschiedene Hilfsmittel<br />
zur Verfugungstehen. Beispiele hierfur s<strong>in</strong>dunter anderem Laufzeit{Simulatoren<br />
wie Design/CPN [Met93] oder LOOPN [Lak92], das e<strong>in</strong>e sprachorientierte Umsetzung<br />
der graphischen Petri{Netz{Darstellung realisiert. Diese unterstutzen <strong>in</strong><br />
der Regel nichtnur die Spezi kation von sequentiellen und nebenlau gen Anwendungssystemen,<br />
sondern erlauben zumeist schon wahrendder Spezi kationsphase<br />
Teilanalysen und auch simulative Tests.<br />
Ausschlaggebender Grund fur die Verwendung von Petri{Netzen als formale<br />
Grundlage fur den hier vorgeschlagenen Ansatz zur Beschreibung verteilter Anwendungsausfuhrung<br />
ist <strong>in</strong>sbesondere ihre Eigenschaft, sowohl die Struktur von<br />
Anwendungsvorgangen als auch ihreAusfuhrung <strong>in</strong>e<strong>in</strong>em <strong>in</strong>tegrierten und mathematisch<br />
fundierten Ansatz beschreiben zu konnen. Hierdurch erleichtert sich<br />
auch die spatere Realisierung e<strong>in</strong>er konkreten Ausfuhrungsumgebung fur Anwendungsvorgange,<br />
da mitder Petri{Netz{basierten Beschreibung e<strong>in</strong>es Anwendungsvorgangs<br />
gleichzeitig auch se<strong>in</strong>e Ausfuhrungssemantik e<strong>in</strong>deutig festgelegt<br />
ist.<br />
Grundlage fur die weitere Darstellung bilden die Stellen{/Transitionsnetze, die<br />
e<strong>in</strong>e wesentliche Grundform von Petri{Netzen darstellen. Aus graphentheoretischer<br />
Sicht s<strong>in</strong>d sie als bipartiter, gerichteter Graph mit Stellen und Transitionen<br />
als Knoten darstellbar, wobei die Knoten uber gewichtete Kanten mite<strong>in</strong>ander<br />
verbunden s<strong>in</strong>d. Durch die Richtung der Kanten s<strong>in</strong>d die Stellen entweder als<br />
E<strong>in</strong>gangs{ oder Ausgangsstellen von Transitionen de niert. Der Zustand e<strong>in</strong>es<br />
Netzes bzw. des damit beschriebenen Systems wird durch e<strong>in</strong>e Markierung beschrieben,<br />
die jeder Stelle e<strong>in</strong>e Anzahl von Marken zuordnet. E<strong>in</strong>e formale Beschreibung<br />
gibt die folgende De nition:<br />
De nition 4.5 (Stellen-/Transitionsnetz) E<strong>in</strong> Stellen{/Transitionsnetz ist<br />
e<strong>in</strong> 6{Tupel N =(S� T� F� K� W�m 0) mit:<br />
e<strong>in</strong>er Menge von Stellen S = fS 1�S 2�:::�Sng,<br />
e<strong>in</strong>er dazu disjunkten nichtleeren Menge von Transitionen T =<br />
fT 1�T 2�:::�Tmg,<br />
e<strong>in</strong>er Flu relation F (S T ) [ (T S),<br />
e<strong>in</strong>er Kapazitatsfunktion K : S ! IN [f1g,<br />
e<strong>in</strong>er Kantengewichtung W :(S T ) [ (T S) ! IN mit W (x� y) =0<br />
genau dann, wenn (x� y) =2 F ,<br />
e<strong>in</strong>er Anfangsmarkierung m 0 : S ! IN mit m 0(s) K(s) fur s 2 S.<br />
Wie oben bereitsangedeutet wurde, eignen sichPetri{Netze sowohl zur Beschreibung<br />
statischer als auch dynamischer Eigenschaften. Wahrend sich die statischen
124 Koord<strong>in</strong>ation von Diensten<br />
Eigenschaften <strong>in</strong> der Netzstruktur widerspiegeln, resultiert die Dynamik e<strong>in</strong>e<br />
Netzes aus se<strong>in</strong>er Ausfuhrung, bei der Marken durch das Schalten der Transitionen<br />
durch das Netz bewegt werden. Das Schalten e<strong>in</strong>er Transition setzt deren<br />
Aktivierung voraus. E<strong>in</strong>e Transition hei t aktiviert,wenn samtlicheE<strong>in</strong>gangsstellen<br />
der Transition mit e<strong>in</strong>er der Kantengewichtung entsprechenden Anzahl von<br />
Marken belegt s<strong>in</strong>d. E<strong>in</strong> aktivierteTransition kann anschlie end schalten, <strong>in</strong>dem<br />
sie der Kantengewichtung entsprechend viele Marken von allen ihren E<strong>in</strong>gangsstellen<br />
entferntund gema der Kantengewichtungentsprechend viele Marken auf<br />
ihren Ausgangsstellen ablegt. Hierdurch entsteht e<strong>in</strong>eneue Markierung, die wiederum<br />
Grundlage fur die Aktivierung und das Schalten weiterer Transitionen<br />
bildet. Das Schalten mehrerer Transitionen kann gleichzeitig erfolgen, wie auch<br />
e<strong>in</strong>e Transition gleichzeitig zu sich selbst schalten kann. Der Schaltvorgang geschieht<br />
unmittelbar und zeitverzugslos. Die Menge aller moglichen Schaltfolgen<br />
e<strong>in</strong>es Petri{Netzes legt se<strong>in</strong>en Erreichbarkeitsgraph fest, der die Gesamtheit der<br />
im Netz e<strong>in</strong>nehmbaren Zustande umfa t.<br />
Ausgehend von diesem e<strong>in</strong>fachen Modell der Stellen{/Transitionsnetze s<strong>in</strong>d ersteMoglichkeiten<br />
fur ihre Nutzung zur Beschreibung von Anwendungsvorgangen<br />
bereits o ensichtlich. So bietet sichunmittelbar e<strong>in</strong>e Zuordnungder Transitionen<br />
zu den Aktivitaten e<strong>in</strong>es Anwendungsvorganges an, wobei die Kanten des Netzes<br />
e<strong>in</strong>en moglichen Aktivitats u verdeutlichen, der durch den Erreichbarkeitsgraphen<br />
des Petri{Netzes bestimmt wird.<br />
4.2.3 Beschreibungskonzepte<br />
Im folgenden werden die Konzepte des hier vorgeschlagenen Ansatzes zur Beschreibung<br />
von Anwendungsvorgangen <strong>in</strong> ihren Details vorgestellt. Die Darstellung<br />
orientiert sich hierbei an den <strong>in</strong> Abschnitt gestellten 4.1.2 Beschreibungsanforderungen.<br />
Um diese Anforderungen erfullen zu konnen, s<strong>in</strong>d Erweiterungen<br />
der grundlegenden Stellen{/Transitionsnetze vorzunehmen. Generelle Zielstellung<br />
ist hierbei die Verwendung bereits aus der Petri{Netz{Theorie stammender<br />
Vorschlage. Hierdurch wird e<strong>in</strong>eweitgehendnahtlose Integration undVertraglichkeit<br />
mit den vorhandenen Grundkonzepten von Stellen{/Transitionsnetzen sichergestellt.<br />
So kann auch auf bereits vorhandene Analysewerkzeuge zugegri en<br />
werden, die grundsatzlich auch fur die Analyse von Anwendungsvorgangen verwendbar<br />
s<strong>in</strong>d.<br />
4.2.3.1 Datenkonzept<br />
Zur Darstellung von komplex strukturierten Daten, die <strong>in</strong> der Regel bei der<br />
Ausfuhrung von Anwendungsvorgangen zwischen den Aktivitaten ausgetauscht<br />
werden, ist e<strong>in</strong>e Erweiterungdes Markenkonzeptes der Stellen{/Transitionsnetze<br />
notwendig, da dort die Marken aufgrund ihrer Uniformitat ke<strong>in</strong>e <strong>in</strong>nere Struktur<br />
und Identitat besitzen.<br />
Unterstutzungfur e<strong>in</strong> derartiges Datenkonzept bieten sogenannte Gefarbte Petri{
4.2 Beschreibung und Modellierung koord<strong>in</strong>ierter <strong>Dienstnutzung</strong> 125<br />
Netze [JR91, Jen92], die zur Klasse der hoheren Petri{Netze gehoren. 1 Hier besitzen<br />
die Marken e<strong>in</strong>e Identitat, die sie e<strong>in</strong>deutig unterscheidbar zu anderen<br />
macht, und e<strong>in</strong>e Typisierung, mit der e<strong>in</strong>e Darstellung komplex strukturierter<br />
Daten moglich wird. Beide Eigenschaften spiegeln sich <strong>in</strong>der folgenden De nition<br />
[JR91] wider:<br />
De nition 4.6 (Gefarbtes Petri{Netz) E<strong>in</strong> gefarbtes Petri{Netz ist e<strong>in</strong><br />
Stellen/Transitionsnetz (S,T,F,K,Mo) mit den zusatzlichen Eigenschaften<br />
( ,C,G,E):<br />
=fC 1�C 2�:::�Cpg ist e<strong>in</strong>e endliche Menge von Typen, genannt Farbenmengen.<br />
Jede Farbenmenge Cn ist endlich und nicht leer.<br />
C : S ! ist e<strong>in</strong>e Farbenfunktion, die jeder Stelle e<strong>in</strong>e Farbenmenge<br />
zuordnet.<br />
G : T ! BoolExpr ist e<strong>in</strong>e logische Schaltbed<strong>in</strong>gung ( " Guard\), die<br />
jeder Transition e<strong>in</strong>en logischen Ausdruck (BoolExpr) zuordnet, der zu<br />
wahr oder falsch evaluiert und der das Schaltverhalten der Transition e<strong>in</strong>schrankende<br />
Bed<strong>in</strong>gungen spezi ziert.<br />
E : F ! Expr ist e<strong>in</strong>e Kantenausdrucksfunktion, die selektiert, welche<br />
Markenfarben beim Schalten der Transition von den E<strong>in</strong>gangsplatzen entfernt<br />
und welche auf den Ausgangsplatzen abgelegt werden. Sie wird durch<br />
e<strong>in</strong>en logischen Ausdruck (Expr) beschrieben, der zu e<strong>in</strong>er Multimenge 2<br />
von Farben evaluiert. Die Variablen des Ausdrucks s<strong>in</strong>d aus der Farbenmenge,<br />
die durch die Farbenfunktion C der mit der Kante verbundenen<br />
Stelle zugeordnet ist.<br />
Die Anfangsmarkierung ist fur gefarbte Petri{Netze de niert als M 0 : S !<br />
fc j c 2 g�<br />
Mit der Typsierung der Marken la t sich | <strong>in</strong> Analogie zur Typisierung von<br />
Diensten (siehe Abschnitt 2.3) | die <strong>in</strong>terne Struktur e<strong>in</strong>er Marke auf wohde -<br />
nierte Art und Weise festlegen. Die Typisierung der Marken wirkt sich auch auf<br />
den Schaltvorgangaus, der <strong>in</strong> Abhangigkeit von der Auswertungder Kantenausdruckeunddurchdiee<strong>in</strong>er<br />
Transition zugeordneten logischen Schaltbed<strong>in</strong>gungen<br />
ausgefuhrt wird.<br />
Die Wahl e<strong>in</strong>es bestimmten Datentypmodells wird durch die De nition nicht<br />
festgelegt, sondern kann <strong>in</strong> H<strong>in</strong>blickauf das beabsichtigteAnwendungsumfeld bestimmtwerden.<br />
Im Modellierungswerkzeug Design/CPN [Met93] wird beispielsweise<br />
das Typmodell der Sprache ML [Mil84] unterstutzt. Bei der Beschreibung<br />
von Anwendungsvorgangen wird sich die Wahl e<strong>in</strong>es konkreten Datentypmodells<br />
1 Die Bezeichnung Gefarbtes Petri{Netz erklart sich aus se<strong>in</strong>er graphischen Darstellungsweise,<br />
<strong>in</strong> der die unterschiedlichen Marken ursprunglich durch farbige Punkte unterschieden<br />
wurden.<br />
2 E<strong>in</strong>e Multimenge kann e<strong>in</strong> Element mehrfach enthalten.
126 Koord<strong>in</strong>ation von Diensten<br />
<strong>in</strong> der Regel <strong>in</strong> Abhangigkeit vom Diensttypmodell ergeben, welches fur die abstrakteBeschreibungder<br />
Diensteund ihrer Schnittstellen verwendet wird. Dieses<br />
ist beispielsweise auch beider <strong>in</strong> Teil II dieser Arbeit vorgestellten Koord<strong>in</strong>ationssprache<br />
PAMELA der Fall, der das Typsystem von CORBA zugrunde liegt.<br />
4.2.3.2 Kontroll u konzept<br />
Die Schaltbed<strong>in</strong>gungen und Kantenausdrucke gefarbter Petri{Netze ermoglichen<br />
e<strong>in</strong>e Darstellung zustandsgesteuerter Kontroll usse, wie es <strong>in</strong> Abschnitt 4.1.2 gefordert<br />
wurde. Mit ihnen konnen die aus Programmiersprachen bekannten Konzepte<br />
wie die bed<strong>in</strong>gteVerzweigung, Auswahl und Schleife dargestelltwerden, die<br />
fur die Steuerung komplizierter Anwendungsvorgange erforderlich s<strong>in</strong>d. Hierfur<br />
ist e<strong>in</strong>e Erweiterung der Kernkonzepte gefarbter Petri{Netze nicht notwendig.<br />
Abbildung 4.3 verdeutlicht verschiedene Kontroll u konstrukte, wobei die Kantenbed<strong>in</strong>gungen<br />
durch <strong>in</strong>formelle logische Ausdrucke reprasentiert s<strong>in</strong>d.<br />
a<br />
a=1 / a=1<br />
Bed<strong>in</strong>gte Verzweigung<br />
a+1<br />
a<br />
a
4.2 Beschreibung und Modellierung koord<strong>in</strong>ierter <strong>Dienstnutzung</strong> 127<br />
denen Informationen undMaterialien verarbeitet werden, wodurchsich beispielsweise<br />
die Arbeit e<strong>in</strong>es Sachbearbeiters oder e<strong>in</strong>er Masch<strong>in</strong>e beschreiben la t. Da<br />
Instanzen uber die Kanale <strong>in</strong>teragieren, s<strong>in</strong>d unter anderem Informations{ und<br />
Material usse <strong>in</strong> e<strong>in</strong>em System darstellbar. Diese Sichtweise auf Petri{Netze<br />
ermoglicht die Betrachtung von Transitionen als Funktionsse<strong>in</strong>heiten [Val87],<br />
die Zustandsanderungen im AnwendungsvorgangdurchdieAusfuhrungvon Operationen<br />
bewirken und sichkonkret <strong>in</strong> Anderungen der Markierung des Petri{<br />
Netzes zeigen.<br />
In Anwendung auf die Beschreibung von Anwendungsvorgangen liegt es deshalb<br />
nahe, die Transitionen mit externen Diensten zu verknupfen, die mittels von<br />
Operationsaufrufen zuganglich s<strong>in</strong>dund die Verarbeitungder <strong>in</strong> den Marken vorhandenen<br />
Informationen ubernehmen. Das Transitionskonzept von Petri{Netzen<br />
erganzt sich hierdurch ume<strong>in</strong>e externe Interaktion, bei der die Dienste externer<br />
Dienstnehmer bei der Ausfuhrung e<strong>in</strong>er Transitionen <strong>in</strong> Anspruch genommen<br />
werden (Abbildung 4.4).<br />
Externer Dienst<br />
Abbildung 4.4:Anb<strong>in</strong>dung von Diensten an Transitionen<br />
Die Verknupfung von Transition und Diensterbr<strong>in</strong>ger wird uber den Diensttyp<br />
erreicht, der die Beschreibung der geforderten Dienstattributeund der Aufrufparameter<br />
der Operation umfa t. Die konkreten Parameterwerte ergeben sich aus<br />
den Marken, die von der Transition von den E<strong>in</strong>gangsstellen entfernt werden.<br />
Die Weitergabe der vom Diensterbr<strong>in</strong>ger zuruckgelieferten Ergebnisse erfolgt anschlie<br />
end durch Erzeugung entsprechender Marken auf den Ausgangsstellen der<br />
Transition.<br />
Formal lassen sich derartige, um Dienstaufrufe erweiterten Petri{Netze auf zeitbehaftete<br />
Petri{Netze (engl. timed petri nets) [Jen95]abbilden. Mit ihnen konnen<br />
im Unterschied zu herkommlichen Stellen{/Transitionsnetzen, bei denen das<br />
Schalten e<strong>in</strong>er Transition zeitverzugslos geschieht, Verweilzeiten <strong>in</strong> den Transitionen<br />
ausgedruckt werden. Der Schaltvorgang e<strong>in</strong>er Transition untergliedert<br />
sich dann <strong>in</strong> mehrere Schaltphasen [Mar89]:<br />
1. In der Startphase (engl. start r<strong>in</strong>g phase) werden die Marken von den<br />
E<strong>in</strong>gangsstellen entfernt�<br />
2. In der Schaltphase (engl. r<strong>in</strong>g <strong>in</strong> progress phase) be nden sich die Marken<br />
" <strong>in</strong>\ der Transition�
128 Koord<strong>in</strong>ation von Diensten<br />
3. In der Endphase (engl. end r<strong>in</strong>gphase) werden die Marken auf den Ausgangsstellen<br />
abgelegt.<br />
Die Darstellung des Zeitverbrauchs <strong>in</strong> der Schaltphase geschieht hierbei mittels<br />
stochastischer Verfahren, die anschlie end auch imRahmen weiterer Netzanalysen<br />
genutzt werden konnen (siehe beispielsweise [Mar89]).<br />
4.2.3.4 Nebenlau gkeitskonzept<br />
Bed<strong>in</strong>gt durch ihre formale De nition stellen Petri{Netze bereits die wesentlichen<br />
Beschreibungsmittel zur Verfugung, die zur Wiedergabe der Dynamik<br />
nebenlau ger Aktivitaten notwendig s<strong>in</strong>d. Aus Sicht von Kooperationsanwendungen<br />
und den dort ausgefuhrten Anwendungsvorgangen ist <strong>in</strong>sbesondere die<br />
Beschreibung der Inter{ und Intravorgangsnebenlau gkeit von Interesse. Erstere<br />
bezeichnet die Nebenlau gkeit, die <strong>in</strong> e<strong>in</strong>er Kooperationsanwendung durch<br />
die gleichzeitige Abwicklung mehrerer identischer Anwendungsvorgange auftritt.<br />
Die Intravorgangsnebenlau gkeit tritt dann auf, wenn <strong>in</strong>nerhalb e<strong>in</strong>es e<strong>in</strong>zelnen<br />
Anwendungsvorgangs mehrere verschiedene Aktivitaten gleichzeitig ausgefuhrt<br />
werden. Abbildung 4.5verdeutlicht beideVarianten.<br />
Abbildung 4.5: Inter- und Intravorgangsnebenlau gkeit<br />
Wahrend sich die Intravorgangsnebenlau gkeit durch gleichzeitiges Schalten<br />
mehrerer Transitionen darstellen la t, druckt sich die Intervorgangsnebenlau gkeit<br />
<strong>in</strong> Form von Transitionen aus, die zu sichselbst nebenlau g schalten. Hierbei<br />
werden die <strong>in</strong> der Abbildung gezeigten zwei Marken, die jeweils e<strong>in</strong>em Anwendungsvorgang<br />
zugeordnet s<strong>in</strong>d, durch die Transition konzeptuell gleichzeitig und<br />
unabhangig vone<strong>in</strong>ander verarbeitet. Aufgrund der Unterscheidbarkeit der Marken<br />
<strong>in</strong> gefarbten Petri{Netzen la t sich hierdurch die unabhangige Bearbeitung<br />
mehrerer Anwendungsvorgange <strong>in</strong> e<strong>in</strong>em Petri{Netz beschreiben.<br />
Im Zusammenhangmitdem nebenlau gen Schalten der Transitionen s<strong>in</strong>d zusatzlich<br />
auch Konsistenzaspektezuberucksichtigen, die beim Zugri auf geme<strong>in</strong>sam<br />
genutzte Ressourcen auftreten. Klassische Beispiele derartiger Synchronisationsproblemes<strong>in</strong>ddas<br />
<strong>in</strong> [JV87, HH89]ausfuhrlich dargestellte Leser/Schreiber{ und<br />
das 5{Philosophen{Problem, an denen sich exemplarischzahlreiche Algorithmen<br />
fur die Analyse von Petri{Netzen, beispielsweise fur die Uberprufungder Lebendigkeit<br />
e<strong>in</strong>es Netzes, zeigen lassen. E<strong>in</strong> genereller Losungsansatz hierfur, der von
4.2 Beschreibung und Modellierung koord<strong>in</strong>ierter <strong>Dienstnutzung</strong> 129<br />
se<strong>in</strong>em Grundpr<strong>in</strong>zip her auchfur andere Koord<strong>in</strong>ationsprobleme(siehe beispielsweise<br />
auch [MC94]) anwendbar ist, ist die De nition von sogenannten kritischen<br />
Abschnitten (Abbildung 4.6).<br />
Abbildung 4.6: Wechselseitiger Ausschlu im kritischen Abschnitt<br />
Die Realisierung des <strong>in</strong> der Abbildung grau unterlegten kritischen Abschnitts<br />
erfolgt mittels e<strong>in</strong>er Synchronisationsstelle, die vergleichbar zum aus dem Betriebssystembereich<br />
bekannten Semaphor [PS85] ist. Der kritische Abschnitt<br />
darf von den nebenlau gen Prozessen nur im wechselseitigen Ausschlu betreten<br />
werden, was sich konkret im Petri{Netz dar<strong>in</strong> ausdruckt, da nur e<strong>in</strong><br />
Proze die Marke aus der Synchronisationstelle entnehmen kann. Die dargestellte<br />
Losung berucksichtigt hierbei nicht das Fairness{Pr<strong>in</strong>zip, da dort durch das<br />
nicht{determ<strong>in</strong>istischeSchalten des Netzes pr<strong>in</strong>zipiell immer derselbe Proze den<br />
kritischen Abschnitt betreten kann. E<strong>in</strong>e Losung dieses Problems ndet sich <strong>in</strong><br />
[JV87].<br />
4.2.3.5 Strukturierungskonzept<br />
Die Beschreibung komplexer Kooperationsanwendungen erfordert die Unterstutzung<br />
durch Strukturierungskonzepte, mit denen e<strong>in</strong>e Modularisierung auf<br />
der Ebene der Anwendungsvorgange moglich ist. Grundlage hierfur bildet die<br />
Aufteilung der Gesamtanwendung <strong>in</strong> beschreibare Teilvorgange, fur die jeweils<br />
dedizierte Losungsansatze entwickelt werden konnen. Des weiteren mussen<br />
e<strong>in</strong>deutige Schnittstellen zwischen den Teilvorgangen de nierbar se<strong>in</strong>, damit<br />
diese anschlie end auf wohlde nierte Art und Weise mite<strong>in</strong>ander verbunden<br />
werden konnen.<br />
Petri{Netze bieten als Strukturierungsmittel <strong>in</strong> der Regel e<strong>in</strong>e Hierarchisierung<br />
an, die auf dem Pr<strong>in</strong>zip transitionsberandeter oder stellenberandeter Teilnetze<br />
[Jen92] beruht. Hierbei werden entweder Transitionen oder Stellen zusammengefa<br />
t, so da sie auf e<strong>in</strong>er hoheren Abstraktionsebene als e<strong>in</strong>e Transition oder<br />
Stelle ersche<strong>in</strong>en. Bei e<strong>in</strong>er spateren Netzanalyse werden die Teilnetze durch<br />
Expansion wieder bis auf die Ebene e<strong>in</strong>zelner Stellen und Transitionen aufgelost.<br />
Obwohl dem Anwendungsentwickler durch die Hierarchisierung zahlreiche<br />
Abstraktionsmoglichkeiten gegeben s<strong>in</strong>d, besteht ihr wesentlicher Nachteil<br />
jedoch dar<strong>in</strong>, da das Verhalten der Teilnetze immer im Zusammenhang mit<br />
dem Gesamtnetz betrachtet werden mu und somit e<strong>in</strong>e getrennteAnalyse nicht
130 Koord<strong>in</strong>ation von Diensten<br />
moglich ist [SB93]. Fur die Darstellungvon Anwendungsvorgangen mittels Petri{<br />
Netzen ersche<strong>in</strong>t es s<strong>in</strong>nvoller, e<strong>in</strong>e losere Kopplung von Teilnetzen anzustreben,<br />
die e<strong>in</strong>en hohen Grad an Unabhangigkeit der verknupften Teilnetze ermoglicht.<br />
E<strong>in</strong>en Ansatz hierfur bieten sogenannte Klienten/Server{Netze [SB93], die e<strong>in</strong>e<br />
Unterscheidung <strong>in</strong>Klienten{ und e<strong>in</strong>Server{Netze vornehmen (Abbildung 4.7).<br />
Klienten-Netz<br />
Server-Netz<br />
Abbildung 4.7: Strukturierung durch Klienten/Server{Netze<br />
In dieser Sichtweise verfugen die Server-Netze uber von au en zugreifbare Stellen,<br />
auf die Marken von Seiten der Transitionen des Klienten{Netzes abgelegt<br />
werden konnen. Die Marken konnen als Auftrage betrachtet werden, die durch<br />
das Server{Netz verarbeitet werden. Die Verb<strong>in</strong>dungsstelle ist als unidirektionaler<br />
Kanal de niert, der beide Netze <strong>in</strong>sofern lose koppelt, als da von Klienten{<br />
Seite der aktuelle Zustand des Server{Netzes nicht berucksichtigt werden mu .<br />
Hierdurch la t sich zume<strong>in</strong>en e<strong>in</strong>e unabhangige Betrachtungder Teilnetze erreichen,<br />
die im Fall komplexer Anwendungsvorgange zur Beschreibung von Teilvorgangen<br />
dienen konnen. Zum anderen ermoglicht sie die problemlose Verknupfung<br />
der Teilnetze zu e<strong>in</strong>em ausfuhrbaren Gesamtnetz. E<strong>in</strong> hiermit verbundener<br />
Vorteil ist dann auch die Wiederverwendbarkeit von Teilvorgangen,<br />
die uber Verb<strong>in</strong>dungsstellen zu neuen Anwendungsvorgangen mite<strong>in</strong>ander komb<strong>in</strong>iert<br />
werden konnen.<br />
4.2.3.6 Fehlerbehandlungskonzept<br />
Nachder De nition von Petri{Netzen geschiehtder Schaltvorganggenerell fehlerlos,<br />
da dort e<strong>in</strong>e Abgeschlossenheit des Gesamtnetzes zugrunde gelegt wird, die<br />
e<strong>in</strong>e Bee<strong>in</strong> u ungder Ausfuhrungdes Petri{Netzes durch externe Ereignisse verh<strong>in</strong>dert.<br />
Diese Grundannahme gilt jedoch nicht mehr fur die oben vorgeschlagene<br />
Erweiterung von Petri{Netzen zur Beschreibung von Anwendungsvorgangen,<br />
die sich gerade dadurch auszeichnet, da wahrend der Ausfuhrung e<strong>in</strong>er Transition<br />
e<strong>in</strong> oder mehrere externe Dienste <strong>in</strong> Anspruch genommen werden. Hier<br />
ist grundsatzlich von Fehlern bei der <strong>Dienstnutzung</strong> auszugehen, die e<strong>in</strong>erseits<br />
aufgrund fehlerhafter Kommunikation, beispielsweise dem Abbruch e<strong>in</strong>er Netzwerkverb<strong>in</strong>dung,<br />
und andererseits auch von den unterstutzenden Systemdiensten<br />
hervorgerufen werden konnen. Insbesondere fur den letzten Fall s<strong>in</strong>d Fehlerfalle<br />
zu beachten, die sich bei der Dienstauswahl ergeben konnen, beispielsweise falls<br />
ke<strong>in</strong>e geeigneten Dienstangebote zur Ausfuhrung e<strong>in</strong>er Aktion gefunden werden
4.2 Beschreibung und Modellierung koord<strong>in</strong>ierter <strong>Dienstnutzung</strong> 131<br />
konnen. Ebenfalls anzunehmen s<strong>in</strong>d auch Fehler h<strong>in</strong>sichtlich der Verfugbarkeit<br />
von Systemdiensten selbst, beispielsweise falls das fur die Dienstauswahl notwendige<br />
Typmanagement kurzfristig nicht zur Verfugung steht. Fur derartige<br />
systemtechnische Fehler s<strong>in</strong>d entsprechende Fehlerbehandlungsma nahmen, d.h.<br />
sowohl Fehlererkennungs{ als auch Fehlererholungsmechanismen, anzubieten. Zu<br />
welchen Grad die Fehlerbehandlung aus der Ausfuhrungsumgebung von Petri{<br />
Netzen bis auf die Beschreibungsebene der Anwendungsvorgange hochgereicht<br />
werden soll, hangt von den dort geforderten Beschreibungsabstraktionen ab. Ist<br />
beispielsweise e<strong>in</strong> hohes Abstraktionsniveau gefordert, mussen von Seiten der Systemumgebung<br />
automatische Fehlererholungsma nahmen durchgefuhrt werden,<br />
die auftretende systemtechnischeFehlerfalle moglichst vollstandig nach obenh<strong>in</strong><br />
verbergen. Im Fall e<strong>in</strong>er erfolglosen Dienstauswahl konnte beispielsweise e<strong>in</strong>e<br />
erneute Dienstanfrage an e<strong>in</strong>en Trader mit abgeschwachten Suchkriterien und<br />
exibleren Suchvorschriften gestellt werden.<br />
E<strong>in</strong>e Moglichkeit zur Integration des geforderten Fehlerbehandlungskonzeptes <strong>in</strong><br />
Petri{Netze besteht <strong>in</strong>der Erweiterung der Transitionskonzeptes. Hierfur werden<br />
fur jede Transition zwei verschiedene Mengen von Ausgangsstellen de niert.<br />
Die ersteMenge berucksichtigt den fehlerfreien Fall, bei dem ke<strong>in</strong>e systemtechnischen<br />
Fehler auftreten. Im fehlerbehafteten Fall wird h<strong>in</strong>gegen die zweite Menge<br />
von Stellen berucksichtigt. Auf diese werden systemseitig Marken abgelegt, aus<br />
denen die Art und der Grund des Fehlers ersichtlich wird, so da anschlie end<br />
e<strong>in</strong>e geeignete Fehlerbehandlung imAnwendungsvorgang durchgefuhrt werden<br />
kann. 3 Hierfur s<strong>in</strong>d bereits bei der Petri{Netz{Beschreibung entsprechende anwendungsspezi<br />
sche Fehlerbehandlungsma nahmen festzulegen. Dies kann beispielsweise<br />
<strong>in</strong> Form e<strong>in</strong>es expliziten Fehlerbehandlungsdienstes geschehen, wie er<br />
<strong>in</strong> Abbildung 4.8 dargestellt ist.<br />
Dienst<br />
Fehler<br />
Fehlerbehandlungsdienst<br />
Abbildung 4.8:Auslosung e<strong>in</strong>er Fehlerbehandlung<br />
Fehlerbehandelnde<br />
Transition<br />
Der Fehlerbehandlungsdienst kann sowohl automatische Aktionen <strong>in</strong>itiieren, die<br />
beispielsweise das erneute Starten e<strong>in</strong>er Operation oder das Auslosen e<strong>in</strong>er kompensierenden<br />
Aktivitat ubernehmen, als auch Benachrichtigungen an den Benutzer<br />
erzeugen, um ihn zu expliziten adm<strong>in</strong>istrativen Ma nahmen aufzufordern.<br />
3 Die Vertraglichkeit dieser Erweiterung ist <strong>in</strong> [Bri95] mittels der Abbildung des Fehlerbehandlungskonzeptes<br />
auf e<strong>in</strong> aquivalentes, nichtdeterm<strong>in</strong>istisches Stellen{/Transitionsnetzes<br />
gezeigt.
132 Koord<strong>in</strong>ation von Diensten<br />
Hierdurch wird e<strong>in</strong>e allgeme<strong>in</strong>e benutzerorientierte Fehlerbehandlung [EN93]<br />
ermoglicht.<br />
4.2.3.7 Interaktionskonzept<br />
Die Abwicklung von Anwendungsvorgangen erfordert <strong>in</strong> der Regel zahlreiche Interaktionen<br />
auch mit externen Benutzern, von denen entweder E<strong>in</strong>gaben explizit<br />
vom Anwendungsvorgang angefordert oder auch selbstandig und unaufgefordert<br />
Daten an e<strong>in</strong>en laufenden Anwendungsvorgang ubergeben werden konnen.<br />
Die erste Art der Benutzer<strong>in</strong>teraktion ist generell orthogonal zum externen<br />
Dienstaufruf bei der Ausfuhrung e<strong>in</strong>er Transition behandelbar. In diesem Fall<br />
versteht sich die Tatigkeit e<strong>in</strong>es Benutzers als Dienstleistung, die dem Anwendungsvorgang<br />
uber e<strong>in</strong>en auf der Systemebene be ndlichen Dienst zuganglich<br />
gemacht wird. Im Unterschied zu automatisch ablaufenden Diensten ist jedoch<br />
e<strong>in</strong>e explizite Interaktion mit dem Benutzer erforderlich, der die E<strong>in</strong>gabe der geforderten<br />
Daten vornimmt. Die Au orderung des Benutzers kann beispielsweise<br />
mittels e<strong>in</strong>er Arbeitsliste [LR94] geschehen, aus der der Benutzer vom Anwendungsvorgang<br />
geforderte Tatigkeiten entnehmen kann.<br />
Bei der zweiten Art, bei der die Benutzer unaufgefordert Daten an den Anwendungvorgang<br />
ubergeben konnen, lassen sich generell die unidirektionale und die<br />
bidirektionale Benutzer<strong>in</strong>teraktion unterscheiden [Bri95]. Im ersten Fall erwartet<br />
der Benutzer nach der E<strong>in</strong>gabe der Daten ke<strong>in</strong>e Antwort, so da die Interaktion<br />
nach der Annahme der E<strong>in</strong>gabe sofort beendet wird. Mit dieser Variante lassen<br />
sich auf e<strong>in</strong>fache Art und Weise Benachrichtigungen, beispielsweise Steuerungsanweisungen,<br />
realisieren, die <strong>in</strong> der Regel ke<strong>in</strong>er Ruckantwort bedurfen.<br />
Im Gegensatz hierzu wird bei der bidirektionalen Interaktion davon ausgegangen,<br />
da der Benutzer e<strong>in</strong>e explizite Antwort erwartet. Hiermit s<strong>in</strong>d <strong>in</strong>sbesondere<br />
Benutzeranfragen realisierbar, die <strong>in</strong> der Ruckgabe e<strong>in</strong>er Menge von Ergebnissen<br />
resultieren.<br />
Obwohl aufgrund der Abgeschlossenheit von Petri{Netzen e<strong>in</strong>e Unterstutzung<br />
derartiger Benutzer<strong>in</strong>teraktionen explizit nicht vorgesehen ist, la t sich die unidirektionale<br />
Interaktion <strong>in</strong> ahnlicher Weise wie die <strong>in</strong> Abschnitt 4.2.3.5 vorgestellten<br />
Klienten/Server{Netze beschreiben (Abbildung 4.9).<br />
Externer Benutzer<br />
Verb<strong>in</strong>dungsstelle<br />
Abbildung 4.9: Unidirektionale Benutzer<strong>in</strong>teraktion
4.2 Beschreibung und Modellierung koord<strong>in</strong>ierter <strong>Dienstnutzung</strong> 133<br />
Konzeptuell werden die Benutzer als Klienten{Netze angesehen, die auf den von<br />
den Server{Netzen nachau en zur Verfugunggestellten Verb<strong>in</strong>dungsstellen asynchron<br />
Marken ablegen konnen. Die Marken werden anschlie end imServer{Netz<br />
vorgangsspezi sch verarbeitet.<br />
Im Gegensatz zur unidirektionalen Interaktion gestaltet sich die Beschreibung<br />
e<strong>in</strong>er bidirektionalen Interaktion vergleichsweise aufwendig. Wesentliche Ursache<br />
hierfur ist die enge logische Verknupfung, die zwischen dem E<strong>in</strong>gabe{ und dem<br />
Ausgabeschrittnotwendig ist. In Abbildung 4.10 ist dieses am Beispiel von zwei<br />
mite<strong>in</strong>ander verbundenen Transitionen dargestellt.<br />
Benutzer<br />
E<strong>in</strong>gabe<br />
Ausgabe<br />
Abbildung 4.10: Bidirektionale Benutzer<strong>in</strong>teraktion mittels zwei Transitionen<br />
In diesem Fall realisiert die erste die Entgegennahme der Daten, wahrend die<br />
zweite spater e<strong>in</strong>e Antwortnachricht anden Benutzer zuruckschickt. Voraussetzung<br />
hierfur ist, da beide Transitionen nur <strong>in</strong> dieser festgelegten Reihenfolge<br />
schalten, da ansonsten Konsistenzprobleme auftreten konnen. Die Erfullung<br />
dieser Eigenschaft ist <strong>in</strong> Petri{Netzen im allgeme<strong>in</strong>en jedoch nur schwer nachzuweisen<br />
[SB94]. E<strong>in</strong>e Moglichkeit zur Umgehung dieser Problematik ist die<br />
E<strong>in</strong>fuhrung e<strong>in</strong>er besonderen Transition, die sich aus der <strong>in</strong> der Abbildung bereits<br />
angedeuteten Verschmelzung der beiden e<strong>in</strong>zelnen Transitionen ergibt. Mit<br />
dieser Verschmelzung istgleichzeitig auch e<strong>in</strong>e Anderung des Schaltverhaltens<br />
der neuen Transition verbunden, die <strong>in</strong> Abbildung 4.11 durch e<strong>in</strong>eentsprechende<br />
Numerierungverdeutlichtist.Beidem Schaltvorgang erfolgt e<strong>in</strong>e Umkehrungdes<br />
ublichen Schaltverhaltens, die sich<strong>in</strong>der vertauschten Reihenfolge des Entfernens<br />
undAblegens von Marken auf den E<strong>in</strong>- undAusgangsstellen ausdruckt. Die Transition<br />
schaltet wie auch e<strong>in</strong>eunidirektional angesto ene Transition, ohne jedoch<br />
Marken von ihren netz<strong>in</strong>ternen E<strong>in</strong>gangsstellen zu entfernen. Im Unterschied<br />
zum unidirektionalen Fall geht die Transition stattdessen <strong>in</strong> e<strong>in</strong>en Wartezustand<br />
uber, <strong>in</strong>dem sie auf die Belegung ihrer E<strong>in</strong>gangsstellen wartet. Sobald dieses geschehen<br />
ist, wird die bis zu diesem Zeitpunkt suspendierte Benutzer<strong>in</strong>teraktion<br />
durch Ruckgabe e<strong>in</strong>er Antwortnachricht beendet. Die Benachrichtigung erfolgt<br />
ebenso wie die E<strong>in</strong>gabe uber e<strong>in</strong>e eigene Verb<strong>in</strong>dungsstelle, so da der Benutzer<br />
konzeptuell e<strong>in</strong>em Server{Netz entspricht. 4<br />
4 Zur tiefergehenden Diskussion der Vertraglichkeit dieser konzeptuellen Erweiterung von
134 Koord<strong>in</strong>ation von Diensten<br />
Benutzer<br />
E<strong>in</strong>gabe<br />
Ausgabe<br />
Abbildung 4.11: Bidirektionale Benutzer<strong>in</strong>teraktion durch Transitionsverschmelzung<br />
4.2.3.8 Transaktionskonzept<br />
Wie <strong>in</strong> Abschnitt 4.2.3.6 bereits verdeutlicht wurde, s<strong>in</strong>d bei der Ausfuhrung<br />
von Anwendungsvorgangen zahlreiche Fehlerfalle zu berucksichtigen, die unter<br />
Umstanden sogar e<strong>in</strong>en Abbruch der Kooperationsanwendung zur Folge haben<br />
konnen. Um trotz dieser Fehler e<strong>in</strong>e konsistente Ausfuhrung der Anwendungsvorgange<br />
sicherstellen zu konnen, ist die E<strong>in</strong>fuhrunge<strong>in</strong>es Konzeptes erforderlich,<br />
mit dem e<strong>in</strong>zelne Aktivitaten bzw. Aktionen als e<strong>in</strong>e logisch zusammengehorende<br />
Ausfuhrungse<strong>in</strong>heit behandelt werden konnen.<br />
E<strong>in</strong> hierfur geeignetes und hau g verwendetes Kontrollkonzept s<strong>in</strong>d die ACID{<br />
Transaktionen [Gra81, GR93], die sich durch die folgenden grundlegenden Eigenschaften<br />
auszeichnen:<br />
Atomaritat: Innerhalb e<strong>in</strong>er Transaktion werden entweder alle Handlungen<br />
ausgefuhrt oder ke<strong>in</strong>e ( " Alles oder Nichts\{Pr<strong>in</strong>zip)�<br />
Konsistenz: E<strong>in</strong>eTransaktion uberfuhrt e<strong>in</strong> System von e<strong>in</strong>em konsistenten<br />
<strong>in</strong> e<strong>in</strong>en anderen. Hierbei ist der Begri der Konsistenz anwendungsspezisch<br />
zude nieren.<br />
Isolation: Die Operationen e<strong>in</strong>er Transaktion werden vor der Bee<strong>in</strong> u -<br />
ung durch dieAusfuhrung nebenlau g ausgefuhrter Operationen anderer<br />
Transaktionen geschutzt.<br />
Dauerhaftigkeit: Nach Beendigung e<strong>in</strong>er Transaktion s<strong>in</strong>d ihre Wirkungen<br />
dauerhaft und konnen nur durch explizite Gegentransaktionen modi ziert<br />
werden.<br />
Um Transaktionen <strong>in</strong> Petri{Netzen darstellen zu konnen, ist e<strong>in</strong>e Erweiterung<br />
des Transitionskonzeptes notwendig. Abbildung 4.12 zeigt e<strong>in</strong>en moglichen Integrationsansatz.<br />
Transaktionale Transitionen werden im folgenden mit e<strong>in</strong>em (T)<br />
gekennzeichnet.<br />
Transitionen siehe <strong>in</strong>sbesondere die Arbeiten von [Bri95] und [SB94].<br />
1.<br />
4.<br />
2.<br />
3.
4.2 Beschreibung und Modellierung koord<strong>in</strong>ierter <strong>Dienstnutzung</strong> 135<br />
Transaktionaler Dienst<br />
Transaktionaler Dienst<br />
Gesamttransaktion<br />
T<br />
Commit<br />
Abbruch<br />
Abbildung 4.12: Commit{ und Abort{Ausgangsstellen zur Transaktionsbehandlung<br />
Die Sicherstellung der Atomaritats{ und Isolationseigenschaften erfolgt <strong>in</strong> ahnlicher<br />
Weise wie beim Fehlerbehandlungskonzept durch die E<strong>in</strong>fuhrung spezieller<br />
Ausgangsstellen, auf die je nach erfolgloser (Abbruch) oder erfolgreicher<br />
(Commit)Beendigung entsprechend Marken abgelegt werden. Die Nutzung mehrerer<br />
transaktionaler Dienste 5 ist hierbei <strong>in</strong>nerhalb der Transition gekapselt, so<br />
da Zwischenzustandenach au en fur andere Transitionen nur uber diese beiden<br />
Stellen sichtbar werden. Die dort abgelegten Marken konnen anschlie end durch<br />
Schalten nachfolgender Transitionen entfernt werden, um anwendungsspezi -<br />
sche Folgeaktivitaten zu <strong>in</strong>itiieren. Hierbei kann es unter Umstanden auch s<strong>in</strong>nvoll<br />
se<strong>in</strong>, Aktionen fruherer, bereits abgeschlossener Transaktionen ruckgangig<br />
zu machen. Dies kann beispielsweise <strong>in</strong> Form von kompensierenden Aktionen<br />
[GMGK + 91, KLS90] geschehen, die ebenfalls durch transaktionale Dienste ausgefuhrt<br />
werden.<br />
E<strong>in</strong> alternativer Vorschlag fur die Zusammenfassung von Operationen <strong>in</strong>nerhalb<br />
von Transaktionen ndet sich imConTract{Modell [WR90, Sch93c], dem ebenfalls<br />
e<strong>in</strong> Petri{Netz{basierter Ansatz <strong>in</strong> Form von Pradikats{/Transitionsnetzen<br />
unterliegt, die vom Konzept her ahnlich zuden hier gewahlten gefarbten Petri{<br />
Netzen s<strong>in</strong>d. In diesem Beschreibungsansatz erfolgt die Transaktionsklammerung<br />
nicht <strong>in</strong>nerhalb der Transitionen, sondern auf der Ebene der Petri{Netze, <strong>in</strong>dem<br />
Transitionen beliebig transaktional mite<strong>in</strong>ander komb<strong>in</strong>iert werden konnen. E<strong>in</strong><br />
mit diesem Ansatz verbundene Problemstellung ist jedoch das Auftreten von<br />
Kon iktsituationen im Kontroll u e<strong>in</strong>er Transaktion, da generell nicht zugesichert<br />
werden kann, da die e<strong>in</strong>e Transaktionsausfuhrung beendende Transition<br />
auch tatsachlich jemals schaltet (siehe hierzu [Sch93c]). Diese Situation konnte<br />
beispielsweise dann auftreten, wenn e<strong>in</strong>e nicht ander Transaktion beteiligte<br />
Transition Marken von Stellen entfernt, die fur die Beendigung der Transaktion<br />
erforderlich s<strong>in</strong>d. Dieses Problem hangt eng mit die Sichtbarkeit von Zwischenzustanden<br />
<strong>in</strong> den die Transitionen verb<strong>in</strong>denden Stellen zusammen, die pr<strong>in</strong>zipi-<br />
5 Bei dieser transaktionalen Zusammenfuhrung konnen jedoch nur Dienste mit bestimmten<br />
transaktionsunterstutzenden Eigenschaften berucksichtigt werden. Dieses betri t <strong>in</strong>sbesondere<br />
die Unterstutzung e<strong>in</strong>es geme<strong>in</strong>samen Ausfuhrungsprotokolls, beispielsweise dem 2{Phasen{<br />
Kommit{Protokoll [GR93], mit dem e<strong>in</strong>e Transaktionsteuerung und {sicherung auch <strong>in</strong>e<strong>in</strong>er<br />
<strong>verteilten</strong> Systemumgebung durchfuhrbar ist.
136 Koord<strong>in</strong>ation von Diensten<br />
ell fur andere Transitionen zuganglich s<strong>in</strong>d. Insbesondere bei der Beschreibung<br />
komplexer Anwendungsvorgange mit e<strong>in</strong>em hieraus resultierenden, <strong>in</strong> der Regel<br />
gro en und unubersichtlichen Netz la t sich dieses pr<strong>in</strong>zipiell nicht ausschlieen.<br />
Aus diesem Grund ersche<strong>in</strong>t der hier gewahlte Ansatz, der Transaktionen<br />
nur <strong>in</strong>nerhalb von Transitionen zula t, fur die Beschreibung von Anwendungsvorgangen<br />
geeigneter.<br />
4.3 Bewertung und erganzende Bemerkungen<br />
Die Bereitstellung e<strong>in</strong>er aus Typmanagement{, Trad<strong>in</strong>g{ und Interzeptions{<br />
Mechanismen bestehenden Dienst<strong>in</strong>frastruktur, die e<strong>in</strong>en weitgehend une<strong>in</strong>geschrankten<br />
Zugang zuden <strong>in</strong> o enen <strong>verteilten</strong> Dienstemarkten vorhandenen<br />
Dienstangeboten zur Verfugung stellt, ermoglicht e<strong>in</strong>en neuen Stil der Realisierung<br />
verteilter Anwendungen. Dieser zeichnet sich imwesentlichen dadurch<br />
aus, da die Anwendungsentwicklung weitestgehend oder sogar ausschlie lich<br />
<strong>in</strong> Form von Diensten geschieht, die im Rahmen von Anwendungsvorgangen<br />
komb<strong>in</strong>iert genutzt werden. Diese Dienste werden entweder <strong>in</strong>nerhalb verteilter<br />
Dienstemarkte von externen Dienstanbietern bereits angeboten oder im Rahmen<br />
der Anwendungsentwicklungneu realisiert. Die weitestgehendeVerwendung<br />
von Diensten kann somit auch als e<strong>in</strong> allgeme<strong>in</strong>gultiges Pr<strong>in</strong>zip zur Realisierung<br />
zukunftiger verteilter Anwendungen verwendet werden.<br />
Bei dieser Art der Anwendungsentwicklung wird ersichtlich, da zukunftig die<br />
Aspekte der Koord<strong>in</strong>ation von Diensten adaquat berucksichtigt werden mussen.<br />
Dieses bedeutet <strong>in</strong>sbesondere, da ausdrucksmachtige Beschreibungsmittel zur<br />
Verfugungstehen mussen, die den ausgepragten dienstorientierten Charakter verteilter<br />
Anwendungen auszudrucken vermogen. Hierzu wurde <strong>in</strong> diesem Kapitel<br />
die Abstraktion von Anwendungsvorgangen vorgestellt, die e<strong>in</strong>e Konzentration<br />
auf die Koord<strong>in</strong>ationsaspekte von <strong>Dienstnutzung</strong> ermoglicht.<br />
Die Darstellung von Anwendungsvorgangen geschieht hierbei auf der Grundlage<br />
e<strong>in</strong>es erweiterten Petri{Netzes. Ausschlaggebender Grund fur die Verwendung<br />
von Petri{Netzen <strong>in</strong> dieser Arbeit ist <strong>in</strong>sbesondere ihre Eigenschaft, sowohl die<br />
Struktur von Anwendungsvorgangen als auch ihre Ausfuhrung<strong>in</strong>e<strong>in</strong>em <strong>in</strong>tegrierten<br />
und mathematisch fundierten Ansatz beschreiben zu konnen. Dieses erlaubt<br />
e<strong>in</strong>en weitestgehend nahtlosen und direkten Ubergang von der Beschreibung <strong>in</strong><br />
die Ausfuhrung von Anwendungsvorgangen, da mit der Struktur e<strong>in</strong>es Petri{<br />
Netz gleichzeitig auch se<strong>in</strong>eAusfuhrungssemantik e<strong>in</strong>deutig festgelegt wird. Dieser<br />
Vorteil zeigt sich auch bei der im Rahmen der TRADE{Systemumgebung<br />
realisierten konkreten Ausfuhrungsumgebung fur Anwendungsvorgange.<br />
Insgesamt zeigt sich, da die durch Petri{Netze <strong>in</strong>harent gegebenen Darstellungsmittel<br />
von Nebenlau gkeit und Synchronisation e<strong>in</strong>e geeignete Grundlage<br />
fur die Beschreibung von Anwendungsvorgangen bilden. Mit ihnen s<strong>in</strong>d die<br />
oben genannteIntra{ und Intervorgangsnebenlau gkeit und die gegebenfalls notwendigen<br />
Synchronisationslosungen auf <strong>in</strong>tuitive und e<strong>in</strong>fache Art und Weise <strong>in</strong><br />
e<strong>in</strong>em Petri{Netz darstellbar. Durch diese Integration <strong>in</strong> e<strong>in</strong>er Beschreibungs-
4.3 Bewertung und erganzende Bemerkungen 137<br />
form la t sich der konzeptuelle Bruchvermeiden, der sich im allgeme<strong>in</strong>en bei der<br />
E<strong>in</strong>fuhrungvon Nebenlau gkeits{ und Synchronisationskonzepten <strong>in</strong> herkommlichen<br />
sequentiellen Beschreibungsansatzen, beispielsweise der Nutzung der DCE{<br />
Thread{Bibliothek [OSF93b] <strong>in</strong>der Systemprogrammiersprache C [KR88], zeigen.<br />
Hierdurch la t sich auch e<strong>in</strong> hohes Abstraktionsniveau fur den Anwendungsentwickler<br />
bei der Beschreibung von Anwendungsvorgangen erreichen. Unterstutzt<br />
wird dieses unter anderem auch dadurch, da mit der gewahlten Petri{<br />
Netz{Darstellung von Anwendungsvorgangen e<strong>in</strong>e vollstandige Trennung der koord<strong>in</strong>ativen<br />
von den verarbeitungsbezogenen Aspekten bereitgestellt wird. Das<br />
Petri{Netz beschreibt hierbei ausschlie lich die Koord<strong>in</strong>ation, wahrend die Beschreibung<br />
der eigentlichen anwendungsspezi schen Berechnungsfunktionalitat<br />
<strong>in</strong> den Diensten verborgen ist und pr<strong>in</strong>zipiell <strong>in</strong> e<strong>in</strong>er beliebigen Programmiersprache<br />
erfolgen kann. In diesem Zusammenhang wird der hier vorgeschlagene<br />
Beschreibungsansatz als Koord<strong>in</strong>ationstechnologie [SV89] aufgefa t, der sich generell<br />
zur Entwicklung e<strong>in</strong>er Koord<strong>in</strong>ationssprache [GC92] eignet.<br />
Bei dem Ubergang zue<strong>in</strong>er konkret nutzbaren Koord<strong>in</strong>ationssprache zur Programmierung<br />
von Anwendungsvorgangen ist als nachster Schritt <strong>in</strong>sbesondere<br />
das Diensttypmodell des Beschreibungsansatzes zu konkretisieren. Erst hierduch<br />
wird e<strong>in</strong>e Verknupfung zue<strong>in</strong>er realen Dienst<strong>in</strong>frastruktur gescha en. Dieser<br />
Schritt wirdkonkret im nachfolgenden zweiten Teil dieser Arbeit vollzogen,<br />
<strong>in</strong> dem unter anderem die Koord<strong>in</strong>ationssprache PAMELA der TRADE{<br />
Systemumgebung vorgestellt wird, die e<strong>in</strong>e programmiersprachliche Umsetzung<br />
des <strong>in</strong> diesem Kapitel beschriebenen Beschreibungsansatzes ermoglicht. Hierbei<br />
zeigt sich dann auch der Vorteil der Wahl von Petri{Netzen als Beschreibungsgrundlage,<br />
da mit ihnen gleichzeitig auch die Semantik der Ausfuhrung der mit<br />
PAMELA beschriebenen Anwendungvorgange de niert ist. Diese Ausfuhrungssemantik,<br />
die im Petri{Netz durch das Schaltverhalten der Transitionen reprasentiert<br />
wird, bildet auch e<strong>in</strong>e geeignete Grundlage fur die Realisierung e<strong>in</strong>er Steuerungskomponente,<br />
wie sie <strong>in</strong> Form des Koord<strong>in</strong>ationsmanagers <strong>in</strong> TRADE realisiert<br />
worden ist.<br />
In dem vorgeschlagenen Beschreibungsansatz wurden e<strong>in</strong>eReihe<strong>in</strong>der Forschung<br />
entwickelter Petri{Netz{Erweiterungen komb<strong>in</strong>iert, um den besonderen Anforderungen,<br />
vor allem nach Unterstutzung e<strong>in</strong>es Aktions{, Nebenlau gkeits{ und<br />
Interaktionskonzeptes, bei der Beschreibungkoord<strong>in</strong>ierter <strong>Dienstnutzung</strong> gerecht<br />
zu werden. Ihre Vertraglichkeit wurdeanden jeweiligen Stellen erortert, wobei jedoch<br />
auf die Darstellung e<strong>in</strong>er formalen Beweisfuhrungverzichtet wurde. Hierfur<br />
sei <strong>in</strong>sbesondere auf die <strong>in</strong> der Literatur vorhandenen, umfangreichen Arbeiten,<br />
beispielsweise [Mar89] fur das Schaltverhalten von Transitionen beim dienstorientierten<br />
Aktionskonzept und [SB93,SB94]fur die Strukurierungstechnik der<br />
Klienten/Server{Netze, verwiesen. Fur die Weiterverfolgungdes Beschreibungsansatzes<br />
ist jedoch zukunftig e<strong>in</strong>e vollstandige formale Spezi kation der Netzsemantik<br />
unter Berucksichtigung der hier vorgestellten Erweiterungen anzustreben.<br />
E<strong>in</strong>en Anhalt fur e<strong>in</strong>e derartige Formalisierung konnte die Darstellung der<br />
FUNSOFT{Netze <strong>in</strong> [Gru91, DGSZ94] bieten.<br />
Der gewahlte Beschreibungsansatz beschrankt sich auf die Erfullung der <strong>in</strong> Ab-
138 Koord<strong>in</strong>ation von Diensten<br />
schnitt 4.1.2 gestellten Anforderungen, die zur Beschreibung von Anwendungsvorgangen<br />
erfullt werden mussen. Er ist jedoch weiter ausbaubar, <strong>in</strong>dem er<br />
pr<strong>in</strong>zipiell die Formulierung weitergehender Anforderung an die Beschreibung<br />
von Anwendungsvorgangen zula t, was <strong>in</strong>sbesondere auch durch die Erweiterungsfahigkeit<br />
von Petri{Netzen unterstutzt wird. So ware erganzend beispielsweise<br />
e<strong>in</strong> Rollenkonzept [Tsc94] s<strong>in</strong>nvoll, mit dem unter anderem e<strong>in</strong>e organisationelle<br />
Zuordnung von Benutzern zu den Aktivitaten bzw. Aktionen e<strong>in</strong>es<br />
Anwendungsvorganges moglich ist. Hierdurch konnen dann bestimmte Anwendungsbereiche,<br />
beispielsweise die Optimierung von Arbeitsablaufen <strong>in</strong> Unternehmen<br />
(engl. work ow management, process management) [Jab95, CKO92], spezi<br />
scher unterstutzt werden. Weitere Uberlegungen konnten beispielsweise auch<br />
h<strong>in</strong>sichtlich der Ersetzung des hier verwendeten ACID{Transaktionskonzeptes<br />
angestellt werden. Gerade <strong>in</strong> H<strong>in</strong>blick auf die Beschreibung langlebiger Aktivitaten<br />
[DHL90], deren Ausfuhrung sich uber e<strong>in</strong>en langen Zeitraum erstreckt,<br />
s<strong>in</strong>d dieACID{Forderungen oftmals zu streng. Hier wird <strong>in</strong> der Regel e<strong>in</strong> gelockertes<br />
Transaktionskonzept gefordert (siehe unter anderem [Elm91] fur e<strong>in</strong>e<br />
Ubersicht verschiedener erweiterter Transaktionskonzepte). Diese besitzen dann<br />
jedoch auch e<strong>in</strong>eandere Ausfuhrungssemantik, zu deren Darstellung zumTeil<br />
andere Ausdrucksmittel zur Verfugung stehen mussen.
Teil II<br />
TRADE: E<strong>in</strong>e verteilte<br />
Systemumgebung zur<br />
Vermittlung und Koord<strong>in</strong>ation<br />
von Diensten
TRADE{Uberblick 141<br />
Der vorliegende Teil stellt das Service Trad<strong>in</strong>g and Coord<strong>in</strong>ation Environment<br />
(TRADE) vor, welches im Rahmen dieser Arbeit entwickelt wurde und e<strong>in</strong>en<br />
<strong>in</strong>tegrierten Losungsansatz zur Unterstutzung koord<strong>in</strong>ierter <strong>Dienstnutzung</strong> <strong>in</strong><br />
o enen <strong>verteilten</strong> Dienstemarkten vorschlagt und konkret implementiert. Die<br />
Konzeption der TRADE{Systemumgebung setzt hierbei unmittelbar auf dem<br />
vorherigen Teil I auf, <strong>in</strong>dem sie e<strong>in</strong>e prototypische Umsetzung der dort zunachst<br />
abstrakt beschriebenen Mechanismen <strong>in</strong> e<strong>in</strong>e konkreteverteilte Systemumgebung<br />
realisiert.<br />
Die entwickelte TRADE{Systemumgebung setzt sich grundsatzlich aus e<strong>in</strong>er<br />
Entwicklungs{ und e<strong>in</strong>er Ausfuhrungsumgebung zusammen (Abbildung 4.13):<br />
Beschreibung koord<strong>in</strong>ierter <strong>Dienstnutzung</strong><br />
(Koord<strong>in</strong>ationssprache PAMELA)<br />
Dienstzugang<br />
Diensttypbasierte<br />
Dienstbeschreibung<br />
Diensttypmanagement<br />
Dienstvermittlung<br />
Dienstzugriff (Interzeption)<br />
DCE-basierte<br />
Verwaltungsdomäne<br />
Dienst-<br />
Koord<strong>in</strong>ation<br />
Entwicklungsumgebung<br />
Koord<strong>in</strong>ationsmanagement<br />
CORBA-basierte<br />
Verwaltungsdomäne<br />
Ausführungsumgebung<br />
Abbildung 4.13: Entwicklungs{ und Ausfuhrungsumgebung <strong>in</strong>TRADE<br />
Die Entwicklungsumgebung stellt abstrakte Mittel und Werkzeuge zur<br />
Verfugung, die zur Beschreibung von Diensten (Kapitel 2) und <strong>verteilten</strong><br />
Anwendungen bzw. Anwendungsvorgangen (Kapitel 4) notwendig s<strong>in</strong>d.<br />
Sie umfa t zum e<strong>in</strong>en e<strong>in</strong>e diensttypbasierte Dienstbeschreibung, mit der<br />
die <strong>in</strong> den unterliegenden Verwaltungsdomanen angebotenen Dienste auf<br />
e<strong>in</strong>heitliche Artund Weise beschrieben werden konnen. Diese Dienstbeschreibungen<br />
konnen anschlie end auch bei der Spezi kation von Anwen-
142 TRADE{Uberblick<br />
dungsvorgangen mittels der Koord<strong>in</strong>ationssprache PAMELA weiterverwendet<br />
werden.<br />
Die Ausfuhrungsumgebung realisiert die Laufzeitmechanismen, die e<strong>in</strong>e<br />
Ausfuhrung der <strong>in</strong> der Entwicklungsumgebung abstrakt beschriebenen koord<strong>in</strong>ierten<br />
<strong>Dienstnutzung</strong> unterstutzen. Sie be<strong>in</strong>haltet unter anderem die<br />
<strong>in</strong> Kapitel 3 identi zierten Unterstutzungsmechanismen des Diensttypmanagements,<br />
der Dienstvermittlung und der Interzeption, mit denen sich e<strong>in</strong><br />
weitgehend une<strong>in</strong>geschrankter Zugang zuden <strong>in</strong> o enen heterogenen <strong>verteilten</strong><br />
Dienstemarkten angebotenen Diensten erreichen la t.<br />
Weiterh<strong>in</strong> umfa t die Ausfuhrungsumgebung Steuerungs{ und Koord<strong>in</strong>ationsmechanismen,<br />
die zur Ausfuhrung von Kooperationsanwendungen bzw.<br />
Anwendungsvorgangen benotigt werden.<br />
Als Grundlage fur die prototypische Realisierung der Entwicklungs{ und<br />
Ausfuhrungsumgebung wurden die <strong>verteilten</strong> Systemplattformen DCE und<br />
CORBA verwendet, mit denen die vorhandene technische Heterogenitat der an<br />
o enen <strong>verteilten</strong> Dienstemarkten beteiligten Verwaltungsdomanen beispielhaft<br />
widergebbar ist. Sie bilden au erdem e<strong>in</strong>e geeignete Basis, die im Rahmen<br />
dieser Arbeit entwickelten Losungsansatze, auf die zum Teil bereits <strong>in</strong> den<br />
vorangegangenen Kapiteln e<strong>in</strong>gegangen wurde, praktisch zu evaluieren und<br />
auf ihre Anwendbarkeit h<strong>in</strong> zu uberprufen. Dabei s<strong>in</strong>d die erzielten Losungen<br />
jedoch weitestgehend generisch, so da sie pr<strong>in</strong>zipiell auch auf andere verteilte<br />
Systemplattformen ubertragbar s<strong>in</strong>d.<br />
Die folgende Darstellung unterteilt sich<strong>in</strong>zwei Abschnitte. Zunachst geht Kapitel<br />
5 auf die <strong>in</strong> TRADE entwickelten Systemmechanismen e<strong>in</strong>, die e<strong>in</strong>en weitestgehend<br />
une<strong>in</strong>geschrankten Zugang zu <strong>in</strong> DCE{ und CORBA{basierten Verwaltungsdomanen<br />
angebotenen Dienste bereitstellen. Hierzu werden <strong>in</strong>sbesondere<br />
der Typmanager [CMML96], der TRADEr [MJM94, MML94b, MML95f,<br />
GGL + 95, LMM95, MMaTT96] und der Interzeptor [GML96] vorgestellt und ihre<br />
Kooperationsbeziehungen beschrieben.<br />
Hierauf aufsetzend stellt Kapitel 6 die Koord<strong>in</strong>ationssprache PAMELA und den<br />
Koord<strong>in</strong>ationsmanager vor [MML95d, MML95e], mit denen zum e<strong>in</strong>en die koord<strong>in</strong>ierte<br />
Nutzung der nun potentiell verfugbaren Dienste beschreibbar und<br />
zum anderen diese Beschreibung auch unmittelbar <strong>in</strong> e<strong>in</strong>er DCE{ und CORBA{<br />
basierten Systemumgebungausfuhrbar ist. Die Darstellungvon PAMELA knupft<br />
hierbei an das vorherige Kapitel 4 an, <strong>in</strong>dem sie e<strong>in</strong>e programmiersprachliche<br />
Umsetzung des dort entwickelten Petri{Netz{basierten Konzeptes fur die<br />
Beschreibung von Kooperationsanwendungen bzw. Anwendungsvorgangen zur<br />
Verfugung stellt. Diese Darstellung mundet <strong>in</strong> der Beschreibung von zwei Anwendungsbeispielen,<br />
an denen unter anderem auch das Zusammenspiel des Koord<strong>in</strong>ationsmanagers<br />
mit dem Typmanager, TRADEr und Interzeptor erlautert<br />
wird. Beide Beispiele verdeutlichen die durch TRADE gegebenen Moglichkeiten<br />
zur Systemunterstutzunge<strong>in</strong>er weitgehend une<strong>in</strong>geschrankten und koord<strong>in</strong>ierten<br />
Nutzung von beliebigen Diensten <strong>in</strong> o enen <strong>verteilten</strong> Dienstemarkten.
Kapitel 5<br />
Systemunterstutzung fur den<br />
Dienstzugang <strong>in</strong> o enen<br />
<strong>verteilten</strong> Umgebungen<br />
Wie schon <strong>in</strong> den Abschnitten 2.1 und 3.1 ausfuhrlich dargestellt wurde, stehen<br />
dem Dienstnutzer <strong>in</strong> o enen <strong>verteilten</strong> Dienstemarkten zahlreiche Heterogenitatsprobleme<br />
gegenuber, die aus der Autonomie der an derartigen Dienstemarkten<br />
beteiligten Verwaltungsdomanen resultieren. Diese Autonomie au ert sichvor<br />
allem <strong>in</strong> adm<strong>in</strong>istrativen und technischen Problemstellungen, die den Dienstzugang<br />
ma geblich erschweren oder sogar | wie im Falle technischer Heterogenitatsgrenzen<br />
| grundsatzlich verh<strong>in</strong>dern. Um trotz dieser Heterogenitatsprobleme<br />
e<strong>in</strong>e domanenubergreifende <strong>Dienstnutzung</strong> und {koord<strong>in</strong>ation zu ermoglichen,<br />
ist e<strong>in</strong>e Erweiterung heutiger verteilter Systemplattformen notwendig. In<br />
Kapitel 3 wurden hierfur <strong>in</strong>sbesondere das Diensttypmanagement, die Dienstvermittlung<br />
(Trad<strong>in</strong>g) und die Interzeption als geeignete Systemmechanismen<br />
herausgearbeitet und ihren grundlegenden Aufgaben und Konzepten vorgestellt.<br />
Hierbei wurde deutlich, da fur e<strong>in</strong>e une<strong>in</strong>geschrankte <strong>Dienstnutzung</strong> <strong>in</strong>o enen<br />
<strong>verteilten</strong> Dienstemarkten e<strong>in</strong>e enge Kooperation dieser Systemmechanismen untere<strong>in</strong>ander<br />
erforderlich ist (siehe auch Abbildung 3.43).<br />
Das vorliegende Kapitel beschreibt im folgenden den im Rahmen des Service<br />
Trad<strong>in</strong>g and Coord<strong>in</strong>ation Environment (TRADE) durchgefuhrten Entwurf und<br />
die Realisierung dieser bisher nur abstrakt betrachteten Systemmechanismen.<br />
Betrachtungs{ und Realisierungsgrundlage von TRADE bilden die beiden <strong>verteilten</strong><br />
Systemplattformen DCE und CORBA. 1 Mit ihnen la t sich die <strong>in</strong> o enen<br />
<strong>verteilten</strong> Dienstemarkten anzutre ende technische Heterogenitat beispielhaft<br />
wiedergeben. Gleichzeitig dienen sie auch als konkrete Testumgebung, <strong>in</strong><br />
der die im Rahmen dieser Arbeit entwickelten Losungsansatze auf ihre Anwend-<br />
1 Fur e<strong>in</strong>e ausfuhrliche Beschreibung beider Plattformen sei an dieser Stelle beispielsweise<br />
auf [OMG91, OPR96, Bet95, OSF92, Paw91, Sch93b, RKF93] sowie auf vergleichende<br />
Darstellungen wie [BKR93, BIBY95] verwiesen. Gegenuberstellungen und Bewertungen beider<br />
Plattformen im Rahmen der <strong>in</strong> dieser Arbeit dargestellten Aktivititaten nden sich <strong>in</strong><br />
[MML95f, CMML96, GML96, CM95, CM96, Gri96, Oh96].
144 Systemunterstutzung fur den Dienstzugang<br />
barkeit h<strong>in</strong> auswertet und beurteilt werden konnen. Weiterh<strong>in</strong> ermoglicht dieses<br />
Vorgehen e<strong>in</strong>e Analyse der genutzten <strong>verteilten</strong> Systemplattformen, so da unter<br />
anderem auch ihre momentan vorhandenen De zite | erstekonkreteAnmerkungen<br />
nden sich unter anderem <strong>in</strong> den Abschnitten 2.4.1 und 3.2.1.1 | aufgezeigt<br />
werden konnen.<br />
Analog zum Kapitel 3 wird zunachst der Entwurf und die Realisierung des<br />
Diensttypmanagers <strong>in</strong> TRADE vorgestellt. Im Anschlu folgt die Beschreibung<br />
der TRADE{Dienstvermittlungskomponente, dem TRADEr, wobei als e<strong>in</strong><br />
Schwerpunkt auf den Aufbau von Trader{Kooperationen e<strong>in</strong>gegangen wird. Abschlie<br />
end wird der Interzeptor beschrieben, der e<strong>in</strong>en Losungsansatz fur das e<strong>in</strong>gangs<br />
angefuhrte Problem technischer Heterogenitatsgrenzen zwischen auf DCE<br />
und CORBA basierenden Verwaltungsdomanen bietet.<br />
5.1 Diensttypmanagement <strong>in</strong> TRADE<br />
Wie <strong>in</strong> Kapitel 3 ausfuhrlich beschrieben wurde, spielt das Diensttypmanagement<br />
e<strong>in</strong>e wichtige Rolle beim Zugang zu Diensten <strong>in</strong> o enen <strong>verteilten</strong> Dienstemarkten.<br />
Hierbei wurden im e<strong>in</strong>zelnen die folgenden Teilaufgaben des Diensttypmanagements<br />
herausgearbeitet:<br />
strukturierte, domanenspezi sche Ablage von Diensttyp- und Beziehungstypbeschreibungen<br />
mit Bereitstellung von Grundfunktionen zum E<strong>in</strong>fugen,<br />
Loschen, Modi zieren, Suchen und Browsen von Typbeschreibungen�<br />
Verwaltungvon Beziehungs<strong>in</strong>stanzen, d.h. von <strong>in</strong> Beziehung stehenden Typen,<br />
wobei <strong>in</strong>nerhalb von TRADE vor allem Beziehungen zwischen Diensttypen<br />
von Interesse s<strong>in</strong>d�<br />
Austausch von Diensttyp- und Beziehungstypbeschreibungen, unter anderem<br />
im Rahmen von Trader{Kooperationen und plattformubergreifenden,<br />
Interzeptor{basierten Dienstzugri en und<br />
Durchfuhrung von Typvergleichen und {uberprufungen wahrend der e<strong>in</strong>zelnen<br />
Dienstzugangsphasen, d.h. der Diensttyp ndung, der Dienstvermittlung,<br />
der B<strong>in</strong>dung und dem Operationsaufruf.<br />
Die Erfullung dieserAufgaben erfolgt <strong>in</strong>nerhalb von TRADE <strong>in</strong> Form des prototypisch<br />
realisierten Diensttypmanagers bzw. Typmanagers. Mit se<strong>in</strong>en oben<br />
beschriebenen Aufgaben ubernimmt ere<strong>in</strong>e wichtige Funktion sowohl <strong>in</strong>nerhalb<br />
der Entwicklungs{ als auch <strong>in</strong>der Ausfuhrungsumgebung von TRADE. Zum<br />
e<strong>in</strong>en wird der Typmanager von den anderen <strong>in</strong> dieser Arbeit entwickelten und<br />
realisierten Systemkomponenten, <strong>in</strong>sbesondere dem TRADEr und dem Interzeptor<br />
(siehe Abschnitte 5.2und 5.3), zur Durchfuhrung ihrer spezi schen Aufgaben<br />
bei der Realisierung des Dienstzugangs <strong>in</strong> TRADE genutzt. Zum anderen<br />
unterstutzt er auch dieAnwendungsentwickler | neben der generellen Moglichkeit<br />
zur Verwaltung von Typbeschreibungen | beim Au nden von geeigneten
5.1 Diensttypmanagement <strong>in</strong> TRADE 145<br />
Diensttypbeschreibungen, um diese anschlie end beispielsweise bei der Entwicklung<br />
von Kooperationsanwendungen mittels der Koord<strong>in</strong>ationssprache PAMELA<br />
(siehe Abschnitt 6.1.2) verwenden zu konnen. Auf die Aspekte der Anwendungsentwicklung<br />
<strong>in</strong> TRADE geht Kapitel 6 noch detailliert e<strong>in</strong>.<br />
Die nachfolgenden Abschnitte beschreiben zunachst die Grundkonzepte des<br />
TRADE{Typmanagers. Die Darstellung schlie t mit der Beschreibung wichtiger<br />
Entwurfs{ sowie Implementationsentscheidungen <strong>in</strong> Abschnitt 5.1.4 ab.<br />
5.1.1 Beschreibung von Diensten<br />
Grundlage fur die Nutzungvon Diensten <strong>in</strong> TRADE bilden die Diensttypbeschreibungen,<br />
die sich imwesentlichen aus der Beschreibung e<strong>in</strong>es Schnittstellentyps<br />
undder Dienstattributtypen zusammensetzen. Wie <strong>in</strong> Abschnitt 2.4.5 ausfuhrlich<br />
diskutiert wurde, stellt das <strong>in</strong> Kapitel2e<strong>in</strong>gefuhrte Konzept der Diensttypen<br />
zum gegenwartigen Zeitpunkt e<strong>in</strong>e geeignete Kompromi losung zur Beschreibung<br />
von Diensten dar, das e<strong>in</strong>erseits e<strong>in</strong>en hohen Grad an Automatisierbarkeit<br />
von Diensttypvergleichen und{uberprufungen erlaubt undanderseitsausreichend<br />
ausdrucksmachtig ist, um die grundlegenden Eigenschaften der Dienste beschreibenzukonnen.<br />
Die fur den zweiten Aspekt bereitgestellten Dienstattributeerweisen<br />
sich unabhangig hiervon auch beider diensttypbasierten Dienstvermittlung<br />
durch den TRADEr als geeignete Grundlage zum automatisierten Au nden geeigneter<br />
Dienstangebote. Hier kommtzusatzlichauchder Vorteil von Diensttypen<br />
zum Tragen, da Vergleiche zwischen ihnen, <strong>in</strong>sbesondere der hier speziell betrachteten<br />
" Konformitats{\Beziehungstypen, <strong>in</strong> den meisten Fallen 2 weitgehend<br />
automatisch erfolgen konnen. Dieses ist e<strong>in</strong>e wesentliche Grundvoraussetzungfur<br />
die von vielen Anwendungen | vor allem auch von den hier speziell betrachteten<br />
Kooperationsanwendungen | geforderte automatische Dienstvermittlung.<br />
Abbildung 5.1 zeigt e<strong>in</strong> e<strong>in</strong>faches Beispiel e<strong>in</strong>er Diensttypbeschreibung <strong>in</strong> TRA-<br />
DE. Die gezeigte Diensttypbeschreibung setzt sich aus zwei Teilen zusammen:<br />
1. Zum e<strong>in</strong>en besteht sie aus der Beschreibung des Schnittstellentyps mit se<strong>in</strong>em<br />
Namen und den dar<strong>in</strong> de nierten Operationssignaturen. Die syntaktische<br />
Darstellung und der angebotene Beschreibungsumfang lehnen sich an<br />
die CORBA{Schnittstellenbeschreibungssprache (CORBA{IDL) [OMG91]<br />
an. So stehen zur Beschreibungder Parameter{und Resultatwerteder Operationen<br />
samtlichee<strong>in</strong>fache und komplexe Datentypen zur Verfugung. Weiterh<strong>in</strong><br />
wird auch das durch die RAISE{Anweisung zur Verfugung gestellte<br />
Fehlerbehandlungskonzept der CORBA{IDL unterstutzt, so da Fehlerfalle<br />
explizit beschrieben werden konnen.<br />
2. E<strong>in</strong> zweiter wesentlicher Bestandteil der Diensttypbeschreibung ist der<br />
Diensttypnameund die Beschreibung der Dienstattribute. Deren Beschreibung<br />
geschieht mittels e<strong>in</strong>er syntaktischen und semantischen Erweiterung<br />
2 Zur Problematik strukturell aquivalenter jedoch semantisch unterschiedlicher Diensttypen<br />
sei auf das <strong>in</strong> Abschnitt 2.1.2 und 2.4.5 beschriebene Beispiel der Diensttypen Stack und Queue<br />
verwiesen.
146 Systemunterstutzung fur den Dienstzugang<br />
// TRADE service type description<br />
// A fundamental pr<strong>in</strong>t service<br />
//@service type Pr<strong>in</strong>tService�<br />
//@category "pr<strong>in</strong>t","druck","hardcopy"�<br />
//@property static float costPerPage�<br />
//@property dynamic long queueLength<br />
<strong>in</strong>terface Pr<strong>in</strong>t {<br />
void Pr<strong>in</strong>tJob (<strong>in</strong> str<strong>in</strong>g Data, out long JobNumber)�<br />
}�<br />
Abbildung 5.1: Beispiel e<strong>in</strong>er TRADE{Diensttypbeschreibung<br />
der Kommentaranweisung (//) der CORBA{IDL. Hierdurch wird e<strong>in</strong>e<br />
hohe Integration <strong>in</strong> die bestehende CORBA{Umgebung erreicht, da derartig<br />
erweiterte Dienstbeschreibungen weiterh<strong>in</strong> auch mit den orig<strong>in</strong>aren<br />
CORBA{Mechanismen, beispielsweise dem dortigen IDL{Sprachubersetzer<br />
(engl. IDL compiler), verarbeitet werden konnen. Hierbei konnen die<br />
erweiterten Beschreibungsbestandteile jedoch nicht erkannt werden, sondern<br />
werden als herkommliche Kommentare behandelt. 3<br />
Die Angabe des Diensttypnamens erfolgt mittels der Anweisung<br />
//@service type. Er dient vor allem zur besseren Charakterisierung<br />
der Semantik des ansonsten nur strukturell und abstrakt beschriebenen<br />
Diensttyps und sollte dementsprechend e<strong>in</strong>en s<strong>in</strong>nvollen Namen besitzen.<br />
In der Diensttypbeschreibung wirdau erdem e<strong>in</strong> uber das Diensttypkonzept<br />
h<strong>in</strong>ausgehendes Kategorisierungskonzept //@category unterstutzt.<br />
Dieses wird vor allem als Grundlage fur e<strong>in</strong>e erweiterteSuchfunktionalitat<br />
im Typmanager verwendet, um zusatzlich zuden vorhandenen Dienstattributen,<br />
die bei der De nition von virtuellen Diensttypen (siehe Abschnitt<br />
3.2.2.6) genutzt werden konnen, e<strong>in</strong>e ubergeordnete Strukturierung von<br />
Diensttypen zu ermoglichen. Sie s<strong>in</strong>d konzeptuell vergleichbar mit den<br />
Schlusselwortern beim Information Retrieval [SM83].<br />
Die Beschreibung der Dienstattribute unterscheidet zwei Arten von<br />
Dienstattributen. //@property static float costPerPage� beispielsweise<br />
beschreibt e<strong>in</strong> statisches Dienstattribut, das den Preis pro<br />
Druckseite charakterisiert. Alternativ kann e<strong>in</strong> Dienstattribut jedoch<br />
auch alsdynamic spezi ziert werden, um se<strong>in</strong>espatere Modi zierbarkeit<br />
zu kennzeichnen. Die Unterscheidung von statischen und dynamischen<br />
Attributen wirkt sich <strong>in</strong>sbesondere auf den Vorgang der Dienstauswahl<br />
3 H<strong>in</strong>sichtlich des Diensttypnamens und der Dienstattribute existiert e<strong>in</strong>e alternative Darstellung<br />
(siehe Abschnitt 6.1.2.3), die auf der semantischen Uberladung von CORBA{IDL{<br />
Anweisungen beruht.
5.1 Diensttypmanagement <strong>in</strong> TRADE 147<br />
durch den TRADEr aus, bei dem die beiden Attributarten <strong>in</strong> e<strong>in</strong>em<br />
gesta elten Auswertungsvorgang jeweils unterschiedlich behandelt werden.<br />
Die speziell fur die CORBA{IDL aufgefuhrten diensttypspezi schen Erganzungen<br />
s<strong>in</strong>d auch fur die ebenfalls <strong>in</strong> TRADE relevante DCE{IDL vorgenommen<br />
worden (siehe[CM95, CM96]). Die Erweiterung erfolgt <strong>in</strong> ahnlicher Weise mittels<br />
der <strong>in</strong> der DCE{IDL vorhandenen Kommentaranweisung, so da auch<strong>in</strong>DCEe<strong>in</strong>e<br />
nahtlose Integration mit den orig<strong>in</strong>aren Typisierungskonzepten und Werkzeugen<br />
erreicht wird. Durch diese orthogonal fur beide Schnittstellenbeschreibungssprachen<br />
durchgefuhrten Erweiterungen wird e<strong>in</strong> e<strong>in</strong>heitliches Dienstverstandnis<br />
bzw. Dienstmodell <strong>in</strong> beiden <strong>verteilten</strong> Systemplattformen zur Verfugunggestellt.<br />
Dieses stellte<strong>in</strong>e erste Grundvoraussetzungdar, um die <strong>in</strong> Abschnitt 2.1 beschriebene<br />
Interoperabilitat auf Dienstbeschreibungsebene zu erreichen und somite<strong>in</strong>e<br />
wechselseitige <strong>Dienstnutzung</strong> zwischen beiden <strong>verteilten</strong> Systemplattformen zu<br />
ermoglichen.<br />
5.1.1.1 E<strong>in</strong> kanonisches Diensttypmodell<br />
Die zweite fur Interoperabilitat auf Beschreibungsebene notwendige Grundvoraussetzung<br />
ist die De nition e<strong>in</strong>er wechselseitigen Abbildung zwischen der DCE{<br />
IDL und der CORBA{IDL. Ziel dieses Abbildungsvorganges ist die De nition<br />
e<strong>in</strong>es kanonischen Diensttypmodells, das e<strong>in</strong>e verb<strong>in</strong>dliche und geme<strong>in</strong>same Beschreibungsgrundlage<br />
bildet, auf die spater auchandere Diensttypbeschreibungssprachen<br />
abgebildet werden konnen. Hierdurch wird e<strong>in</strong> geme<strong>in</strong>sames Verstandnis<br />
uber den Inhalt der ansonsten syntaktisch verschiedenen Dienstbeschreibungen<br />
erreicht. Es bildet somit die Grundvoraussetzung fur den wohlde nierten<br />
Austausch von Typbeschreibungen zwischen den Verwaltungsdomanen, wie<br />
er beispielsweise bei der Abwicklung der <strong>in</strong> Abschnitt 3.3.3.3 beschriebenen<br />
Trader{Kooperationsprotokolle notwendig ist. E<strong>in</strong> ahnlicher Abbildungsansatz<br />
ist beispielsweise auch <strong>in</strong> CORBA [OMG91] oder ILU [JSS95] durch sogenannte<br />
Sprachabbildungen (engl. language mapp<strong>in</strong>gs) realisiert, bei denen die Typsysteme<br />
verschiedener Programmiersprachen auf das kanonische CORBA{ bzw. ILU{<br />
Typmodell abgebildet werden. Dadurch wird es anschlie endmoglich, Dienstnehmer<br />
und Diensterbr<strong>in</strong>ger <strong>in</strong> verschiedenen Programmiersprachen zu entwickeln,<br />
die uber das geme<strong>in</strong>same Typverstandnis des kanonischen Modells zue<strong>in</strong>ander<br />
typkompatibel s<strong>in</strong>d.<br />
Bei der <strong>in</strong> TRADE speziell untersuchten Abbildung von DCE{ und CORBA{<br />
Diensttypbeschreibung zeigtsich <strong>in</strong>sgesamt, da e<strong>in</strong>e wechselseitige Abbildung<br />
von samtlichen <strong>in</strong> beiden IDLs vorhandenen Beschreibungskonzepten generell<br />
nicht s<strong>in</strong>nvoll ist bzw. zum Teil, wie beispielsweise bei den Kontext<strong>in</strong>formationen,<br />
auch nicht durchfuhrbar ist. Wesentliches Kriterium fur die Entwicklung<br />
e<strong>in</strong>es kanonischen Diensttypmodells war die Auswahl derjenigen Beschreibungskonzepte,<br />
die e<strong>in</strong> hohes Ma an Unabhangigkeit von Spezi kas der DCE{ und<br />
CORBA{Plattformen erlauben. Resultat dieses Auswahlprozesses, der ausfuhrlich<br />
<strong>in</strong> [CM95, Oh96] beschrieben ist, ist die De nition e<strong>in</strong>er maximalen Schnittmenge<br />
der <strong>in</strong> beiden Diensttypbeschreibungssprachen vorhandenen Beschrei-
148 Systemunterstutzung fur den Dienstzugang<br />
bungskonzepte. Diese Schnittmenge bildet das kanonische Diensttypmodell. Es<br />
versteht sich hierbei nicht als universelles Modell, da esimhohem Ma e <strong>in</strong><br />
H<strong>in</strong>blick auf die Unterstutzung des Dienstzugangs <strong>in</strong> DCE{ und CORBA{<br />
Systemumgebungen angepa t ist.<br />
Erleichtert wird die Abbildungdadurch, da CORBA{ und DCE{basierte Diensttypbeschreibungen<br />
e<strong>in</strong>e gewisse Ahnlichkeit besitzen. Dieses zeigt sich beispielsweise<br />
bei der Abbildung des Schnittstellentypkonzeptes, das <strong>in</strong> beiden <strong>verteilten</strong><br />
Systemplattformen ahnlich ausgedruckt wird.<br />
Aufwendiger gestaltet sich die Abbildung von Konzepten, fur die ke<strong>in</strong>e aquivalenten<br />
Beschreibungsmoglichkeiten existieren. E<strong>in</strong> <strong>in</strong>sbesondere zu berucksichtigendes<br />
Problem ist die Nutzung von sogenannten Zeigern (engl. po<strong>in</strong>ters) <strong>in</strong> der<br />
DCE{IDL. Sie nden unter anderem Verwendung bei der Beschreibung von komplexen<br />
Strukturen, wie beispielsweise verketteten Listen. Da <strong>in</strong> der CORBA{IDL<br />
Zeiger nicht unterstutzt werden, wird e<strong>in</strong>e Abbildung auf den dort vorhandenen<br />
sequence{Konstruktur vorgenommen. E<strong>in</strong> Beispiel hierfur wurde bereits<strong>in</strong>Abbildung<br />
3.38 <strong>in</strong> Abschnitt 3.4.1.1 gezeigt.<br />
E<strong>in</strong> weiteres Problem stellt auch die Abbildungvon Beschreibungskonzepten dar,<br />
die nur exklusiv <strong>in</strong> e<strong>in</strong>er der beiden IDLs de niert s<strong>in</strong>d. Dieses betri t beispielsweise<br />
das <strong>in</strong> der CORBA{IDL vorhandene Darstellung von Fehlerfallen mittels<br />
der RAISE{Anweisung, die <strong>in</strong> dieser Form nicht durch die DCE{IDL unterstutzt<br />
wird. E<strong>in</strong> anderes Beispiel s<strong>in</strong>d die sogenannten Kontext<strong>in</strong>formationen (engl.<br />
context handles) <strong>in</strong> der DCE{IDL, die zur Beschreibung zustandsbasierter Interaktionsverb<strong>in</strong>dungen<br />
zwischen Dienstnehmer und Diensterbr<strong>in</strong>ger verwendet<br />
werden. Hierfur existiert <strong>in</strong> der CORBA{IDL ke<strong>in</strong> semantisch vergleichbares<br />
Konzept.<br />
5.1.2 Beschreibung und Verwaltung von Beziehungstypen und<br />
{<strong>in</strong>stanzen<br />
E<strong>in</strong>e der Hauptaufgaben des Typmanagers ist zum e<strong>in</strong>en die Verwaltung von<br />
Beziehungstypen. Zum anderen verwaltet er Beziehungs<strong>in</strong>stanzen, die konkret<br />
<strong>in</strong> Beziehung stehende Typen des kanonischen Diensttypmodells kennzeichnen.<br />
Grundlage hierfur bildet das <strong>in</strong> Abschnitt 3.2.2.2 dargestellte rollenbasierte Beziehungstypkonzept.<br />
Bei diesem werden sogenannte Rollen, die pr<strong>in</strong>zipiell verschiedenartigsten<br />
Typs se<strong>in</strong> konnen, uber Charakteristika und De nitionsregeln<br />
sowie unter Umstanden auch durch e<strong>in</strong>e <strong>in</strong>formelle Beschreibung <strong>in</strong>Beziehung<br />
gesetzt. In H<strong>in</strong>blick auf die Unterstutzung des Dienstzugangs <strong>in</strong> o enen <strong>verteilten</strong><br />
Dienstemarkten <strong>in</strong>teressieren hierbei vor allem die homogenen, b<strong>in</strong>aren<br />
Beziehungstypen, die zwei Diensttypen | d.h. Rollen dieses spezi schen Typs<br />
| zue<strong>in</strong>ander <strong>in</strong> Beziehung stellen. Beispiele hierfur s<strong>in</strong>d die im Abschnitt 5.1.2<br />
speziell betrachteten Konformitats{ bzw. Subtypbeziehungen, die <strong>in</strong>nerhalb von<br />
DCE und CORBA sowie dem ODP{Referenzmodell Verwendung nden. Generell<br />
werden durchden realisierten Typmanager jedoch beliebige Beziehungstypen<br />
unterstutzt, bei denen die Rollen nichtnur homogenen, sondern auchheterogenen<br />
Typs se<strong>in</strong> konnen. Die vom Typmanager hierfur zur Verfugung gestellten Typen
5.1 Diensttypmanagement <strong>in</strong> TRADE 149<br />
fur die Rollen orientieren sich andem oben genannten kanonischen Diensttypmodell.<br />
5.1.2.1 Unterstutzung von Konformitatsbeziehungen<br />
E<strong>in</strong> besonderer Gesichtspunkt <strong>in</strong> der momentanen Realisierung des Typmanagers<br />
ist dabei die spezielle Unterstutzung verschiedener Varianten von Konformitatsbeziehungen<br />
zwischen Diensttypen. Wesentlicher Grund hierfur ist die Existenz<br />
zahlreicher De nitionen, die zur Zeit von den etablierten <strong>verteilten</strong> Systemplattformen<br />
angeboten werden und die beim konkreten, plattformubergreifenden<br />
Dienstzugang berucksichtigt werden mussen. Das durch den Typmanager bereitgestellte<br />
Unterstutzungskonzept ist dabei derartig allgeme<strong>in</strong> entworfen, da im<br />
Pr<strong>in</strong>zip verschiedenste Arten von Konformitatsbeziehungen de niert und verarbeitet<br />
werden konnen. Dieses umfa t auch die <strong>in</strong> Abschnitt 2.3.2 ausfuhrlich beschriebene<br />
ODP{basierte Konformitatsbeziehung. Der hierfur gewahlte allgeme<strong>in</strong>e<br />
De nitionsansatz, der auch <strong>in</strong> [CMML96] und [CM96] ausfuhrlichbeschrieben<br />
ist, basiert auf e<strong>in</strong>em aus [ZW95] stammenden formalen Konzept von Beziehungen<br />
zwischen (Software{)Modulen und Funktionen. Hierbei wird davon ausgegangen,<br />
da jede Beziehung e<strong>in</strong>er hoheren Granularitatsebene auf Beziehungen<br />
unterliegender Granularitatsebenen aufbaut. So setzen sich im dort betrachtetem<br />
Fall die Software{Module aus e<strong>in</strong> oder mehreren Funktionen zusammen.<br />
Dieser generelle Ansatz der Unterscheidung unterschiedlicher Granularitatsebenen<br />
eignet sich auch fur die hier speziell betrachteten Diensttypen, die sich ebenfalls<br />
<strong>in</strong> mehrere Granularitatsebenen e<strong>in</strong>teilen lassen. Hierzu wurdeder orig<strong>in</strong>are<br />
Ansatz derartig geandert und erweitert, da entsprechend der De nition des <strong>in</strong><br />
TRADE verwendeten kanonischen Diensttypmodells <strong>in</strong>sgesamt vier verschiedene<br />
Granularitatsebenen unterschieden werden: Die Ebene der Datentypen, der<br />
Operationstypen, der Schnittstellentypen und der Diensttypen. Die Verknupfung<br />
der Ebenen <strong>in</strong>nerhalb e<strong>in</strong>es Beziehungstyps wird mit Hilfe sogenannter De nitionsregelmuster<br />
(engl. de nition rule templates) [ZW95] ausgedruckt. Hierbei<br />
referenziert e<strong>in</strong> auf hoherer Granularitatsebene de niertes De nitionsregelmuster<br />
e<strong>in</strong>e beliebige Anzahl von auf unterliegenden Granularitatsebenen be ndlichen<br />
Beziehungen. Jedes De nitionsregelmuster besteht hierbei zusatzlichaus e<strong>in</strong>er<br />
Menge von speziellen De nitionsregeln, den sogenannten " Lockerungsregeln\<br />
(engl. relaxations) [ZW95]. Diese ermoglichen e<strong>in</strong>e Erhohung der Flexibilitat bei<br />
der bei Konformitatsbeziehungstypen ansonsten ublicherweise sehr strikten und<br />
statischen Festlegung von Identitaten auf e<strong>in</strong>er bestimmten Granularitatsebene.<br />
So kann es beispielsweise unter Umstanden s<strong>in</strong>nvoll se<strong>in</strong>, da bei e<strong>in</strong>er Beziehung<br />
zwischen zwei Diensttypen die Namen der Operationen unterschiedlich se<strong>in</strong><br />
konnen. Zusammenfassend werden vom Typmanager folgende De nitionsregelmuster<br />
zur Verfugunggestellt, mit denen Konformitats{ bzw. Subtypbeziehungen<br />
auf den vier verschiedenen Granularitatsebenen de niert werden konnen:<br />
De nition 5.1 (De nitionsregelmuster fur Datentypen)<br />
(Lockerungs{)Regeln:
150 Systemunterstutzung fur den Dienstzugang<br />
1. Die Namen der Datentypen zwischen Sub{ und Supertyp durfen unterschiedlich<br />
se<strong>in</strong> (engl. type variable renam<strong>in</strong>g [ZW95, LW93]).<br />
2. Typanpassungen (engl. coercion) [CW85] zwischen e<strong>in</strong>fachen Datentypen<br />
s<strong>in</strong>d moglich, beispielsweise kann e<strong>in</strong> Ganzzahlwert auch bei Erwartung<br />
e<strong>in</strong>es reellen Wertes verwendet werden.<br />
3. Subtypen von Tupel{Typen, beispielsweise Strukturen, durfen die Signatur<br />
des Supertypen erweitern, wahrend Subtypen von Auswahltypen (engl. option<br />
types) nur e<strong>in</strong>e Teilmenge der Teilkomponenten des Supertypen haben<br />
durfen [Car89].<br />
4. Jeder Datentyp ist Subtyp von e<strong>in</strong>em Typ top (Parametrischer Polymorphismus<br />
[CW85]), beispielsweise any <strong>in</strong> der CORBA{IDL, und bottom ist<br />
der Subtyp aller Datentypen [ODP95c].<br />
De nition 5.2 (De nitionsregelmuster fur Operationstypen)<br />
Referenz: Beziehung zwischen Datentypen<br />
Regeln: 4<br />
1. Operationsnamen durfen unterschiedlich se<strong>in</strong>.<br />
2. Die Namen der Operationsparameter durfen di erieren.<br />
3. E<strong>in</strong>e unterschiedliche Reihenfolge der Operationsparameter ist moglich<br />
(engl. reorder<strong>in</strong>g [ZW95]).<br />
4. Subtypen durfen zusatzliche Operationsparameter h<strong>in</strong>zufugen.<br />
De nition 5.3 (De nitionsregelmuster fur Schnittstellentypen)<br />
Referenz: Beziehung zwischen Operationstypen<br />
Regeln:<br />
1. Schnittstellennamen durfen unterschiedlich se<strong>in</strong>.<br />
2. E<strong>in</strong>e Anderung der Reihenfolge der Operationstypen ist moglich.<br />
3. Subtypen durfen neue Operationstypen h<strong>in</strong>zufugen.<br />
De nition 5.4 (De nitionsregelmuster fur Diensttypen)<br />
Referenz: Beziehung zwischen Datentypen (zur Darstellung von Dienstattributen)<br />
Referenz: Beziehung zwischen Schnittstellentypen<br />
Regeln:<br />
1. Die Namen der Dienstattribute durfen unterschiedlich se<strong>in</strong>.<br />
4 Die Subtypisierung von Operationsparametern basiert grundsatzlich auf dem Pr<strong>in</strong>zip kovarianter<br />
Argumente und kontravarianter Resultate [Car89, ODP95c] (siehe auch De nition<br />
2.1 <strong>in</strong> Abschnitt 2.3.2).
5.1 Diensttypmanagement <strong>in</strong> TRADE 151<br />
2. Die Diensttypnamen durfen di erieren.<br />
3. Subtypen durfen neue Dienstattributtypen h<strong>in</strong>zufugen.<br />
Mit Hilfe dieser De nitionsregelmuster konnen unter anderem die <strong>in</strong> den oben genannten<br />
<strong>verteilten</strong> Systemplattformen de nierten Konformitatsbeziehungen zwischen<br />
Schnittstellentypen ausgedruckt werden. Tabelle 5.1 gibt e<strong>in</strong>en Uberblick<br />
uber die Konformitatsbeziehungen des ODP{Referenzmodells, der Object Management<br />
Architecture (OMA) [OMG92] und der <strong>verteilten</strong> Systemplattformen<br />
DCE, CORBA und ANSA.<br />
Datentypen Operationstypen Schnittst.<br />
1 2 3 4 1 2 3 4 1 2 3<br />
ODP x x x x x x<br />
OMA x x x<br />
CORBA, DCE, ANSA x x<br />
Tabelle 5.1: Darstellbarkeit verschiedener Konformitatsbeziehungen mittels Denitionsregelmustern<br />
Weiterh<strong>in</strong> s<strong>in</strong>d jedochauch andere Variationen von Konformitatsbeziehungen<br />
zwischen Diensttypen mit Hilfe der obigen De nitionsregelmuster de nierbar.<br />
Bei der De nition von Konformitatsbeziehungen wird der Anwendungsentwickler<br />
durch e<strong>in</strong>e graphische Benutzerschnittstelle unterstutzt. Diese nutzt die Funktionen<br />
des <strong>in</strong> dieser Arbeit entwickelten Typmanagers, der im Rahmen von TRADE<br />
prototypisch realisiert ist. Der Typmanager ubernimmt hierbei die e<strong>in</strong>gangs von<br />
Abschnitt 5.1 beschriebenen Aufgaben des Typmanagements <strong>in</strong>o enen <strong>verteilten</strong><br />
Dienstemarkten. Se<strong>in</strong>e Funktionen bietet er den Klienten <strong>in</strong> Form mehrerer<br />
funktional getrennter Schnittstellen an (siehe Abschnitt 5.1.4). Die graphische<br />
Benutzerschnittstelle als e<strong>in</strong>e wichtige Klientenanwendung ermoglicht dem Anwendungsprogrammierer<br />
e<strong>in</strong>en <strong>in</strong>tuitiven und e<strong>in</strong>fachen Zugang zuder Funktionalitat<br />
des Typmanagers und verbirgt hierbei die Komplexitat der hierfur notwendigen,<br />
<strong>in</strong> der Regel komplexen Operationsaufrufe an den Typmanagerschnittstellen.<br />
Dabei unterstutzt sie sowohl das <strong>in</strong>teraktive E<strong>in</strong>fugen neuer Diensttyp{<br />
und Beziehungstypbeschreibungen als auch das Brows<strong>in</strong>g und die strukturierte<br />
Suche nach Diensttypbeschreibungen, die beispielsweise im Rahmen der Entwicklung<br />
von Kooperationsanwendungen und deren Anwendungsvorgangen genutzt<br />
werden mochten. Das E<strong>in</strong>fugen neuer Beziehungstypen auf der Grundlage<br />
der obigen De nitionsregelmuster verdeutlicht Abbildung 5.2. Die Optionen der<br />
E<strong>in</strong>gabemaske orientieren sich anden De nitionsregeln, die fur jede Granularitatsebene<br />
im De nitionsregelmuster de niert s<strong>in</strong>d. Grundlage fur die <strong>in</strong> der<br />
Abbildung gezeigte Ebeneder Schnittstellentypen bildet dementsprechend das<br />
De nitionsregelmuster 5.3), <strong>in</strong> dem <strong>in</strong>sgesamt drei De nitionsregeln festgelegt<br />
s<strong>in</strong>d. Der im De nitionsregelmuster geforderte Bezug zur bereits vorhandenen<br />
Beziehungstypde nition auf Operationstypebene wird mit Hilfe e<strong>in</strong>es e<strong>in</strong>deutigen<br />
Namens erreicht, welcher im gezeigten E<strong>in</strong>gabefeld Relationship between<br />
operations angegeben wird.
152 Systemunterstutzung fur den Dienstzugang<br />
Abbildung 5.2:E<strong>in</strong>fugen neuer Konformitatsbeziehungstypen auf der Granularitatsebene<br />
der Schnittstellentypen<br />
Au er der De nition von Konformitatsbeziehungen unterstutzt der Typmanager<br />
auch die De nition beliebiger anderer Beziehungen, die zwischen Typen auf den<br />
unterschiedlichen Granularitatsebenen ausgedruckt werden sollen. Im Gegensatz<br />
zu den auf De nitionsregelmustern aufsetzenden Konformitatsbeziehungen, die<br />
speziell durch den Typmanager unterstutzt werden, existiert hierbei momentan<br />
jedoch nochke<strong>in</strong>e Moglichkeit, De nitionsregeln formal angeben zu konnen. Ihre<br />
Beschreibung erfolgt <strong>in</strong>formell durch textuelle Beschreibung der Charakteristika<br />
der Beziehung und ihrer Semantik. Neue Beziehungs<strong>in</strong>stanzen mussen deshalb<br />
spater manuell durch den Anwendungsprogrammierer e<strong>in</strong>gefugt werden, da e<strong>in</strong>e<br />
automatisierteVerwaltungderartiger Beziehungen nichtmoglich ist. E<strong>in</strong> Beispiel<br />
ist die De nition e<strong>in</strong>er " semantischen\ Beziehung, die Diensttypen mit e<strong>in</strong>em<br />
bestimmten Anwendungsentwicklungsprojekt verknupft, so da e<strong>in</strong>e projektbezogene<br />
Gruppierung von Diensttypbeschreibungen moglich ist.<br />
5.1.2.2 Automatisierter Aufbau von Diensttyphierarchien<br />
Nachdem mit Hilfe der De nitionsregelmuster neue Konformitatsbeziehungen<br />
de niert wurden, lassen sich durch E<strong>in</strong>fugen neuer Diensttypbeschreibungen automatisch<br />
Diensttyphierarchien durchden Typmanager aufbauen. Der Aufbauerfolgt<br />
unter Nutzungder fur jede Granularitatsebenee<strong>in</strong>er Diensttypbeschreibung<br />
de nierten De nitionsregeln. Hierzu ist e<strong>in</strong> Traversieren der Diensttyphierarchie<br />
notwendig, bei dem Vergleiche zwischen dem e<strong>in</strong>zufugenden und den bereits vorhandenen<br />
Diensttypen durchgefuhrt werden mussen. Die Vergleiche nden auf<br />
der Basis der strukturellen Bestandteile der Diensttypbeschreibungen und der <strong>in</strong>
5.1 Diensttypmanagement <strong>in</strong> TRADE 153<br />
Abbildung 5.3: Graphische Visualisierung e<strong>in</strong>er Diensttyphierarchie<br />
den De nitionsregeln des Beziehungstyps festgelegten Vergleichskriterien statt.<br />
Das Resultat des E<strong>in</strong>fugevorganges kann dem Anwendungsentwickler wiederum<br />
mittels der graphischen Benutzerschnittstelle des Typmanagers angezeigt<br />
werden (Abbildung 5.3). Durch diese Eigenschaft des Typmanagers, Diensttypbeschreibungen<br />
automatisch <strong>in</strong> Konformitatsbeziehungen e<strong>in</strong>fugen zu konnen,<br />
wird die unter anderem <strong>in</strong> Abschnitt 2.4.5 gestellte Forderung nach e<strong>in</strong>er weitgehenden<br />
Automatisierbarkeit der Verarbeitung von Diensttypbeschreibungen und<br />
ihrer Beziehungen erfullt. Hierdurch la t sich die zukunftig <strong>in</strong> o enen <strong>verteilten</strong><br />
Dienstemarkten zu erwartende Vielzahl standig neu h<strong>in</strong>zukommender Diensttypbeschreibungen<br />
adaquat behandeln. Manuelle Losungsansatze s<strong>in</strong>d hierfur aufgrund<br />
des Verwaltungsaufwandes nicht geeignet und auch h<strong>in</strong>sichtlich Anderungen<br />
zu wenig exibel. Hieraus ergibt sich auch der wesentliche Kritikpunkt an<br />
den zur Zeit etablierten <strong>verteilten</strong> Systemplattformen, die im Vergleich zum hier<br />
entwickelten Typmanager <strong>in</strong> der Regel nur relative e<strong>in</strong>facheTypverwaltungs{ und<br />
Typvergleichsmechanismen zur Verfugung stellen. So bieten beispielsweise DCE<br />
und ANSA nur namensbasierte Ansatze an, die fur e<strong>in</strong>e automatisierte Verwaltung<br />
von Diensttypen nicht ausreichends<strong>in</strong>d. Zudem s<strong>in</strong>d sieauf die Behandlung<br />
e<strong>in</strong>es spezi schen Beziehungstyps beschrankt, so da auf dieser Grundlage Vergleiche<br />
zwischen Diensttypbeschreibungen anderer Plattformen | sofern dieses<br />
uberhaupt angestrebt wird | nur h<strong>in</strong>sichtlich ihrer Identitat erfolgen konnen.<br />
5.1.2.3 Suche nach konformen Diensttypen<br />
Im engen Zusammenhang mit dem automatisierten Aufbau von Diensttyphierarchien<br />
stehen auch dieFahigkeiten des Typmanagers, automatisierte Typuberprufungen<br />
und {vergleiche anbieten zu konnen. So eignen sich die implizit<br />
beim E<strong>in</strong>fugen von Diensttypbeschreibungen verwendeten Vergleichsmechanismen<br />
auch dazu, sie direkt an der Schnittstelle des Typmanagers verfugbar zu<br />
machen. Diese konnen dann, wie es beispielsweise konkret beim TRADEr im
154 Systemunterstutzung fur den Dienstzugang<br />
Rahmen der von ihm durchgefuhrten gesta elten Auswertung realisiert wird,<br />
zum automatischen Au nden <strong>in</strong> Konformitatsbeziehung stehender Diensttypen<br />
verwendet werden. Hierbei wird ausgenutzt, da die Diensttypen <strong>in</strong> e<strong>in</strong>er hierarchischen<br />
Struktur angeordnet s<strong>in</strong>d, so da die Diensttypvergleiche nur bis zum<br />
Au nden e<strong>in</strong>es aquivalenten Diensttyps oder e<strong>in</strong>es Subtyps durchgefuhrt werden<br />
mussen. Alle anderen Subtypen s<strong>in</strong>d dann <strong>in</strong> den unterliegenden Teilhierarchien<br />
ohne weitere Vergleiche direkt zugreifbar.<br />
5.1.3 Austausch und Verarbeitung von Typbeschreibungen<br />
Bei der Darstellung <strong>in</strong>den vorherigen Abschnitten wurde bereits implizit die<br />
Annahme getro en, da e<strong>in</strong>e systemtechnische Reprasentation von Diensttyp{<br />
und Beziehungstypbeschreibungen im Typmanager existiert, auf der unter anderem<br />
die erwahnten Typvergleiche beim E<strong>in</strong>fugen neuer Diensttypbeschreibungen<br />
<strong>in</strong> e<strong>in</strong>e Typhierarchie durchfuhrbar s<strong>in</strong>d. E<strong>in</strong>e derartige Typreprasentation<br />
ermoglicht die Reprasentation der <strong>in</strong> den Typbeschreibungen zunachst abstrakt<br />
vorhandenen Informationen, um sie e<strong>in</strong>er weiteren systemtechnischen Verarbeitung<br />
zuganglich zumachen. 5 Sie stellt gleichzeitig fur den Typmanager auche<strong>in</strong>e<br />
Moglichkeit dar, um Typbeschreibungen mit se<strong>in</strong>en externen Nutzer austauschen<br />
zu konnen. Grundsatzlich s<strong>in</strong>d <strong>in</strong>sgesamt drei unterschiedliche Austauschvarianten<br />
an der Schnittstelle des Typmanagers moglich:<br />
1. Verwendung von bereits vom Typmanager vergebenen Typbezeichnern:<br />
In diesem Fall ist die Typbeschreibung bereitszue<strong>in</strong>em fruheren Zeitpunkt<br />
e<strong>in</strong>gefugt worden, so da zu ihrer Referenzierung der vom Typmanager erzeugte<br />
e<strong>in</strong>deutige Typbezeichner verwendet werden kann. Bei se<strong>in</strong>em Austausch,<br />
<strong>in</strong>sbesondere mit Klienten anderer Verwaltungsdomanen, wird er<br />
<strong>in</strong> global e<strong>in</strong>deutiger Form angeboten (siehe Abschnitt 3.2.3.1), so da er<br />
domanenubergreifende<strong>in</strong>deutig dem erzeugenden Typmanager zugeordnet<br />
werden kann. Mit ihm kann dann beispielsweise e<strong>in</strong> anderer Typmanager<br />
im Rahmen e<strong>in</strong>er Typmanager{gesteuerten Trader{Kooperation die dem<br />
Typbezeichner h<strong>in</strong>terliegende Diensttypbeschreibung <strong>in</strong>e<strong>in</strong>er ihm bekannten<br />
Diensttypbeschreibungssprache anfordern (siehe Abschnitt 3.3.3.3).<br />
2. Ubergabe der Typbeschreibung als e<strong>in</strong>fache, un<strong>in</strong>terpretierteZeichenkette:<br />
Diese Moglichkeit des Austausches von Typbeschreibungen, <strong>in</strong>sbesondere<br />
Diensttypbeschreibungen, <strong>in</strong> textueller Form stellt die e<strong>in</strong>fachste Moglichkeit<br />
e<strong>in</strong>er Typreprasentation dar. Sie setzt voraus, da der Anfragende uber<br />
geeignete Interpretationsmechanismen, beispielsweise entsprechende Parser,<br />
verfugt, die ihm e<strong>in</strong>en Zugang zuden Informationen der Typbeschreibung<br />
ermoglichen. In dem entwickelten Typmanager wird diese Funktionalitat<br />
durch sogenannte Abbildungskomponenten erbracht, die e<strong>in</strong>e <strong>in</strong>e<strong>in</strong>er<br />
bestimmten Beschreibungssprache verfa te Diensttypbeschreibung <strong>in</strong>die<br />
<strong>in</strong>tern im Typmanager verwendete, selbstbeschreibende Typreprasentation<br />
uberfuhren (siehe auch Abbildung 5.4).<br />
5 siehe hierzu vor allem auch die Abschnitte 2.1.3 und 3.2.3.2
5.1 Diensttypmanagement <strong>in</strong> TRADE 155<br />
3. Kodierung der Typbeschreibung <strong>in</strong>Form e<strong>in</strong>er sich selbstbeschreibenden<br />
Datenstruktur:<br />
Die e<strong>in</strong>gangs erwahnte Typreprasentation ermoglicht durch ihren selbstbeschreibenden<br />
Charakter e<strong>in</strong>e Vorstrukturierung der Informationen e<strong>in</strong>er<br />
Diensttypbeschreibung. In ihr liegen die Informationen <strong>in</strong> e<strong>in</strong>deutig kodierter<br />
Form vor, so da bei entsprechender Kenntnis dieses Formates e<strong>in</strong>e<br />
direkter Zugri auf Teil<strong>in</strong>formationen moglich ist. Diese Darstellungsweise<br />
bildet e<strong>in</strong>e geeignete Grundlage zur systemtechnischen Verarbeitung im<br />
Typmanager, auf der unter anderem die beim E<strong>in</strong>fugen neuer Diensttypbeschreibungen<br />
<strong>in</strong> e<strong>in</strong>e Konformitatsbeziehung notwendigen Typvergleichsmechanismen<br />
e zient realisiert werden konnen.<br />
E<strong>in</strong>e bildliche Darstellung der beiden letztgenannten Ubergabevarianten ndet<br />
sich <strong>in</strong>Abschnitt 2.1.3 <strong>in</strong> Abbildung 2.1.<br />
Die nachfolgende Beschreibung gibt e<strong>in</strong>en konkreten E<strong>in</strong>blick <strong>in</strong> die vom<br />
TRADE{Typmanager zum Austausch von Typbeschreibungen (Diensttypen<br />
und Beziehungstypen) genutzte Typrepasentation. 6<br />
/* Dienstattributtypen */<br />
struct Property {<br />
Identifier propertyName�<br />
TypeId propertyType�<br />
boolean dynamic�<br />
}�<br />
typedef sequence PropertyList�<br />
/* Diensttypen */<br />
struct ServiceType {<br />
Identifier name�<br />
str<strong>in</strong>g uuid�<br />
str<strong>in</strong>g orig<strong>in</strong>alImplementationMiddleware�<br />
TypeId <strong>in</strong>terfaceType� // Verweis auf Typbezeichner<br />
PropertyList properties�<br />
IdentifierList semantics�<br />
IdentifierList categories�<br />
}�<br />
union Type switch (K<strong>in</strong>dOfType) {<br />
case DATA_TYPE: TypeCode dt�<br />
case CONST_TYPE: Const cnst�<br />
case TYPEDEF_TYPE: Typedef tdef�<br />
case EXCEPTION_TYPE: Exception exc�<br />
case ATTRIBUTE_TYPE: Attribute attr�<br />
case OPERATION_TYPE: Operation op�<br />
case INTERFACE_TYPE: Interface <strong>in</strong>tf�<br />
case SERVICE_TYPE: ServiceType svc�<br />
case RELATIONSHIP_TYPE: Relationship rel�<br />
}�<br />
6 Diese Typreprasentation wird auch bei der Realisierung des <strong>in</strong> dieser Arbeit entwickelten<br />
TRADErs (Abschnitt 5.2) und des Interzeptors (Abschnitt 5.3) verwendet.
156 Systemunterstutzung fur den Dienstzugang<br />
Sie zeigt e<strong>in</strong>en kle<strong>in</strong>en Ausschnitt aus der <strong>in</strong> der CORBA{IDL beschriebenen<br />
Schnittstelle des Typmanagers, deren vollstandige Schnittstellenbeschreibung<br />
sich<strong>in</strong>den Anhangen B undCbe ndet. Die entsprechende <strong>in</strong> DCE{IDL beschriebeneTypmanagerschnittstelle<br />
ndet sich <strong>in</strong> [CM96]. Die dargestellteDatenstruktur<br />
Type bildet die zentrale Basis der Typreprasentation. Neben der Wiedergabe<br />
von Beziehungstypbeschreibungen (RELATIONSHIP Type) ermoglicht sie vor allem<br />
die Reprasentation der Bestandteile e<strong>in</strong>er auf dem kanonischen Diensttypmodell<br />
basierenden Diensttypbeschreibung. So verzweigt sich beispielsweise e<strong>in</strong><br />
Diensttyp (case SERVICE TYPE) <strong>in</strong> se<strong>in</strong>e weiteren E<strong>in</strong>zelbestandteile, die durch<br />
den Datentypen ServiceType de niert s<strong>in</strong>d, der selbst wiederum unter anderem<br />
auf e<strong>in</strong>e Listevon Dienstattributtypen (PropertyList)und e<strong>in</strong>en Schnittstellentyp<br />
verweist. Die Verknupfung der sich auf unterschiedlicher Granularitatsebene<br />
be ndlichen Typen, wie <strong>in</strong> diesem Fall beispielsweise Diensttypen und Schnittstellentypen,<br />
geschieht hierbei <strong>in</strong> Form von Typbezeichnern (TypeId), die fur<br />
jeden de nierten Typ e<strong>in</strong>deutig vom Typmanager vergeben werden.<br />
5.1.4 Aufbau des Typmanagers<br />
Dieser Abschnitt beschreibt ausgewahlte Aspekte der Realisierung des Typmanagers.<br />
Als Realisierungsplattformen standen zum e<strong>in</strong>en stellvertretend fur e<strong>in</strong>e<br />
CORBA{Umgebung e<strong>in</strong>e aktuelle Orbix{Implementation von IONA Technologies<br />
Ltd. [ION94] und zumanderen die aktuelle DCE{Version von IBM zur<br />
Verfugung, so da der Typmanager derzeitig auf beiden Plattformen verfugbar<br />
ist.<br />
Generelle Grundlage fur die Realisierung des Typmanagers bildet die oben genannte<br />
Typreprasentation, die <strong>in</strong> Form e<strong>in</strong>er C++{basierten Klassenbibliothek 7<br />
zur Verfugung steht. Diese Klassenbibliothek erlaubt e<strong>in</strong>en e<strong>in</strong>fachen Umgang<br />
mit den zum Teil komplexen Datenstrukturen, die bei der Reprasentation von<br />
Diensttypen und Beziehungstypen aufzubauen und zuverarbeiten s<strong>in</strong>d. Sie kann<br />
auch fur die Entwicklung von Anwendungen genutzt werden, die auf die Funktionalitat<br />
des Typmanagers zugreifen. E<strong>in</strong>e wesentliche Eigenschaft der Klassenbibliothek<br />
ist die Moglichkeit zur persistenten Speicherung [Sou94], so da<br />
im Typmanager verarbeitete Typreprasentationen auf e<strong>in</strong>em stabilen Speicher<br />
gesichert und spater auch wieder gelesen werden konnen. Weiterh<strong>in</strong> bietet die<br />
Bibliothek Methoden zum Erzeugen, Kopieren, Ausdrucken und zumVergleichen<br />
an. Insbesondere die Vergleichsmethoden werden <strong>in</strong>tensiv genutzt, um unter anderem<br />
die auf De nitionsregelmustern basierenden Konformitatsbeziehungen zu<br />
verwalten.<br />
In der Gesamtkonzeption des Typmanagers spielt die Klassenbibliothek e<strong>in</strong>e zentrale<br />
Rolle. So setzen samtliche E<strong>in</strong>zelkomponenten des Typmanagerkerns auf ihrer<br />
Funktionalitat auf (sieheAbbildung 5.4). Weiterh<strong>in</strong> bildet sie durchihrePersistenzeigenschaft<br />
auch die Grundlage fur die Realisierung e<strong>in</strong>es Typbeschreibungs{<br />
und e<strong>in</strong>es Beziehungsrepositories.<br />
7 Diese nutzt selbst wiederum e<strong>in</strong>eandere generische objektorientierte Klassenbibliothek,<br />
die auf e<strong>in</strong>em musterbasierten (engl. pattern{based) Ansatz [GHJV94] beruht.
5.1 Diensttypmanagement <strong>in</strong> TRADE 157<br />
Typ-<br />
Manager<br />
TRADEr<br />
Generisches Repository<br />
Typbeschreibungsrepository Beziehungsrepository<br />
Beziehungstypbeschreibung<br />
Typbeschreibung<br />
Graphenrepository<br />
Homogene b<strong>in</strong>äre Beziehungen<br />
Beziehungs<strong>in</strong>stanz<br />
Graphischer<br />
Browser<br />
Föderation Anfragen Adm<strong>in</strong>istration<br />
Brows<strong>in</strong>g<br />
Abbildungskomponenten<br />
DCE CORBA<br />
5.1.4.1 Typmanagerkern<br />
Typmanagerkern<br />
Klassenbibliothek (Typrepräsentation)<br />
Abbildung 5.4: Komponenten des Typmanagers<br />
Der Typmanagerkern stellt die au eren Schnittstellen zur Verfugung, die von<br />
se<strong>in</strong>en potentiellen Klienten | beispielsweise anderen Typmanagern, dem TRA-<br />
DEr oder der <strong>in</strong> den Abbildungen 5.2 und 5.3 gezeigten graphischen Benutzerschnittstelle<br />
| genutzt werden konnen. Hierzu bietet er unter anderem Funktionen<br />
zum E<strong>in</strong>fugen, Loschen, Vergleichen und Browsen von Typbeschreibungen<br />
und Beziehungs<strong>in</strong>stanzen an. Der Typmanagerkern realisiert hierbei auch die<br />
Durchfuhrung von Vergleichsmechanismen, die im Zusammenhang mitder Verwaltung<br />
von Konformitatsbeziehungen bzw. Diensttyphierarchien benotigt werden.<br />
5.1.4.2 Repositories<br />
Die Verwaltung der Typbeschreibungen und Beziehungs<strong>in</strong>stanzen geschieht mit<br />
Hilfe der <strong>in</strong> der Abbildung gezeigten Typbeschreibungs{ und Beziehungsrepositories<br />
und e<strong>in</strong>es sogenannten Graphenrepositories.<br />
Die Realisierung der beiden erstgenannten Repositories, deren grundlegende<br />
Konzeption <strong>in</strong> Abschnitt 3.2.2.3 beschrieben wurde, ist auf Basis der persistenten<br />
Klassenbibliothek durchgefuhrt worden. Sie s<strong>in</strong>d zur Zeit fester Bestandteil<br />
des Typmanagers, wobei ihre Funktionalitat jedoch uber die Schnittstelle des<br />
<strong>in</strong> der Abbildung gezeigten Generischen Repositories e<strong>in</strong>deutig abgrenzbar ist.<br />
Dadurch konnen auch alternative Repositories uber diese Schnittstelle verwendet<br />
werden, wie beispielsweise das <strong>in</strong> Abschnitt 3.2.1.1 vorgestellte CORBA{
158 Systemunterstutzung fur den Dienstzugang<br />
Schnittstellenrepository.<br />
Aufsetzend auf der Schnittstelle des Generischen Repositories realisiert das sogenannte<br />
Graphenrepository e<strong>in</strong>e spezielle Verwaltung von homogenen b<strong>in</strong>aren<br />
Beziehungen, <strong>in</strong>sbesondere von Konformitatsbeziehungen. Die Verwaltung geschieht<br />
<strong>in</strong>Form von gerichteten Graphen, die e<strong>in</strong>e e ziente Realisierung von<br />
E<strong>in</strong>fuge{, Vergleichs und Anderungsfunktionen ermoglichen. Diese E zienz kann<br />
<strong>in</strong> der Regel durch das unterliegende Typbeschreibungs{ bzw. Beziehungsrepository<br />
aufgrund se<strong>in</strong>es unstrukturierten Charakters <strong>in</strong>dieserForm nicht gewahrleistet<br />
werden.<br />
5.1.4.3 Abbildungskomponenten<br />
E<strong>in</strong>e weitere Aufgabe des Typmanagerkerns ist die Anb<strong>in</strong>dung von Abbildungskomponenten,<br />
diee<strong>in</strong>edynamische Integration neuer Dienstbeschreibungssprachen<br />
<strong>in</strong> den Typmanager erlauben. Sie realisieren jeweils e<strong>in</strong>e wechselseitige Abbildung<br />
von e<strong>in</strong>er textuellen Diensttypbeschreibung <strong>in</strong> die kanonische Diensttypreprasentation,<br />
die Bestandteil der Typmanager{<strong>in</strong>ternen Typreprasentation<br />
ist. Hierdurch ist e<strong>in</strong>e dynamische Erweiterbarkeit des Typmanagers gegeben, so<br />
da zukunftig auch diejenigen Anfragen externer Klienten beantwortet werden<br />
konnen, die e<strong>in</strong>e Ruckgabe e<strong>in</strong>er Diensttypbeschreibung<strong>in</strong>e<strong>in</strong>er bestimmten, zur<br />
Zeit noch nichtunterstutzten Beschreibungssprache erfordern. Diese Eigenschaft<br />
ist vor allem wichtig fur die plattformubergreifende <strong>Dienstnutzung</strong> anderer als<br />
der zur Zeit <strong>in</strong> TRADE unterstutzten <strong>verteilten</strong> Systemplattformen DCE und<br />
CORBA.<br />
5.1.4.4 Graphische Benutzerschnittstelle<br />
E<strong>in</strong>e wichtige Rolle beim Zugri auf den Typmanager kommt der <strong>in</strong> den vorherigen<br />
Abschnitten gezeigten graphischen Benutzerschnittstelle zu, welche dem<br />
Anwendungsentwickler und Endbenutzer e<strong>in</strong>en <strong>in</strong>teraktiven Zugangzuse<strong>in</strong>en angebotenen<br />
Funktionen ermoglicht. Neben den oben erlauterten adm<strong>in</strong>istrativen<br />
Tatigkeiten des E<strong>in</strong>fugens, Loschens und Modi zierens von Typbeschreibungen<br />
besteht ihre Hauptaufgabe vor allem <strong>in</strong> der Unterstutzung des Benutzers beim<br />
Au nden von fur ihn geeigneten Diensttypen. So bilden die im Typmanager<br />
verwalteten Diensttypbeschreibungen e<strong>in</strong>e geeignete Basis, um sie beispielsweise<br />
bei der Entwicklung von Kooperationsanwendungen zu verwenden oder als Ausgangsbasis<br />
fur die anschlie ende Suche nach geeigneten Dienstangeboten zu nutzen.<br />
Hierfur bietet die graphische Benutzerschnittstelle umfangreicheMoglichkeiten,<br />
unter anderem zum Browsen <strong>in</strong> Diensttyphierachien (siehe Abbildung 5.3)<br />
oder zum Ansehen von Diensttypbeschreibungen. Um diesen Proze der Wiederverwendung<br />
von Diensttypbeschreibungen [CMML96] <strong>in</strong> o enen <strong>verteilten</strong><br />
Dienstemarkten optimal zu unterstutzen, wurde ihre Realisierung auf Grundlage<br />
der Java{Programmiersprache <strong>in</strong>Form von Java{Applets [Fla96] durchgefuhrt<br />
(siehe [CM96, CMML96]). Diese stellen e<strong>in</strong>e Moglichkeit zur Entwicklung graphischer<br />
Endanwendungen dar, die zur Zeit im Rahmen des World{Wide{Web
5.1 Diensttypmanagement <strong>in</strong> TRADE 159<br />
zunehmende Verwendung ndet. Die Nutzung der im Netz verschickbaren Java{<br />
Applets geschieht hierbei mittels Web/Java{Browsern, beispielsweise Netscape<br />
Navigator, die fur jede Plattform zur Verfugung stehen und e<strong>in</strong>en transparenten<br />
Zugri auf die Dienste des CORBA{ bzw. DCE{basierten Typmanagers uber<br />
die gezeigte graphische Schnittstelle ermoglichen.<br />
5.1.5 Bewertung und erganzende Anmerkungen<br />
Der <strong>in</strong> TRADE entwickelteTypmanager stellt exible Mechanismen fur die Verwaltungvon<br />
Diensttyp{ und Beziehungstypbeschreibungen zur Verfugung. Insbesondere<br />
erlaubt er im Rahmen von Konformitatsbeziehungen die Durchfuhrung<br />
automatischer Typvergleiche. Hierdurch wird e<strong>in</strong>e der wesentlichen Grundvoraussetzungen<br />
erfullt, um die von vielen Anwendungen | vor allem auch von<br />
den <strong>in</strong> TRADE speziell betrachteten Kooperationsanwendungen | geforderte<br />
selbstandige und automatische Dienstvermittlung zuunterstutzen, so da derartige<br />
Anwendungen hochgradig autonom und unabhangig von externen Benutzere<strong>in</strong>gri<br />
en ablaufen konnen.<br />
Mit Hilfe der automatischen Typvergleiche kann auchdas E<strong>in</strong>fugen neuer Diensttypbeschreibungen<br />
<strong>in</strong> vorhandene Konformitatbeziehungen automatisch erfolgen,<br />
wodurch sichvor allem die Adm<strong>in</strong>istration der zukunftig <strong>in</strong> o enen <strong>verteilten</strong><br />
Dienstemarkten zu erwartenden Vielfalt neuer Diensttypen ma geblich erleichtert.<br />
Unterstutzt wird dieses au erdem durch die entwickelte graphische Benutzerschnittstelle,<br />
die nicht nur das E<strong>in</strong>fugen, Loschen und Modi zieren von<br />
neuen Diensttypbeschreibungen sowie das Browsen vorhandener Typbeschreibungen<br />
ermoglicht, sondern auch die exible De nition neuer Beziehungstypbeschreibungen<br />
ermoglicht. Sie unterstutzt <strong>in</strong>sbesondere die De nition von Konformitatsbeziehungstypen,<br />
die <strong>in</strong> o enen <strong>verteilten</strong> Dienstemarkten wahrsche<strong>in</strong>lich<br />
am hau gsten anzutre en se<strong>in</strong> werden. Diese konnen auf e<strong>in</strong>fache Art und Weise<br />
mittels der De nitionsregelmustern aus bestehenden Beziehungstypbeschreibungen<br />
zusammengesetzt werden. Bisherige Erfahrungen im Umgang mitder graphischen<br />
Benutzerschnittstellen zeigen auch, da vor allem die Moglichkeit zum<br />
Browsen von Diensttypbeschreibungen recht hilfreich zumAu nden gesuchter<br />
Diensttypen ist. Dieses kann <strong>in</strong>sbesondere fur die Entwicklung von Kooperationsanwendungen<br />
genutzt werden, bei denen sich die dort de nierten Anwendungsvorgange<br />
aus e<strong>in</strong>er Vielzahl genutzter Dienste zusammensetzten.<br />
Weiterh<strong>in</strong> bietet der Typmanager die fur die Abwicklung von Trader{<br />
Kooperationen notwendigen Unterstutzungsfunktionen, <strong>in</strong>dem er e<strong>in</strong>e kanonische<br />
Typreprasentation zur Verfugung stellt. Diese wird fur den Austausch<br />
von Diensttyp{ und Beziehungstypbeschreibungen im Rahmen des<br />
Projektes Interwork<strong>in</strong>g of Traders zur Realisierung der verschiedenen Trader{<br />
Koooperationsprotokolle genutzt (siehe hierzu Abschnitt 5.2.4). In diesem<br />
Zusammenhangistfur e<strong>in</strong>e allgeme<strong>in</strong>e Anwendbarkeit zu untersuchen, ob der <strong>in</strong><br />
TRADE zunachst fur DCE und CORBA speziell angepa te und ausreichende<br />
Ansatz ausdrucksmachtig genug ist, um auch andere, eventuell heute noch<br />
nicht entwickelte Dienstbeschreibungssprachen reprasentieren zu konnen. E<strong>in</strong>en
160 Systemunterstutzung fur den Dienstzugang<br />
moglichen Ansatz hierfur bieten die zur Zeit statt ndenden <strong>in</strong>ternationalen<br />
Standardisierungsarbeiten zur De nition e<strong>in</strong>es ODP{Type{Repositories<br />
[ISO94, ISO95].<br />
5.2 Dienstvermittlung und {verwaltung durch den<br />
TRADEr<br />
Der im vorherigen Abschnitt vorgestellte TRADE{Typmanager ermoglicht die<br />
strukturierteVerwaltung von Diensttyp{ und Beziehungstypbeschreibungen und<br />
Beziehungs<strong>in</strong>stanzen. Er stellt hierdurch die Grundlage zur Verfugung, auf der e<strong>in</strong>e<br />
Vermittlung und {verwaltungvon konkreten Dienstangeboten aufsetzen kann.<br />
Die Realisierung dieserfur den Dienstzugang grundlegenden Dienstangebotsvermittlung<br />
erfolgt <strong>in</strong> TRADE durch den TRADEr [MJM94, MML94b, MML95f,<br />
GGL + 95, LMM95, MMaTT96]. Se<strong>in</strong>e generelle Konzeption orientiert sich an<br />
der im Rahmen <strong>in</strong>ternationaler Standardisierung durchgefuhrten De nition e<strong>in</strong>er<br />
ODP{Trad<strong>in</strong>g{Funktion [ODP95a], <strong>in</strong> der die elementare Funktionalitat e<strong>in</strong>es<br />
Traders und se<strong>in</strong>eexternen Schnittstellen festgelegt wird (siehe auch Abschnitt<br />
3.3.2). Der TRADEr verstehtsich <strong>in</strong> diesem Zusammenhang als Konkretisierung<br />
der dort nur abstrakt beschriebenen Dienstvermittlungsfunktionalitat<br />
und bietet e<strong>in</strong>e adaquate Umsetzung <strong>in</strong>nerhalb e<strong>in</strong>er realen Systemumgebung<br />
an. Ma geblich bee<strong>in</strong> u t wurde se<strong>in</strong> Entwurf und se<strong>in</strong>e Realisierung au erdem<br />
durch die im Rahmen des <strong>in</strong>ternationalen Projektes Interwork<strong>in</strong>g of Traders<br />
[Vog94, VBB95, MMaTT96] durchgefuhrten Arbeiten. In diesem Projekt<br />
standen primar Fragen der Kooperation von Tradern heterogener Verwaltungsdomanen<br />
im Vordergrund der Betrachtung. Auf e<strong>in</strong>en Teil der dort erzielten<br />
Forschungsergebnisse wurde bereits <strong>in</strong>Abschnitt 3.3.3.3 bei der Darstellung verschiedener<br />
Trader{Kooperationsprotokolle e<strong>in</strong>gegangen. Die Beschreibung der<br />
konkreten Realisierung derartiger Trader{Kooperationen bildet e<strong>in</strong>en der Hauptschwerpunkte<br />
des vorliegenden Abschnitts. Zuvor wird der TRADEr jedoch <strong>in</strong><br />
se<strong>in</strong>em generellen Aufbau beschrieben und die zugrundeliegenden Entwurfsentscheidungen<br />
diskutiert.<br />
5.2.1 Komponenten des TRADErs<br />
In diesem Abschnittwerden anhanddes <strong>in</strong>nerhalbder TRADE{Systemumgebung<br />
prototypisch realisierten TRADErs die wesentlichen Komponenten e<strong>in</strong>es Traders<br />
vorgestellt, die fur die Realisierung e<strong>in</strong>er adaquaten Dienstangebotsvermittlung<br />
<strong>in</strong> o enen <strong>verteilten</strong> Dienstemarkten notwendig s<strong>in</strong>d. Hauptaugenmerk beider<br />
Konzeption und Realisierung des TRADErs ist <strong>in</strong>sbesondere das Erreichen e<strong>in</strong>es<br />
hochgradig modularen Aufbaus, der e<strong>in</strong>e dedizierte und somit optimale Unterstutzung<br />
der e<strong>in</strong>zelnen Aufgaben bei der Dienstverwaltung und {vermittlung<br />
erlaubt. Hierdurch bietet sich <strong>in</strong>sbesondere die Moglichkeit zur Verwendung bereits<br />
vorhandener elementarer Systemdienste, wie sie derzeit von gangigen <strong>verteilten</strong><br />
Systemplattformen angeboten werden. Diese Art von Wiederverwendung<br />
wird beispielsweise bei der Dienstangebotsverwaltungdes TRADErs deutlich, bei
5.2 Dienstvermittlung und {verwaltung durch den TRADEr 161<br />
deren Entwurf und Realisierung externe Namensdienste verwendet werden. Die<br />
folgende Abbildung 5.5 zeigt den groben architekturellen Aufbau des TRADErs.<br />
TRADEr<br />
Typprüfung<br />
und<br />
-suche<br />
Schnittstelle<br />
Typmanager<br />
Zugriffskontrolle<br />
Importeur Exporteur<br />
Dienstvermittlungsschnittstelle<br />
Dienstangebotsauswertung<br />
Dienstangebotsverwaltung<br />
Schnittstelle Schnittstelle<br />
Schnittstelle<br />
Sicherheitsdienst<br />
Attributmanager<br />
Namensdienst<br />
Abbildung 5.5: Komponenten des TRADErs<br />
Trader-<br />
Kooperationskontrolle<br />
Schnittstelle<br />
Andere<br />
Trader<br />
Der TRADEr unterscheidet <strong>in</strong>sgesamtfunf verschiedene E<strong>in</strong>zelkomponenten, die<br />
jeweils spezi scheTeilaufgaben bei der Dienstverwaltungund {vermittlung ubernehmen<br />
und zwischen denen e<strong>in</strong> enges Zusammenspiel statt ndet. Diese Komponenten<br />
s<strong>in</strong>d <strong>in</strong>terner Bestandteil des TRADErs, der <strong>in</strong> der Abbildung durch<br />
e<strong>in</strong>e Grauschattierung hervorgehoben ist. Samtliche E<strong>in</strong>zelkomponenten setzen<br />
ihrerseits auf anderen Systemkomponenten auf, die extern zur Verfugung stehen.<br />
Hierdurch wird e<strong>in</strong> hoher Grad an Modularitat und auch Vere<strong>in</strong>fachung im<br />
TRADEr{Aufbau erreicht. So nutzt beispielsweise die Dienstangebotsverwaltung<br />
die Funktionen e<strong>in</strong>es Namensdienstes. Systemtechnisch erfolgt die Anb<strong>in</strong>dung<br />
durch generische Adapter, die aus Sicht des TRADErs e<strong>in</strong>e abstrakte Zugri sschichtauf<br />
die extern genutzten Dienste bereitstellen. Hierdurch wird die vorhandene<br />
Heterogenitat anzub<strong>in</strong>dender Dienste im TRADEr verborgen und e<strong>in</strong> hoher<br />
Grad an Flexibilitat beim Austausch e<strong>in</strong>zelner Unterstutzungsdienste erreicht.<br />
Im Fall der genannten Dienstangebotsverwaltung wird hierfur e<strong>in</strong>e standardisierte<br />
Programmierschnittstelle zum Zugri auf verschiedene DCE{Namensdienste<br />
verwendet (siehe Abschnitt 5.2.2.1).<br />
5.2.2 Dienstangebotsverwaltung und {vermittlung<br />
Zum Zugri auf die Dienstvermittlungs{ und Dienstverwaltungsfunktionen des<br />
TRADErs steht den Klienten e<strong>in</strong>e operationale Schnittstelle zur Verfugung,<br />
die im wesentlichen aus den Operationen exportOffer, importOffer und<br />
withdrawOffer besteht. 8 Diese konnen entsprechend zum Exportieren, Importieren<br />
und Loschen von Dienstangeboten genutzt werden. Samtliche Zugrie<br />
8 Die detaillierte Beschreibung dieser Operationen und ihrer Argumente ndet sich unter<br />
anderem <strong>in</strong> Abschnitt 3.3.2.3 und <strong>in</strong> Anhang D.
162 Systemunterstutzung fur den Dienstzugang<br />
der Klienten werden hierbei mit Hilfe der Zugri skontrolle auf ihre Berechtigung<br />
h<strong>in</strong> uberpruft [Mul95]. Hierzu nutzt der TRADEr den <strong>in</strong> der DCE{<br />
Implementationsumgebung bereits vorhandenen, auf dem Kerberos{System basierenden<br />
Security Service [OSF93a]. Hierdurch lassen sich <strong>in</strong>sbesondere die Aufgaben<br />
der Benutzerverwaltungund{autorisierungaus dem TRADEr ausgliedern,<br />
wodurch sichse<strong>in</strong>Entwurf und se<strong>in</strong>e Realisierung ma geblich vere<strong>in</strong>fachen.<br />
Um den Anforderungen nach e<strong>in</strong>er exiblen und e zienten Dienstangebotsvermittlung<br />
nachzukommen, realisiert der TRADEr e<strong>in</strong> dreigeteiltes Konzept zur<br />
Ablage und zum Zugri auf Dienstangebote:<br />
1. Ablage statischer Dienstangebots<strong>in</strong>formationen unter Nutzung attributbasierter<br />
Namensdienste<br />
2. Verwaltung dynamischer Dienstangebots<strong>in</strong>formationen <strong>in</strong> e<strong>in</strong>em Attributmanagementsystem<br />
3. Zugri auf Dienstangebote anderer Trader im Rahmen von direkten<br />
Trader{Kooperationen<br />
Die beiden erstgenannten Punkte betre en ausschlie lich diejenigen Mechanismen<br />
des TRADErs, die unmittelbar unter se<strong>in</strong>er eigenen Kontrolle stehen.<br />
Der dritte Punkt erweitert diese lokale Dienstvermittlungssicht, <strong>in</strong> dem er die<br />
E<strong>in</strong>beziehung externer und ebenfalls autonomer Trader erlaubt. Durch diese<br />
domanenubergreifende Zusammenarbeit ergibt sich e<strong>in</strong>eSteigerung der Dienstvermittlungsfahigkeiten<br />
des TRADErs. Hierbei s<strong>in</strong>d jedochse<strong>in</strong>e direkten E<strong>in</strong>u<br />
moglichkeiten auf die Vermittlungsprozesse der anderen Trader begrenzt. Abschnitt<br />
5.2.3 geht auf diese Aspekte von Trader{Kooperationen und des sogenannten<br />
L<strong>in</strong>k{Managements noch genauer e<strong>in</strong>.<br />
5.2.2.1 Verwendung attributbasierter Namensdienste<br />
Grundlage fur die Verwaltung statischer Dienstangebots<strong>in</strong>formationen bilden attributbasierte<br />
Namensdienste, wie sie <strong>in</strong> der DCE{Implementierungsumgebung<br />
durch das Cell Directory Service (CDS) und den X.500{konformen Global Directory<br />
Service (GDS) zur Verfugung stehen [OSF93a]. Beide ermoglichen e<strong>in</strong>e<br />
hierarchische Ablage von Namense<strong>in</strong>tragen, wobei diese E<strong>in</strong>trage zusatzlich mit<br />
weiteren Attribute<strong>in</strong>tragen versehen werden konnen.<br />
Grundlegende Strukturierungse<strong>in</strong>heit des Namensraums s<strong>in</strong>d sogenannte<br />
Namenskontexte, <strong>in</strong> die E<strong>in</strong>trage unter Angabe e<strong>in</strong>es e<strong>in</strong>deutigen Namens,<br />
beispielsweise unter dem GDS{Namen /.../c=DE/o=Universitat<br />
Hamburg/ou=Informatik/cn=Druckdienst,abgelegt werden konnen. In diesem<br />
Fall stellt Informatik e<strong>in</strong> Unterkontext von Universitat Hamburg dar, welcher<br />
selbst wiederum Unterkontext von DE ist. Diese Fahigkeit zur hierarchischen<br />
Strukturierung la t sich <strong>in</strong> geeigneter Weise fur die Verwaltung von Dienstangeboten<br />
nach unterschiedlichsten Organisationskriterien e<strong>in</strong>setzen. Hierdurch<br />
vere<strong>in</strong>facht sichvor allem die Dienstauswahl, da sichder beabsichtigte Dienstangebotssuchraum<br />
zum<strong>in</strong>dest lokal e<strong>in</strong>schranken la t. Des weiteren bilden
5.2 Dienstvermittlung und {verwaltung durch den TRADEr 163<br />
Kontexteauch e<strong>in</strong>emogliche Grundlage zur De nition von Zugri sbeschrankungen,<br />
die beispielsweise bestimmten Importeuren bzw. Exporteuren den Zugri<br />
auf geschutzte Namenskontexte verwahren.<br />
Zu jedem Namense<strong>in</strong>trag im CDS und GDS konnen zusatzliche Namensattribute<br />
abgelegt werden, die den E<strong>in</strong>trag naher charakterisieren. Der TRADEr nutzt diese<br />
Namensattribute, um diezue<strong>in</strong>em Dienstangebot gehorenden Informationen<br />
abzulegen [Gre95, MML95f, MML94b]. Die Informationen umfassen unter anderem<br />
den angebotenen Diensttypbezeichner, die aktuelle Belegung der statischen<br />
Dienstattribute und die Schnittstellenreferenzen (engl. <strong>in</strong>terface references), die<br />
zume<strong>in</strong>deutigen Zugri auf die Dienstzugangs{ und Dienstangebotsauswertungsschnittstelle<br />
des Diensterbr<strong>in</strong>gers erforderlich ist. Der TRADEr erhalt die Dienstangebots<strong>in</strong>formationen<br />
von den Exporteuren uber die exportOffer{Operation,<br />
die er an se<strong>in</strong>er Schnittstelle fur die Registration von Dienstangeboten anbietet<br />
(siehe auch Anhang D).<br />
Um von den spezi schen Eigenschaften e<strong>in</strong>es konkreten Namensdienstes abstrahieren<br />
zu konnen, wurde beim Entwurf des TRADErs zunachst e<strong>in</strong>e generische<br />
Schnittstelle fur die Dienstangebotsverwaltung de niert [Gre95]. Ihre Realisierung<br />
erfolgtehierbeiweitgehendauf Basis der standardisierten XDS{ und XOM{<br />
Programmierschnittstellen 9 [OSF93a] (Abbildung 5.6). Beide Schnittstellen abstrahieren<br />
bei der Programmierungvon den unterliegend genutzten Namensdiensten<br />
und ermoglichen so e<strong>in</strong>e von der vorhandenen Heterogenitat unabhangige<br />
und e<strong>in</strong>heitliche Anwendungsprogrammierung.<br />
DCE-RPC-<br />
Klient<br />
rpc_ns_b<strong>in</strong>d<strong>in</strong>g_import(<br />
"/.:/pr<strong>in</strong>ter")<br />
Gruppen-<br />
E<strong>in</strong>trag<br />
RPC-<br />
E<strong>in</strong>trag<br />
NSI<br />
/.:/service_offers<br />
CDS<br />
/.:/pr<strong>in</strong>ter_if_0<br />
importOffer()<br />
RPC-Schnittstellenreferenz<br />
DCE-<br />
Importeur<br />
TRADEr<br />
/.:/pr<strong>in</strong>ter<br />
/.:/pr<strong>in</strong>ter_svc_[UUID]<br />
Diensttyp<br />
Dienstattributwerte<br />
•••<br />
/.:/pr<strong>in</strong>ter_if_1<br />
RPC-Schnittstellenreferenz<br />
•••<br />
DCE-<br />
Exporteur<br />
exportOffer<br />
( ..., DCE-Schnittstellenreferenz,<br />
Diensttyp,<br />
"/.:/pr<strong>in</strong>ter",<br />
Dienstattributwerte, ...)<br />
XDS/XOM<br />
GDS (X .500)<br />
Abbildung 5.6: XDS/XOM{basierter Zugri auf Namensdienste im TRADEr<br />
9 X/Open Directory Service und X/Open OSI{Abstract{Data Manipulation
164 Systemunterstutzung fur den Dienstzugang<br />
E<strong>in</strong>e Besonderheit der <strong>in</strong> der Abbildung dargestellten TRADEr{Realisierung<br />
ist die Moglichkeit, da vorhandene DCE{Dienstnehmer auch direkt uber die<br />
DCE{RPC{spezi sche NSI{Schnittstelle [OSF93a] auf vom TRADEr im CDS{<br />
Namensraumabgelegte Dienstangebote zugreifen konnen (sieheauch [MML95f]).<br />
Hierdurch ergibt sich der Vorteil, da neue Versionen vorhandener Diensterbr<strong>in</strong>ger<br />
die exibleren Moglichkeiten der Dienstvermittlung des TRADErs nutzen<br />
konnen, ohne da die bisherigen Dienstnehmer, die weiterh<strong>in</strong> auf Nutzung des<br />
CDS beruhen, geandert werden mussen. Aus diesem Grund werden <strong>in</strong> den CDS{<br />
Namensraum exportierten Dienstangebote mittels der NSI{Schnittstelle abgelegt<br />
und anschlie end uber die XDS{ und XOM{Schnittstellen um die dazugehorigen<br />
Dienstattribute erganzt.<br />
Insgesamt bietet die Dienstangebotsverwaltung Funktionen zum E<strong>in</strong>fugen, Lesen,<br />
Loschen, Andern und Loschen von Dienstangeboten [Gre95]. Ebenso werden<br />
attributbasierteSuchanfragen unterstutzt, die vom TRADEr bei der gesta elten<br />
Dienstauswahl (siehe Abschnitt 3.3.2.3) alternativ zu den vom Attributmanagementsystem<br />
angebotenen Suchanfragen verwendet werden konnen. Hierbei kann<br />
ausgenutzt werden, da die Werte der statischen Dienstattribute bereitsfruhzeitig<br />
wahrend des Dienstauswahlprozesses, d.h. bei der Suche von diensttypkonformen<br />
Dienstangeboten im Namensraum, zur Verfugung stehen.<br />
5.2.2.2 Das Attributmanagementsystem<br />
Die fur die Dienstangebotsverwaltung im TRADEr e<strong>in</strong>gesetzten Namensdienste<br />
s<strong>in</strong>d <strong>in</strong>der Regel nur fur die Ablage statischer, sich kaum verandernder E<strong>in</strong>trage<br />
geeignet. Um nun jedoch auch dynamische Dienstangebots<strong>in</strong>formationen verwalten<br />
zu konnen, ist <strong>in</strong> der TRADE{Systemumgebung e<strong>in</strong> eigenstandiges Attributmanagementsystem<br />
realisiert [Spr96]. Dieses arbeitet eng mit dem TRADEr<br />
zusammen und unterstutzt se<strong>in</strong>e Dienstauswahl, bei der nun auch dieWerte der<br />
dynamischen Dienstattribute und der operationale Zustand der Dienstanbieter<br />
im Rahmen der gesta elten Dienstauswahl berucksichtigt werden konnen.<br />
Abbildung 5.7 stellt das Zusammenspiel zwischen dem TRADEr und dem Attributmanagementsystem<br />
genauer dar. Sie zeigt gleichzeitig auch e<strong>in</strong>e Konkretisierung<br />
der beim ODP{Trad<strong>in</strong>g <strong>in</strong>Abschnitt 3.3.2.2 gezeigten Abbildung 3.21,<br />
<strong>in</strong> der unter anderem die Dienstangebotsauswertungsschnittstelle (engl. service<br />
o er evaluation <strong>in</strong>terface | SOEI) e<strong>in</strong>gefuhrt wurde. Diese wird vom TRADEr<br />
zum e<strong>in</strong>heitlichen Zugri auf die Werte der Dienstattribute verwendet, wobei im<br />
Gegensatz zur Darstellung <strong>in</strong>Abbildung 3.21 die Realisierung nicht von Seiten<br />
der Dienstanbieter, sondern zentral durch den Attributmanager des Attributmanagementsystems<br />
erfolgt. Die Attributverwaltung ist <strong>in</strong>tegraler Bestandteil e<strong>in</strong>es<br />
jeden Exporteurs und b<strong>in</strong>det ihn an das Attributmanagementsystem an. Uber<br />
ihre <strong>in</strong>terne Zugri sschnittstelle bietet sie den Exporteuren die folgende Funktionalitat:<br />
Verwaltung der Werte statischer und dynamischer Dienstattribute:<br />
Die Werte der Dienstattribute konnen vom Dienstanbieter jederzeit nach
5.2 Dienstvermittlung und {verwaltung durch den TRADEr 165<br />
TRADEr<br />
Dienstangebotsauswahl<br />
Attributanfragen,<br />
Zustandsüberprüfung<br />
Dienstangebotsauswertungsschnittstelle<br />
(SOEI)<br />
Attributmanager<br />
Ereignismeldungen<br />
Export<br />
Attributanfragen<br />
Registration, Zustandsmeldungen<br />
DCE- Exporteur<br />
Attributverwaltung<br />
Schnittstelle<br />
Zustandsabfragen<br />
Registration,<br />
Zustandsmeldungen<br />
Attributagent<br />
Abbildung 5.7: Komponenten und Informations usse des Attributmanagementsystems<br />
Bedarf geandert werden, wobei die Anderungen automatischandas Managementsystem<br />
weitergereicht werden. Der konkrete Ablauf im Attributmanagementsystem,<br />
d.h. die Interaktion mit dem Attributmanager und dem<br />
Attributagenten, bleibt vor dem Exporteur verborgen.<br />
Verwaltung von Aktualitatspradikaten:<br />
Zu jedem von der Attributverwaltung verwalteten Dienstattribut ist die<br />
Angabe von Aktualitatspradikaten moglich. Mit ihnen lassen sich Aussagen<br />
uber das Aktualisierungsverhalten bei Attributanderungen tre en. So<br />
werden derzeit unter anderem das Verzogerungs{, das Anderungs{ und das<br />
" Beste{Moglichkeit\{Pradikat unterstutzt [Spr96]. Beispielsweise kann mit<br />
dem Anderungspradikat bestimmtwerden, nach wievielen Wertanderungen<br />
e<strong>in</strong>e Mitteilung anden Attributmanager erfolgen soll. Es eignet sich <strong>in</strong>sbesondere<br />
zur Verwaltung sichpermanent andernder Dienstattribute, beispielsweise<br />
der Lange e<strong>in</strong>er Druckwarteschlange, bei denen die Propagierung<br />
jeder e<strong>in</strong>zelnen Anderung mit e<strong>in</strong>em erheblichen Aufwand verbunden<br />
ware. Fur die Dienstauswahl im TRADEr ist zudem e<strong>in</strong>e hochstmogliche<br />
Aktualitat von dynamischen Attributwerten oftmals auch nicht erforderlich.<br />
Verwaltung des operativen Zustandes:<br />
Neben den Werten der Dienstattribute konnen die Dienstanbieter dem Attributmanagementsystem<br />
mitteilen, ob sie derzeit verfugbar oder, beispielsweise<br />
fur kurzfristige Wartungsarbeiten, <strong>in</strong>aktiv s<strong>in</strong>d. Sofern es vom Importeur<br />
bei der Dienstanfrage mittels der Angabe von Suchvorschriften gefordert<br />
wird (siehe Abschnitt 5.2.2.3), kann diese Information anschlie end<br />
bei der Dienstauwahl des TRADErs entsprechend berucksichtigt werden.<br />
Der Attributagent dient zur Unterstutzung des Attributmanagers bei der Verwaltung<br />
der operativen Zustande der Dienstanbieter. Hierzu uberwacht er die
166 Systemunterstutzung fur den Dienstzugang<br />
Dienstanbieter auf Fehlerfalle, <strong>in</strong> dem er periodisch ihre Verfugbarkeit uberpruft.<br />
Sollte e<strong>in</strong> Dienstanbieter ausgefallen se<strong>in</strong>, so wird dieses dem Attributmanager<br />
mitgeteilt, der e<strong>in</strong>en entsprechenden Vermerk vornimmt.<br />
E<strong>in</strong>e weitere Kernkomponente des Attributmanagementsystems ist der Attributmanager.<br />
Er realisiert die Dienstangebotsauswertungsschnittstelle (SOEI) fur<br />
alle beim TRADEr registrierten Dienstangebote. Hierzu bietet er dem TRA-<br />
DEr unter anderem die Operation ServicePropertyValueEnquiry an. Sie unterstutzt<br />
die Auswertungder vom Importeur gestellten Attributanfragen, <strong>in</strong> dem<br />
sie den Zugri auf die aktuellen Werte der statischen und dynamischen Attribute<br />
der Dienstanbieter ermoglicht. Bei diesem Vorgang wird auf die dem Dienstanbieter<br />
zugeordneteAttributverwaltung zugegri en. Zur Optimierung dieser unter<br />
Umstanden zeitaufwendigen Zugri e bietet der Attributmanager zusatzliche<strong>in</strong>en<br />
Attributzwischenspeicher (engl. attribute cache), der die Attributwerteder beim<br />
TRADEr registrierten Dienstanbieter vorhalt. Die Aktualisierung dieser Werte<br />
geschiehtentsprechendder vom Dienstanbieter spezi zierten Aktualitatspradikate,<br />
die ebenfalls im Attributzwischenspeicher gehalten werden. Weiterh<strong>in</strong> verwaltet<br />
der Attributmanager auch die aktuellen operativen Zustandeder Dienstanbieter.<br />
Diese konnen vom TRADEr im Rahmen der gesta elten Auswertung mittels<br />
der ServiceOfferEvaluate{Operation abgefragt werden.<br />
5.2.2.3 Ablauf e<strong>in</strong>er domanenbegrenzten Dienstangebotsvermittlung<br />
Im folgenden sollen anhand e<strong>in</strong>es Beispiels die E<strong>in</strong> u moglichkeiten e<strong>in</strong>es Importeurs<br />
auf den Ablauf e<strong>in</strong>er vom TRADErs durchgefuhrten Dienstvermittlung<br />
verdeutlicht werden. Hierbei wird zunachst von e<strong>in</strong>er lokal begrenzten Dienstauswahl<br />
ausgegangen, bei deren Ablauf ausschlie lich das dem TRADEr lokal<br />
zugeordnete Attributmanagementsystem bzw. die beiden DCE{Namensdienste<br />
genutzt werden. Der Abschnitt 5.2.3 beschreibt anschlie end die erweiterten<br />
Dienstvermittlungsfahigkeiten des TRADErs, die durch die Kooperation mit anderen<br />
Tradern <strong>in</strong> e<strong>in</strong>em globalen Dienstvermittlungsverbund erreicht werden.<br />
Konzeptionell orientiert sich die lokale Dienstauswahl an dem Pr<strong>in</strong>zip der <strong>in</strong><br />
Abschnitt 3.3.2.3 vorgestellten gesta elten Auswertung. E<strong>in</strong>e Bee<strong>in</strong> ussung des<br />
Auswertungsvorganges kann der Importeur mittels der E<strong>in</strong>gabeparameter der<br />
importOffer{Operation vornehmen. Die hierbei moglichen Optionen s<strong>in</strong>d<strong>in</strong>Abbildung<br />
5.8 anhand e<strong>in</strong>er graphischen Benutzerschnittstelle zum Browsen von<br />
im TRADEr verwalteten Dienstangeboten verdeutlicht. Die Abbildung zeigt<br />
die Anfrage nach Dienstangeboten zum Drucken von Dokumenten. Zunachst<br />
wird die Dienstangebotssuche auf den Suchkontext /.../c=de/o=universitaet<br />
hamburg/ou=services e<strong>in</strong>geschrankt. Der gesuchte Diensttyp ist durch den<br />
Diensttypbezeichner Pr<strong>in</strong>tService gekennzeichnet, der auf e<strong>in</strong>e DiensttypbeschreibungimTypmanager<br />
zeigt undimRahmen der gesta elten Auswertung zur<br />
Suche nach konformen Diensttypen verwendet wird. Die Diensttypbeschreibung<br />
be<strong>in</strong>haltet unter anderem die Beschreibung der Dienstattribute costperpage,<br />
location und queuelenght,wobei letzteres e<strong>in</strong> dynamisches Dienstattribut ist.<br />
Uber die Attribute konnen nun pr<strong>in</strong>zipiell beliebig verschachtelte Anfragen ge-
5.2 Dienstvermittlung und {verwaltung durch den TRADEr 167<br />
Abbildung 5.8: Optionen bei der domanenbegrenzten Dienstauswahl<br />
stellt werden. In dem gezeigten Fall werden beispielsweise Druckdienstangebote<br />
gesucht, deren Kosten pro Druckseite ger<strong>in</strong>ger als 30 Pfennige s<strong>in</strong>d(costperpage<br />
< 0.3). Hierzu sucht der TRADEr zunachst <strong>in</strong> dem angegebenen Suchkontext<br />
bzw. allen unterliegenden Suchkontexten nach geeigneten Dienstangeboten, die<br />
den spezi zierten Diensttyp bzw. e<strong>in</strong>en se<strong>in</strong>er Subtypen realisieren. Anschlieend<br />
wertet der TRADEr mit Hilfe des Attributmanagementsystems die Attributanfrage<br />
aus. Die Auswertung kann durch Vorschriften CheckAvailability<br />
und IgnoreDynamicAttributes bee<strong>in</strong> u t werden, die <strong>in</strong> der graphischen Benutzerschnittstelle<br />
durchKnopfe aktiviert werden. Mit der ersten Vorschrift wird<br />
bestimmt, ob der aktuelle operationale Zustande<strong>in</strong>es Dienstanbieters mit berucksichtigt<br />
werden soll. Mit der zweiten kann der Zugri auf die Werte dynamischer<br />
Dienstattributeverh<strong>in</strong>dert werden, um so beispielsweise die Geschw<strong>in</strong>digkeit des<br />
Dienstauswahlvorganges zu erhohen.<br />
Weiterh<strong>in</strong> wird <strong>in</strong> dem gezeigten Beispiel spezi ziert, da die Ruckgabe von<br />
geeigneten Dienstangeboten entsprechend der aktuellen Warteschlangenlangen<br />
geordnet se<strong>in</strong> soll. Dieses geschieht mit Hilfe des mit M<strong>in</strong> bezeichneten Knopfes<br />
und des Dienstattributes queuelength. Zusatzlich wirdauch gefordert, da<br />
zu jedem gefundenen Dienstangebot die Attribute queuelength und location<br />
vom TRADEr zuruckgegeben werden sollen. Das Ergebnis der Dienstauswahl ist<br />
im unteren Ausgabefenster gezeigt, wobei die drei gefundenen Dienstangebote<br />
aufsteigend nach der Warteschlangenlange geordnet s<strong>in</strong>d.<br />
5.2.3 Aufbau von Trader{Kooperationen<br />
Die oben gezeigten, auf Namensdiensten und e<strong>in</strong>em Attributmanagementsystem<br />
basierenden TRADEr{Dienstauswahlmechanismen bilden e<strong>in</strong>e geeignete Grundlage<br />
fur die Dienstvermittlung <strong>in</strong> lokal abgegrenzten Verwaltungsdomanen. Um
168 Systemunterstutzung fur den Dienstzugang<br />
nun jedochauch auf Dienstangebote anderer Verwaltungsdomanen zugreifen zu<br />
konnen, ist die Zusammenarbeit mit den dort vorhandenen Tradern erforderlich.<br />
Hierdurch la t sich der zunachst lokal beschrankte Suchraum des TRADErs um<br />
die Dienstangebote der anderen Trader erweitern. Somit wird gleichzeitig e<strong>in</strong>e<br />
der wichtigen Grundvoraussetzungen fur die domanenubergreifendeNutzungvon<br />
<strong>in</strong> o enen <strong>verteilten</strong> Dienstemarkten angebotenen Diensten gescha en.<br />
In Abschnitt 3.3.3 wurden fur den Aufbauderartiger Trader{Kooperationen (engl.<br />
trader <strong>in</strong>terwork<strong>in</strong>g) verschiedene Varianten diskutiert, die sich zunachst <strong>in</strong> <strong>in</strong>direkte<br />
und direkte Kooperationsformen unterschieden. Die Umsetzung der ersten<br />
Variante ergibt sich beim TRADEr bereits implizit durch die Wahl von globalen<br />
Namensdiensten als Grundlage fur se<strong>in</strong>e Dienstangebotsverwaltung. Insbesondere<br />
der auf dem X.500{Standard basierende Global Directory Service bietet<br />
durch se<strong>in</strong>e derzeitige weite Verbreitung e<strong>in</strong>en geeigneten Ablagedienst, um die<br />
<strong>in</strong> o enen <strong>verteilten</strong> Dienstemarkten angebotenen Dienstangebote e<strong>in</strong>em gro en<br />
Nutzerkreis zur Verfugung zustellen. E<strong>in</strong> bedeutender Nachteil fur die Anwendbarkeit<br />
dieses Ansatzes ist jedoch die E<strong>in</strong>schrankungder Automie der an o enen<br />
<strong>verteilten</strong> Dienstemarkten beteiligten Verwaltungsdomanen [MMaTT96]. Dieses<br />
begrundet sich vor allem dar<strong>in</strong>, da fur die Ablage von Dienstangeboten vorab<br />
e<strong>in</strong>e Standardisierung der Semantik von Diensttypen erforderlich ist,da ansonsten<br />
e<strong>in</strong>e Vermittlung von Dienstangeboten anderer Verwaltungsdomanen nicht<br />
s<strong>in</strong>nvoll durchfuhrbar ist. Diese Voraussetzung ist jedoch angesichts der Heterogenitat,<br />
<strong>in</strong>sbesondere <strong>in</strong> den Aspekten der Semantik von Diensten und ihrer<br />
Beschreibung (siehe Kapitel 2), <strong>in</strong> dieser strikt standardisierten Form <strong>in</strong> o enen<br />
<strong>verteilten</strong> Dienstemarkten nicht haltbar.<br />
Aus diesem Grund wurde bei der Realisierung des TRADErs die direkte Kooperation<br />
von Tradern bevorzugt. Bee<strong>in</strong> u t wurde diese Entscheidung auch durch<br />
die Forschungsarbeiten im Rahmen des Projektes Interwork<strong>in</strong>g of Traders 10<br />
[Vog94, VBB95, MMaTT96], bei dem aufgrund der weltweiten Verteilung der<br />
Projektteilnehmer auf zw<strong>in</strong>gende Weise von e<strong>in</strong>er Heterogenitat der Verwaltungsdomanen<br />
ausgegangen werden mu te. Zielstellung dieses Projektes war die<br />
Verknupfung der jeweiligen von den Projektpartnern unabhangig entwickelten<br />
Trader{Implementierungen, damit diese anschlie end <strong>in</strong> direkten Kooperationen<br />
e<strong>in</strong>en domanenubergreifenden Dienstvermittlungsverbund realisieren konnen.<br />
Begleitet wurden diese Arbeiten durch die im Rahmen der ODP{Trad<strong>in</strong>g{<br />
Standardisierungdurchgefuhrten Normungsarbeiten, wobei fur das IWT{Projekt<br />
vor allem die Festlegung der importOffer{Operation und der zur Verwaltung<br />
von L<strong>in</strong>ks (siehe Abschnitt 3.3.3.2) notwendigen L<strong>in</strong>k Management{Schnittstelle<br />
von Bedeutung waren. In diesem Zusammenhang ergab sichauch die Anforderungandas<br />
Projekt, nichtnur die Durchfuhrbarkeit von standardisierten Trader{<br />
Kooperationen aufzuzeigen, sondern gleichzeitig die erzielten Ergebnisse und Erfahrungen<br />
mit <strong>in</strong> den Standardisierungsproze e<strong>in</strong> ie en zu lassen. E<strong>in</strong>ige dieser<br />
Ergebnisse wurden bereits <strong>in</strong>Abschnitt 3.3.3.3 <strong>in</strong> Form der dort erlauterten<br />
Trader{Kooperationsprotokolle aufgezeigt. Erganzende Bemerkungen bzw. weitere<br />
Bewertungen zu diesen Kooperationsprotokollen s<strong>in</strong>dau erdem <strong>in</strong> Abschnitt<br />
10 Das Projekt wird im folgenden auch kurz als IWT{Projekt bezeichnet.
5.2 Dienstvermittlung und {verwaltung durch den TRADEr 169<br />
5.2.4 angefuhrt.<br />
Im folgenden soll die Verknupfung zweier Trader exemplarischanhanddes TRA-<br />
DErs und des am australischen Forschungszentrum DSTC entworfenen Traders<br />
[BB94] beschrieben werden. Erganzende Beschreibungen, <strong>in</strong>sbesondere von Implementationsentscheidungen,<br />
nden sich <strong>in</strong>[Mul96].<br />
5.2.3.1 IWT{Testszenario<br />
Als geme<strong>in</strong>same Interaktionsplattform fur das <strong>in</strong> Abbildung 5.9 gezeigte IWT{<br />
Testszenario dient das e<strong>in</strong>gangs dieses Kapitels und im Zusammenhang mit der<br />
TRADEr{Realsisierung erwahnte Distributed Comput<strong>in</strong>g Environment (DCE).<br />
Sowohl <strong>in</strong> Brisbane, Australien, als auch <strong>in</strong> Hamburg existieren jeweils autonome<br />
Verwaltungsdomanen, die durch sogenannte DCE{Zellen vone<strong>in</strong>ander abgegrenzt<br />
werden. Beide Zellen s<strong>in</strong>d uber das Internet mit Hilfe des auf dem Doma<strong>in</strong> Name<br />
Service basierenden Global Directory Service von DCE mite<strong>in</strong>ander verbunden,<br />
so da die <strong>in</strong> den jeweiligen Zellen angebotenen Dienste von beiden Seiten uber<br />
RPC{Mechanismen aufgerufen werden konnen.<br />
L<strong>in</strong>k-<br />
Konfigurations-<br />
DCE-Zelle (Hamburg)<br />
Taxi-Server<br />
manager<br />
Taxi-Klient<br />
L<strong>in</strong>k-Management-<br />
Schnittstelle<br />
Dienstangebotsverwaltung<br />
Typprüfung<br />
und -suche<br />
DSTC-Trader TRADEr<br />
DCE-Zelle (Brisbane)<br />
L<strong>in</strong>k-Management-<br />
Schnittstelle<br />
Traderkooperationskontrolle<br />
Svc 1<br />
Zugriffskontrolle<br />
Trad<strong>in</strong>g-Schnittstelle<br />
Dienstangebotsauswertung<br />
Typmanager<br />
Abbildung 5.9: Die Testumgebung des Projektes Interwork<strong>in</strong>g of Traders<br />
In beiden Verwaltungsdomanen existiert jeweils e<strong>in</strong> lokaler Trader, die fur den<br />
externen Zugri im Rahmen des IWT{Szenarios m<strong>in</strong>destens die importOffer{<br />
Operation und die Operationen der L<strong>in</strong>k{Management{Schnittstelle 11 anbieten<br />
mussen. Weiterh<strong>in</strong> stehen zu Testzwecken <strong>in</strong> beiden DCE{Zellen jeweils<br />
identische Dienstanbieter <strong>in</strong> Form e<strong>in</strong>es Taxibuchungsdienstes zur Verfugung<br />
11 Die vollstandige Beschreibung der L<strong>in</strong>k{Management{Schnittstelle ist <strong>in</strong> Anhang D.2 mit-<br />
tels der DCE{IDL dargestellt.
170 Systemunterstutzung fur den Dienstzugang<br />
(siehe auch Abbildung 5.11), die <strong>in</strong> jeder Verwaltungsdomane lokal im dortigen<br />
Trader verwaltet werden. Diese s<strong>in</strong>d zunachst durch die Isolation der beiden<br />
Trader nur von den lokalen Importeuren nutzbar. Um nun jedochauch<br />
die Vermittlung dieser Dienstangebote <strong>in</strong>der anderen Verwaltungsdomane zu<br />
ermoglichen, wird mit Hilfe des im TRADE/IWT{Projektrahmen entwickelten<br />
L<strong>in</strong>k{Kon gurationsmanagers (engl. L<strong>in</strong>k Con guration Manager) [MMaTT96,<br />
Mul96] e<strong>in</strong>e Kooperationsbeziehung zwischen den Tradern aufgebaut.<br />
5.2.3.2 L<strong>in</strong>k{Kon gurationsmanager<br />
Grundlage fur den L<strong>in</strong>k{Kon gurationsmanager bilden die <strong>in</strong> Abschnitt 3.3.3.2<br />
e<strong>in</strong>gefuhrten unidirektionalen L<strong>in</strong>ks, mit denen die Kooperationsbeziehung zwischen<br />
zwei Tradern ausgedruckt wird. Neben den zum Aufbau e<strong>in</strong>er Kooperationsbeziehung<br />
notwendigen B<strong>in</strong>dungs<strong>in</strong>formationen enthalten sie Informationen<br />
uber die Typisierungsmechanismen der Zieldomane, anhand derer die <strong>in</strong> der<br />
Rolle des Importeurs auftretenden Trader erkennen konnen, ob gegebenenfalls<br />
e<strong>in</strong> Typmanager <strong>in</strong> die Interaktion e<strong>in</strong>geschaltet werden mu . Dieses ist <strong>in</strong> der<br />
Regel dann notwendig, wenn aufgrund adm<strong>in</strong>istrativer und technischer Heterogenitatgrenzen<br />
Unterschiede <strong>in</strong>der Typisierung bzw. <strong>in</strong> der Beschreibung von<br />
Diensten bestehen (siehe auch Abschnitt 3.1.1). Weiterh<strong>in</strong> ermoglichen L<strong>in</strong>ks<br />
durch die Verwaltung statistischer Informationen Aussagen uber die Qualitat e<strong>in</strong>er<br />
genutzten Kooperationsbeziehung, um diese anschlie end beispielsweise als<br />
Grundlage fur e<strong>in</strong>e Auswahl der am besten geeigneten Kooperationspartner zu<br />
nutzen. Die Aktualisierung dieser Informationen geschieht jeweils nach Benutzung<br />
e<strong>in</strong>es L<strong>in</strong>ks.<br />
Grundsatzlich la t sich das mit Hilfe des L<strong>in</strong>k{Kon gurationsmanagers<br />
durchfuhrbare L<strong>in</strong>k{Management <strong>in</strong> drei Abschnitte unterteilen:<br />
1. Strategische Phase:<br />
Im Rahmen der strategischen Phase werden die L<strong>in</strong>ks zwischen den verschiedenen<br />
kooperierenden Tradern e<strong>in</strong>gerichtet. Diese E<strong>in</strong>richtung erfolgt<br />
uber e<strong>in</strong>e standardisierte Schnittstelle der Trader, die sogenannte L<strong>in</strong>k{<br />
Management{Schnittstelle, mit deren Hilfe die L<strong>in</strong>ks <strong>in</strong> den durch dieTrader<br />
verwalteten L<strong>in</strong>kraum (engl. l<strong>in</strong>k space) abgelegt werden. L<strong>in</strong>ks s<strong>in</strong>d<br />
unidirektional, wobei jedoch durch E<strong>in</strong>richtung e<strong>in</strong>es L<strong>in</strong>ks <strong>in</strong> entgegengesetzter<br />
Richtung bidirektionale Verb<strong>in</strong>dungen aufgebaut werden konnen.<br />
2. Taktische Phase:<br />
In der taktischen Phase wahlt e<strong>in</strong> Trader unter den <strong>in</strong> seiem L<strong>in</strong>kraum bekannten<br />
L<strong>in</strong>ks die fur die jeweilige Anfrage geeignetesten aus. Die Auswahl<br />
la t sich hierbei mit Hilfe von Verwaltungsvorschriften (engl. policies) bee<strong>in</strong><br />
ussen. Hiermit kann der Dienstnehmer unter anderem festlegen, ob die<br />
Anfrage sich auch uber Domanengrenzen h<strong>in</strong>weg erstrecken soll, oder ob<br />
sie synchron oder asynchron an verbundene Trader weitergereicht werden<br />
soll (siehe auch Abbildung 5.11).
5.2 Dienstvermittlung und {verwaltung durch den TRADEr 171<br />
3. Operationale Phase:<br />
In der abschlie enden operationalen Phase ruft der Trader die <strong>in</strong> den<br />
ausgewahlten L<strong>in</strong>ks referenzierten Trader uber deren importOffer{<br />
Schnittstelle auf, um die durch sie verwalteten Dienstangebote zu erfragen.<br />
Wurden von den Kooperationspartnern Resultate geliefert, so werden diese<br />
zusammen mit den lokalen Ergebnissen gebundelt an den anfragenden<br />
Importeur zuruckgeliefert. Die Herkunft der Dienstangebote ist dabei<br />
fur ihn nicht ersichtlich. Abschlie end erfolgt e<strong>in</strong>e Aktualisierung der<br />
statistischen Informationen e<strong>in</strong>es L<strong>in</strong>ks.<br />
Abbildung 5.10 zeigt e<strong>in</strong>en Teilausschnitt der graphischen Benutzerschnittstelle<br />
des L<strong>in</strong>k{Kon gurationsmanagers, uber die der Zugri auf alle Operationen<br />
der L<strong>in</strong>k{Management{Schnittstelle und die importOffer{Operation der Trader<br />
gesteuert wird.<br />
Abbildung 5.10: Der Dienstangebotsmodus des L<strong>in</strong>k{Kon gurationsmanagers<br />
Um e<strong>in</strong>en L<strong>in</strong>k zwischen zwei Tradern e<strong>in</strong>zurichten, mu zunachst das<br />
Dienstangebot des beabsichtigten Kooperationspartners <strong>in</strong> Erfahrung gebracht<br />
werden. Hierzu wird im sogenannten Dienstangebotsmodus des L<strong>in</strong>k{<br />
Kon gurationsmanagers e<strong>in</strong>e Dienstanfrage an e<strong>in</strong>en Trader gestellt, um dessen<br />
eigenes Dienstangebot zu ermitteln. Grundlage fur diese Dienstanfrage bildet<br />
der Diensttyp Trad<strong>in</strong>gService, der im IWT{Projekt hierfur projekt<strong>in</strong>tern<br />
standardisiert wurde. Die zu diesem Diensttyp gehorende Diensttypbeschreibung<br />
umfa t im wesentlichen die Beschreibung der oben bereits genannten<br />
Operationen exportOffer, importOffer und withdrawOffer sowie samtliche<br />
Operationen der L<strong>in</strong>k{Management{Schnittstelle. Dieser Diensttyp wird von<br />
jedem Trader benutzt, um se<strong>in</strong>en Trad<strong>in</strong>g{Dienst anderen Tradern im Rah-
172 Systemunterstutzung fur den Dienstzugang<br />
men des L<strong>in</strong>k{Managements zur Verfugung zu stellen. Die Abbildung zeigt<br />
das Resultat e<strong>in</strong>er derartigen Dienstanfrage, wobei auch die zum Diensttyp<br />
gehorigen Dienstattribute ausgegeben werden. So existiert beispielsweise das<br />
Attribut typemanager identifier, welches die B<strong>in</strong>dungs<strong>in</strong>formationen des<br />
dem Trader zugeordneten Typmanagers be<strong>in</strong>haltet. Andere Attribute, wie<br />
beispielsweise search method und search strategy geben Auskunft uber vom<br />
Trader angebotenen Suchmethoden und {strategien.<br />
Nachdem e<strong>in</strong> derartiges Angebot e<strong>in</strong>es Trad<strong>in</strong>g{Dienstes gefunden wurde, wird<br />
im sogenannten L<strong>in</strong>k{Modus des L<strong>in</strong>k{Kon gurationsmanagers e<strong>in</strong>e Verb<strong>in</strong>dung<br />
zur L<strong>in</strong>k{Management{Schnittstelle des lokalen Traders hergestellt. Anschlieend<br />
kann das ermittelte Dienstangebot als L<strong>in</strong>k abgelegt werden. Durch die<br />
B<strong>in</strong>dung an die L<strong>in</strong>k{Management{Schnittstelle lassen sich auch spater die<br />
gespeicherten L<strong>in</strong>ks und ihre statistischen Informationen mit Hilfe des L<strong>in</strong>k{<br />
Kon gurationsmanagers uberwachen.<br />
5.2.3.3 Verwaltung und Nutzung von L<strong>in</strong>ks im TRADEr<br />
Zur Realisierung der L<strong>in</strong>k{Management{Schnittstelle im TRADEr und auch<br />
im DSTC{Trader war zunachst e<strong>in</strong>e Modi kation der bereits vorhandenen<br />
Dienstvermittlungsschnittstellen beider Trader notwendig. Im Vergleich zur orig<strong>in</strong>aren<br />
Spezi kation der importOffer{Operation, die sich ursprunglich ander<br />
im Trader{Standarddokument [ODP95a] de nierten orientiert, verfugt die neue<br />
importOffer{Operation uber folgende Erweiterungen:<br />
Dienstanfragen werden nicht langer anonym behandelt, sondern mit e<strong>in</strong>deutigen<br />
Dienstanfragekennungen versehen. Diese werden wahrend der gesamten<br />
Lebenszeit e<strong>in</strong>er Dienstanfrage beibehalten und bleiben auch bei<br />
der Weitergabe an kooperierende Trader bestehen. Samtliche Kennungen<br />
werden durch den Trader gespeichert und ermoglichen so die Identi kation<br />
bereits beantworteter Dienstanfragen. Hiermit kann auch das zyklische<br />
Weiterreichen von Dienstanfragen vermieden werden.<br />
Anfragen konnen an Kooperationspartner weitergegeben werden. Dabei<br />
verhalt sichder <strong>in</strong>itierende Trader gegenuber se<strong>in</strong>em Kooperationspartner<br />
wie e<strong>in</strong> normaler Importeur.<br />
Spezielle Suchvorschriften (engl. search policies) konnen zur Bee<strong>in</strong> ussung<br />
der Behandlung e<strong>in</strong>er verteilt ablaufenden Dienstanfrage durch den Trader<br />
| beispielsweise <strong>in</strong> Bezug auf die E<strong>in</strong>beziehung e<strong>in</strong>oder mehrerer Kooperationspartner<br />
oder eventuellen Optimierungskriterien | mit ubergeben<br />
werden.<br />
Die von den kooperierenden Tradern zuruckkommenden Ergebnisse werden<br />
gebundelt und geme<strong>in</strong>sam an den Importeur zuruckgegeben. Die ursprungliche<br />
Herkunft der e<strong>in</strong>zelnen Dienstangebote bleibt dabei verborgen.<br />
Abbildung 5.11 zeigt am Beispiel e<strong>in</strong>er Taxibuchungsanwendung die erweiterten<br />
Moglichkeiten der Dienstauswahl. Im Unterschied zu der <strong>in</strong> Abbildung 5.8
5.2 Dienstvermittlung und {verwaltung durch den TRADEr 173<br />
Abbildung 5.11: Angabe von Suchstrategien am Beispiel e<strong>in</strong>es Taxi{Klienten<br />
gezeigten generischen Benutzerschnittstelle, die e<strong>in</strong>e domanenbegrenzte Dienstauswahl<br />
unter unmittelbarer Nutzung der orig<strong>in</strong>aren importOffer{Operation<br />
unterstutzt, kann mit der hier gezeigten Benutzerschnittstelle beispielsweise<br />
bestimmt werden, ob Anfragen nur lokal oder auch imRahmen von Trader{<br />
Kooperationen verschickt werden sollen.<br />
Auf systemtechnischer Ebene werden derartige Dienstanfragen an die erweiterte<br />
importOffer{Operation gerichtet. Sie wird an der Schnittstelle des TRADErs<br />
zur Verfugung gestellt und realisiert unter anderem die Behandlung der vom Importeur<br />
spezi zierten Suchvorschriften und die Zusammenfassung der im Rahmen<br />
der Trader{Kooperationen gefundenen Dienstangebote. Hierzu nimmt sie die<br />
Funktionen der Trader{Kooperationskontrolle <strong>in</strong> Anspruch. Abbildung 5.12 skizziert<br />
den pr<strong>in</strong>zipiellen Ablauf e<strong>in</strong>er Dienstanfrage unter Nutzungexterner Trader.<br />
Der Importeur, im obigen Fall die vom Benutzer gesteuerte graphische E<strong>in</strong>gabeschnittstelle,<br />
wendet sich hierbei an die erweiterte importOffer{Operation.<br />
Dort ndet als erstes e<strong>in</strong>e Auswertung der Suchvorschriften der Dienstanfrage<br />
statt, wobei als Resultat beispielsweise entweder zunachst nur der lokale Trader<br />
genutzt wird 12 oder auch andere Trader bei der Dienstangebotssuche mit genutzt<br />
werden. In dem <strong>in</strong> der Abbildung gezeigten Fall werden als erstes die lokal<br />
vorhandenen Dienstangebote des TRADErs erfragt und anschlie end durch die<br />
Trader{Kooperationskontrolle uber L<strong>in</strong>ks erreichbare Trader mit <strong>in</strong> die Dienstangebotsvermittlung<br />
e<strong>in</strong>bezogen. Der genaue Ablauf wird durch e<strong>in</strong>en speziellen<br />
Algorithmus gesteuert, der <strong>in</strong> Abbildung 5.13 dargestelltist.Detaillierte Erlauterungen<br />
hierzu nden sich <strong>in</strong>[Mul96].<br />
12 Dieses entspricht dann e<strong>in</strong>er sonst ublichen domanenbegrenzten Dienstanfrage (siehe Ab-<br />
schnitt 5.2.2.3).
174 Systemunterstutzung fur den Dienstzugang<br />
TRADEr<br />
Importeur<br />
1<br />
Standard-<br />
Dienstvermittlungsschnittstelle<br />
Erweiterte<br />
Dienstvermittlungsschnittstelle<br />
2<br />
importOffer (erweitert)<br />
importOffer<br />
TRADEr-Module<br />
- Typprüfung und -suche<br />
- Dienstangebotsauswertung<br />
- Dienstangebotsverwaltung<br />
- Zugriffskontrolle<br />
3<br />
useTraderL<strong>in</strong>ks<br />
Entfernter<br />
Trader<br />
4<br />
importOffer<br />
(erweitert)<br />
Trader-Kooperationskontrolle<br />
- L<strong>in</strong>k-Verwaltung<br />
- Verwaltung von Anfragekennungen<br />
L<strong>in</strong>k-Management-<br />
Schnittstelle<br />
Abbildung 5.12: Ablauf e<strong>in</strong>er Dienstanfrage im TRADEr im Rahmen e<strong>in</strong>er<br />
Trader{Kooperation<br />
Angebotskennung<br />
vorhanden ?<br />
Ne<strong>in</strong><br />
Angebotskennung (AK)<br />
erstellen<br />
Läßt sich AK<br />
registrieren ?<br />
Ja<br />
Suchmethode<br />
spezifiziert ?<br />
Ja<br />
Suchmethode<br />
vermerken<br />
Suchvorschrift<br />
spezifiziert ?<br />
Ja<br />
Suchvorschrift<br />
vermerken<br />
Ja<br />
Ne<strong>in</strong><br />
Ne<strong>in</strong><br />
Suchmethode auf<br />
Defaultwert setzen<br />
Ne<strong>in</strong><br />
Suchvorschrift auf<br />
Defaultwert setzen<br />
Abbruch<br />
Anfrage<br />
nur lokal ?<br />
Synchrone Anfrage ?<br />
Ja<br />
Lokale Anfrage<br />
zuerst ?<br />
Ja<br />
lokale<br />
Dienstanfrage<br />
Hole relevante<br />
L<strong>in</strong>ks<br />
Stelle Dienstanfrage<br />
an Kooperationspartner<br />
Ergebnisse komb<strong>in</strong>ieren<br />
und Resultatrückgabe<br />
Ne<strong>in</strong><br />
Ne<strong>in</strong><br />
Ja<br />
lokale<br />
Dienstanfrage<br />
Hole relevante<br />
L<strong>in</strong>ks<br />
Threads erstellen für<br />
L<strong>in</strong>ks & lokale Anfrage<br />
Anfragen stellen und<br />
warten bis term<strong>in</strong>iert<br />
Hole relevante<br />
L<strong>in</strong>ks<br />
Stelle Dienstanfrage<br />
an Kooperationspartner<br />
lokale<br />
Dienstanfrage<br />
Abbildung 5.13: Algorithmus fur die Abwicklung e<strong>in</strong>er Trader{Kooperation im<br />
TRADEr
5.2 Dienstvermittlung und {verwaltung durch den TRADEr 175<br />
5.2.4 Bewertung und erganzende Anmerkungen<br />
In H<strong>in</strong>blick auf die Gesamtentwicklung von TRADE bildet der TRADEr e<strong>in</strong>en<br />
zentralen Integrationspunkt fur das <strong>in</strong> dieser Arbeit verfolgte Zielder Unterstutzung<br />
der Vermittlung und Koord<strong>in</strong>ation von Diensten <strong>in</strong> o enen <strong>verteilten</strong><br />
Dienstemarkten. Ausgehend von e<strong>in</strong>er Sichtweise, die sich zunachst auf<br />
die Grundfunktionen von Tradern <strong>in</strong> <strong>verteilten</strong> und technisch homogenen Verwaltungsdomanen<br />
konzentrierte [MJM94, MML94b, MML95f], s<strong>in</strong>d imVerlaufe<br />
dieser Arbeit bereits fruhzeitig Erfahrungen gesammelt worden, die fur den<br />
modularen Entwurf und dieEntwicklung des TRADErs genutzt werden konnten.<br />
Hierbei erweist es sich als gunstig, da zu diesem Zeitpunkt erste stabile<br />
Versionen verteilter Systemplattformen, wie beispielsweise das <strong>in</strong> dieser Arbeit<br />
verwendete Distributed Comput<strong>in</strong>g Environment, zur Verfugung standen,<br />
die bereits fur die Entwicklung und Ausfuhrung verteilter Anwendungen wesentliche<br />
Systemmechanismen anbieten. E<strong>in</strong>e <strong>in</strong> diesem Zusammenhangwichtige<br />
Fragestellung fur die Realisierung koord<strong>in</strong>ierter <strong>Dienstnutzung</strong> <strong>in</strong> o enen heterogenen<br />
<strong>verteilten</strong> Dienstemarkten betri t die Integration von Dienstvermittlungsmechanismen,<br />
<strong>in</strong>sbesondere der hier speziell betrachteten ODP{basierten<br />
Trad<strong>in</strong>g{Ansatze [ODP95a], <strong>in</strong> derartige bestehende verteilte Systemplattformen.<br />
E<strong>in</strong>e der Hauptaufgaben besteht deshalb <strong>in</strong>der konkreten systemtechnischen<br />
Umsetzung der dort nur abstrakt de nierten Dienstvermittlungsschnittstelle<br />
mit ihren Operationen exportOffer, importOffer und withdrawOffer.<br />
Erst hierdurch lassen sich fundierte Aussagen uber die Praktikabilitat von<br />
ODP{Trad<strong>in</strong>g{basierten Dienstvermittlungsmechanismen <strong>in</strong> realen Systemumgebungen<br />
tre en. Im Gegensatz zu anderen Arbeiten, wie beispielsweise die <strong>in</strong><br />
[WT90, PZTT91, WT93, TWW92, Tsc94] beschriebenen, <strong>in</strong> denen kommerzielle<br />
verteilte Systemplattformen noch nicht zur Verfugung standen und somit<br />
zunachst grundlegende Verteilungsmechanismen erst entwickelt werden mu ten,<br />
konnte beim Entwurf undder Entwicklungdes TRADErs auf e<strong>in</strong>e Anzahl bereits<br />
vorhandener Basisdienste zuruckgegri en werden. Somit waren zunachst geeignete<br />
Basisdienste zuidenti zieren, die die Grundlage fur e<strong>in</strong>e diensttypbasierte<br />
Dienstvermittlung bereitstellen. Zielstellung des TRADEr{Entwurfs war hierbei<br />
das Erreichen e<strong>in</strong>es hohen Grades an Modularitat, so da die speziell auf DCE<br />
bezogenen Erfahrungen verhaltnisma ig e<strong>in</strong>fach auch fur den Entwurf und die<br />
Entwicklung e<strong>in</strong>es Traders auf anderen <strong>verteilten</strong> Systemplattformen, beispielsweise<br />
der ebenfalls <strong>in</strong> dieser Arbeit betrachteten CORBA{Plattform, ubertragen<br />
werden konnen.<br />
Im e<strong>in</strong>zelnen s<strong>in</strong>d folgende Basiskomponenten e<strong>in</strong>er Trad<strong>in</strong>g{Komponente zur<br />
Unterstutzung der Dienstverwaltung und {vermittlung <strong>in</strong> o enen <strong>verteilten</strong><br />
Dienstemarkten identi ziert (siehe auch Abbildung 5.5) und imRahmen der prototypischen<br />
Realisierung des TRADErs <strong>in</strong> ihrer praktischen Nutzbarkeit verdeutlicht<br />
worden.
176 Systemunterstutzung fur den Dienstzugang<br />
Dienstangebotsverwaltung<br />
E<strong>in</strong>e geeignete Basisfur die Verwaltung von Dienstangeboten s<strong>in</strong>d <strong>in</strong>sbesondere<br />
attributbasierteNamensdienste, wie sie <strong>in</strong> DCE <strong>in</strong> Form des Cell Directory Service<br />
und des X.500{konformen Global Directory Service angeboten werden. Ihre<br />
Fahigkeit zur hierarchischen Ablage von E<strong>in</strong>tragen beliebiger Art <strong>in</strong> Namenskontexten<br />
la t sich <strong>in</strong> geeigneter Weise fur die Verwaltungvon Dienstangeboten nach<br />
unterschiedlichsten Organisationskriterien e<strong>in</strong>setzen. Weiterh<strong>in</strong> bilden Kontexte<br />
auch e<strong>in</strong>emogliche Grundlage zur De nition von Zugri sbeschrankungen. Fur<br />
den TRADEr konnte au erdem ausgenutzt werden, da zu jedem E<strong>in</strong>trag beliebig<br />
viele Attribute ablegbar s<strong>in</strong>d, die fur die nahere Charakterisierung e<strong>in</strong>es<br />
Dienstangebotes, beispielsweise des Diensttyps und von B<strong>in</strong>dungs<strong>in</strong>formationen,<br />
benotigt werden. Hierbei konnte au erdem durch H<strong>in</strong>zufugen DCE{spezi scher<br />
Attribute, die fur die Kopplung des RPC mit dem Cell Directory Service notwendig<br />
s<strong>in</strong>d, e<strong>in</strong>e weitgehend nahtlose Integration des TRADErs <strong>in</strong> DCE erreicht<br />
werden (siehe Abschnitt 5.2.2 und [MML94b, MML95f]). Mit der Nutzung<br />
des X.500{konformen Global Directory Service ergab sich bereits fruhzeitig<br />
auch e<strong>in</strong> e<strong>in</strong>facher Ansatz h<strong>in</strong>sichtlich der Unterstutzung <strong>in</strong>direkter Trader{<br />
Kooperationen. Insbesondere <strong>in</strong> homogenen, auf e<strong>in</strong>e Verwaltungsdomane beschrankteSystemumgebungen<br />
lassen sich Trader{Kooperationen durch Nutzung<br />
standardisierter Namensdiensteauf verhaltnisma ig e<strong>in</strong>fache Artund Weise aufbauen,<br />
ohneda umfangreicheAbsprachen <strong>in</strong> Form von Kooperationsprotokollen,<br />
die bei der direkten Trader{Kooperation zu vere<strong>in</strong>baren s<strong>in</strong>d, getro en werden<br />
mussen. Um diesen Namensdienst{basierten Kooperationsansatz auch <strong>in</strong>heterogenen<br />
Umgebungen zu etablieren, s<strong>in</strong>d jedoch zusatzliche Anstrengungen h<strong>in</strong>sichtlichder<br />
Standardisierungvon Ablageformaten fur Dienstangebote zu tre en.<br />
H<strong>in</strong>weise hierzu nden sich unter anderem <strong>in</strong> [AA91, PM93, RH95, WB95].<br />
Dienstangebotsauswertung<br />
Durch die im Trader{Standarddokument de nierte Dienstangebotsauswertungsschnittstelle<br />
(engl. service o er evaluation <strong>in</strong>terface | SOEI) steht e<strong>in</strong>estandardisierte<br />
Schnittstelle fur den e<strong>in</strong>heitlichen Zugri auf die Werte der Dienstattribute<br />
von Dienstangeboten zur Verfugung. Da nur e<strong>in</strong>e abstrakte Beschreibung<br />
dieser Schnittstelle angeboten wird, konnen pr<strong>in</strong>zipiell verschiedenartigste Varianten<br />
des Attributmanagements realisiert werden. E<strong>in</strong> moglicher Ansatz bietet<br />
der fur den TRADEr gewahlte Ansatz, bei dem das Attributmanagementsystem<br />
nicht nur die Werteder statischen und dynamischen Dienstattributeverwaltet,<br />
sondern gleichzeitig auch die operationalen Zustande der Dienstanbieter mit<br />
berucksichtigt. Hierdurch la t sich e<strong>in</strong>e exible Unterstutzung der gesta elten<br />
Dienstangebotsauswertung des TRADErs erreichen. E<strong>in</strong>e der zukunftigen Verallgeme<strong>in</strong>erungen<br />
der Verwaltung statischer und dynamischer Dienstangebots<strong>in</strong>formationen<br />
besteht dar<strong>in</strong>, dieses Attributmanagementsystem, das <strong>in</strong> TRADE<br />
speziell fur DCE entwickelt wurde und somit e<strong>in</strong>e proprietare Losung darstellt,<br />
durch e<strong>in</strong>eo ene, standardisierte Losung zu ersetzen. E<strong>in</strong>en moglichen Ansatzpunkt<br />
hierfur bilden Ergebnisse aus dem Bereich der Entwicklung standardi-
5.2 Dienstvermittlung und {verwaltung durch den TRADEr 177<br />
sierter Managementsysteme fur verteilte Systemumgebungen [HA93]. Die dort<br />
entwickelten, standardisierten Interaktionsprotokolle zum Zugri auf Status<strong>in</strong>formationen<br />
von Netzkomponenten eignen sich beispielsweise dazu, die derzeit<br />
im TRADE{Attributmanagementsystem verwendeten DCE{Aufrufen zu ersetzen<br />
und soe<strong>in</strong>en standardisierten Zugri auf die Dienstattribute der Dienstanbieter<br />
zu ermoglichen. In diesem Fall konntedas derzeitige Attributmanagementsystem<br />
moglicherweise sogar vollstandig ersetzt werden und somit e<strong>in</strong> weiterer<br />
Schritt <strong>in</strong>Richtung der Wiederverwendung bereits vorhandener generischer Systemmechanismen<br />
erreicht werden.<br />
Zugri skontrolle<br />
Obwohl Sicherheitsaspekte beim Entwurf von TRADE und <strong>in</strong>sbesondere des<br />
TRADErs und der anderen Systemkomponenten nicht imVordergrund der Betrachtung<br />
standen, konnten Autorisierungsmechanismen durch die Nutzung des<br />
Security Service von DCE verhaltnisma ig e<strong>in</strong>fach <strong>in</strong>den TRADEr <strong>in</strong>tegriert<br />
werden. Hierbei wurde ausgenutzt, da samtliche Nutzer von DCE sich vorab<br />
authentisieren mussen. Auf dieser Grundlage lassen sich dann fur jeden <strong>in</strong><br />
DCE angebotenen Anwendungs{ und Systemdienst dedizierte Zugri skontrolllisten<br />
verwalten, mit denen der Zugri von Klienten auf die jeweiligen Dienste<br />
bzw. Operationen der Diensterbr<strong>in</strong>ger gesteuert werden kann. In diesem Zusammenhangergabsich<br />
als <strong>in</strong>teressanteFragestellung, ob bereitsdurchden TRADEr<br />
uberpruft werden sollte, ob e<strong>in</strong> Importeur uber entsprechende Zugri srechtezum<br />
Zugri auf bestimmte Dienstangebote verfugt. Diese Kenntnis konnte dann beispielsweise<br />
bereits bei der Dienstangebotsauswahl mit berucksichtigt werden.<br />
Typuberprufung und {suche<br />
In den ersten Versionen des TRADErs wurde zunachst nur e<strong>in</strong> namensbasierter<br />
Typmanagementmechanismus benotigt. Dieser war fur die Integration des<br />
TRADErs <strong>in</strong> DCE ausreichend, da DCE selbst nur uber rudimentare, auf den<br />
Vergleich von Schnittstellentypnamen basierende Typuberprufungsmechanismen<br />
zum Zeitpunkt der B<strong>in</strong>dung und des Operationsaufrufes verfugt. Aus diesem<br />
Grund bot das fur den TRADEr entwickelteTypmanagementnur e<strong>in</strong>facheFunktionen<br />
zum E<strong>in</strong>fugen, Suchen und Loschen von Diensttypnamen, Schnittstellentypnamen<br />
sowie Aliasnamen <strong>in</strong> Typhierarchien an [MML94b, MML95f]. Diese<br />
e<strong>in</strong>fache Art des Typmanagements erwies sich jedoch bei der Entwicklung von<br />
Trader{Kooperationen, <strong>in</strong>sbesondere im Rahmen des <strong>in</strong> Abschnitt 5.2.3 beschriebenen<br />
IWT{Projektes, zunehmend als un exibel, da aufgrund der Heterogenitat<br />
der beteiligten Verwaltungsdomanen die Absprache von Diensttypnamen <strong>in</strong> der<br />
Regel zu Mi verstandnissen bei der wohlde nierten, semantisch korrekten Nutzung<br />
von Diensten fuhrt. Aus diesem Grund wurde bereits fruhzeitig parallel<br />
e<strong>in</strong> struktureller Ansatz fur den Austausch von Dienstbeschreibungen verfolgt,<br />
der letztendlich zumEntwurf und der Entwicklung des <strong>in</strong> Abschnitt 5.1.1.1 beschriebenen<br />
kanonischen Typmodells fuhrte. Erst hierdurch konnten machtige
178 Systemunterstutzung fur den Dienstzugang<br />
Typmanagementfunktionen realisiert werden, wie sie derzeitig vom TRADE{<br />
Typmanager angeboten werden.<br />
Trader{Kooperationskontrolle<br />
Aufsetzend auf den Erfahrungen beim Entwurf und der Realisierung des ausschlie<br />
lich <strong>in</strong>nerhalb e<strong>in</strong>er Verwaltungsdomane agierenden TRADErs ergab sich<br />
die Moglichkeit, erweiterte Formen der Dienstangebotsvermittlung zuuntersuchen<br />
und erste Erfahrungen und Ergebnisse h<strong>in</strong>sichtlichdes Aufbaus von Trader{<br />
Kooperationen im Rahmen des Projektes Interwork<strong>in</strong>g of Traders [Vog94,<br />
VBB95, MMaTT96] zu sammeln.<br />
Zielstellung dieses Projektes (siehe auch Abschnitt 5.2.3) war die systemtechnische<br />
Verknupfung der von den Projektpartnern unabhangig entwickelten<br />
Trader{Implementierungen uber e<strong>in</strong> geme<strong>in</strong>sames DCE{basiertes Testszenario.<br />
Begleitet wurden diese Arbeiten durch die im Rahmen der ODP{Trad<strong>in</strong>g{<br />
Standardisierungdurchgefuhrten Normungsarbeiten, wobei im IWT{Projekt vor<br />
allem die importOffer{Operation und die L<strong>in</strong>k{Management{Schnittstelle von<br />
Interesse waren. In diesem Zusammenhang sollte nicht nur die Durchfuhrbarkeit<br />
von standardisierten Trader{Kooperationen aufgezeigt werden, sondern gleichzeitig<br />
die erzielten Ergebnisse und Erfahrungen mit <strong>in</strong> den Standardisierungsproze<br />
e<strong>in</strong> ie en. Bei der konkreten Durchfuhrung des Projektes wurde von e<strong>in</strong>em<br />
mehrstu gen Plan ausgegangen, wobei <strong>in</strong> der derzeit abgeschlossenen Phase<br />
zunachst nur zwei DCE{basierte Trader mite<strong>in</strong>ander kooperieren konnen. Anschlie<br />
endsolltedas Szenario auf heterogene Systemplattformen ausgeweitet werden,<br />
so da auch Trader{Kooperationen, beispielsweise zwischen e<strong>in</strong>em DCE{<br />
und e<strong>in</strong>em CORBA{Trader, moglich se<strong>in</strong> sollten. Hierfur mu ten dann zusatzlich<br />
Trader{spezi zische Interzeptionsmechanismen entwickelt werden. Zur Vere<strong>in</strong>fachung<br />
des DCE{Testszenarios wurde weiterh<strong>in</strong> von e<strong>in</strong>em homogenen Typverstandnis<br />
ausgegangen, so da die E<strong>in</strong>beziehung von Typmanagern bei der<br />
Trader{Kooperation auf e<strong>in</strong>en spateren Zeitpunkt verschoben werden konnte.<br />
Die Verknupfung von zwei DCE{basierten Tradern zwischen zwei getrennten<br />
Verwaltungsdomanen konnte am Beispiel des TRADErs mit dem DSTC{Trader<br />
und dem an der Universitat Stuttgart entwickelten Trader [BKS91, KW94]<br />
praktisch demonstriert werden. Wesentliche Resultate dieserTests waren zum<br />
e<strong>in</strong>en die <strong>in</strong> Abschnitt 5.2.3.3 beschriebene Erweiterung der importOffer{<br />
Operation und zum anderen der Entwurf und die Entwicklung des L<strong>in</strong>k{<br />
Kon gurationsmanagers. Dieser erlaubt die adm<strong>in</strong>istrativeVerwaltungvon L<strong>in</strong>ks<br />
und stellt somit die Grundlage fur den Aufbau von Trader{Kooperationen<br />
dar. Hierbei zeigt sich, da die vom ODP{Trader{Standarddokument de nierte<br />
L<strong>in</strong>k{Management{Schnittstelle fur derartige Aufgaben ausreichend machtig<br />
ist. Die von ihr angebotenen Operationen addL<strong>in</strong>k, removeL<strong>in</strong>k, modifyL<strong>in</strong>k,<br />
describeL<strong>in</strong>k und listL<strong>in</strong>ks (siehe auch Anhang D.2) wurden <strong>in</strong>tensiv vom<br />
L<strong>in</strong>k{Kon gurationsmanager verwendet und ermoglichen neben dem E<strong>in</strong>richten,<br />
Loschen und Modi zieren von L<strong>in</strong>ks auch die Verwaltungstatistischer Informationen<br />
uber die L<strong>in</strong>ks. Diese Informationen konnen beispielsweise fur adm<strong>in</strong>istrative
5.2 Dienstvermittlung und {verwaltung durch den TRADEr 179<br />
Entscheidungen beim Aufbauvon Trader{Kooperationen oder aber auchvon den<br />
Tradern selbst zur Auswahl geeigneter Koooperationspartner genutzt werden.<br />
Die ersten praktischen Erfahrungen im Umgang mit Kooperationen von Tradern<br />
zweier getrennter Verwaltungsdomanen zeigen, da zum gegenwartigen Zeitpunkt,<br />
<strong>in</strong>sbesondere aufgrund der weiten Entfernung zwischen Hamburg und<br />
Brisbane uber das Internet, mit hohen Wartezeiten bei der Kooperation zwischen<br />
dem TRADEr und dem DSTC{Trader gerechnet werden mu . Generell<br />
s<strong>in</strong>d Laufzeiten von uber zehn M<strong>in</strong>uten fur e<strong>in</strong>en e<strong>in</strong>fachen RPC{Aufruf der<br />
importOffer{Operation ke<strong>in</strong>e Seltenheit, wobei jedoch der zusatzliche Aufwand<br />
berucksichtigt werden mu , der durch Nutzung des Cell Directory Service zur<br />
Lokalisierung der Trader entsteht. Diese Laufzeiten s<strong>in</strong>d fur e<strong>in</strong>en E<strong>in</strong>satz <strong>in</strong> der<br />
alltaglichen Rout<strong>in</strong>e nicht tolerabel, so da zukunftig vor allem Optimierungen<br />
des Zeitverhaltens vorgenommen werden mussen. Dieses ist vor allem h<strong>in</strong>sichtlich<br />
der Realisierung mehrstu ger Trader{Kooperationen, bei denen mehrere Trader<br />
h<strong>in</strong>tere<strong>in</strong>andergeschaltet s<strong>in</strong>d, notwendig.<br />
E<strong>in</strong> weiteres im Rahmen des IWT{Projektes erzieltes Ergebnis ist die Untersuchung<br />
verschiedener Kooperationsprotokolle, wie sie ausfuhrlich <strong>in</strong>Abschnitt<br />
3.3.3.3 beschrieben s<strong>in</strong>d. Sie bieten die konzeptionelle Grundlage fur die Entwicklung<br />
verschiedener Kooperationsszenarien zwischen Tradern. Mit ihnen lassen<br />
sichkonkrete Realisierungen von exiblen Trader{Kooperationen entwickeln,<br />
die dann beispielsweise h<strong>in</strong>sichlich ihrer E zienz evaluiert werden konnen. Um<br />
trotz der oben genannten Performanzprobleme die Durchfuhrbarkeit der verschiedenen<br />
Trader{Kooperationsprotokolle zeigen zu konnen, wurde neben dem<br />
oben beschriebenen Testszenario e<strong>in</strong> weiteres Szenario aufgebaut, das nur <strong>in</strong>nerhalb<br />
e<strong>in</strong>er Verwaltungsdomane bzw. DCE{Zelle <strong>in</strong> Hamburg ablief und auf e<strong>in</strong><br />
lokales Netzwerk beschrankt war. Hierzu wurden zwei TRADEr gestartet und<br />
mit jeweils e<strong>in</strong>em eigenen TRADE{Typmanager verknupft. Der Aufbau der Kooperationsbeziehungzwischen<br />
den beiden TRADErn erfolgte mit Hilfe des L<strong>in</strong>k{<br />
Kon gurationsmanagers. Als geme<strong>in</strong>same Basis fur den Austausch von Dienstbeschreibungen<br />
diente die vom Typmanager bereitgestellte kanonische Typreprasentation,<br />
die sich <strong>in</strong> diesem Zusammenhang als geeignete Transportstruktur<br />
von Dienstbeschreibungen erwies. Weiterh<strong>in</strong> wurde die <strong>in</strong> DCE de nierte Subtypbeziehung<br />
als geme<strong>in</strong>same Grundlage fur beide Typmanager vere<strong>in</strong>bart. Als<br />
vergleichsweise e<strong>in</strong>fach zeigtesich die Realisierung der beiden standardisierten<br />
Kooperationsprotokolle, da hier nur Interaktionen zwischen den jeweils zusammengehorenden<br />
TRADEr und Typmanager statt nden und der Typmanager der<br />
anderen Verwaltungsdomane nicht kontaktiert werden mu . Weiterh<strong>in</strong> wurden<br />
beide ignoranten Varianten und die bewu te, Trader{gesteuerte Koooperationsform<br />
realisiert. Die bewu te, Typmanager{gesteuerteKoooperationsformkonnte<br />
aufgrundder zur Zeit nicht implementierten Operation GetForeignTypeId (siehe<br />
auch Abbildung 3.32) noch nicht realisiert werden.<br />
Mit dieser praktischen Realisierung der verschiedenen Kooperationsprotokolle<br />
konnte zume<strong>in</strong>en ihre Durchfuhrbarkeit praktisch demonstriert werden. Zum<br />
anderen ergaben sich Ruckschlusse auf den Software{technischen Entwurf von<br />
Tradern. So vere<strong>in</strong>fachtsich beispielsweise bei den Typmanager{gesteuerten Ko-
180 Systemunterstutzung fur den Dienstzugang<br />
operationsformen der Entwurf des TRADErs ma geblich, da im TRADEr selbst<br />
ke<strong>in</strong>e weitere Behandlung von Typ<strong>in</strong>formationen mehr notwendig ist, sondern<br />
samtliche hiermit verbundenen Aufgaben von den kooperierenden Typmanagern<br />
ubernommen werden.<br />
Im ubergeordneten IWT{Projekt stehen als nachstes vor allem Schritte fur die<br />
oben erwahnteAusweitungdes Testszenarios auf heterogeneverteilte Systemumgebungen<br />
unter Nutzung von Interzeptoren an. Voraussetzung hierfur ist, da<br />
IWT{konforme Trader{Implementierungen auch auf anderen <strong>verteilten</strong> Systemplattformen<br />
als auf DCE zur Verfugung stehen. Erst dieses ermoglicht die Analyse<br />
der verschiedenen Trader{Kooperationsprotokolle unter gro tmoglichen Heterogenitatsbed<strong>in</strong>gungen,<br />
wobei <strong>in</strong>sbesondere auf dem H<strong>in</strong>tergrund der bisherigen<br />
praktischen Erfahrungen des IWT{Projektes auch auf Performanzaspekte<br />
vordr<strong>in</strong>glich geachtet werden sollte. In diesem Zusammenhang istauch der fur<br />
den plattformubergreifenden Dienstzugang notwendige Interzeptor detailliert zu<br />
untersuchen. Erste Anmerkungen zur Performanz e<strong>in</strong>es derartigen Interzeptors<br />
nden sich <strong>in</strong>den Abschnitten 5.3.3.2 und 5.3.4, wo auf verschiedene Realisierungsaspekte<br />
des <strong>in</strong> TRADE fur DCE und CORBA entwickelten Interzeptors<br />
e<strong>in</strong>gegangen wird.<br />
Vorschriften<br />
Insgesamt zeigt sichbeider Realisierungvon Tradern undTrader{Kooperationen<br />
die Behandlung von Verwaltungsvorschriften (engl. policies) als e<strong>in</strong>e wichtige<br />
ubergreifende Fragestellung. Sie kann <strong>in</strong> <strong>verteilten</strong> Systemplattformen generisch<br />
behandelt werden, da sie nicht nur e<strong>in</strong> Trad<strong>in</strong>g{spezi sches Problem ist, sondern<br />
generell auch <strong>in</strong>anderen System{ und Anwendungsdiensten zur dynamischen<br />
Steuerung benotigt wird. Da hierfur zur Zeit erst grundlegende Ansatze <strong>in</strong> der<br />
Entwicklung s<strong>in</strong>d(siehe beispielsweise [Mof94, Bur95, MK95]), wurden fur den<br />
TRADEr | und ebenso fur den Typmanager, den Interzeptor und den Koord<strong>in</strong>ationsmanager<br />
| bestimmte Verwaltungsvorschriften vorde niert. Beispiele<br />
hierfur nden sich fur den TRADEr <strong>in</strong> den Abschnitten 5.2.2.3 und 5.2.3.3, wo<br />
Vorschriften zur Steuerungder importOffer{Operation dienen. E<strong>in</strong>eder zukunftigen<br />
Aufgabenstellungen wird es <strong>in</strong> diesem Zusammenhang se<strong>in</strong>, diese statischen<br />
Ansatze durch e<strong>in</strong>en generischen und dynamischen Steuerungsmechanismus zu<br />
ersetzen, so da e<strong>in</strong>e exible De nition, Ausfuhrung und Kontrolle von Vorschriften<br />
durchfuhrbar ist. Dieser Mechanismus konnte beispielsweise als eigener<br />
Systemdienst etabliert werden, wodurch e<strong>in</strong>eweiterer Schritt der auch <strong>in</strong> TRA-<br />
DE verfolgten Zielstellung h<strong>in</strong>sichtlich der Entwicklung generischer Basisdienste<br />
erreicht werden wurde.<br />
5.3 Domanenubergreifender Dienstzugri<br />
Das rasche Voranschreiten der Entwicklung globaler verteilter Dienstemarkte<br />
ermoglicht neue Formen der Entwicklung und Ausfuhrung von <strong>verteilten</strong> Anwendungen,<br />
die sich <strong>in</strong>sbesondere durch e<strong>in</strong> kooperatives Zusammenspiel unter-
5.3 Domanenubergreifender Dienstzugri 181<br />
schiedlicher, oft auf heterogenen E<strong>in</strong>zelsystemen verteilt angebotenen Diensten<br />
auszeichnet. Die Realisierung derartiger fast ausschlie lich aus der Nutzung externer<br />
Dienste bestehender Kooperationsanwendungen (siehe Abschnitt 4.2) wird<br />
vor allem durch die Bereitstellung weitreichender Systemfunktionen unterstutzt,<br />
die durch verteilte Systemplattformen bzw. sogenannte Middleware [Ber93] erbrachtwerden.<br />
Diese, beispielsweise auch die <strong>in</strong> TRADE speziell betrachteDCE{<br />
und die CORBA{Plattform, bieten dem Programmierer machtige und auf hohem<br />
Abstraktionsniveau be ndliche systemtechnische Funktionen und Schnittstellen<br />
an und ermoglichen so e<strong>in</strong>e e ziente Software{Entwicklung, ohne ihn mit tieferliegenden<br />
system{ und netzwerktechnischen Details zu konfrontieren. Allerd<strong>in</strong>gs<br />
ermoglichen sie die Uberw<strong>in</strong>dung der Grenzen heterogener E<strong>in</strong>zelsysteme im<br />
allgeme<strong>in</strong>en nur <strong>in</strong>nerhalb ihrer eigenen homogenen Realisierungsumgebungen,<br />
so da sich zwischen zwei verschiedenen <strong>verteilten</strong> Systemplattformen zunachst<br />
unuberw<strong>in</strong>dbare Heterogenitatsgrenzen ergeben. Um nun trotz dieser Heterogenitatsproblemee<strong>in</strong>e<br />
domanenubergreifende <strong>Dienstnutzung</strong> und {koord<strong>in</strong>ation zu<br />
ermoglichen, ist e<strong>in</strong>e Erweiterung heutiger verteilter Systemplattformen um die<br />
<strong>in</strong> Abschnitt 3.4vorgestellten Interzeptionsmechanismen notwendig, die e<strong>in</strong>en<br />
Ubergang uber die technische Heterogenitatsgrenze ermoglichen und somit e<strong>in</strong>e<br />
systemtechnische Interoperabilitat der unterliegenden Middleware{Architekturen<br />
realisieren. Mit ihnen la t sichdann das <strong>in</strong> TRADE verfolgte Ziel nache<strong>in</strong>em une<strong>in</strong>geschrankten<br />
Dienstzugang <strong>in</strong> o enen heterogenen <strong>verteilten</strong> Dienstemarkten<br />
erreichen.<br />
Der vorliegende Abschnittstellt imfolgenden den <strong>in</strong> TRADE entwickelten Interzeptor<br />
[GML96, Gri96]vor. Zum e<strong>in</strong>en werden se<strong>in</strong>e unterliegenden verallgeme<strong>in</strong>erbaren<br />
Konzepte fur den oben beschriebenen Ubergang technischer Heterogenitatsgrenzen<br />
dargestellt und zumanderen ihre Umsetzung konkret am Beispiel<br />
von DCE und CORBA demonstriert. Hierbei wird auch das Zusammenspiel des<br />
Interzeptors mit den <strong>in</strong> den beiden vorherigen Abschnitten beschriebenen Typmanager<br />
unddem TRADEr deutlich, das <strong>in</strong> Teil I bisher nur <strong>in</strong> se<strong>in</strong>er Konzeption<br />
erlautert wurde.<br />
5.3.1 Voraussetzungen fur die Interzeption<br />
Als Grundvoraussetzung fur die Wirksamkeit des hier beschriebenen Interzeptionskonzeptes<br />
wird zunachst e<strong>in</strong>e Ahnlichkeit der zu <strong>in</strong>tegrierenden <strong>verteilten</strong><br />
Systemplattformen <strong>in</strong> der Unterstutzung der genannten Ebenen gefordert. Ahnlichkeit<br />
hei t <strong>in</strong> diesem Zusammenhang die Gewahrleistung e<strong>in</strong>er grundsatzlichen<br />
Kommunikationsfahigkeit, e<strong>in</strong>er Abbildbarkeit von Modellierungskonzepten<br />
und die Absicht, verwandte Anwendungsklassen zu unterstutzen. Interoperabilitat<br />
wird <strong>in</strong> diesem Beitrag ausdrucklichnur zwischen <strong>in</strong> diesem S<strong>in</strong>ne ahnlichen<br />
Plattformen untersucht, welches im S<strong>in</strong>ne e<strong>in</strong>er Anwendungsunterstutzung ke<strong>in</strong>e<br />
wesentliche E<strong>in</strong>schrankung darstellt, da sichfur gangige praxisrelevante Systemplattformen,<br />
<strong>in</strong>sbesondere auch fur DCE und CORBA, e<strong>in</strong>e solche Ahnlichkeit<br />
identi zieren la t [YV96, BKR93]. Dieses wurde <strong>in</strong>Abschnitt 5.1.1 konkret<br />
auch bei der Abbildung der von beiden Plattformen angebotenen Schnittstellenbeschreibungssprachen<br />
deutlich. Beide Plattformen nutzen zudem den Objekt-
182 Systemunterstutzung fur den Dienstzugang<br />
begri zur Charakterisierung ihrer eigenen Basiskonzepte. E<strong>in</strong> Objekt versteht<br />
sich dabei im S<strong>in</strong>ne der <strong>in</strong> Abschnitt 2.2 vorgestellten Begri sbildung als e<strong>in</strong>e<br />
durch ihre Schnittstelle von der Umgebung abgegrenzte E<strong>in</strong>heit, deren Verhalten<br />
durch <strong>in</strong>der Schnittstelle spezi zierten Operationen beschrieben wird. Je nach<br />
Entstehungsgeschichte der beiden Plattformen spiegelt sich diese Objektsicht<br />
mehr oder weniger ausgepragt <strong>in</strong> ihren jeweiligen Programmiermodellen wider:<br />
Wahrend beispielsweise der Schwerpunkt von DCE eher <strong>in</strong> der Uberw<strong>in</strong>dung<br />
heterogener Transportprotokolle mittels RPC und der Bereitstellung kommerziell<br />
wichtiger Mechanismen der Sicherheit und e<strong>in</strong>es hierarischen Namensdienstes<br />
liegt, zielt CORBA eher auf die Bereitstellung e<strong>in</strong>heitlicher objektorientierter Methoden<br />
und Schnittstellen fur die Programmierung verteilter Systeme ab. Unter<br />
anderem schon wegen dieser unterschiedlichen konzeptionellen Herangehensweise<br />
werden auch zukunftig noch beide Plattformen nebene<strong>in</strong>ander existieren, welches<br />
Programmierern o ener verteilter Anwendungen ihre Arbeit zunachst erschwert.<br />
Dennoch bleibt ihr geme<strong>in</strong>samer E<strong>in</strong>satz fur e<strong>in</strong>e Vielzahl verteilter Anwendungen<br />
wunschenswert und ist bei e<strong>in</strong>er stufenweisen Migration, beispielsweise von<br />
DCE nach CORBA, sogar unvermeidlich.<br />
5.3.2 Entwurfsziele fur e<strong>in</strong>e Interzeptor{Komponente<br />
Wichtige Zielstellungen fur den Entwurf e<strong>in</strong>er Interzeptor{Komponente zur<br />
Uberw<strong>in</strong>dung der <strong>in</strong> o enen <strong>verteilten</strong> Systemumgebungen vorhandenen Heterogenitat<br />
s<strong>in</strong>d:<br />
die Erleichterung des Zugangs zu e<strong>in</strong>er Vielzahl verschiedener Dienstangebote<br />
heterogener Herkunft zur Erstellung verteilter Anwendungen, <strong>in</strong>sbesondere<br />
der <strong>in</strong> TRADE speziell zu unterstutzenden, auf Koord<strong>in</strong>ationssprachen<br />
und {steuerungsmechanismen basierenden Kooperationsanwendungen<br />
(Abschnitt 4.2),<br />
die Zusammenarbeit der Interzeptionsmechanismen mit den Diensttypisierungs{<br />
und Dienstvermittlungsmechanismen, wie sie <strong>in</strong> TRADE durch<br />
den Typmanager und TRADEr zur Verfugung gestellt werden und<br />
e<strong>in</strong>e weitgehende programmiertechnische Integration mit den <strong>in</strong> den <strong>verteilten</strong><br />
Systemplattformen vorhandenen Programmierungskonzepten, wobei<br />
die explizite Nutzung e<strong>in</strong>es Interzeptors beim plattformubergreifenden<br />
Dienstzugri moglichst verborgen bleiben soll. Dieses bedeutet vor allem,<br />
da ke<strong>in</strong>e explizite B<strong>in</strong>dung zumInterzeptor aufgebaut werden mu , sondern<br />
der Interzeptionsvorgang automatisch und weitgehend unsichtbar fur<br />
Dienstnehmer und Diensterbr<strong>in</strong>ger durchgefuhrt wird.<br />
Insbesondere durch die Erfullung der letztgenannten Anforderung la t sich e<strong>in</strong>e<br />
hohe Akzeptanz des <strong>in</strong> TRADE entwickelten Interzeptors <strong>in</strong>nerhalb bestehender<br />
Systemumgebungen erreichen, da der Programmierer von e<strong>in</strong>zelnen Anwendungsdiensten<br />
weiterh<strong>in</strong> <strong>in</strong> se<strong>in</strong>er gewohnten Systemumgebung realisieren kann,<br />
se<strong>in</strong>e Dienstangebote nun jedoch mit verhaltnisma ig ger<strong>in</strong>gem Aufwand mit
5.3 Domanenubergreifender Dienstzugri 183<br />
Hilfe der vom Interzeptor bereitgestellten Funktionen auch <strong>in</strong>anderen Verwaltungsdomanen<br />
sichtbar werden und somit fur Anwendungsprogrammierer anderer<br />
Domanen nutzbar werden.<br />
Um die obigen Anforderungen zu erfullen, ist zum e<strong>in</strong>en e<strong>in</strong>e Methode und e<strong>in</strong>e<br />
Entwurfsumgebung fur die Diensterstellung (im S<strong>in</strong>ne e<strong>in</strong>es " programm<strong>in</strong>g <strong>in</strong><br />
the small\) und zumanderen e<strong>in</strong>e Methode und e<strong>in</strong>eEntwurfsumgebung fur die<br />
Systemerstellung ( " programm<strong>in</strong>g <strong>in</strong>the large\) erforderlich. Sowohl die Dienst{<br />
als auch die Systemerstellung, d.h. die Erstellung neuer Koooperationsanwendungen<br />
mit ihren Anwendungsvorgangen, wird <strong>in</strong> TRADE durch e<strong>in</strong> spezielles<br />
Framework unterstutzt. Dieser Programmier{Framework, das unter anderem<br />
auch die Koord<strong>in</strong>ationssprache PAMELA be<strong>in</strong>haltet, wird <strong>in</strong> nachfolgenden Kapitel<br />
6 <strong>in</strong> se<strong>in</strong>en Details vorgestellt. Es ermoglicht e<strong>in</strong>e e<strong>in</strong>fache Nutzung der<br />
Interzeptionsmechanismen und bietet gleichzeitig auch dieFunktionen, mit denen<br />
e<strong>in</strong>e domanenubergreifendeSteuerungund Koord<strong>in</strong>ation der <strong>in</strong> Anwendungsvorgangen<br />
genutzten Dienste durchfuhrbar ist. Hierbei werden bei der Diensterstellung<br />
die orig<strong>in</strong>aren Konzepte der genutzten DCE{ und CORBA{Plattform<br />
weitgehend beibehalten, 13 umden benotigten Lern{ und Umstellungsaufwand<br />
fur den Programmierer so ger<strong>in</strong>g wie moglich zuhalten.<br />
5.3.3 Der Interzeptionsmechanismus<br />
Der Interzeptor realisiert die wesentlichen Funktionen zur B<strong>in</strong>dung und Interaktion<br />
von Dienstnehmern und Diensterbr<strong>in</strong>gern uber Domanengrenzen h<strong>in</strong>weg.<br />
Den dazu notwendigen Vergleich und die Transformation von Schnittstellentypen<br />
fuhrt er mit Hilfe des <strong>in</strong> Abschnitt 5.1 beschriebenen Typmanagers aus.<br />
Daruberh<strong>in</strong>aus stellt der Interzeptor auch e<strong>in</strong>en Integrationspunkt fur <strong>in</strong> Abschnitt<br />
3.4.1 identi zierten Kontroll{, Uberwachungs{ und Informationsfunktionen<br />
dar, da sich mit ihm die entsprechenden Ubergangsmoglichkeiten der e<strong>in</strong>zelnen<br />
Verwaltungsdomanen auf ubersichtlicheWeise <strong>in</strong> e<strong>in</strong>er Komponenten e<strong>in</strong>heitlich<br />
zusammenfassen lassen. Hierdurch unterscheidet er sich auch von den <strong>in</strong>sbesondere<br />
<strong>in</strong> [YV96] und [MZP96] vorgeschlagenen Bridge{Mechanismen, die sich<br />
hauptsachlich auf Transformationsaspekte beim plattformubergreifenden Dienstzugri<br />
beschranken.<br />
5.3.3.1 Pr<strong>in</strong>zipielle Funktionsweise<br />
Der Interzeptor mu auf e<strong>in</strong>er Systemplattform lokalisiert se<strong>in</strong>, die den Zugang<br />
zu den beiden beteiligten und technisch unterschiedlichen Verwaltungsdomanen<br />
erlaubt. Se<strong>in</strong>e Basisfunktionalitat umfa t im e<strong>in</strong>zelnen die folgenden Arbeitsschritte<br />
(siehe auch [Gri96]):<br />
E<strong>in</strong>gehen e<strong>in</strong>er B<strong>in</strong>dung mit e<strong>in</strong>em Dienstnehmer e<strong>in</strong>er der beteiligten Verwaltungsdomanen,<br />
13 Dieser Trend zur moglichst weitgehenden Integration wurde auch bei der Nutzung von<br />
DCE{Namensdiensten zur TRADEr{Dienstangebotsverwaltung <strong>in</strong>Abschnitt 5.2.2deutlich.
184 Systemunterstutzung fur den Dienstzugang<br />
Ermittlung des vom Dienstnehmer gewunschten Diensttyps,<br />
Au nden e<strong>in</strong>es diensttypkonformen Diensterbr<strong>in</strong>gers <strong>in</strong> der anderen<br />
Domane,<br />
B<strong>in</strong>dung an diesen Diensterbr<strong>in</strong>ger,<br />
Entgegennahme e<strong>in</strong>es Operationsaufrufes vom Dienstnehmer,<br />
Transformation der Operationsparameter und ihrer Werte gema dem dort<br />
vorhandenen Typsystem,<br />
Aufruf e<strong>in</strong>er zur gewunschten Operation typkonformen Operation beim<br />
Diensterbr<strong>in</strong>ger der anderen Domane,<br />
Entgegennahme der Operationsergebnisse und Transformation der Ausgabeparameter<br />
und ihrer Werte <strong>in</strong>e<strong>in</strong>efur die Domane des Dienstnehmers<br />
geeignete Form und<br />
Ubergabe der so erhaltenen Ergebnisse an den Dienstnehmer.<br />
GrundlegendeIdee, um die <strong>in</strong> Abschnitt 5.3.2 geforderteAbstraktion bei der Nutzung<br />
des Interzeptionskonzeptes zur erfullen, s<strong>in</strong>d sogenannte Proxies (Stellvertreter)<br />
[GML96, Gri96]. Sie stellen fur jede <strong>in</strong>e<strong>in</strong>er Verwaltungsdomanevorhandenen<br />
Dienstanbieter entsprechendeStellvertreter <strong>in</strong> der jeweils anderen Domane<br />
dar, <strong>in</strong> der diese dann mit den dort bekannten Techniken genutzt und verwaltet<br />
werden konnen.<br />
Initiiert wird die Generierung von Proxies wahrendder Registration vorhandener<br />
Dienstanbieter beim Interzeptor, der anschlie end die Interaktion zwischen der<br />
tatsachlichen und der stellvertretenden Komponente abwickelt und uberwacht.<br />
Bed<strong>in</strong>gt durch die Generierungvon Proxies <strong>in</strong>nerhalbder Zieldomanewirddamit<br />
gleichzeitig auch verh<strong>in</strong>dert, da Fremdkonzepte aus der <strong>in</strong>itiierenden Domane,<br />
die entweder semantischoder technisch<strong>in</strong>der Zieldomane nicht fa bar s<strong>in</strong>d, von<br />
au en here<strong>in</strong>getragen werden konnen (siehe auch Abschnitt 3.4.3). E<strong>in</strong> Beispiel<br />
hierfur s<strong>in</strong>d B<strong>in</strong>dungs<strong>in</strong>formationen, die nur bezuglich e<strong>in</strong>er bestimmten Verwaltungsdomane<br />
e<strong>in</strong>es<strong>in</strong>nvolle Bedeutung besitzen. In diesem speziellen Fall la t<br />
sich dieses Problem jedoch auf elegante Weise durch Registrierung der erzeugten<br />
Proxies bei der jeweils vorhandenen Dienstvermittlungskomponenteder Zieldomane<br />
erreichen. In konkreter Anwendung auf die <strong>in</strong> TRADE konkret betrachtete<br />
Verknupfung e<strong>in</strong>er DCE{ und e<strong>in</strong>er CORBA{Domane ndet entsprechend<br />
e<strong>in</strong>e Zusammenarbeit des Interzeptors mit dem CORBA{Broker und dem DCE{<br />
basierten TRADEr statt. Hierdurch wird e<strong>in</strong>e hochgradige Abstraktion vom Interzeptorkonzept<br />
<strong>in</strong> der Zieldomane erreicht, da dort die bereits verfugbaren<br />
Systemmechanismen, wie <strong>in</strong> diesem speziellen Fall die Dienstvermittlungskomponenten,<br />
e<strong>in</strong>gesetzt werden konnen. Aus Sicht des Dienstnehmers ersche<strong>in</strong>t der<br />
hierbei generierte Proxy wie e<strong>in</strong> normaler Diensterbr<strong>in</strong>ger der eigenen Verwaltungsdomane.<br />
Grob umfa t das Interoperabilitatskonzept die folgende Vorgehensweise. Zur<br />
Verfugung stehende Dienstanbieter registrieren sich lokal ( " domanen<strong>in</strong>tern\) bei
5.3 Domanenubergreifender Dienstzugri 185<br />
dem TRADEr bzw. CORBA{Broker und global ( " domanenubergreifend\) bei<br />
dem Interzeptor. Dieser registriert wechselseitig Stellvertreter fur die ihm bekannten<br />
Komponenten <strong>in</strong> der jeweils anderen Domane. Anschlie end konnen<br />
Kooperationsanwendungen durch Komposition beliebiger vorhandener Dienstangebote<br />
erstellt werden, bei deren Ablauf wahrend der Nutzung von Stellvertreterkomponenten<br />
der Interzeptor entsprechende Dienstzugri e beim orig<strong>in</strong>aren<br />
Dienstanbieter veranla t. Abbildung 5.14 skizziert diesen generellen Mechanismus<br />
am Beispiel der Nutzung e<strong>in</strong>es DCE{Dienstes durch e<strong>in</strong>en CORBA{<br />
Dienstnehmer.<br />
Broker Interzeptor TRADEr<br />
Register Create<br />
Transform<br />
6<br />
5<br />
1<br />
2<br />
Return Lookup<br />
Typ-<br />
Export<br />
Manager<br />
CORBA-<br />
Klient<br />
4<br />
B<strong>in</strong>d & Call<br />
7<br />
DCE-<br />
Proxy<br />
3<br />
Interception<br />
8<br />
DCE-<br />
Server<br />
Abbildung 5.14: Nutzung e<strong>in</strong>es DCE{Dienstes durch e<strong>in</strong>en CORBA{<br />
Dienstnehmer<br />
Der Interzeptionsvorgang der Nutzung e<strong>in</strong>es CORBA{Dienstes <strong>in</strong> e<strong>in</strong>er DCE{<br />
Domane verhalt sichentsprechend spiegelverkehrt (Abbildung 5.15). Wahrend<br />
dieser Interzeptionsvorgange werden Informationen uber registrierte Dienstanbieter,<br />
ihre B<strong>in</strong>dungen und samtliche Interaktionsversuche protokolliert. E<strong>in</strong>e<br />
E<strong>in</strong> u nahme auf die Sichtbarkeit von Diensterbr<strong>in</strong>gern <strong>in</strong> Fremddomanen ist<br />
durch die Steuerungsmoglichkeit der Proxy{Generierungmoglich. Sie kann auch<br />
durch e<strong>in</strong>e Regelung der Suchtiefen <strong>in</strong> den <strong>verteilten</strong> Umgebungen gesteuert wer-<br />
Broker Interzeptor<br />
1<br />
Register<br />
CORBA-<br />
Server<br />
Transform<br />
2<br />
Typ-<br />
Manager<br />
3 4<br />
Create Register<br />
CORBA-<br />
Proxy<br />
Interception B<strong>in</strong>d & Call<br />
8<br />
7<br />
Return<br />
TRADEr<br />
6<br />
DCE-<br />
Klient<br />
5<br />
Lookup<br />
Abbildung 5.15: Nutzung e<strong>in</strong>es CORBA{Dienstes durch e<strong>in</strong>en DCE{<br />
Dienstnehmer
186 Systemunterstutzung fur den Dienstzugang<br />
den. Weiterh<strong>in</strong> konnen Sicherheitsaspekte die Nutzung von Komponenten e<strong>in</strong>schranken,<br />
<strong>in</strong>dem Zugri srechte vergeben werden [Gri96].<br />
5.3.3.2 Entwurfsvarianten<br />
Die genauere Betrachtung der vorab beschriebenen Interzeptionsfunktionen la t<br />
unterschiedliche Variationsmoglichkeiten fur den Entwurf e<strong>in</strong>er konkreten Interzeptorkomponente<br />
zu(siehe auch erganzend [Gri96]):<br />
Automatische Registrierung So konnte zume<strong>in</strong>en die explizite Registrierung<br />
von Dienstanbietern beim Interzeptor uber den TRADEr bzw. Broker automatischdurchgefuhrt<br />
werden, da bei diesen domanen<strong>in</strong>ternen Vermittlungs<strong>in</strong>stanzen<br />
ohneh<strong>in</strong> alle beteiligten Diensterbr<strong>in</strong>ger registriert werden sollten. Hierbei<br />
lie en sich die Dienstanbieter von entsprechendem Registrierungscode befreien,<br />
allerd<strong>in</strong>gs unter Inkaufnahmee<strong>in</strong>es E<strong>in</strong>gri s <strong>in</strong> den TRADEr bzw. Broker. Da<br />
e<strong>in</strong> solcher E<strong>in</strong>gri bei der Verwendung kommerzieller Produkte im allgeme<strong>in</strong>en<br />
nicht moglich istoder zur Notwendigkeit der E<strong>in</strong>fuhrung weiterer Zusatzkomponenten<br />
fuhrt und da die <strong>in</strong> TRADE erhobene Grundforderung ohneh<strong>in</strong> moglichst<br />
wenige E<strong>in</strong>gri e <strong>in</strong> die orig<strong>in</strong>aren Mechanismen der beteiligten Systemumgebungen<br />
verlangt, ist diese implizite Variante nicht s<strong>in</strong>nvoll e<strong>in</strong>setzbar. Stattdessen<br />
wird hier die Idee des vorab bereits kurz beschriebenen Framework bevorzugt,<br />
das e<strong>in</strong>e konsistente und transparente Erweiterung der fur den domanenubergreifenden<br />
E<strong>in</strong>satz vorgesehenen Dienstanbieter erlaubt (siehe Kapitel 6).<br />
Dynamische Proxy{Generierung Zum anderen ersche<strong>in</strong>t es s<strong>in</strong>nvoll, den<br />
Zeitpunkt der Proxy{Erzeugungunter den Aspekten Optimierung und Ressourcenschonung<br />
zuvariieren. Die moglichen Varianten werden hier gema Abschnitt<br />
3.4.2 als statisch bzw. dynamisch bezeichnet. Der statische Mechanismus, der <strong>in</strong><br />
den Abbildungen 5.14 und 5.15 gezeigt wurde, ermoglichtmaximale Transparenz,<br />
<strong>in</strong>dem bei der Verfugbarkeit e<strong>in</strong>es Dienstanbieters <strong>in</strong> der e<strong>in</strong>en Domane sofort<br />
e<strong>in</strong> konformer Stellvertreter <strong>in</strong> der anderen Domane etabliert wird. Gleichzeitig<br />
stellt dieseLosung auch e<strong>in</strong>e Optimierung fur den Zugri dar, da beie<strong>in</strong>em<br />
Operationsaufruf an Stellvertreter dieser sofort bereit steht. Andererseits kann<br />
diese Losung jedoch zue<strong>in</strong>em hohen Ressourcenaufwand fuhren, da auch fur<br />
vielleicht niemals nachgefragte Dienstanbieter Proze { und Speicherressourcen<br />
<strong>in</strong> Anspruch genommen werden. Die dynamische Variante kehrt diese Situation<br />
genau um. Der Interzeptor wird explizit durch den TRADEr bzw. Broker<br />
angesprochen, sobald diese die Anfrage nach e<strong>in</strong>em bestimmten Dienstangebot<br />
erhalten haben, welches <strong>in</strong> e<strong>in</strong>er anderen Domane angeboten wird. Erst zu diesem<br />
Zeitpunkt erzeugt er e<strong>in</strong>en entsprechenden Proxy (siehe Abbildung 5.16).<br />
Der Vorteil besteht <strong>in</strong>der Ressourcenschonung, <strong>in</strong>dem nur wirklich benotigte<br />
Proxies erzeugt werden, der Nachteil<strong>in</strong>der hoheren Antwortzeit fur den Dienstnehmer.<br />
Um hier e<strong>in</strong> moglichst hohes Ma an Flexibilitat <strong>in</strong> der Anwendbarkeit<br />
zu erreichen, ersche<strong>in</strong>t dieUnterstutzung beider Varianten generell s<strong>in</strong>nvoll.
5.3 Domanenubergreifender Dienstzugri 187<br />
2 Notify<br />
3 Lookup<br />
Broker Interzeptor TRADEr<br />
Register Create<br />
Transform<br />
1<br />
Lookup<br />
8<br />
Return<br />
7<br />
6<br />
Typ-<br />
Manager<br />
5<br />
Export<br />
CORBA-<br />
Klient<br />
B<strong>in</strong>d & Call<br />
DCE-<br />
Proxy<br />
Interception<br />
9 10<br />
Return<br />
4<br />
DCE-<br />
Server<br />
Abbildung 5.16: Dynamische Proxy{Generierung bei der Nutzung e<strong>in</strong>es DCE{<br />
Dienstes durch e<strong>in</strong>en CORBA{Dienstnehmer<br />
Ubertragung von Fremdkonzepten Weiterh<strong>in</strong> s<strong>in</strong>d Anwendungen zu<br />
berucksichtigen, die die vom Interzeptor angebotenen Abstraktionen beim<br />
domanenubergreifenden Dienstzugri nicht nutzen mochten, da sie im Gegenteil<br />
gerade darauf angewiesen s<strong>in</strong>d, im obigen S<strong>in</strong>ne domanenfremde Konzepte <strong>in</strong><br />
die andere Domane ubertragen zu mussen. Fur derartige Anwendungen s<strong>in</strong>d<br />
vom Interzeptor zusatzliche Schnittstellen anzubieten, die auch e<strong>in</strong>eInteraktion<br />
unter Beteiligung solcher Fremdkonzepte erlauben. Im Rahmen von TRADE<br />
bestand hier <strong>in</strong>sbesondere die im IWT{Projekt 14 gestellte Forderung nach der<br />
Unterstutzungder Zusammenarbeit von heterogen realisierten Tradernbzw.der<br />
dort statt ndene Interaktion von Typmanagern heterogener Domanen. Diese<br />
beiden Teilprojekte [Vog94, VBB95, MMaTT96, CMML96] bieten e<strong>in</strong> Beispiel<br />
fur die Forderung nach e<strong>in</strong>er derartigen nicht{abstrahierenden Interzeption. Hier<br />
werden beispielsweise DCE{spezi sche B<strong>in</strong>dungs<strong>in</strong>formationen vom TRADEr<br />
weitergereicht, die bei dem Trader e<strong>in</strong>er CORBA{basierten Verwaltungsdomane<br />
vorgehalten werden mussen.<br />
5.3.4 Implementationsaspekte des Interzeptors<br />
Aufbauend auf den angefuhrten Entwurfsmoglichkeiten wird im folgenden die<br />
<strong>in</strong> TRADE realisierte Interzeptionskomponente beschrieben. Die Implementation<br />
des Interzeptors erfolgte unter Nutzung von C++ und Motif. Als Middleware<br />
standen stellvertretend fur e<strong>in</strong>e CORBA{Umgebung e<strong>in</strong>e aktuelle Orbix{<br />
Implementation von IONA Technologies Ltd. [ION94] und DCEvon IBM zur<br />
Verfugung.<br />
Um bei der hier beschriebenen prototypischen Realisierung von Interzeptionsmechanismen<br />
pr<strong>in</strong>zipiell die O enheit auch gegenuber weiteren <strong>verteilten</strong> Systemplattformen<br />
zu gewahrleisten, wurde <strong>in</strong>sbesondere auf e<strong>in</strong>en hochgradig modularisierten<br />
Aufbau des Interzeptors geachtet. Die Idee der E<strong>in</strong>bettung <strong>in</strong>e<strong>in</strong>en<br />
modularen Programmier{Framework (siehe auch Abschnitt 6.1) stand ebenfalls<br />
14 siehe Abschnitt 5.2.3
188 Systemunterstutzung fur den Dienstzugang<br />
fruhzeitig fest, so da zunachst e<strong>in</strong>e C++{Klassenbibliothek erstellt wurde, die<br />
dem Programmierer immer wieder gleichartig benotigte Funktionalitat, wie beispielsweise<br />
die Kommunikation mit dem TRADEr bzw. Broker, das Erhalten<br />
von B<strong>in</strong>dungs{ und Referenz<strong>in</strong>formationen sowie die Ereignisverwaltung, auf e<strong>in</strong>heitliche<br />
Weise bereitstellt. Dabei werden sowohl die Orbix als auch die DCE{<br />
Mechanismen <strong>in</strong>nerhalb der C++{Bibliothek geme<strong>in</strong>sam berucksichtigt und <strong>in</strong><br />
e<strong>in</strong>er moglichst fur DCE und CORBA homogenen und symmetrischen Form<br />
dem Programmierer zuganglich gemacht. Gleichzeitig wurde diese Bibliothek<br />
auch fur die Entwicklung des Interzeptorkerns genutzt, so da automatisch e<strong>in</strong>e<br />
durchgangige und konsistente Sicht auf das spatere Gesamtkonzept besteht.<br />
Der Kern entsteht dabei aus den wichtigsten Bibliotheksklassen ORB server,<br />
ORB client bzw. DCE server und DCE client durchMehrfachvererbung [Gri96].<br />
Somit konnte e<strong>in</strong>ehohe Rationalitat bei der gesamten Entwicklung erreicht und<br />
auf ausgiebig getestete Software{Bauste<strong>in</strong>e zuruckgegri en werden.<br />
Der bisher realisierte Interzeptor ist als aktiver E<strong>in</strong>zelproze konzipiert und<br />
vere<strong>in</strong>t als solcher die Dienstnehmer{ und Diensterbr<strong>in</strong>gerrolle sowohl <strong>in</strong> der<br />
CORBA{ als auch <strong>in</strong>der DCE{Domane. Dadurch mu ten zur Gestaltung der<br />
Schnittstellen des Interzeptors ke<strong>in</strong>e neuen Mechanismen e<strong>in</strong>gefuhrt werden, sondern<br />
es konnten die <strong>in</strong> den entsprechenden Domanen jeweils vorhandenen verwandt<br />
werden. Diese Art der Realisierung erforderte e<strong>in</strong>e<strong>in</strong>terne mehrpfadige<br />
(engl. multi{threaded) Strukturierung des Interzeptionsprozesses mit e<strong>in</strong>em<br />
komplexen Konsistenzsicherungs{ und Priorisierungsverfahren fur die Ereignisbehandlung.<br />
Basis fur das Modul zur Ereignisbehandlungs<strong>in</strong>d die DCE{Threads,<br />
mit deren Hilfe e<strong>in</strong>e geme<strong>in</strong>same Verwaltung der Orbix{ und DCE{Events sowie<br />
der X{Events der Benutzerschnittstelle des Interzeptors realisiert wurde.<br />
Da hier der Interzeptor als zentrale Komponente e<strong>in</strong>en potentiellen Flaschenhals<br />
darstellt, wurde der Optimierung des Zeitverhaltens, <strong>in</strong>sbesondere bei der<br />
Ereignisbehandlung, besondere Aufmerksamkeit gewidmet. Allerd<strong>in</strong>gs lassen die<br />
<strong>in</strong> TRADE speziell zu unterstutzenden Kooperationsanwendungen diese Problematik<br />
ohneh<strong>in</strong> etwas unkritischer ersche<strong>in</strong>en, da sie sich aus Diensten recht<br />
hoher funktionaler Komplexitat zusammensetzen und somit der hauptsachliche<br />
Zeitbedarf eher bei der Dienstausfuhrung als bei der Kommunikation uber den<br />
Interzeptor auftritt.<br />
Weiterh<strong>in</strong> enthalt der gegenwartig realisierte Interzeptor e<strong>in</strong> eigenes, <strong>in</strong>ternes<br />
Typmanagementsystem, das alternativ zum externen Typmanager zu Testzwecken<br />
zur Untersuchung von Performanzeigenschaften dient. Die eigentliche<br />
Interaktionsfahigkeit fur die DCE{ und CORBA{Dienstnehmer bzw. {nutzer<br />
stellen die <strong>in</strong>ternen Proxy{Handler des Interzeptors bereit, die die Generierung<br />
und dieUberwachung von Proxies ubernehmen. Hierbei wurden zwei Varianten<br />
implementiert:<br />
Die DCE{Proxies, also Komponenten, die stellvertretend fur DCE{<br />
Dienstanbieter <strong>in</strong> die CORBA Domane e<strong>in</strong>gefuhrt werden, s<strong>in</strong>d eigene<br />
externe Prozesse, die selbstandig Aufgaben der Interzeption ausfuhren<br />
konnen und anderen CORBA{Dienstnehmern durch e<strong>in</strong>en E<strong>in</strong>trag im<br />
Broker auf Nachfrage zur Verfugung stehen.
5.3 Domanenubergreifender Dienstzugri 189<br />
Die CORBA{Proxies dagegen werden <strong>in</strong> der DCE{Domane sichtbar, <strong>in</strong>dem<br />
der Interzeptor sich selbst als Stellvertreter mit dem entsprechenden<br />
Diensttyp im TRADEr der DCE{Umgebung e<strong>in</strong>tragt und etwaige Aufrufe<br />
dann <strong>in</strong> e<strong>in</strong>em eigenen Thread abarbeitet.<br />
Diese Realisierung beider Varianten ermoglicht Untersuchungen und Vergleiche<br />
des Zeit{ und Ressourcenverhaltens der E<strong>in</strong>proze { gegenuber der Mehrproze<br />
losung. Steuer{ und kon gurierbar werden die Funktionen dieser Kernmodule<br />
durch e<strong>in</strong>eaufgesetzte Benutzerschnittstelle, die sowohl unterstutzende Funktionen<br />
zur Systemkon guration, wie beispielsweise die Steuerung der Sichtbarkeit<br />
von Proxies, als auch zur Erstellung von Kooperationsanwendungen (siehe den<br />
Application Builder <strong>in</strong> Kapitel 6) und deren Uberwachung und Kontrolle anbietet.<br />
Insgesamt prasentiert sich die Benutzerschnittstelle dem Benutzer mit<br />
e<strong>in</strong>er komfortablen graphischen Bedienung (siehe auch Bild 6.3). Fur die Sicherheitsmechanismen<br />
wurden ke<strong>in</strong>e eigenen Techniken implementiert, sondern die<br />
Moglichkeiten der jeweiligen Verwaltungsdomanen ausgenutzt, auf deren Grundlage<br />
e<strong>in</strong>e benutzerorientierte Vergabe von Rechten fur die Erzeugung, Aktivierung<br />
und Weitergabe von Komponenten durchgefuhrt werden kann.<br />
external<br />
G<br />
U<br />
I<br />
<strong>in</strong>ternal external<br />
Event Dispatcher<br />
Type Checker Type Checker<br />
Transformer Transformer<br />
Type Management Interface<br />
DCE Proxy<br />
Handler<br />
CORBA<br />
Head<br />
CORBA<br />
Proxy Hand<br />
DCE<br />
Head<br />
Adm<strong>in</strong>istration Interface<br />
T<br />
y<br />
p<br />
e<br />
M<br />
P<br />
r<br />
x<br />
y<br />
A<br />
d<br />
m<br />
i<br />
n<br />
Abbildung 5.17: Architektureller Aufbau des Interzeptors<br />
Zusammenfassend ergibt sich somit das obige Bild 5.17 der groben Interzeptorstruktur<br />
mit se<strong>in</strong>er Proxy{Schnittstelle, der Typmanagementschnittstelle und<br />
der Interaktionsschnittstelle. Letztere wird gleichzeitig auch zu Adm<strong>in</strong>istrationszwecken<br />
genutzt. Der Entwurf der e<strong>in</strong>zelnen Module richtet sich im S<strong>in</strong>ne e<strong>in</strong>er<br />
modernen Software{Eentwicklung nach gangigen etablierten Entwurfsmustern<br />
(engl. design patterns) [GHJV94], welches sich beispielsweise <strong>in</strong> der Anlehnung<br />
an die Muster Mediator, Bridge, Observer und Proxy sowie Acceptor, Connector<br />
und Reactor zeigt. Zur Zeit wird untersucht, ob e<strong>in</strong> eigenstandiges Interzeptor{
190 Systemunterstutzung fur den Dienstzugang<br />
Muster s<strong>in</strong>nvoll etabliert werden kann [Gri96].<br />
5.3.5 Bewertung und erganzende Anmerkungen<br />
E<strong>in</strong> unmittelbares Resultat der gestellten Anforderungen an das Interzeptionskonzept<br />
ist die Moglichkeit zur Scha ung sanfter Technologieubergange,<br />
da die beteiligten Eigenschaften der technisch unterschiedlichen Verwaltungsdomanen<br />
beibehalten werden und dennoch die Anb<strong>in</strong>dung ane<strong>in</strong>eandere Technologie<br />
moglich wird. Dieses erhoht die Akzeptanz e<strong>in</strong>es entwickelten Interzeptors<br />
und erlaubt e<strong>in</strong> Wachsen bestehender Systemlandschaften ohne abrupte<br />
technische und konzeptionelle Bruche. Hierzu tragt auch der Verzicht auf die<br />
E<strong>in</strong>fuhrung neuer plattform{ bzw. domanenubergreifender Mechanismen bei,<br />
die e<strong>in</strong>en erhohten Anpassungsaufwand <strong>in</strong>den Verwaltungsdomanen zur Folge<br />
hatten. Spezielle Anwendungen, wie beispielsweise die <strong>in</strong> Abschnitt 5.2.3 angefuhrten<br />
Trader{Kooperationen, s<strong>in</strong>d ohne die domanen<strong>in</strong>tegrierenden Konzepte<br />
des Interzeptors <strong>in</strong> dieser Form gar nicht realisierbar. Hier relativiert sich<br />
jedoch gleichzeitig auch der Vorteil der Interzeption, ke<strong>in</strong>e Fremdkonzepte<strong>in</strong>die<br />
Verwaltungsdomanen e<strong>in</strong>zubr<strong>in</strong>gen, dae<strong>in</strong>e Klasse spezieller Anwendungen diese<br />
Abstraktion zu Gunsten eigener Verarbeitungsmoglichkeiten aufgeben mu . Zudem<br />
stehen zu e<strong>in</strong>em gegebenen Zeitpunkt ohneh<strong>in</strong> nicht alle benotigten Mechanismen,<br />
beispielsweise fur die Transaktionssicherung<strong>in</strong>dem <strong>in</strong> Abschnitt 6.1.2.4<br />
vorgestellten Hotelbeispiel, plattformubergreifend zur Verfugung, so da die angestrebte<br />
hochgradige Symmetrie des Interzeptionskonzeptes nur bis zu e<strong>in</strong>er<br />
gewissen Stufe realisiert werden kann. Andererseits ist der Interzeptor selbst<br />
<strong>in</strong> der Lage, gewisse fehlende Funktionalitat e<strong>in</strong>er Domane zukompensieren.<br />
So ubernimmt er beispielsweise <strong>in</strong> TRADE fur die CORBA{Domane gewisse<br />
Trad<strong>in</strong>g{Eigenschaften, <strong>in</strong>dem er beispielsweise den dortigen Diensterbr<strong>in</strong>gern<br />
Diensttypen zuordnet.<br />
In Bezug auf die Software{Entwicklung selbst bietet die vorgestellte Art der<br />
Interzeption den besonderen Vorteil, Transformations{ und B<strong>in</strong>dungskonzepte<br />
nicht fur jeden Dienstanbieter neu entwerfen zu mussen, sondern e<strong>in</strong>en e<strong>in</strong>heitlichen<br />
geme<strong>in</strong>samen Mechanimus zur Verfugung stellen zu konnen. Hierbei<br />
hat sich die Integration des TRADErs, des CORBA{Brokers, des Typmanagers<br />
und des <strong>in</strong> Kapitel 6 beschriebenen Koord<strong>in</strong>ationmanagers mit dem entwickelten<br />
TRADE{Interzeptor <strong>in</strong> e<strong>in</strong>em umfassenden Framework als besonders fruchtbar<br />
erwiesen und bietet neuartige Moglichkeiten e<strong>in</strong>er Software{Entwicklung <strong>in</strong>heterogenen<br />
<strong>verteilten</strong> Systemumgebungen. Trotz der hohen Eigenfunktionalitat<br />
bereits dieser E<strong>in</strong>zelteile ermoglicht erst das Interzeptionskonzept e<strong>in</strong>e wesentliche<br />
Erweiterung ihrer E<strong>in</strong>satzmoglichkeiten. So ist es zwar nur s<strong>in</strong>nvoll beim<br />
gleichzeitigen E<strong>in</strong>satz entsprechender Vermittlungskomponenten e<strong>in</strong>setzbar, wie<br />
beispielsweise dem TRADEr und Broker, andererseits wird bereits fur die ubergreifende<br />
Zusammenarbeit von Tradern e<strong>in</strong> der Interzeption aquivalentes Konzept<br />
benotigt. Ebenso wird die Interaktionsfahigkeit bei der Zusammenarbeit<br />
von Typmanagern erreicht, wobei das Auslagern des Typmanagements aus dem<br />
eigentlichen Interzeptor s<strong>in</strong>nvoll ist, da diese Komponente, wie <strong>in</strong>sbesondere bei<br />
der Dienstvermittlung deutlich wurde, auch eigenstandig <strong>in</strong>nerhalb e<strong>in</strong>er Verwal-
5.3 Domanenubergreifender Dienstzugri 191<br />
tungsdomane von allgeme<strong>in</strong>em Nutzen ist. Daruberh<strong>in</strong>aus liefert die Betrachtung<br />
der fur e<strong>in</strong>en konkreten Interzeptor notwendigen Funktionalitat Aussagen<br />
uber Starken, Schwachen und fehlende Funktionen der beteiligten Verwaltungsdomanen.<br />
So konnen Erfahrungen bei der Realisierung e<strong>in</strong>es Interzeptionskonzeptes<br />
e<strong>in</strong>e direkte Migration dort verwandter Funktionalitat <strong>in</strong> entsprechend<br />
unzureichend ausgestattete Domanen zur Folge haben. E<strong>in</strong> konkretes Beispiel<br />
fur e<strong>in</strong> solches Vorgehen ware die Realisierung e<strong>in</strong>es CORBA{Traders bei Verwendung<br />
des bereits unter DCE existierenden TRADErs.<br />
Insgesamt erweist sich der so entwickelte Interzeptor <strong>in</strong> Zusammenarbeit mit<br />
dem TRADEr und dem Typmanager als tragfahige Grundlage fur die Realisierung<br />
des <strong>in</strong> dieser Arbeit geforderten Zieles e<strong>in</strong>es weitgehend une<strong>in</strong>geschrankten<br />
domanenubergreifenden Dienstzugangs. Mit ihm wird es moglich, auf e<strong>in</strong>e<br />
Vielzahl von Diensten unterschiedlicher Verwaltungsdomanen unabhangig von<br />
ihrer technischen Realisierungsgrundlage zuzugreifen. Hierdurch wird e<strong>in</strong>e wichtige<br />
Voraussetzung fur die Nutzung von <strong>in</strong> heterogenen <strong>verteilten</strong> elektronischen<br />
Markten angebotenen Diensten zur exiblen Entwicklung von o enen Kooperationsanwendungen<br />
gescha en.
Kapitel 6<br />
Entwicklung und Ausfuhrung<br />
von Kooperationsanwendungen<br />
Aufsetzend auf Kapitel 4, <strong>in</strong> dem das <strong>in</strong> dieser Arbeit verwendete, abstrakte<br />
Petri{Netz{basierte Beschreibungs{ und Ausfuhrungsmodell von Kooperationsanwendungen<br />
vorgestellt wurde, beschreibt das vorliegendeKapitel se<strong>in</strong>e konkrete<br />
Umsetzung<strong>in</strong>e<strong>in</strong>efur den Anwendungsentwickler nutzbare Entwicklungs{ und<br />
Ablaufumgebung. Grundlage hierfur bilden die im vorherigen Kapitel beschriebenen<br />
Systemdienstedes Typmanagers,des TRADErs und des Interzeptors, die<br />
<strong>in</strong> Zusammenarbeit mit den DCE{ und CORBA{Mechanismen die systemtechnische<br />
Unterstutzung fur den Dienstzugang <strong>in</strong> TRADE bereitstellen. Mit ihrer<br />
Hilfe kann e<strong>in</strong> Anwendungsprogrammierer potientiell auf e<strong>in</strong>e gro e Anzahl<br />
von verschiedenartigen Diensten im S<strong>in</strong>ne e<strong>in</strong>es <strong>verteilten</strong> Systembaukastens von<br />
Diensten [MML95d, MML95e, GML96] zugreifen. Diese Dienste konnen dann im<br />
Rahmen der Entwicklungkomplexer Anwendungsvorgange <strong>in</strong>nerhalb von Kooperationsanwendungen<br />
beliebig mite<strong>in</strong>ander komb<strong>in</strong>iert werden, wobei es generell<br />
ke<strong>in</strong>e Rolle spielt, auf welcher konkreten <strong>verteilten</strong> Systemplattform die Dienste<br />
angeboten werden. So s<strong>in</strong>d beispielsweise aus e<strong>in</strong>er DCE{Verwaltungsdomane<br />
heraus uber den Interzeptor auch die <strong>in</strong> e<strong>in</strong>er CORBA{basierten Verwaltungsdomane<br />
angebotenen Dienste nutzbar. Dieses gilt auch umgekehrt fur die Nutzung<br />
von DCE{Diensten <strong>in</strong> e<strong>in</strong>er CORBA{Verwaltungsdomane. Um nun konkret<br />
verteilte Kooperationsanwendungen mit ihren Anwendungsvorgangen spezi<br />
zieren zu konnen, stellt TRADE auf Basis der Ausfuhrungsumgebung e<strong>in</strong>e<br />
<strong>in</strong>tegrierte Entwicklungsumgebung zur Verfugung. Zusatzlich wird die TRADE{<br />
Ausfuhrungsumgebung um Systemmechanismen zur Dienstkoord<strong>in</strong>ation (siehe<br />
auch Abbildung 4.13) erganzt, welche die Ausfuhrung von Kooperationsanwendungen<br />
durchentsprechendeKoord<strong>in</strong>ationsmechanismen <strong>in</strong> Form e<strong>in</strong>es sogenannten<br />
Koord<strong>in</strong>ationsmanagers systemtechnisch unterstutzen.<br />
Im folgenden wird zunachst auf die Entwicklungsumgebung e<strong>in</strong>gegangen und der<br />
dort entwickelte Programmier{Framework erlautert. Hierbei wird <strong>in</strong>sbesondere<br />
die <strong>in</strong> dieser Arbeit entwickelte Koord<strong>in</strong>ationssprache PAMELA, die e<strong>in</strong>e programmiersprachliche<br />
Umsetzung des abstrakten Petri{Netz{basierten Anwen-
194 Entwicklung und Ausfuhrung von Kooperationsanwendungen<br />
dungsmodells realisiert, beispielhaft vorgestellt und zwei verschiedene Moglichkeiten<br />
ihrer Verwendung verdeutlicht. In diesem Zusammenhang wird auch auf<br />
den <strong>in</strong> TRADE entwickelten Application Builder e<strong>in</strong>gegangen, der e<strong>in</strong>e Erstellung<br />
von Kooperationsanwendungen nach dem " Plug <strong>in</strong> and play\{Pr<strong>in</strong>zip<br />
ermoglicht. Im Anschlu wird <strong>in</strong> Abschnitt 6.2 der Koord<strong>in</strong>ationsmanager <strong>in</strong><br />
se<strong>in</strong>en Details vorgestellt. Dieser ubernimmt die Aufgaben der Dienstkoord<strong>in</strong>ation<br />
<strong>in</strong> der TRADE{Ausfuhrungsumgebung und erlaubt e<strong>in</strong>e direkte Umsetzung<br />
e<strong>in</strong>er PAMELA{Anwendungsbeschreibung <strong>in</strong> e<strong>in</strong> ausfuhrbares Anwendungsprogramm.<br />
6.1 TRADE{Entwicklungsumgebung<br />
Die von TRADE vorgeschlageneund realisierte Entwicklungsumgebungla t sich<br />
grob <strong>in</strong> e<strong>in</strong>en Bereich fur die Erstellung von e<strong>in</strong>zelnen Diensten und <strong>in</strong>e<strong>in</strong>en zur<br />
Systemerstellung bzw. zur Entwicklung von Kooperationsanwendungen unterteilen.<br />
6.1.1 Diensterstellung<br />
Fur die Erstellung e<strong>in</strong>zelner Dienste steht <strong>in</strong> TRADE neben den von den Systemplattformen<br />
DCE und CORBA angebotenen Programmierwerkzeugen, <strong>in</strong>sbesondere<br />
den dortigen IDL{Sprachubersetzern und Programmierbibliotheken<br />
[OSF93a, ION94] ubergeordnete C++{Klassenbibliotheken fur beide Plattformen<br />
zur Verfugung. Diese vere<strong>in</strong>fachen die Programmierung e<strong>in</strong>zelner Dienste<br />
ma geblich, <strong>in</strong>dem sie den Programmierer vor allem von den <strong>in</strong> der Regel umfangreichen<br />
Initialisierungsvorgangen befreien. Zum e<strong>in</strong>en ermoglichen sie e<strong>in</strong>e<br />
vergleichsweise e<strong>in</strong>fache Nutzung der vom Typmanager, TRADEr, Interzeptor<br />
und vom Koord<strong>in</strong>ationsmanager bereitgestellten Dienste, <strong>in</strong>dem sie unter anderem<br />
den im allgeme<strong>in</strong>en komplexen Aufbauder zum Austauschvon Diensttypbeschreibungen<br />
benotigten Typreprasentation, den Ex{ bzw. Import von Dienstangeboten<br />
an den TRADEr und die Registration von Dienstangeboten beim Interzeptor<br />
unterstutzen. Weiterh<strong>in</strong> stellen sie auch Methoden bereit, mit denen e<strong>in</strong>e<br />
transaktionale Ausfuhrung von Diensterbr<strong>in</strong>gern <strong>in</strong> e<strong>in</strong>er DCE{Domanemoglich<br />
ist. Hierbei werden ebenfalls die im allgeme<strong>in</strong>en komplizierten Initialisierungsvorgange<br />
des im Rahmen von TRADE genutzten, auf DCE aufsetzenden Enc<strong>in</strong>a{<br />
Transaktionspaketes [IBM93] weitgehend vor dem Anwendungsentwickler verborgen.<br />
Diese <strong>in</strong> [Gri96, Bri95, Mul96, Spr96, CM96, Gre95] ausfuhrlich beschriebenen<br />
Klassenbibliotheken s<strong>in</strong>d Bestandteil e<strong>in</strong>es durch TRADE realisierten<br />
neuartigen Programmier{Framework. 1 Grundlegende Idee des Programmier{<br />
Framework ist es, die Erstellung von E<strong>in</strong>zeldiensten trotz technisch heterogener<br />
Verteilungsplattformen unter e<strong>in</strong>em geme<strong>in</strong>samen konsistenten Konzept ersche<strong>in</strong>en<br />
zu lassen und e<strong>in</strong>ekomplette Entwicklungsumgebung fur die System{ bzw.<br />
Anwendungserstellung mit Entwicklungs{ und Laufzeitsystem bereitzustellen. Er<br />
1 Fur e<strong>in</strong>e generelle De nition des Begri es Framework siehe unter anderem [Ber93] und<br />
[Ber95].
6.1 TRADE{Entwicklungsumgebung 195<br />
besteht zume<strong>in</strong>en aus den aktiven Komponenten der TRADE{Ausfuhrungsumgebung<br />
|Typmanager, TRADEr, Interzeptor, CORBA{Broker und Koord<strong>in</strong>ationsmanager<br />
| und zumanderen aus den erwahnten Klassenbibliotheken, die<br />
die passiven Komponenten des Framework bilden.<br />
Insgesamt realisiert der TRADE{Programmier{Frameworkdamit e<strong>in</strong>e <strong>in</strong>tegrierteEntwicklungs{<br />
und Ausfuhrungsumgebung, die e<strong>in</strong>e e ziente Realisierung von<br />
neuen Kooperationsanwendungen und e<strong>in</strong>zelnen Diensten ermoglicht. Hierbei<br />
wird der Programmier{Framework nicht nur fur die Erstellung von Anwendungen<br />
genutzt, sondern bietet gleichzeitig auch die Grundlage fur die Entwicklung<br />
der TRADE{Basisdienste selbst. So nutzt beispielsweise der Interzeptor<br />
die angebotenen Bibliotheksklassen ORB server, ORB client bzw. DCE server<br />
und DCE client [Gri96], die die fur se<strong>in</strong>e Registrierung <strong>in</strong> CORBA und DCE<br />
notwendigen Initialisierungsschritte ausfuhren (siehe auch Abschnitt 5.3.4).<br />
E<strong>in</strong> wichtiger Bestandteil des Programmier{Framework ist die Bereitstellung e<strong>in</strong>es<br />
Kommunikationskonzeptes, um beliebige, <strong>in</strong> der Regel zum Kompilationszeitpunkt<br />
e<strong>in</strong>er Anwendung unbekannteDatenstrukturen ubergeben und Operationsaufrufe<br />
ausfuhren zu konnen. Dieses wird <strong>in</strong>nerhalb von TRADE durch die<br />
Realisierung e<strong>in</strong>es Dynamic Invocation Interface (DII) bereitgestellt, das e<strong>in</strong>e<br />
typattributierte Ubergabe beliebiger Daten erlaubt. In der auf Orbix aufsetzenden<br />
CORBA{Domane [ION94] ist e<strong>in</strong> solcher Mechanismus gema der CORBA{<br />
Spezi kation [OMG91] bereits vorhanden, wahrend erfur die DCE{Domane |<br />
sich ebenfalls am CORBA Vorschlag orientierend |neu implementiert wurde<br />
[Bri95,Gri96]. Um hier fur die Implementierungsowohl <strong>in</strong> DCE als auch CORBA<br />
e<strong>in</strong>e e<strong>in</strong>heitliche Programmmierungschnittstelle zu scha en, wurden die jeweiligen<br />
Implementierungen von e<strong>in</strong>er sogenannte Wrapper{Klasse umgeben, so da<br />
ihre Unterschiede bei der Anwendungsprogrammierung weitgehend verborgen<br />
bleiben. Verwendung ndet das DII bei samtlichen im Zusammenhang mit dem<br />
Interzeptor und dem Koord<strong>in</strong>ationsmanager durchgefuhrten Interaktionen.<br />
6.1.2 Entwicklung von Kooperationsanwendungen mittels der<br />
Koord<strong>in</strong>ationssprache PAMELA<br />
Zum Erreichen des <strong>in</strong> dieser Arbeit verfolgten Ziels der Erstellung von <strong>verteilten</strong><br />
Anwendungen unter weitestgehender oder sogar ausschlie licher Nutzung<br />
externer Dienste s<strong>in</strong>d geeignete Ausdrucksmittel zu entwickeln, mit denen<br />
die <strong>Dienstnutzung</strong> imRahmen verteilter kooperativer Anwendungen darstellbar<br />
ist. Zu diesem Zweck wurde <strong>in</strong> Kapitel 4 das <strong>in</strong> dieser Arbeit entwickelte<br />
Beschreibungs{ und Ausfuhrungsmodell von Kooperationsanwendungen vorgestellt.<br />
Dieses ermoglichte<strong>in</strong>e abstrakte vorgangsorientierte Sicht auf die Nutzung<br />
von Diensten im Rahmen von Anwendungsvorgangen. Formale Grundlage fur<br />
die Beschreibung von Anwendungsvorgangen bilden Petri{Netze, die h<strong>in</strong>sichtlich<br />
der von Kooperationsanwendungen geforderten Beschreibungskonzepte um<br />
entsprechende Darstellungsmittel erweitert wurden (siehe Abschnitt 4.2.3).<br />
Um diesen formalen Beschreibungsansatz nun <strong>in</strong>e<strong>in</strong>efur den Anwendungsprogrammierer<br />
unmittelbar nutzbare Form zu uberfuhren, ist die Bereitstellung ei-
196 Entwicklung und Ausfuhrung von Kooperationsanwendungen<br />
ner konkreten Programmiersprache erforderlich, die e<strong>in</strong>e Verknupfung zue<strong>in</strong>er<br />
realen Systemumgebung ermoglicht. Erst hierdurch konnen spezi zierte Anwendungsvorgange,<br />
beispielsweise bei Verwendung e<strong>in</strong>es bestimmten Datentypmodells<br />
(siehe auch Abschnitt 4.2.3.1), <strong>in</strong>e<strong>in</strong>er spezi schen Systemumgebung zur<br />
Ausfuhrung gebrachtwerden. Das Schlie en dieser Lucke zwischen dem abstrakten<br />
Beschreibungsmodell und e<strong>in</strong>er bestimmten Ausfuhrungumgebung wird <strong>in</strong><br />
diesem Abschnitt konkret am Beispiel der TRADE{Systemumgebung und der<br />
Koord<strong>in</strong>ationssprache PAMELA 2 [MML95d, MML95e, Gri95] verdeutlicht.<br />
6.1.2.1 Zielstellung und Entwurfsentscheidungen<br />
Ziel des Sprachentwurfs von PAMELA war die Bereitstellung von Ausdrucksmitteln,<br />
mit denen die koord<strong>in</strong>ierte Nutzung von <strong>in</strong> o enen <strong>verteilten</strong> Dienstemarkten<br />
angebotenen bzw. <strong>in</strong> Entwicklung be ndlichen Dienstangeboten <strong>in</strong>nerhalb<br />
von Anwendungsvorgangen adaquat beschrieben werden kann. Konzeptionelle<br />
Grundlage hierfur bildet das oben erwahnte, auf erweiterten Petri{Netzen<br />
basierende Modell von Kooperationsanwendungen und Anwendungsvorgangen.<br />
Zusatzlich wurden im Sprachentwurf auch Randbed<strong>in</strong>gungen berucksichtigt, die<br />
sich aus der unmittelbaren Nutzung von DCE und CORBA als Realisierungsgrundlage<br />
von TRADE ergaben und somit nicht direkt aus dem Anwendungsmodell<br />
ersichtlich s<strong>in</strong>d. Dieses betri t <strong>in</strong>sbesondere die Verwendung der CORBA{<br />
IDL als Diensttypbeschreibungssprache, auf deren Integration <strong>in</strong> PAMELA im<br />
folgenden noch genauer e<strong>in</strong>gegangen wird.<br />
Wie bereits <strong>in</strong> Kapitel 4 ausfuhrlich erlautert wurde, stellen Petri{Netze als Darstellungsmittel<br />
von Nebenlau gkeit und Synchronisation e<strong>in</strong>e geeignete Grundlage<br />
fur die Beschreibung von Anwendungsvorgangen dar. Mit ihnen ist die Intra{<br />
und Intervorgangsnebenlau gkeit von Anwendungsvorgangen auf <strong>in</strong>tuitive und<br />
e<strong>in</strong>fache Artund Weise beschreibbar. Durch diese Integration <strong>in</strong> e<strong>in</strong>er Beschreibungsform<br />
kann der konzeptuelle Bruch vermieden werden, der im allgeme<strong>in</strong>en<br />
bei der E<strong>in</strong>fuhrung von Nebenlau gkeits{ und Synchronisationskonzepten <strong>in</strong><br />
herkommlichen sequentiellen Beschreibungsansatzen auftritt. Hierdurch wird e<strong>in</strong><br />
hohes Abstraktionsniveau fur den Anwendungsentwickler bei der Beschreibung<br />
von Anwendungsvorgangen erreicht. Unterstutzt wird dieses dadurch, da beispielsweise<br />
mit der <strong>in</strong> dieser Arbeit und konkret <strong>in</strong> PAMELA gewahlten Petri{<br />
Netz{basierten Darstellungsweise von Anwendungsvorgangen e<strong>in</strong>e vollstandige<br />
Trennung ihrer koord<strong>in</strong>ativen undverarbeitungsbezogenen Aspekteerreichtwird.<br />
PAMELA{Programme spezi zieren deshalb ausschlie lich Koord<strong>in</strong>ationsaspekte,<br />
wahrend die Beschreibung und Realisierung der eigentlichen anwendungsspezi<br />
schen Berechnungsfunktionalitat <strong>in</strong> den Diensten verborgen ist und beispielsweise<br />
unter Nutzung der <strong>in</strong> TRADE angebotenen C++{Klassenbibliotheken des<br />
Programmier{Framework erfolgen kann. Aus diesem Grund wirdPAMELA <strong>in</strong><br />
Anlehnung an [GC92] auch als e<strong>in</strong>e Koord<strong>in</strong>ationssprache bezeichnet.<br />
Angestrebt wird weiterh<strong>in</strong> e<strong>in</strong>e moglichst weitgehende Abstraktion von den unterliegenden<br />
Systemmechanismen der TRADE{Ausfuhrungsumgebung, um von<br />
2 Petri net based Activity Management Execution Language
6.1 TRADE{Entwicklungsumgebung 197<br />
dem <strong>verteilten</strong> Charakter e<strong>in</strong>er Kooperationsanwendung zuabstrahieren und e<strong>in</strong>e<br />
e<strong>in</strong>heitliche Nutzung der <strong>in</strong> TRADE angebotenen Anwendungs{ und Systemdienste<br />
zu erlauben. Hierdurch wird e<strong>in</strong>e der <strong>in</strong> TRADE ubergeordnet verfolgten<br />
Zielstellungen nach Verteilungsabstraktion erfullt (siehe auch Kapitel 1). Hierzu<br />
mussen <strong>in</strong> Anlehnung an[Tol94] <strong>in</strong>sbesondere die folgenden vier Heterogenitatsaspektevon<br />
o enen heterogenen <strong>verteilten</strong> Systemumgebungen bzw. Dienstemarkten<br />
adaquat behandelt werden:<br />
die Heterogenitat der Rechnerarchitekturen undder sie verb<strong>in</strong>denden Netzwerktechnologien,<br />
die Heterogenitat der e<strong>in</strong>gesetzen Programmiersprachen, die zur Realisierung<br />
der genutzten Dienste verwandt wurden,<br />
die Heterogenitat der bearbeiteten Informationen, beispielsweise numerische<br />
Daten, Texte oder Multimedia{Dokumente, und<br />
die Heterogenitat der Struktur e<strong>in</strong>er komplexen Anwendung, <strong>in</strong> der beispielsweise<br />
Teilkomponenten unvorhergesehen und plotzlichnicht mehr zur<br />
Verfugung stehen konnen.<br />
Samtliche dieser aufgefuhrten Aspekte werden im vorliegenden PAMELA{<br />
Sprachentwurf durch das der TRADE{Systemumgebung unterliegende <strong>Dienstnutzung</strong>sparadigma<br />
<strong>in</strong>e<strong>in</strong>em e<strong>in</strong>zigen Konzept behandelt. PAMELA bietet jedoch<br />
nicht nur die Abstraktion von Heterogenitatsproblemen, sondern verbirgt<br />
auch die | trotz des Vorhandense<strong>in</strong>s der im vorherigen Abschnitt vorgestellten<br />
und vergleichsweise e<strong>in</strong>fach zuhandhabenden Klassenbibliothek | im allgeme<strong>in</strong>en<br />
hohe Programmierkomplexitat bei der Nutzung der <strong>in</strong> TRADE entwickelten<br />
Systemdienste. Erreicht wird dieses durch die Bereitstellung e<strong>in</strong>es generischen<br />
Koord<strong>in</strong>ationsmanagers, der samtliche mit diesen Systemdiensten durchzufuhrenden<br />
Interaktionen auf der Grundlage des PAMELA{Beschreibung automatisch<br />
abwickelt (siehe Abschnitt 6.2).<br />
6.1.2.2 Sprachkonzepte<br />
Das Pr<strong>in</strong>zip von PAMELA, ausschlie lich die Koord<strong>in</strong>ation von Diensten zu beschreiben,<br />
ist e<strong>in</strong>es ihrer wesentlichen Hauptmerkmale. Daruberh<strong>in</strong>aus zeichnet<br />
sich PAMELA durch folgende weitere Eigenschaften aus:<br />
die sprachliche Umsetzung des auf gefarbten Petri{Netzen basierenden<br />
Anwendungsmodells mit Erweiterungen h<strong>in</strong>sichtlich des Dienstkonzeptes�<br />
um bei der Beschreibung von Anwendungsvorgangen generell den Bezug<br />
zu Petri{Netzen weiterh<strong>in</strong> beizubehalten, wurde die Syntax von PAME-<br />
LA moglichst wenig abstrakt, sondern durch e<strong>in</strong>e aus dem Englischen<br />
stammende Wortwahl leichtverstandlich und anwendungsorientiert gehalten.<br />
Hierdurch bleiben fur den Anwendungsprogrammierer auch komplexe<br />
Anwendungsvorgange durch die Moglichkeit der Abbildung der PAMELA{<br />
Beschreibung auf e<strong>in</strong>e graphische Petri{Netz{Darstellung durchschaubar�
198 Entwicklung und Ausfuhrung von Kooperationsanwendungen<br />
die E<strong>in</strong>bettung der <strong>in</strong> o enen <strong>verteilten</strong> Systemen etablierten IDL{<br />
Beschreibungen von Diensterbr<strong>in</strong>gern, im speziellen der CORBA{IDL zur<br />
De nition von Diensttypen (d. h. Schnittstellentypen, Operationstypen,<br />
Attributtypen und Datentypen),<br />
die Spezi kation von Aktivitatsemantiken, wie beispielsweise synchrone,<br />
asynchrone und transaktionale Ausfuhrung von Aktionen <strong>in</strong>nerhalb von<br />
Aktivitaten� das hierbei verwendete dienstorientierte Aktionskonzept von<br />
PAMELA ist angelehntandas ebenfalls auf der Grundlage gefarbter Petri{<br />
Netze entwickelte LOOPN [Lak92]�<br />
die Darstellung parallel oder sequentiell auszufuhrender Aktionen <strong>in</strong>nerhalb<br />
e<strong>in</strong>er Aktivitat und<br />
die Beschreibung externer, synchroner und asynchroner Benutzer<strong>in</strong>teraktionen,<br />
die von au en an e<strong>in</strong>en laufenden Anwendungsvorgang herangetragen<br />
werden.<br />
Die IDL{Integration stellt hierbei fur den Sprachentwurf e<strong>in</strong>en wichtigen Aspekt<br />
dar, da soe<strong>in</strong>hoher Integrationsgrad mit den bereits von DCE und CORBA<br />
angebotenen Dienstbeschreibungskonzepten erreicht werden kann. In PAMELA<br />
spiegelt sichdiesesunmittelbar <strong>in</strong> der Anlehnung der Sprache an die bereits <strong>in</strong><br />
der CORBA{IDL gewahlten syntaktischen Konstrukte wider, die der Programmiersprache<br />
C++ahneln. Dieses betri t sowohl Datentypde nitionen als auch<br />
die Wahl der Kontrollkonstrukte, <strong>in</strong>sbesondere aber die Art des Aufrufs externer<br />
Dienste <strong>in</strong>Form von Operationen. Die grundlegendeIdee dieser IDL{Integration,<br />
<strong>in</strong>sbesondere der konkret durchgefuhrten Integration der CORBA{IDL, besteht<br />
zum e<strong>in</strong>en dar<strong>in</strong>, e<strong>in</strong>e homogene Basis fur die Beschreibung von Diensten zu<br />
erhalten.Sokonnen <strong>in</strong> CORBA{IDL verfa te Diensttypbeschreibungen direkt<br />
<strong>in</strong> PAMELA{Programmen wiederverwendet werden. Zum anderen kann hiermit<br />
auch ausgenutzt werden, da mit Hilfe der IDLs gleichzeitig auch automatisch<br />
Programmkode generiert werden kann, wie es konkret <strong>in</strong> DCE und CORBA<br />
fur die Generierung von RPC{Programmierkoderumpfen (engl. stubs) zum Aufruf<br />
und zur Entgegennahmeentfernter Prozeduraufrufe verwendet wird. In e<strong>in</strong>er<br />
PAMELA{Beschreibung werden diese IDLs au erdem dazu benutzt, entsprechende<br />
Operationsaufrufe zum Zugri auf den Koord<strong>in</strong>ationsmanager zu generieren,<br />
die Voraussetzung fur e<strong>in</strong>e anschlie ende Anwendungsausfuhrung s<strong>in</strong>d.<br />
Diese Integration vorhandener Dienstbeschreibungen<strong>in</strong>PAMELA und die anschlie<br />
ende Referenzierung<strong>in</strong>den Aktivititaten e<strong>in</strong>es Anwendungsvorganges mittels<br />
des dienstorientierten Aktionskonzeptes ist e<strong>in</strong>es der wesentlichen Unterschiede<br />
zuvergleichbaren Ansatzen zur Beschreibung von Vorgangen <strong>in</strong> anderen<br />
Anwendungsbereichen. Beispiele hierfur s<strong>in</strong>d <strong>in</strong>sbesondere die aus dem Umfeld<br />
des Work ow{Managementsund der Transaktionsverarbeitungstammende Aktivitatenbeschreibungssprache<br />
ActSpec [Rei93], die Distributed Operation Language<br />
[HAB + 92] und die im ConTract{Modell [WR91] verwandte De nitionssprache.<br />
Diese ermoglichen jeweils die Beschreibungvon Vorgangen <strong>in</strong> ahnlicher Form<br />
wie die <strong>in</strong> dieser Arbeit speziell betrachteten Anwendungsvorgange. Analog zum
6.1 TRADE{Entwicklungsumgebung 199<br />
<strong>in</strong> dieser Arbeit gewahlten Ansatz werden dort oftmals ebenso zur Reprasentation<br />
von Vorgangen, beispielsweise im ConTract{Modell oder im FlowMark{<br />
System [LR94], Petri{Netz{basierte Modelle verwendet. E<strong>in</strong>e E<strong>in</strong>schrankung<br />
aller genannten Ansatze ist jedoch, da sie ke<strong>in</strong>e explizite Unterstutzung der<br />
fur Kooperationsanwendungen notwendigen Dienstsicht bieten. Insbesondere die<br />
Dienstauswahl bzw. die Abstraktion von e<strong>in</strong>em konkreten Diensterbr<strong>in</strong>ger ndet<br />
bei ihnen ke<strong>in</strong>e oder nur e<strong>in</strong>e sehr rudimentare Berucksichtigung. So ist beispielsweise<br />
<strong>in</strong>nerhalb der Distributed Operation Language nur e<strong>in</strong>e Zuweisung<br />
von Diensterbr<strong>in</strong>gern zu e<strong>in</strong>em Vorgang vor Beg<strong>in</strong>n se<strong>in</strong>er Ausfuhrung moglich.<br />
Hierdurch ergibt sich e<strong>in</strong>estarre Struktur der im Anwendungsverlauf genutzten<br />
Diensterbr<strong>in</strong>ger, bei der auf Veranderungen, beispielsweise beim Ersche<strong>in</strong>en neuer<br />
leistungsfahigerer Dienstanbieter, entweder nicht reagiert werden kann oder<br />
der Vorgang erneut unter expliziter Angabe anderer Diensterbr<strong>in</strong>ger gestartet<br />
werden mu . Hier weist das <strong>in</strong> PAMELA umgesetzte dienstorientierte Aktionskonzept<br />
e<strong>in</strong>en wesentlichen Vorteil auf, da ese<strong>in</strong>en hohen Grad an Flexibilitat<br />
bei der Anwendungsausfuhrung durch Unterstutzunge<strong>in</strong>er dynamischen Dienstauswahl<br />
gewahrleistet.<br />
Mit den oben beschriebenen Eigenschaften erfullt PAMELA alle <strong>in</strong> Abschnitt<br />
4.1.2 gestellten Anforderungen zur Beschreibung koord<strong>in</strong>ierter <strong>Dienstnutzung</strong><br />
im Rahmen verteilter kooperativer Anwendungen:<br />
Strukturierungskonzept Grundlegende Strukturierungse<strong>in</strong>heit <strong>in</strong> PAMELA<br />
s<strong>in</strong>d sogenannte Prozesse. E<strong>in</strong> Proze be<strong>in</strong>haltet hierbei die gesamte Beschreibung<br />
e<strong>in</strong>es Anwendungsvorganges und kapselt ihn von der Beschreibung<br />
anderer Anwendungsvorgangeab. Letztendlichhandelt essich hierbei<br />
um die unmittelbare textuelle programmiersprachliche Umsetzung des <strong>in</strong><br />
Abschnitt 4.2dargestellten erweiterten Petri{Netzes, <strong>in</strong>dem die Elemente<br />
e<strong>in</strong>es Petri{Netzes, d.h. Stellen, Transitionen und Kanten, durch entsprechende<br />
Sprachkonstrukte spezi zierbar s<strong>in</strong>d.<br />
Datenkonzept Die Umsetzung des Datenkonzeptes erfolgt <strong>in</strong> PAMELA<br />
durch dieVerwendung des Typsystems der CORBA{IDL fur die Typisierung<br />
der im Petri{Netz{Modell enthaltenen Marken. Hierdurch wird<br />
der konkrete Bezug des bisher abstrakten Beschreibungsansatzes zur<br />
TRADE{Systemumgebung und der zugrundeliegenden CORBA{ bzw.<br />
DCE{Systemplattform hergestellt.<br />
Aktions{ und Transaktionskonzept Zur Beschreibung der <strong>Dienstnutzung</strong><br />
<strong>in</strong>nerhalbder Aktivitaten e<strong>in</strong>es Anwendungsvorganges bietet PAMELA die<br />
sprachliche Umsetzung des Transitionskonzeptes von Petri{Netzen. Dieses<br />
geschieht <strong>in</strong>Form des oben bereits genannten dienstorientierten Aktionskonzeptes<br />
(siehe auch Abschnitt 4.2.3.3), das die Spezi kation von Operationsaufrufen<br />
zum Zugri auf die im Rahmen e<strong>in</strong>er Aktivitat bzw. Aktion<br />
genutzten Dienste erlaubt. Die Auswahl e<strong>in</strong>es hierfur gewunschten Dienstangebotes<br />
wird durch die Angabe von quali zierenden Dienstattributen<br />
unterstutzt, die als Grundlage fur die spatere Dienstvermittlung durch den<br />
<strong>in</strong> der TRADE{Systemumgebung realisierten TRADEr dienen. Durch ent-
200 Entwicklung und Ausfuhrung von Kooperationsanwendungen<br />
sprechende Deklaration e<strong>in</strong>er Aktivitat als transaktional kann auch auf<br />
e<strong>in</strong>fache Weise e<strong>in</strong>e transaktionale Ausfuhrung samtlicher der <strong>in</strong> ihr durchzufuhrenden<br />
Operationsaufrufe erreicht werden.<br />
Fehlerbehandlungskonzept Die Behandlung von Fehlern bei der Aktivitatsausfuhrung<br />
wird entsprechend der geforderten Ausfuhrungssemantik |<br />
transaktional oder nicht{transaktional | durch e<strong>in</strong>e Deklaration von speziellen<br />
Ausgangsstellen e<strong>in</strong>er Transition erreicht (siehe auch Abschnitt<br />
4.2.3.6).<br />
Kontroll u { und Nebenlau gkeitskonzept Durch die Deklaration von<br />
Stellen, Transitionen, E<strong>in</strong>{ und Ausgangskanten und Kantenausdrucken<br />
<strong>in</strong> e<strong>in</strong>em PAMELA{Proze erfolgt bereits implizit die Darstellung der<br />
Intra{ und Intervorgangsnebenlau gkeit von Anwendungsvorgangen und<br />
den dort ablaufenden Kontroll ussen. Weiterh<strong>in</strong> ist <strong>in</strong> PAMELA auch<br />
<strong>in</strong>nerhalb der Aktivitaten e<strong>in</strong>es Anwendungsvorganges die Spezi kation<br />
e<strong>in</strong>er nebenlau gen oder sequentiellen Ausfuhrung von Operationsaufrufen<br />
moglich.<br />
Interaktionskonzept Die Unterstutzung des Interaktionskonzeptes geschieht<br />
<strong>in</strong> PAMELA mittels ausgezeichneter Transitionen, den sogenannten Task{<br />
Transitionen. Diese ermoglichen die Beschreibung von Benutzer<strong>in</strong>teraktionen<br />
gema der <strong>in</strong> Abschnitt 4.2.3.7 festgelegten Ablaufsemantik.<br />
Im e<strong>in</strong>zelnen bietet PAMELA fur jedes der obigen Beschreibungskonzepte e<strong>in</strong>e<br />
entsprechende sprachliche Umsetzung. Im folgenden sollen die Sprachelemente<br />
anhand e<strong>in</strong>es Beispiels <strong>in</strong>formell e<strong>in</strong>gefuhrt und ihre Ausdrucksmoglichkeiten<br />
zur Beschreibung von Anwendungsvorgangen exemplarisch verdeutlicht werden.<br />
E<strong>in</strong>e detaillierte Darstellung der vollstandigen Syntax von PAMELA und ihrer<br />
Semantik gibt Anhang A.1. In Anhang A.2 ist au erdem e<strong>in</strong> umfangreiches,<br />
<strong>in</strong> sich abgeschlossenes PAMELA{Beispiel e<strong>in</strong>er Hotelanwendung dargestellt.<br />
Auf dieses Hotelbeispiel geht Abschnitt 6.1.2.4 noch genauer e<strong>in</strong>. Weiterh<strong>in</strong> sei<br />
auch auf [Bri95] und [Gri95] verwiesen, <strong>in</strong> denen sich neben der Erlauterung von<br />
PAMELA{Sprachkonzepten erganzende Anmerkungen vor allem h<strong>in</strong>sichtlich der<br />
Implementation des zu PAMELA gehorenden Sprachubersetzers und des Koord<strong>in</strong>ationsmanagers<br />
nden.<br />
6.1.2.3 PAMELA{Beispielspezi kation e<strong>in</strong>es <strong>verteilten</strong> kooperativen<br />
Anwendungsvorganges<br />
Abbildung 6.1 zeigt e<strong>in</strong>e e<strong>in</strong>fache PAMELA{Spezi kation e<strong>in</strong>er Versicherungsanwendung.<br />
Im Verlaufe des gezeigten Ausschnittes e<strong>in</strong>es Anwendungsvorganges<br />
<strong>in</strong> e<strong>in</strong>er Versicherung werden mehrere externe Dienste <strong>in</strong> Anspruch genommen,<br />
wie beispielsweise der e<strong>in</strong>es Sachbearbeiters zur E<strong>in</strong>gabe von Daten oder<br />
die Nutzung e<strong>in</strong>es Druckers zur Ausfertigung e<strong>in</strong>er Bestatigung fur den Versicherungskunden.<br />
Der Ablauf wird <strong>in</strong>nerhalb e<strong>in</strong>es process{Blocks dargestellt.<br />
Dieser klammert die De nition der Aktivitaten (trans), der Aktivitatsubergange
6.1 TRADE{Entwicklungsumgebung 201<br />
JobPool<br />
cust<br />
userInput<br />
ReadyToCompute<br />
computeBill<br />
module Insurance_Service {<br />
typedef unit_t ...; typedef task_t ...;<br />
struct policy_data_t {<br />
customer_id customer;<br />
name_t name; ...<br />
} ;<br />
readonly attribute unit_t unit;<br />
readonly attribute task_t task;<br />
<strong>in</strong>terface Employee {<br />
Add_Insurance_Data ([<strong>in</strong>out] policy_data_t customer);<br />
}; //CORBA <strong>in</strong>terface<br />
}; //CORBA module<br />
process PartOfInsurance {<br />
import : service Insurance_Service with Employee;<br />
token job_t {<br />
long job_nr;<br />
Insurance: policy_data_t policy;<br />
};<br />
places : job_t JobPool, ReadyToCompute; ...<br />
trans userInput {<br />
get cust from JobPool;<br />
put cust to ReadyToCompute;<br />
action {<br />
Add_Insurance_Data (cust.policy);<br />
us<strong>in</strong>g Employee with {unit = Insurance && task = Bill<strong>in</strong>g};<br />
} ...<br />
} } //process<br />
pr<strong>in</strong>tAck<br />
Abbildung 6.1: Ausschnitt e<strong>in</strong>er PAMELA{Vorgangsbeschreibung<br />
bzw. Stellen (place) und der Marken (token), welche von Aktivitat zu Aktivitat<br />
uber die Aktivitatsubergange weitergegeben werden. Die <strong>in</strong> der Abbildung<br />
beschriebene Aktivitat userInput entnimmt hierbei e<strong>in</strong>e Marke von dem<br />
Aktivitatsubergang JobPool (get{Anweisung) und fuhrt die Aktion (action)<br />
Add Insurance Data mit den entsprechenden Argumentwerten aus. Nach erfolgreicher<br />
Ausfuhrung der Aktion wird die um die entsprechenden Daten erganzte<br />
Marke anden ReadyToCompute{Aktivititatsubergang weitergereicht (put{<br />
Anweisung), welcher mit der ComputeBill{Aktivitat verbunden ist.<br />
Der Operationsaufruf Add Insurance Data wird quali ziert durch den dazugehorigen<br />
Schnittstellentyp (Employee) und die Dienstattribute (unit =<br />
Insurance && task = Bill<strong>in</strong>g), die den gewunschten Dienst genauer spezi<br />
zieren. Der Bezug des Schnittstellentyps zu dem dazugehorigen Diensttyp<br />
(Insurance Service) wird mittels der service{Deklaration <strong>in</strong>nerhalb der
202 Entwicklung und Ausfuhrung von Kooperationsanwendungen<br />
import{Anweisung des process{Blocks angegeben. Hierbei wird die Beziehung<br />
der <strong>in</strong> der CORBA{IDL de nierten Schnittstelle (<strong>in</strong>terface Employee)<br />
mit der diese Schnittstelle umfassenden CORBA{Modulde nition (module<br />
Insurance Service) hergestellt. Hierbei ndet e<strong>in</strong> semantisches Uberladen<br />
des CORBA{Modulkonzeptes statt, <strong>in</strong>dem der Modulname als Diensttypname<br />
<strong>in</strong>nerhalb von PAMELA und auch fur die Dienstvermittlung durchden TRADEr<br />
verwendet wird. 3<br />
Je nach De nition der Aktivitat konnen pr<strong>in</strong>zipiell auch mehrere Aktionen sequentiell<br />
bzw. parallel (durch hier nichtdargestellte par{und seq{Anweisungen)<br />
bei e<strong>in</strong>em oder jeweils fur jede Aktion separat spezi zierten Diensterbr<strong>in</strong>ger<br />
ausgefuhrt werden. Dieses wird durch entsprechende Schachtelung der us<strong>in</strong>g{<br />
und action{Anweisungen erreicht. Sollen <strong>in</strong>nerhalb e<strong>in</strong>es Anwendungsvorganges<br />
Aktionen, die <strong>in</strong>nerhalb verschiedener Aktivitaten auftreten, bei demselben<br />
Diensterbr<strong>in</strong>ger ausgefuhrt werden, so mu dieses explizit durch die entsprechende<br />
Wahl der quali zierenden Dienstattribute ausgedruckt werden. Hiermit<br />
wird e<strong>in</strong> Halten von Diensterbr<strong>in</strong>gerb<strong>in</strong>dungen uber mehrere Aktivitaten h<strong>in</strong>weg<br />
erreicht.<br />
Im Gegensatz zu den durch Dienstaufrufe <strong>in</strong>itiierten externen E<strong>in</strong>gaben, beispielsweise<br />
durch die obige userInput{Aktivitat, erlauben sogenannte Task{<br />
Transitionen externe E<strong>in</strong>gaben <strong>in</strong> den Anwendungsvorgang unabhangig von se<strong>in</strong>em<br />
konkreten Abarbeitungszustand. Sie s<strong>in</strong>d Bestandteil des <strong>in</strong> Abschnitt 4.1.2<br />
geforderten Interaktionskonzeptes. In Bezug auf das Versicherungsbeispiel konnte<br />
e<strong>in</strong>e Task{Transition dispatchJobs existieren, die asynchron neue Token bzw.<br />
Auftrage durch e<strong>in</strong>eentsprechende Benutzere<strong>in</strong>gabe <strong>in</strong> den durch JobPool spezi<br />
zierten Aktivitatsubergang e<strong>in</strong>fugt.<br />
Die Spezi kation e<strong>in</strong>er Aktivitat als transaktional ([transactional] trans)<br />
garantiert die Ausfuhrung der spezi zierten Aktionen gema der bekannten<br />
ACID{Transaktionseigenschaften [GR93]. So lassen sich mehrere Aktionen zu<br />
e<strong>in</strong>er Transaktion zusammenfassen, wobei je nach Ausgang der Transaktion<br />
(commit{oder abort{Anweisung) entsprechendeVerknupfungen zu anwendungsspezi<br />
schen Aktivitatsubergangen de niert werden mussen. Ahnlich der beiden<br />
commit{ oder abort{Ausgange e<strong>in</strong>er Transaktion lassen sich fur jede Aktivitat<br />
mittels e<strong>in</strong>er error{Anweisung aktionsspezi sche Fehler behandeln. Dieses<br />
betri t jedoch nur die mit der <strong>Dienstnutzung</strong> verbundenen Fehlerfalle, wie<br />
beispielsweise das Nichtvorhandense<strong>in</strong> e<strong>in</strong>es geeigneten Diensterbr<strong>in</strong>gers. Fehlerfalle<br />
aufgrund anwendungsspezi scher Resultatauswertungen e<strong>in</strong>es Dienstaufrufes<br />
mussen von Anwendungsprogrammierer beim Entwurf e<strong>in</strong>es Anwendungsvorganges<br />
explizit beschrieben werden. Abbildung A.9 <strong>in</strong> Anhang A.1.1 gibt e<strong>in</strong>e<br />
zusammenfassende Ubersicht uber die generelle Struktur e<strong>in</strong>er PAMELA{<br />
Beschreibung, die auch dem obigen Versicherungsbeispiel unterliegt.<br />
3 Diese Art der Diensttypbeschreibung stellt e<strong>in</strong>ealternative Methode zuder <strong>in</strong> Abschnitt<br />
5.1.1 beschriebenen dar. Sie bietet jedoch dieselbe Ausdrucksmachtigkeit.
6.1 TRADE{Entwicklungsumgebung 203<br />
6.1.2.4 Sichtweisen der Anwendungsprogrammierung mitPAMELA<br />
Im folgenden werden zwei Anwendungsbeispiele skizziert, die jeweils e<strong>in</strong>e bestimmte<br />
Sichtweise auf die Nutzung von Diensten <strong>in</strong> TRADE verdeutlichen. Beide<br />
Anwendungen, <strong>in</strong> denen sich zume<strong>in</strong>en e<strong>in</strong>e Work ow{orientierte und zum<br />
anderen e<strong>in</strong>e komponentenorientierte Programmiersichtweise widerspiegelt, s<strong>in</strong>d<br />
vollstandig <strong>in</strong> PAMELA beschrieben und <strong>in</strong>nerhalb der realisierten TRADE{<br />
Systemumgebung ablau ahig [Bri95, Gri95]. Sie s<strong>in</strong>d als Testanwendungen konzipiert,<br />
mit deren Hilfe das Zusammenspiel der verschiedenen Systemmechanismen<br />
von TRADE <strong>in</strong>tegriert evaluiert werden kann. Zudem ermoglichen sie Aussagen<br />
uber die Anwendbarkeit und Praktikabilitat von PAMELA, <strong>in</strong>sbesondere<br />
daruber, ob sie die <strong>in</strong> dieser Arbeit verfolgte Zielstellung der e<strong>in</strong>fachen Wiederverwendbarkeit<br />
und Komb<strong>in</strong>ation von vorhandenen Diensten zu neuen Kooperationsanwendungen<br />
erfullen kann.<br />
Vorgangsbeschreibungen<br />
Das erste Anwendungsbeispiel entstammt dem Bereich des Work ow{<br />
Managements. Diese Anwendung simuliert e<strong>in</strong> rudimentares Hotelmanagementsystem,<br />
<strong>in</strong> dem Dienste, wie beispielsweise der Zimmerdienst, Abrechnungsdienste,<br />
Kreditkartenbetreuung und der Empfang sowie der " Checkout\<br />
von Gasten, koord<strong>in</strong>iert werden. Wesentliches Merkmal dieser Anwendung ist<br />
e<strong>in</strong>e vorgangsorientierte Sichtweise. Hierbei wird die Verwaltung e<strong>in</strong>es Gastes<br />
im Hotel als e<strong>in</strong> Vorgang verstanden, dessen Verlauf durch e<strong>in</strong> bestimmtes<br />
Handlungsmuster vorgegeben ist. Im Rahmen dieses Vorganges werden verschiedene<br />
Aktivitaten durchgefuhrt, die wiederum den Ansto weiterer Aktivitaten<br />
verursachen konnen. Letztendlich gliedern sie sich <strong>in</strong> e<strong>in</strong>zelne Aktionen auf, <strong>in</strong><br />
denen letztendlich die eigentliche Nutzung der oben genannten Dienste erfolgt.<br />
Abbildung 6.2 zeigt die Hotelanwendung mittels der <strong>in</strong> Abschnitt 4.2 fur Anwendungsvorgange<br />
e<strong>in</strong>gefuhrten Petri{Netz{Notation. Die Abbildung verdeutlicht<br />
die moglichen Anwendungsablaufe <strong>in</strong> der Hotelanwendung. Aus Grunden der<br />
Ubersichtlichkeit ist dabei auf die Angabe von Kantenbed<strong>in</strong>gungen zwischen den<br />
Transitionen und die Typsierung von Stellen verzichtet worden. An dieser Stelle<br />
sei auf den Anhang A.2verwiesen, <strong>in</strong> dem die vollstandige textuelle PAMELA{<br />
Beschreibung der Hotelanwendung zu nden ist. Anhang A.2.1 zeigt <strong>in</strong> der<br />
Abbildung A.13 au erdem die graphische Benutzerschnittstelle der Hotelanwendung<br />
im Zusammenhang mit der Darstellung der Adm<strong>in</strong>istrationsschnittstelle<br />
des Koord<strong>in</strong>ationsmanagers. Mit diesen graphischen Endanwendungen konnen<br />
dann Benutzere<strong>in</strong>gaben an den <strong>in</strong> Abbildung 6.2 gezeigten Anwendungsvorgang<br />
ubergeben werden.<br />
Grundsatzlich spielt es bei der Spezi kation der Anwendungsvorgange ke<strong>in</strong>e Rolle,<br />
auf welcher der beiden unterliegenden <strong>verteilten</strong> Systemplattformen die <strong>in</strong><br />
der Anwendung genutzten Dienste realisiert s<strong>in</strong>d. Die Verwendung sowohl von<br />
CORBA{ als auch DCE{Diensten geschieht auf e<strong>in</strong>heitliche Weise mittels den <strong>in</strong><br />
der erweiterten CORBA{IDL (siehe auch Abschnitt 5.1.1) spezi zierten Diensttypbeschreibungen.<br />
Diese lassen sichnahtlos <strong>in</strong> die PAMELA{Beschreibung e<strong>in</strong>-
204 Entwicklung und Ausfuhrung von Kooperationsanwendungen<br />
arrival<br />
HOTEL<br />
<strong>in</strong>itAcc checkCard<br />
notify<br />
ACCOUNTING<br />
I<br />
<strong>in</strong>itialize<br />
T<br />
abort<br />
abort<br />
checkIn<br />
commit<br />
checkOut chargeCard<br />
pr<strong>in</strong>t pr<strong>in</strong>tBill<br />
rooms<br />
notifyManager<br />
taxReturn payTax<br />
b<strong>in</strong>den.<br />
departure<br />
commit<br />
abort<br />
commit<br />
charge<br />
notify<br />
T<br />
abort<br />
guests<br />
getBalance<br />
commit<br />
T<br />
pay<br />
abort<br />
commit<br />
processOrder<br />
order<br />
notify<br />
deliver<br />
notifyStaff<br />
pr<strong>in</strong>tBill<br />
notify<br />
notifyManager<br />
deliverY<br />
deliverX<br />
error<br />
deliver<br />
deliver<br />
handleError<br />
Abbildung 6.2: Vergroberte Petri{Netz{Darstellung des Hotelbeispiels<br />
E<strong>in</strong>e E<strong>in</strong>schrankung der <strong>in</strong> PAMELA gebotenen Dienstabstraktion bildet die<br />
Nutzung transaktionaler Dienste, da das fur ihre Realisierung verwendete<br />
Enc<strong>in</strong>a{Toolkit [IBM93] derzeit nur fur die DCE{Umgebung zur Verfugung<br />
steht. Dieses betri t <strong>in</strong> dem Hotelbeispiel vor allem die fur die Rechnungsabwicklung<br />
erforderlichen Kreditkartendienste, die realistischerweise <strong>in</strong>nerhalb<br />
von transaktional gesicherten Anwendungsvorgangen spezi ziert s<strong>in</strong>d. An dieser<br />
Stelle ist somit e<strong>in</strong> gewisses Vorwissen des Anwendungsentwicklers uber die<br />
Art des gewunschten Dienstes notwendig. Hilfestellung fur die Gew<strong>in</strong>nung dieser<br />
Informationen erfahrt er <strong>in</strong> TRADE durch durch den Typmanager und se<strong>in</strong>e<br />
<strong>in</strong> Abschnitt 5.1.2 vorgestellte graphische Benutzerschnittstelle, mit deren Hilfe<br />
Diensttypbeschreibungen gesucht und angezeigt werden konnen.<br />
Komponentenbeschreibungen<br />
Das zweite Beispiel veranschaulichte<strong>in</strong>eSichtweise von <strong>Dienstnutzung</strong> <strong>in</strong>o enen<br />
<strong>verteilten</strong> Dienstemarkten, bei der die vorhandenen Diensteauf e<strong>in</strong>facheWeise im<br />
Rahmen e<strong>in</strong>er komponentenbasierten Software{Entwicklung [GML96] zuneuen<br />
Kooperationsanwendungen zusammengefugt werden konnen. Erreicht wird dieses<br />
<strong>in</strong> TRADE durch dieUnterstutzung des Anwendungsprogrammiers mittels<br />
e<strong>in</strong>er e<strong>in</strong>fachen Art von visueller Programmierung, die e<strong>in</strong> schnelles Austesten<br />
notify
6.1 TRADE{Entwicklungsumgebung 205<br />
von neu entwickelten Diensten erlaubt. Hierzu lassen sich <strong>in</strong>PAMELA spezi -<br />
zierte Anwendungsablaufe, wie beispielsweise der fur den <strong>in</strong> der Abbildung 6.3<br />
gezeigten Taschenrechner, zusammen mit e<strong>in</strong>er zusatzlichen Spezi kation ihrer<br />
graphischen Benutzerschnittstelle <strong>in</strong> e<strong>in</strong>en sogenannten Application Builder |<br />
<strong>in</strong> der Abbildung unten erkennbar | laden. 4<br />
Abbildung 6.3: Der Application Builder aus Benutzersicht<br />
Dort konnen dann anschlie end e<strong>in</strong>zelne Dienstangebote aus der CORBA{<br />
oder DCE{Domane, die jeweils durch e<strong>in</strong> Ober achenelement im sogenannten<br />
Dienstangebots{Pool des Interzeptors (unten l<strong>in</strong>ks) reprasentiert werden, durch<br />
e<strong>in</strong> " drag & drop\{Verfahren fur die Realisierung des Taschenrechners genutzt<br />
werden. Auf diese Weise lassen sich die Tasten des Taschenrechners mit Diensten<br />
h<strong>in</strong>terlegen, die jeweils die Grundrechenarten zur Verfugung stellen. Durch Ansteuerung<br />
des Koord<strong>in</strong>ationsmanagers, der <strong>in</strong> der obigen Abbildung rechts unten<br />
angedeutet ist, ist anschlie end das Austesten des Zusammenspiels der im Rahmen<br />
der Taschenrechneranwendung genutzten E<strong>in</strong>zelkomponenten moglich. Bei<br />
Bedarf konnen Dienste auch zur Laufzeit durch e<strong>in</strong>faches " drag & drop\ ausgetauscht<br />
werden. Ebenso wie im obigen Hotelbeispiel spielt esdurch die E<strong>in</strong>beziehung<br />
des Interzeptors generell ke<strong>in</strong>e Rolle, ob hierfur DCE{ oder CORBA{<br />
basierte Dienstangebote genutzt werden.<br />
4 Der Application Builder ist Bestandteil der graphischen Benutzerschnittstelle des <strong>in</strong> TRA-<br />
DE realisierten Interzeptors (siehe auch Abbildung 5.17).
206 Entwicklung und Ausfuhrung von Kooperationsanwendungen<br />
6.2 Ablaufkontrolle<br />
Die im vorherigen Abschnitt beschriebeneVerwendungvon PAMELA ermoglicht<br />
die Spezi kation von <strong>verteilten</strong> Anwendungen unter ausschlie licher Nutzung extern<br />
angebotener Dienste. Samtliche<strong>in</strong>den Anwendungsvorgangen zu erbr<strong>in</strong>gende<br />
Teilaufgaben und deren Verarbeitung s<strong>in</strong>ddabei <strong>in</strong> externe Dienste ausgelagert.<br />
Um diese <strong>in</strong> PAMELA spezi zierten Anwendungsvorgange nun <strong>in</strong>e<strong>in</strong>er<br />
konkreten Systemumgebungausfuhren zu konnen, mussen sie <strong>in</strong> e<strong>in</strong>eablau ahige<br />
Form uberfuhrt werden. Diese Aufgabe wird <strong>in</strong> der Regel durch eigenstandige,<br />
e<strong>in</strong>em spezi schen Anwendungsvorgang zugeordnete Klientenanwendungen (siehe<br />
Abschnitt 4.1.1) ubernommen. Als Konsequenz aus der Art und Weise der<br />
Programmierung mit PAMELA beschrankt sich hierbei im Vergleich zur heute<br />
ublichen Programmierung jedoch die Aufgabe der Klientenanwendung, die<br />
bisher neben dem Aufruf der e<strong>in</strong>zelnen Dienste nochselbst wesentliche Teile<br />
der anwendungsspezi schen Verarbeitung realisiert, nur noch auf die Steuerung<br />
und Uberwachungder Koord<strong>in</strong>ation der genutzten Dienste und die Verarbeitung<br />
von Benutzer<strong>in</strong>teraktionen. Hierdurch verandert sich fur den Anwendungsprogrammierer<br />
nicht nur der eigentliche Anwendungsentwurf und se<strong>in</strong>e Programmierung<br />
| wie es konkret am Beispiel von PAMELA gezeigt wurde | sondern<br />
es ergeben sich fur ihn gleichzeitig auch erweiterte Moglichkeiten der Anwendungsausfuhrung.<br />
Dieses au ert sich vor allem dar<strong>in</strong>, da sich aufgrund der<br />
Beschrankung e<strong>in</strong>er Klientenanwendung auf koord<strong>in</strong>ative Aspekte nun zumAblauf<br />
von Anwendungsvorgangen dedizierte, generische Koord<strong>in</strong>ationsdienste entwickeln<br />
lassen, welche die Kontrollfunktionen fur e<strong>in</strong>e Vielzahl verschiedener<br />
Klientenanwendungen stellvertretend ubernehmen.<br />
Der vorliegende Abschnitt verdeutlicht anhand des <strong>in</strong> der TRADE{Systemumgebung<br />
entwickelten und konkret realisierten Koord<strong>in</strong>ationsmanagers diese Vorgehensweise.<br />
Dieser bietet e<strong>in</strong>en dementsprechenden generischen Ablaufkontroll{<br />
bzw. Koord<strong>in</strong>ationsdienst, welcher die Ausfuhrung von <strong>in</strong> PAMELA spezi zierten<br />
Anwendungsvorgangen steuert und uberwacht. Er bildet als Komponente<br />
der Ausfuhrungsumgebung neben dem Typmanager, TRADEr und Interzeptor<br />
e<strong>in</strong>en der Basisdienste von TRADE. Zunachst wird im folgenden die Rolle des<br />
Koord<strong>in</strong>ationsmanagers<strong>in</strong>der TRADE{Systemumgebungbeschrieben und se<strong>in</strong>e<br />
grundlegenden Aufgaben vorgestellt. Hierauf aufsetzend beschreiben die nachfolgenden<br />
Abschnitte genauere Details se<strong>in</strong>er Konzeption und Realisierung. Hierbei<br />
wird auch der enge Bezug zum <strong>in</strong>Abschnitt 4.2 vorgestellten Petri{Netz{<br />
basierten Modell von Kooperationsanwendungen deutlich, das die Grundlage fur<br />
den Entwurf der Steuerungsmechanismen im Koord<strong>in</strong>ationsmanager bildet.<br />
6.2.1 E<strong>in</strong>ordnung des Koord<strong>in</strong>ationsmanagers <strong>in</strong> TRADE<br />
Abbildung 6.4 gibt e<strong>in</strong>en Uberblick uber die grobe Konzeption des Koord<strong>in</strong>ationsmanagers<br />
und se<strong>in</strong>e Beziehungen zu den sonstigen <strong>in</strong> der TRADE{<br />
Systemumgebung vorhandenen Basisdiensten. Die Abbildung zeigt e<strong>in</strong>e verfe<strong>in</strong>erte<br />
Darstellung der bereits <strong>in</strong>Abbildung 4.13 gezeigten Grundstruktur von
6.2 Ablaufkontrolle 207<br />
PAMELA-<br />
Sprachübersetzer<br />
Entwicklungsumgebung<br />
PAMELA-<br />
Beschreibung<br />
Diensttypbeschreibung<br />
Typmanager<br />
Koord<strong>in</strong>ationsmanagerklient<br />
Def<strong>in</strong>ition<br />
Import<br />
TRADEr<br />
Ausführungsumgebung<br />
Adm<strong>in</strong>istration Ausführung<br />
Koord<strong>in</strong>ationsmanager<br />
DCE-Dienst<br />
Transaktionaler DCE-Dienst<br />
CORBA-Dienst<br />
Interzeptor<br />
DCE-<br />
DII<br />
Enc<strong>in</strong>a-<br />
DII<br />
Abbildung 6.4: Architektur und Beziehungen des Koord<strong>in</strong>ationsmanagers<br />
TRADE, <strong>in</strong> der grob e<strong>in</strong>e Entwicklungs{ und e<strong>in</strong>eAusfuhrungsumgebung unterschieden<br />
wurden. Auf der l<strong>in</strong>ken Seite, der Entwicklungsumgebung von TRA-<br />
DE, s<strong>in</strong>d die Details der Verarbeitung von PAMELA{Beschreibungen verdeutlicht.<br />
Dort existiert e<strong>in</strong> PAMELA{Sprachubersetzer [Gri95], dessen Hauptaufgabe<br />
die Generierung von Programmkode zumAufruf des Koord<strong>in</strong>ationsmanagers<br />
ist. Dieser Programmkode wird anschlie end mit Hilfe e<strong>in</strong>es herkommlichen C{<br />
Sprachubersetzers zu e<strong>in</strong>em lau ahigen Programm,dem sogenannten Koord<strong>in</strong>ationsmanagerklienten,<br />
ubersetzt. Dieser fuhrt letztendlich <strong>in</strong>der Ausfuhrungsumgebung<br />
von TRADE die konkreten Operationsaufrufe ander De nitionsschnittstelle<br />
des Koord<strong>in</strong>ationsmanagers durch. Diese Schnittstelle ist e<strong>in</strong>e von<br />
<strong>in</strong>sgesamt drei, nach funktionalen Kriterien getrennten DCE{Schnittstellen. Sie<br />
werden <strong>in</strong> den nachfolgenden Abschnitten noch genauer beschrieben. E<strong>in</strong>e andere<br />
Verknupfung der Entwicklungs{ und Ausfuhrungsumgebung wirdneben dem<br />
PAMELA{Sprachubersetzer durch den <strong>in</strong> Abschnitt 5.1beschriebenen Typmanager<br />
realisiert. Dieser verwaltet die Diensttypbeschreibungen, die <strong>in</strong> PAMELA{<br />
Beschreibungen beliebig <strong>in</strong>tegriert werden konnen. Sie dienen jedoch gleichzeitig<br />
auch zumAu nden diensttypkonformer Dienstangebote imRahmen der gestaffelten<br />
Dienstauswahl des TRADErs.<br />
Im Verlaufe der Abarbeitung e<strong>in</strong>es vorher registrierten Anwendungsvorganges<br />
nutzt der Koord<strong>in</strong>ationsmanager den TRADEr zum Au nden geeigneter<br />
Dienstanbieter. Der TRADEr verwaltet hierbei zum e<strong>in</strong>en die <strong>in</strong>nerhalb von<br />
DCE angebotenen und realisierten Dienste. Diese konnen auch e<strong>in</strong>e transaktionale<br />
Ausfuhrungssemantik besitzen, wobei im Unterschied zu herkommlichen<br />
DCE-<br />
DII
208 Entwicklung und Ausfuhrung von Kooperationsanwendungen<br />
DCE{Diensten der Zugri uber e<strong>in</strong> spezielles transaktionales Dynamic Invocation<br />
Interface durchgefuhrt wird, welches mit Hilfe des auf DCE aufsetzenden<br />
Enc<strong>in</strong>a{Toolkit [IBM93] realisiert ist [Bri95] (siehe auch Abschnitt 6.2.3.2).Zum<br />
anderen verwaltet der TRADEr die <strong>in</strong> der CORBA{Domane angebotenen Dienste,<br />
die <strong>in</strong> der DCE{Domane<strong>in</strong>Form von durchden Interzeptor generierten Proxies<br />
ersche<strong>in</strong>en (siehe Abschnitt 5.3.3). Diese s<strong>in</strong>d ebenso wie die herkommlichen<br />
DCE{Dienste uber e<strong>in</strong> auf dem DCE{RPC aufsetzendes Dynamic Invocation<br />
Interface zugreifbar, so da fur den Koord<strong>in</strong>ationsmanager pr<strong>in</strong>zipiell ke<strong>in</strong> Unterschied<br />
beim Zugri auf DCE{ oder CORBA{Dienste erkennbar ist. E<strong>in</strong>ziges<br />
Problem beim Aufruf von CORBA{Diensten ist ihre derzeit noch fehlende E<strong>in</strong>b<strong>in</strong>dung<br />
<strong>in</strong> transaktionale Aktivitaten. Hierfur existiert <strong>in</strong> CORBA noch ke<strong>in</strong>e<br />
adaquate Systemunterstutzung, die vergleichbar zu dem auf DCE{Seite genutzten<br />
Enc<strong>in</strong>a{Toolkit ist.<br />
6.2.2 Schnittstellen des Koord<strong>in</strong>ationsmanagers<br />
Zum Zugri auf se<strong>in</strong>e Funktionen bietet der Koord<strong>in</strong>ationsmanager den Klienten<br />
drei verschiedene Schnittstellen an (Abbildung 6.4). Diese s<strong>in</strong>d nach funktionalen<br />
Kriterien getrennt und ermoglichen so e<strong>in</strong>en dedizierten Zugang zu dort<br />
angebotenen, modular abgrenzbaren Teilfunktionen des Koord<strong>in</strong>ationsmanagers.<br />
6.2.2.1 De nitionsschnittstelle<br />
Die De nitionsschnittstelle 5 ermoglicht die Registration von Anwendungsvorgangen,<br />
um diese anschlie end durch den Koord<strong>in</strong>ationsmanager ausfuhren<br />
zu lassen. Grundidee der hierzu vom Koord<strong>in</strong>ationsmanager angebotenen<br />
Operationen ist ihre Anlehnung an die den Anwendungsvorgangen unterliegende<br />
Petri{Netz{Darstellung. So wird e<strong>in</strong> Anwendungsvorgang <strong>in</strong> Form<br />
von Stellen, Transitionen und Kanten als dynamisches Objekt <strong>in</strong>nerhalb des<br />
Koord<strong>in</strong>ationsmanagers erzeugt. Zusatzlich werden die Transitionen mit den<br />
dazugehorigen Dienstaufrufen verbunden und die Kanten um die de nierten<br />
Kantenbed<strong>in</strong>gungen erganzt. Wesentliche von der De nitionsschnittstelle<br />
angebotene Operationen s<strong>in</strong>d:<br />
createNet erzeugt e<strong>in</strong>e neue Netzreprasentation<br />
createTransition erzeugt e<strong>in</strong> neue Transition<br />
createPlace erzeugt e<strong>in</strong> neue Stelle<br />
createInputArc stellt e<strong>in</strong>e E<strong>in</strong>gangskantenbeziehung her<br />
createOutputArc stellt e<strong>in</strong>eAusgangskantenbeziehung her<br />
addService verknupft e<strong>in</strong>e Transition mit e<strong>in</strong>em Dienst<br />
modifyToken erlaubt e<strong>in</strong>e Operation auf e<strong>in</strong>er Marke<br />
Pr<strong>in</strong>zipiell s<strong>in</strong>d diese Operationen auch direkt bei der Programmierung von<br />
Klientenanwendungen nutzbar. Generell sollte hierauf jedoch aus Grunden der<br />
Komplexitat verzichtet werden. Diese Komplexitat, die sich bereits schon bei<br />
5 Die vollstandige, <strong>in</strong> DCE{IDL beschriebene Schnittstelle ndet sich <strong>in</strong>Anhang E.
6.2 Ablaufkontrolle 209<br />
vergleichsweise kle<strong>in</strong>en Anwendungsvorgangen zeigt, wird <strong>in</strong> Anhang E.2 am<br />
Beispiel des vom PAMELA{Sprachubersetzer generierten De nitionskodes deutlich.<br />
Statt der direkten Verwendung der Operationen der De nitionsschnittstelle<br />
sollte deshalb im allgeme<strong>in</strong>en der ubliche und komfortablere Weg uber die Generierung<br />
des Koord<strong>in</strong>ationsmanagerklienten aus e<strong>in</strong>er PAMELA{Beschreibung<br />
gewahlt werden. Zudem ermoglicht der PAMELA{Sprachubersetzer bereits vor<br />
dem Ausfuhrungszeitpunkt die Uberprufung der Typkonformitat zwischen Stellen<br />
und der auf ihnen abgelegten Marken sowie von Dienstaufrufen und den ihnen<br />
zugeordneten Parametern.<br />
6.2.2.2 Adm<strong>in</strong>istrationsschnittstelle<br />
Die Adm<strong>in</strong>istrationsschnittstelle stellt Operationen zur Verfugung, mit denen<br />
sich Anwendungsvorgange sowohl steuern als auch manipulieren lassen:<br />
startNet aktiviert e<strong>in</strong>en Anwendungsvorgang<br />
stopNet deaktiviert e<strong>in</strong>en Anwendungsvorgang<br />
suspendTransition suspendiert e<strong>in</strong>e Transition vorubergehend<br />
resumeTransition reaktiviert e<strong>in</strong>e supendierte Transition<br />
stopTransition deaktiviert e<strong>in</strong>e Transition dauerhaft<br />
Durch die Komb<strong>in</strong>ation mit den an der De nitionsschnittstelle angebotenen Operationen<br />
kann pr<strong>in</strong>zipiell zur Laufzeit die statische Netzstruktur und damit das<br />
Netzverhalten geandert werden. So kann beispielsweise e<strong>in</strong>e fehlerhafte Transition<br />
durch stopTransition deaktiviert werden und durch e<strong>in</strong>eneue Transition<br />
uber createTransition ersetzt werden. Die Adm<strong>in</strong>istrationsschnittstelle umfa<br />
t weiterh<strong>in</strong> auch Operationen zur Abfrage des statischen Netzzustandes und<br />
zur Ermittlung des aktuellen Markierung des Netzes:<br />
getNets liefert die registrierten Netze<br />
getTransitions liefert die Transitionen e<strong>in</strong>es Netzes<br />
getPlaces liefert die Stellen sowie ihre momentane Markierung<br />
getInputPlaces liefert die E<strong>in</strong>gangsstellen e<strong>in</strong>er Transition<br />
getOutputPlaces liefert die Ausgangsstellen e<strong>in</strong>er Transition<br />
Die Nutzung samtlicher Adm<strong>in</strong>istrationsoperationen wird durch e<strong>in</strong> graphisches<br />
Adm<strong>in</strong>istrationswerkzeug unterstutzt (Abbildung 6.5), welches auch die vom Koord<strong>in</strong>ationsmanager<br />
wahrend der Ausfuhrung e<strong>in</strong>es Anwendungsvorganges erzeugten<br />
Kontroll<strong>in</strong>formationen darstellt.<br />
6.2.2.3 Ausfuhrungsschnittstelle<br />
Mit Hilfe der vom Koord<strong>in</strong>ationsmanager angebotenen Ausfuhrungsschnittstelle<br />
kann der externeBenutzer auf das Verhalten e<strong>in</strong>es Anwendungsvorganges e<strong>in</strong>wirken.<br />
Die Realisierung dieses Interaktionskonzeptes (sieheauch Abschnitt 4.2.3.7)<br />
geschieht mittels der Operation putToken, mit der Marken auf ausgezeichnete<br />
Stellen des Petri{Netzes gelegt werden konnen. Die Ubergabe der Marken<br />
erfolgt dabei unter Nutzung von Teilen der <strong>in</strong> Abschnitt 5.1.3 und Anhang B
210 Entwicklung und Ausfuhrung von Kooperationsanwendungen<br />
Abbildung 6.5: Graphische Adm<strong>in</strong>istrationsschnittstelle des Koord<strong>in</strong>ationsmanagers<br />
vorgestellten Diensttypreprasentation. Diese ist nicht nur zum Austausch von<br />
Typ<strong>in</strong>formationen geeignet, sondern ermoglicht gleichzeitig auch den Transport<br />
von Datenwerten. Zur Gewahrleistung der Typsicherheit der Benutzere<strong>in</strong>gabe<br />
fuhrt der Koord<strong>in</strong>ationsmanager zusatzlich e<strong>in</strong>eTypvergleich mit dem der Stelle<br />
zugeordneten Markentyp durch.<br />
6.2.3 Steuerung von Anwendungsvorgangen<br />
Aufgrund der <strong>in</strong> Petri{Netzen <strong>in</strong>harent gegebenen Integration von Struktur und<br />
Verhalten, bei der die statische Netzbeschreibung gleichzeitig auch ihr dynamisches<br />
Verhalten festlegt, bietet sich bei der Realisierung von Steuerungskomponenten<br />
an, die Schaltsemantik von Petri{Netzen auch als Grundlage fur die<br />
Ausfuhrung von Anwendungsvorgangen zu verwenden. Diese Idee lag bereits<br />
schon den <strong>in</strong> den vorherigen Abschnitten vorgestellten Schnittstellen des Koord<strong>in</strong>ationsmanagers<br />
zugrunde. Hierdurch la t sich der durch Abbildungsprobleme<br />
hervorgerufenekonzeptionelle Bruch zwischen Modellierung und Ausfuhrungvon<br />
Anwendungsvorgangen vermeiden.
6.2 Ablaufkontrolle 211<br />
6.2.3.1 Objektorientierte Umsetzung von Petri{Netzen<br />
Grundlage fur samtliche Steuerungs{ und Kontrollmechanismen im Koord<strong>in</strong>ationsmanager<br />
bildet die Abbildung von Petri{Netzen <strong>in</strong> e<strong>in</strong>e systemtechnisch verarbeitbare<br />
Datenstruktur. Um hier e<strong>in</strong>en maximalen Grad an Wiederverwendbarkeit<br />
und Orthogonalitat ihrer Nutzung zu erreichen, wird fur ihre Implementation<br />
e<strong>in</strong> objektorientierter Ansatz gewahlt, welcher e<strong>in</strong>e unmittelbare Reprasentation<br />
der Elementee<strong>in</strong>es Petri{Netzes durchentsprechende Objektklassen<br />
erlaubt. In der Implementation des Koord<strong>in</strong>ationsmanagers existiert dementsprechend<br />
fur jedes Petri{Netz{Element jeweils e<strong>in</strong>e eigene Objektklasse, die durch<br />
Assoziations{ und Vererbungsbeziehungen mit anderen Klassen verknupft ist.<br />
Die e<strong>in</strong>zelnen Objektklassen s<strong>in</strong>d <strong>in</strong>Abbildung 6.6 verdeutlicht, wobei die Darstellung<br />
die <strong>in</strong> der Object Model<strong>in</strong>g Technique [RBP + 91] angebotenen Beschreibungsmittel<br />
nutzt.<br />
class<br />
Place<br />
class<br />
OutputArc<br />
class<br />
Token<br />
class<br />
Net<br />
class<br />
Arc<br />
class class<br />
Transition Service<br />
class<br />
InputArc<br />
class<br />
Expression<br />
Legende<br />
Vererbung<br />
m:1 Beziehung<br />
optionale Beziehung<br />
Abbildung 6.6: Objektorientierte Modellierung e<strong>in</strong>es Petri{Netzes<br />
Netze (class Net): Auf oberster Ebene des Objektmodells be nden sich die<br />
Petri{Netze selbst, die als ubergeordnete Objektesamtliche weiteren Objekte<br />
e<strong>in</strong>es Petri{Netzes be<strong>in</strong>halten.<br />
Die E<strong>in</strong>fuhrung dieser Klasse dient vor allem zur parallelen Verwaltung<br />
mehrerer Netze, die jeweils e<strong>in</strong>e eigene Struktur und e<strong>in</strong>unabhangiges<br />
Verhalten besitzen. Sie stellt samtliche Methoden zum Aufbau von Netzen<br />
uber die De nitionsschnittstelle, zur Uberwachung und Kontrolle uber<br />
die Adm<strong>in</strong>istrationsschnittstelle und zur Benutzer<strong>in</strong>teraktion bereit. Samtliche<br />
Methoden spiegeln sich unmittelbar an der DCE{Schnittstelle des<br />
Koord<strong>in</strong>ationsmanagers wider.
212 Entwicklung und Ausfuhrung von Kooperationsanwendungen<br />
Stellen (class Place): Die Klasse der Stellen realisiert e<strong>in</strong> passives, typisiertes<br />
Speicherobjekt fur Objekte der Klasse Token. Die von ihr angebotenen<br />
Methoden unfassen das Ablegen und Entfernen der Marken, wobei diese<br />
die Typvertraglichkeit zwischen dem Stellentyp undden abgelegten Marken<br />
uberprufen. Da auf e<strong>in</strong>zelne Stellen durch mehrere verschiedene Transitionen<br />
des Petri{Netzes nebenlau g zugegri en werden kann, realisieren die<br />
Methoden weiterh<strong>in</strong> auch konsistenzsichernde Synchronisationsfunktionen,<br />
die auf Semaphoren aufsetzen. Des weiteren existieren Methoden, mit denen<br />
e<strong>in</strong>e Stelle mit E<strong>in</strong>gangs- und Ausgangskanten verknupft werden kann.<br />
Transitionen (class Transition): Die aktiven Objekte <strong>in</strong>nerhalb e<strong>in</strong>es<br />
Petri{Netzes s<strong>in</strong>d die Transitionen. Sie s<strong>in</strong>d mit den Objekten der<br />
Klasse Service assoziiert, die die wahrend e<strong>in</strong>er Aktivitat auszufuhrenden<br />
Dienstaufrufe reprasentieren. Durch Nutzung von DCE{Threads<br />
[OSF93a] konnten die Transitionen als aktive Objekte realisiert werden,<br />
die selbstandig ihre Aktivierung uberwachen und ihr Schalten auslosen.<br />
Hierdurch konnte auf die Realisierung e<strong>in</strong>er ubergeordneten und zentralen<br />
Kontrollkomponente fur Transitionen (engl. transition scheduler)<br />
verzichtet werden.<br />
Kanten (class Arc): Die Klasse der Kanten dient primar zur besseren Modularisierung<br />
des Objektmodells. Samtliche von ihr angebotenen Methoden<br />
s<strong>in</strong>d durch Vererbung auch <strong>in</strong> den Klassen InputArc und OutputArc<br />
verfugbar. Neben den Uberprufungsmethoden fur Kantenbed<strong>in</strong>gungen<br />
stellt sie dem Anwendungsprogrammierer Methoden bereit, welche die<br />
Transitionen mit den Stellen e<strong>in</strong>es Petri{Netzes verknupfen.<br />
Marken (class Token): Marken s<strong>in</strong>d typisierte und sichselbst beschreibende<br />
Datenobjekte, die zwischen den Stellen uber die Transitionen bewegt<br />
werden. Sie reprasentieren die veranderbaren Nutz{ und Steuerdaten, die<br />
von Aktivitat zu Aktivitat ubermittelt werden und die durch ihre konkrete<br />
Wertbelegung den Ablauf bzw. das Schaltverhalten e<strong>in</strong>es Petri{Netzes bee<strong>in</strong><br />
ussen. Im wesentlichen realisieren MarkenobjekteMethoden zum Auslesen<br />
und zum Setzen der Datenwerte sowie zum Ubertragen der Datenwerte<br />
bei Operationsaufrufen an die Diensterbr<strong>in</strong>ger.<br />
Ausdrucke (class Expression): Die Klasse der Ausdrucke stellt Methoden<br />
zur De nition und Auswertung logischer Ausdrucke bereit, die fur die Bearbeitung<br />
der Kantenbed<strong>in</strong>gungen benotigt werden. Weiterh<strong>in</strong> werden die<br />
Ausdrucke auch dazu verwandt, um die Dienstattribute fur die Auswahl<br />
geeigneter Dienstangebote beim TRADEr zu spezi zieren.<br />
Dienste (class Service): Fur die Verknupfung des Koord<strong>in</strong>ationsmanagers<br />
mit der TRADE{Ausfuhrungsumgebung spielt die Klasse der Dienste e<strong>in</strong>e<br />
wichtige Rolle. Sie realisiert zum e<strong>in</strong>en die Interaktion mit dem TRADEr,<br />
der die benotigten Diensterbr<strong>in</strong>ger entsprechend der geforderten Eigenschaften<br />
vermittelt. Zumanderen steuert sie die Durchfuhrungder anschlieenden<br />
Operationsaufrufe bei den DCE{Dienstanbietern bzw. den vom Interzeptor<br />
generierten Proxies, wobei erstere je nach Semantik entweder <strong>in</strong>
6.2 Ablaufkontrolle 213<br />
herkommlicher Weise oder transaktional erfolgen konnen. Sie ermoglicht<br />
hierbei auch die nebenlau ge Ausfuhrungverschiedener Operationsaufrufe,<br />
<strong>in</strong>dem sie jedem Operationsaufruf e<strong>in</strong>em eigenen Thread zuordnet, der <strong>in</strong><br />
geeigneter Weise mit den anderen Threads sychronisiert wird. Diese werden<br />
dann je nachAnwendungsspezi kation beliebig sequentiell oder parallel<br />
und unter Umstanden sogar rekursiv ausgefuhrt.<br />
6.2.3.2 Steuerungsalgorithmen<br />
Im folgenden wird exemplarisch gezeigt, wie geeignete Steuerungsalgorithmen<br />
im Koord<strong>in</strong>ationsmanager realisiert werden konnen. Sie unterstutzen die <strong>in</strong><br />
Petri{Netzen <strong>in</strong>harent gegebene Nebenlau gkeit des Schaltens von Transitionen<br />
bzw. | im Kontext von Kooperationsanwendungen | der Ausfuhrung<br />
von Aktivitaten unter Gewahrleistung von Verklemmungsfreiheit und maximaler<br />
Nebenlau gkeit. Systemtechnische Grundlage hierfur bildet die uber die Denitionsschnittstelle<br />
des Koord<strong>in</strong>ationsmanagers aufgebaute <strong>in</strong>terne Petri{Netz{<br />
Reprasentation von Anwendungsvorgangen, die <strong>in</strong>tern mit Hilfe der im vorherigen<br />
Abschnitt beschriebenen Programmierklassen realisiert ist. In der Implementation<br />
des Vorgangsverwalters kann e<strong>in</strong> hoher Grad an nebenlau ger Aktivitatsausfuhrung<br />
durch die Verwendung des Thread-Konzeptes erreicht werden,<br />
<strong>in</strong>dem die auf Programmiersprachebene angebotene Transitionsausfuhrungsmethode<br />
Transition::run fur jedeTransition e<strong>in</strong>en eigenstandigen Thread kreiert.<br />
Der dieser Methode zugrundeliegende Algorithmus ist im Koord<strong>in</strong>ationsmanager<br />
realisiert worden und <strong>in</strong>Abbildung 6.7 und <strong>in</strong>der nachfolgend erlauterten Abbildung<br />
6.8 graphisch dargestellt. Die Ausfuhrung der Transitionen ndet dabei<br />
generell <strong>in</strong> Form e<strong>in</strong>er Schleife statt, die durchdas Ablaufpr<strong>in</strong>zip Ereignis, Bed<strong>in</strong>gung,<br />
Handlung (engl. event, condition, action | ECA) [DHL90] charakterisiert<br />
ist. Durch das Ereignis der Ablage e<strong>in</strong>er Markeauf der E<strong>in</strong>gangsstelle e<strong>in</strong>er Transition<br />
wird diese programmtechnisch aktiviert, worauf sie ihre Schaltbed<strong>in</strong>gungen<br />
uberpruft und gegebenenfalls die mit ihr verknupften entfernten Dienste aufruft.<br />
Bei der nebenlau gen Ausfuhrung der Transitionen s<strong>in</strong>d <strong>in</strong>sbesondere Konkurrenzsituationen<br />
beim Zugri auf die Marken der E<strong>in</strong>gangsstellen der Transitionen<br />
zu berucksichtigen. Um hier e<strong>in</strong>e konsistente Vorgehensweise zu realisieren,<br />
mussen die Stellen programmiertechnischdurch Semaphore geschutzt werden. So<br />
kann auf e<strong>in</strong>e Stelle nur dann zugegri en werden, wenn die Transition e<strong>in</strong>e exklusive<br />
Sperre auf die Stelle besitzt. Da dieses nebenlau g zu allen anderen Transitionen<br />
geschieht, besteht beim Erwerb mehrerer Sperren zu verschieden Stellen<br />
das Risikovon Verklemmungen (engl. deadlock), die durch zyklische Wartebeziehungen<br />
zwischen den Transitionen entstehen. Um dieses zu vermeiden wird e<strong>in</strong>e<br />
Strategie zur Verklemmungsvorbeugung (engl. deadlock prevention) e<strong>in</strong>gesetzt,<br />
die auf dem Konzept der Vorbelegung (engl. preclaim<strong>in</strong>g) beruht (siehe hierzu<br />
auch [PS85]). Jede Transition strebt hierbei zunachst den Erwerb von Sperren<br />
auf allen E<strong>in</strong>gangsstellen an. Tritt e<strong>in</strong> Kon ikt auf, da e<strong>in</strong>eStelle bereits durch<br />
e<strong>in</strong>e andere Transition vorbelegt ist, so werden alle erworbenen Sperren freigegeben,<br />
so da Wartebeziehungen pr<strong>in</strong>zipiell nicht auftreten konnen. Anschlie end<br />
wiederholt die Transition den Sperrvorgang von neuem (siehe Abbildung 6.7).
214 Entwicklung und Ausfuhrung von Kooperationsanwendungen<br />
Transition::<br />
run()<br />
Erwerb von<br />
Sperren auf alle<br />
E<strong>in</strong>gangsstellen<br />
erfolgreich<br />
ja<br />
Test der<br />
Kantenbed<strong>in</strong>gungen<br />
erfolgreich<br />
ja<br />
Erzeugung<br />
e<strong>in</strong>er neuen<br />
Transitions<strong>in</strong>stanz<br />
Freigabe aller<br />
bestehenden Sperren<br />
Freigabe aller<br />
bestehenden Sperren<br />
Entfernen der<br />
Marken von<br />
E<strong>in</strong>gangstellen<br />
Transitionsresultat<br />
Sperrerwerb<br />
auf Ausgangsstellen<br />
auf Ausgangsstellen<br />
für Commit für Abort<br />
Ablage<br />
der Marken<br />
auf Ausgangsstellen<br />
ne<strong>in</strong><br />
ne<strong>in</strong><br />
commit<br />
ne<strong>in</strong><br />
erfolgreich<br />
Signal durch<br />
parallelen Thread<br />
abort error<br />
Reaktivierung<br />
des Threads<br />
Suspendierung<br />
des Threads<br />
Service::<br />
<strong>in</strong>vokeAll()<br />
Sperrerwerb Sperrerwerb<br />
ja<br />
Freigabe<br />
bestehender Sperren<br />
auf Ausgangsstellen<br />
für Fehler<br />
Freigabe von<br />
Datenstrukturen<br />
Thread-Beendigung<br />
Abbildung 6.7: Algorithmus fur die Ausfuhrung e<strong>in</strong>er Transition<br />
S<strong>in</strong>d alle gewunschten Sperren erworben, so werden die Kantenbed<strong>in</strong>gungen im<br />
Kontext der auf den jeweiligen Stellen vorhandenen Marken ausgewertet.Indem<br />
Fall, wenn alle Kantenbed<strong>in</strong>gungen zu wahr evaluieren, wird die Transition anschlie<br />
end geschaltet. Evaluiert jedoch e<strong>in</strong>eder Kantenbed<strong>in</strong>gungen zu falsch<br />
oder s<strong>in</strong>d auf e<strong>in</strong>er Stelle eventuell gar ke<strong>in</strong>e Marken vorhanden, so ist die Transition<br />
nicht aktiviert und kann somit auch nicht geschaltet werden. Alle auf<br />
die Stellen gehaltenen Sperren werden <strong>in</strong> diesem Fall freigegeben, um anderen<br />
Transitionen den Zugri zu ermoglichen. S<strong>in</strong>d jedoch alle Bed<strong>in</strong>gungen an den<br />
E<strong>in</strong>gangskanten erfullt, werden die ausgewahlten Marken von den E<strong>in</strong>gangsstellen<br />
entfernt und die Sperren freigegeben. Um e<strong>in</strong> nebenlau ges Schalten der-
6.2 Ablaufkontrolle 215<br />
selben Transition zu ermoglichen, erzeugt die Transition vor der weiteren Verarbeitung<br />
zunachst e<strong>in</strong>en weiteren Thread, der als neue Transitions<strong>in</strong>stanz die<br />
Methode Transition::run ausfuhrt. Hierdurch wird erreicht, da e<strong>in</strong>e Transition<br />
bei Belegung ihrer E<strong>in</strong>gangsstellen mit mehreren Marken nebenlau g zu<br />
sich selbst schalten kann. Diese Eigenschaft wurde <strong>in</strong>Abschnitt 4.2.3.4 als Intravorgangsnebenlau<br />
gkeit bezeichnet. Beim Schalten der Transition wird entweder<br />
die Methode Service::<strong>in</strong>vokeAll fur nicht{transaktionale Transitionen oder<br />
die Methode Service::<strong>in</strong>vokeTopTransaction fur transaktionale Transitionen<br />
aufgerufen (Abbildung 6.8).<br />
Service::<br />
<strong>in</strong>vokeAll() bzw.<br />
<strong>in</strong>vokeTopTrans()<br />
transaktional:<br />
beg<strong>in</strong>Tran()<br />
weitere<br />
sequentielle<br />
Dienste<br />
ja<br />
Erzeugung<br />
e<strong>in</strong>es neuen<br />
Threads<br />
Service::<br />
<strong>in</strong>voke()<br />
weitere<br />
parallele<br />
Dienste<br />
ne<strong>in</strong><br />
Warten auf<br />
Term<strong>in</strong>ierung<br />
paralleler Threads<br />
Dienstresultat<br />
commit<br />
ne<strong>in</strong><br />
ja<br />
abort/<br />
error<br />
transaktional:<br />
commitTran()<br />
return<br />
commit<br />
return<br />
abort/error<br />
transaktional:<br />
abortTran()<br />
Service::<br />
<strong>in</strong>voke()<br />
Bereitstellung<br />
der Parameter<br />
aus Markenwerten<br />
Ermittlung<br />
e<strong>in</strong>es<br />
Diensterbr<strong>in</strong>gers<br />
Dienst<br />
vorhanden<br />
ja<br />
Dienstaufruf<br />
mit Parametern<br />
Ergebnisüberprüfung<br />
Fehler<br />
ja<br />
return<br />
error<br />
ne<strong>in</strong><br />
ne<strong>in</strong><br />
TRADEr<br />
importOffer()<br />
return<br />
error<br />
Dienst<br />
<strong>in</strong>vokeService()<br />
<strong>in</strong>vokeTran()<br />
return<br />
commit<br />
Abbildung 6.8: Algorithmus fur den Aufruf von Operationen <strong>in</strong>nerhalb e<strong>in</strong>er<br />
Transition<br />
Der Algorithmus transaktional geschutzter Transitionen mit mehreren Dienstaufrufen<br />
wird fur den Fall der Nutzung von DCE{Diensten mittels der vom<br />
Enc<strong>in</strong>a{Toolkit [IBM93] angebotenen Funktionen realisiert, welche die atomare<br />
Ausfuhrung aller <strong>in</strong>nerhalb e<strong>in</strong>er Transition ausgefuhrten Operationsaufrufe<br />
bei externen Diensten sichern. Der Schaltvorgang beg<strong>in</strong>nt hierbei mit dem Start<br />
e<strong>in</strong>er Transaktion, die nur dann durche<strong>in</strong>Commit abgeschlossen wird, sofern alle
216 Entwicklung und Ausfuhrung von Kooperationsanwendungen<br />
aufgerufenen transaktionalen Operationen erfolgreich beendet worden s<strong>in</strong>d. Die<br />
im Enc<strong>in</strong>a{Toolkit bereitgestellte Ausnahmebehandlung garantiert, da im Fall<br />
des Scheiterns e<strong>in</strong>er der Teiltransaktionen bzw. Operationsaufrufe die gesamte<br />
Operationsfolge explizit beendet wird und entsprechende Ma nahmen fur die<br />
Herstellung des orig<strong>in</strong>aren Ausgangszustandes vor der Transaktion (engl. rollback)<br />
getro en werden.<br />
Die <strong>in</strong> der Transition <strong>in</strong> Anspruch genommenen Diensterbr<strong>in</strong>ger werden mittels<br />
der vom TRADEr angebotenen importOffer{Operation (siehe Abschnitte<br />
3.3.2.3 und 5.2.2.3) ausgewahlt. Kann hierbei vom TRADEr ke<strong>in</strong> geeigneter<br />
Diensterbr<strong>in</strong>ger ermitteltwerden, so wird mit der Ruckgabe e<strong>in</strong>es Fehlers (error)<br />
bzw. mit dem Abbruch der Transaktion (abort) reagiert. In diesem Fall werden<br />
alle weiteren Operationsaufrufe <strong>in</strong> dieser Transition nicht mehr ausgefuhrt.<br />
Sollte die Dienstvermittlung jedoch erfolgreich gewesen se<strong>in</strong>, so wird die vom<br />
TRADEr fur e<strong>in</strong>en Diensterbr<strong>in</strong>ger zuruckgelieferte B<strong>in</strong>dungs<strong>in</strong>formation beim<br />
Operationsaufruf unter Nutzung des Dynamic Invocation Interface (siehe auch<br />
Abbildung 6.4)verwendet. Hieruber werden dann die von den E<strong>in</strong>gangsstellen<br />
stammenden Markenwerte als Operationsparameter ubergeben. Die nach dem<br />
Dienstaufruf moglicherweise veranderten Marken werden anschlie end durch die<br />
Transition auf den Ausgangsstellen abgelegt. In ahnlicher Weise wie bei den<br />
E<strong>in</strong>gangsstellen werden vorher fur die Ausgangsstellen Sperren angefordert, um<br />
Konsistenzprobleme beim Zugri mehrerer Transitionen auf dieselben Stellen zu<br />
vermeiden. Abschlie end wird die Methode Transition::run beendet.<br />
6.3 Bewertung und erganzende Anmerkungen<br />
Die <strong>in</strong> diesem Kapitel und <strong>in</strong> Anhang A vorgestellte Koord<strong>in</strong>ationssprache<br />
PAMELA berucksichtigt <strong>in</strong> ihrem Sprachumfang alle im Kapitel 4.2 geforderten<br />
Beschreibungskonzepte. Durch das Anbieten e<strong>in</strong>es Daten{, e<strong>in</strong>es<br />
Aktions{, e<strong>in</strong>es Kontroll u {, e<strong>in</strong>es Nebenlau gkeits{, e<strong>in</strong>es Transaktions{,<br />
e<strong>in</strong>es Fehlerbehandlungs{, e<strong>in</strong>es Interaktions{ und e<strong>in</strong>es Strukturierungskonzeptes<br />
stehen dem Anwendungsprogrammierer samtliche Ausdrucksmittel zur<br />
Verfugung, die zur Realisierung von Kooperationsanwendungen benotigt werden.<br />
PAMELA stellt damit e<strong>in</strong>e konkrete programmiersprachliche Umsetzung des <strong>in</strong><br />
Kapitel 4 e<strong>in</strong>gefuhrten abstrakten und auf Petri{Netzen aufsetzenden Modells<br />
von Kooperationsanwendungen dar. PAMELA erbr<strong>in</strong>gt hierdurch gleichzeitig<br />
auch den Nachweis der Durchfuhrbarkeit der <strong>in</strong> diesem Modell entwickelten,<br />
zunachst nur abstrakten Beschreibungskonzepte <strong>in</strong> e<strong>in</strong>e konkrete verteilte<br />
Systemumgebung, <strong>in</strong> diesem Fall <strong>in</strong> die auf DCE und CORBA aufsetzende<br />
TRADE{Systemumgebung. Durch die Integration von dort bereits vorhandenen<br />
Dienstbeschreibungen und deren unmittelbare Bezugnahme beim Dienstaufruf<br />
<strong>in</strong> PAMELA wird die Verb<strong>in</strong>dung der Entwicklungs{ zur Ausfuhrungsumgebung<br />
<strong>in</strong> TRADE gescha en. Hierdurch wird es fur den Anwendungsprogrammierer<br />
moglich, auf samtliche <strong>in</strong>nerhalb von TRADE vorhandenen Dienste zuzugreifen,<br />
wobei er <strong>in</strong> PAMELA ausschlie lich die Koord<strong>in</strong>ation der gewunschten Dienste<br />
beschreiben mu . Hierbei wird er neben der von PAMELA bzw. Petri{Netzen
6.3 Bewertung und erganzende Anmerkungen 217<br />
gegebenen Ausdrucksmoglichkeit von Nebenlau gkeit und Synchronisation,<br />
die zur Darstellung der koord<strong>in</strong>ativen Aspekte der <strong>Dienstnutzung</strong> <strong>in</strong>nerhalb<br />
von Anwendungsvorgangen geeignet ist, vor allem durch das dienstorientierte<br />
Aktionskonzept unterstutzt. Dieses ermoglicht die e<strong>in</strong>fache Verwendung der<br />
durch die TRADE{Systemumgebung zur Verfugung gestellten exiblen Dienstvermittlungsmechanismen,<br />
die dort <strong>in</strong> Form des TRADErs unter expliziter<br />
Verwendung von Trader{Kooperationen realisiert werden.<br />
Trotz der vielseitigen Ausdrucksmoglichkeiten von PAMELA, die <strong>in</strong> diesem<br />
Kapitel beispielhaft anhand der Versicherungsanwendung, der Hotelanwendung<br />
und dem Taschenrechner verdeutlicht wurden, s<strong>in</strong>d konzeptuelle Erweiterungen<br />
denkbar, die ihr Anwendungsfeld und ihre Beschreibungsmachtigkeit vergro ern.<br />
Hierfur s<strong>in</strong>d zume<strong>in</strong>en diejenigen Erweiterungen zu betrachten, die das zugrundeliegende<br />
Petri{Netz{basierte Anwendungsmodell betre en. Hierauf wurde bereits<br />
bei der Bewertung des Anwendungsmodells <strong>in</strong> Abschnitt 4.3 e<strong>in</strong>gegangen.<br />
Zum anderen s<strong>in</strong>d derartige Erweiterungen zu betrachten, die sich aus der engen<br />
Kopplung von PAMELA an die TRADE{Ausfuhrungsumgebung und den<br />
hierdurch bereitgestellten Verarbeitungsmoglichkeiten ergeben. Dieses betri t<br />
vor allem das Dienstkonzept von PAMELA, welches den direkten Bezug zum<br />
Typmanager und TRADEr ermoglicht. Hier ist <strong>in</strong>sbesondere <strong>in</strong>teressant, ob der<br />
von PAMELA gebotene hohe Grad an Programmierabstraktion zugunsten direkterer<br />
E<strong>in</strong> u moglichkeiten auf die unterliegenden Systemdienste von TRA-<br />
DE gelockert werden sollte. Im Fall der Dienstauswahl konnte beispielsweise die<br />
Ausdrucksmoglichkeit der us<strong>in</strong>g{Anweisung zur Bee<strong>in</strong> ussung der TRADEr{<br />
Dienstauswahl durch Angaben von Suchvorschriften oder e<strong>in</strong>em Suchkontext erweitert<br />
werden. Diese wurden dann die ansonsten greifenden Standardannahmen<br />
ersetzen oder weiter verfe<strong>in</strong>ern. Die zur Zeit fur PAMELA de nierten Standarde<strong>in</strong>stellungen<br />
erlauben die " maximale\ Ausnutzung der durch die TRADE{<br />
Basisdienste gegebenen Moglichkeiten, so da im Rahmen von vorhandenen<br />
Trader{Kooperationen grundsatzlich beider Dienstauswahl immer auch Dienste<br />
anderer angeschlossener Verwaltungsdomanen berucksichtigt werden. Auf diese<br />
mu te dann nach der Dienstvermittlung gegebenfalls uber den Interzeptor zugegri<br />
en werden. In diesem Fall ware, beispielsweise falls die Anforderung nach<br />
moglichst schneller Ausfuhrung e<strong>in</strong>es Dienstaufrufes besteht, die Beschrankung<br />
auf lokal <strong>in</strong>nerhalbe<strong>in</strong>er Verwaltungsdomaneangebotene Dienste s<strong>in</strong>nvoll. In PA-<br />
MELA wurde auf derartige E<strong>in</strong> u moglichkeiten bisher ausdrucklich verzichtet,<br />
umdem Anwendungsprogrammierer e<strong>in</strong>en hochstmoglichen Grad an Abstraktion<br />
von den <strong>in</strong> TRADE <strong>in</strong> der Ausfuhrungsumgebung ablaufenden und <strong>in</strong>der Regel<br />
komplexen systemtechnischen Ablaufen zu bieten.<br />
Diese Entscheidung zuweitestgehender Programmierabstraktion <strong>in</strong> PAMELA<br />
sollte generell als e<strong>in</strong> Experiment angesehen werden, mit dem Erfahrungen im<br />
Umgang mit Diensten bei der Entwicklung von Kooperationsanwendungen im<br />
S<strong>in</strong>ne e<strong>in</strong>er komponenten{ oder Work ow{basierten Programmiersichtweise gesammelt<br />
werden konnen. PAMELA versteht sich hierbei als e<strong>in</strong> Hilfsmittel, das<br />
|angesichts der Forderungen bei der Entwicklung verteilter Anwendungen unter<br />
anderem nachAusdrucksmoglichkeiten fur Nebenlau gkeit, Transaktionalitat<br />
und automatischer Fehlerbehandlung |e<strong>in</strong>eAnwendungsentwicklung erlaubt,
218 Entwicklung und Ausfuhrung von Kooperationsanwendungen<br />
die mit verhaltnisma ig ger<strong>in</strong>gem Aufwand durchfuhrbar ist. So haben die bisherigen<br />
Erfahrungen mit PAMELA gezeigt, da mit ihr sehr schnell | im S<strong>in</strong>ne<br />
e<strong>in</strong>es Rapid{Prototyp<strong>in</strong>g |neue Anwendungen aus bereitsvorhandenen Diensten<br />
zusammengesetzt werden konnen, die dann anschlie end unter Verwendung des<br />
Koord<strong>in</strong>ationsmanagers sofort ausfuhr{ und austestbar s<strong>in</strong>d. Dieses wird <strong>in</strong>sbesondere<br />
bei dem gezeigten Application Builder und der Taschenrechneranwendung<br />
deutlich, bei der verschiedene Dienstangebote durch e<strong>in</strong>faches " drag<br />
& drop\ genutzt und getestet sowie auch zur Laufzeit durch andere Dienstangebote<br />
ausgetauscht werden konnen. Systemtechnisch unterstutzt wird dieser<br />
Entwicklungsproze von Kooperationsanwendungen durch den <strong>in</strong> der TRADE{<br />
Systemumgebung prototypisch realisierten Koord<strong>in</strong>ationsmanager,der samtliche<br />
Funktionen zur Dienstkoord<strong>in</strong>ation zur Verfugung stellt. Hierbei kann er aufgrund<br />
des <strong>in</strong> PAMELA gewahlten Ansatzes, ausschlie lich koord<strong>in</strong>ativeAspekte<br />
der Steuerung und Uberwachung der <strong>in</strong> den Anwendungsvorgangen genutzten<br />
Dienste zubeschreiben, als eigenstandiger, generischer Koord<strong>in</strong>ationsdienst realisiert<br />
werden. Dieser fuhrt fur alle <strong>in</strong> PAMELA spezi zierten Kooperationsanwendungen<br />
die Anwendungssteuerung und {kontrolle durch und ubernimmt damit<br />
die bisherigen Aufgaben von herkommlichen Klientenanwendungen. Fur den<br />
Anwendungsprogrammierer ergibt sichdadurch die Moglichkeit zur direkten und<br />
automatischen Ausfuhrungder von ihm spezi zierten Kooperationsanwendungen.
Teil III<br />
Zusammenfassung und Ausblick
Zusammenfassung und Ausblick 221<br />
Ausgangspunkt fur diese Arbeit war die Betrachtung o ener heterogener verteilter<br />
Dienstemarkte, <strong>in</strong> denen Dienstnutzern e<strong>in</strong>e Vielzahl und Vielfalt von<br />
Diensten an unterschiedlichen Orten angeboten werden. Diese Dienste sollen<br />
pr<strong>in</strong>zipiell <strong>in</strong> beliebiger Art und Weise bei der Entwicklungverteilter Anwendungen<br />
genutzt werden konnen, um e<strong>in</strong>en hohen Grad an Wiederverwendung und<br />
somit an E zienzgew<strong>in</strong>n bei der Anwendungsentwicklung zu erreichen. Bevor<br />
jedoch e<strong>in</strong>ederartig une<strong>in</strong>geschrankte <strong>Dienstnutzung</strong> und Komb<strong>in</strong>ation zu neuen<br />
<strong>verteilten</strong> Anwendungen realisiert werden kann, s<strong>in</strong>d sowohl modellierungs{<br />
als auch systemtechnische Voraussetzungen zu erfullen:<br />
Geeignete Modellierung von Diensten <strong>in</strong> o enen <strong>verteilten</strong> Dienstemarkten<br />
Die Modellierung von Diensten mu aus der Sicht e<strong>in</strong>es Dienstnutzers e<strong>in</strong>e<br />
e<strong>in</strong>heitlicheBehandlungder <strong>in</strong> der Regel auf der Basis unterschiedlicher verteilter<br />
Systemplattformen und organisationeller Rahmenbed<strong>in</strong>gungen entwickelten<br />
und realisierten Dienstleistungen moglich machen. In dieser Arbeit<br />
wird hierfur e<strong>in</strong> objektbasiertes Dienstmodell vorgeschlagen, welches<br />
durch se<strong>in</strong>en Diensttypbegri e<strong>in</strong>en hohen Grad an Abstraktion von der<br />
eigentlichen Realisierung e<strong>in</strong>er Dienstleistung bietet (siehe Abschnitt 2.2).<br />
Bereitstellung geeigneter formaler Beschreibungsmittel, mit denen Dienstleistungen<br />
auch bezuglich ihrer Semantik beschrieben werden konnen<br />
Bei der Beschreibung von Diensten mu generell zwischen der Ausdrucksmachtigkeit<br />
auf der e<strong>in</strong>en Seite und der Automatisierbarkeit ihrer<br />
Verarbeitung auf der anderen Seite abgewogen werden. Aus diesem Grund<br />
wird <strong>in</strong> dieser Arbeit die Beschreibung von Diensten mittels Operationssignaturen<br />
und Dienstattributen als e<strong>in</strong>e hierfur geeignete Kompromi losung<br />
unterstutzt (siehe Abschnitt 2.4.5). Aufgrund ihres hohen Grades an automatischer<br />
Verarbeitung, vor allem bei dem Vergleich und der Suche von<br />
Dienstbeschreibungen, bildet diese Art der Beschreibung e<strong>in</strong>e geeignete<br />
Grundlage fur die <strong>in</strong> dieser Arbeit entwickelten Dienstzugangsmechanismen<br />
(Typmanagement, Dienstvermittlung, Interzeption) und Koord<strong>in</strong>ationsmechanismen<br />
(Dienstkoord<strong>in</strong>ation), da diese <strong>in</strong> der Regel selbst hochgradig<br />
automatisch ablaufen bzw. e<strong>in</strong>e automatische Ausfuhrung der <strong>in</strong><br />
dieser Arbeit speziell betrachteten Kooperationsanwendungen unterstutzen<br />
mussen.<br />
Systemtechnische Unterstutzung der Entwicklung verteilter Anwendungen<br />
unter weitestgehender bzw. ausschlie licher Nutzung von Diensten<br />
Bei konsequenter Wiederverwendung und Neukomb<strong>in</strong>ation bereits irgendwo<br />
<strong>in</strong> o enen <strong>verteilten</strong> Dienstemarkten vorhandener Dienste spielt <strong>in</strong>sbesondere<br />
die Beschreibung ihrer Koord<strong>in</strong>ation e<strong>in</strong>e wichtige Rolle. Hierzu<br />
schlagt diese Arbeit die Abstraktion der Kooperationsanwendungen<br />
vor, die aufbauend auf dem formalen Ansatz e<strong>in</strong>es erweiterten gefarbten<br />
Petri{Netzes die Beschreibung strukturierter <strong>Dienstnutzung</strong> imRahmen<br />
von Anwendungsvorgangen erlaubt (siehe Abschnitt 4.2). Dieser Ansatz<br />
beruht auf der Beschreibung der Kooperationsbeziehungen der genutzten<br />
Dienste. Hierzu stellt ererweiterte Petri{Netz{basierte Ausdrucksmittel
222 Zusammenfassung und Ausblick<br />
zur Verfugung, mit denen unter anderem die | moglicherweise transaktionale<br />
| nebenlau ge oder sequentielle <strong>Dienstnutzung</strong> imRahmen von<br />
Anwendungsvorgangen dargestellt werden kann. Kernkonzept ist hierbei<br />
das dienstorientierte Aktionskonzept, welches die Kopplung der Dienste<br />
zum ubergeordneten Anwendungsablauf ermoglicht. Insgesamt bildet der<br />
gewahlte Petri{Netz{basierte Beschreibungsansatz die Grundlage fur die<br />
anschlie ende Umsetzung <strong>in</strong> die konkrete Koord<strong>in</strong>ationssprache PAMELA,<br />
die <strong>in</strong>nerhalbvon TRADE zur Entwicklungvon Kooperationsanwendungen<br />
e<strong>in</strong>gesetzt wird.<br />
Unterstutzungder Ausfuhrungund Steuerungvon Kooperationsanwendungen<br />
Um Kooperationsanwendungen bzw. die dort enthaltenen Anwendungsvorgange<br />
ausfuhren zu konnen, mussen die entsprechenden PAMELA{<br />
Beschreibungen <strong>in</strong> e<strong>in</strong>e ablau ahige Form uberfuhrt werden. Diese Arbeit<br />
schlagt hierfur die Bereitstellung e<strong>in</strong>es dedizierten Koord<strong>in</strong>ationsdienstes<br />
|den Koord<strong>in</strong>ationsmanager |vor, welcher e<strong>in</strong>e direkte Ausfuhrung der<br />
spezi zierten Anwendungsvorgange vornimmt. Bei der Entwicklungder im<br />
Koord<strong>in</strong>ationsmanager benotigten Steuerungsmechanismen konnte ausgenutzt<br />
werden, da mit der <strong>in</strong> Petri{Netzen gegebenen Schaltsemantik zugleich<br />
auch e<strong>in</strong>e geeignete Ausgangsbasis fur ihre Realisierung gegeben ist.<br />
Dieses wurde <strong>in</strong>sbesondere bei den realisierten Verarbeitungsalgorithmen<br />
deutlich, <strong>in</strong> denen das <strong>in</strong> Petri{Netzen de nierte Schalten von Transitionen<br />
nachgebildet wird (siehe Abschnitt 6.2.3.2). Insgesamt ubernimmt der<br />
Koord<strong>in</strong>ationsmanager somit die Aufgabe herkommlicher Klientenanwendungen,<br />
<strong>in</strong>dem er die bisher jeweils fur jede Kooperationsanwendung neu<br />
zu entwickelnden Steuerungsmechanismen als generische Dienstleistung im<br />
Dienstemarkt anbietet. Diese Dienstleistung kanndann beispielsweise uber<br />
die aus PAMELA{Beschreibungen generierten Koord<strong>in</strong>ationsmanagerklienten<br />
auf e<strong>in</strong>fache Art und Weise <strong>in</strong> Anspruch genommen werden (siehe<br />
Abschnitt 6.2.1).<br />
Systemtechnische Unterstutzung des Dienstzugangs <strong>in</strong> heterogenen Systemumgebungen<br />
Voraussetzung fur die Realisierung des Koord<strong>in</strong>ationsmanagers bilden diejenigen<br />
Systemtechniken, die trotz der <strong>in</strong> <strong>verteilten</strong> Dienstemarkten vorhandenen<br />
technischen und adm<strong>in</strong>istrativen Heterogenitat e<strong>in</strong>en weitgehend<br />
une<strong>in</strong>geschrankten Zugang zuden dort angebotenen Diensten ermoglichen.<br />
Fur e<strong>in</strong>e Untersuchung geeigneter Systemmechanismen wurden hierzu<br />
zunachst wesentliche Heterogenitatsprobleme bei der <strong>Dienstnutzung</strong> <strong>in</strong><br />
o enen <strong>verteilten</strong> Dienstemarkten charakterisiert und e<strong>in</strong>eAufteilung des<br />
Dienstzugangs <strong>in</strong> die Phasen der Diensttyp ndung, der Dienstvermittlung<br />
und des Dienstzugri s vorgenommen (siehe Kapitel 3). Diese erlaubt e<strong>in</strong>e<br />
problemorientierte Betrachtung der fur die e<strong>in</strong>zelnen Phasen am besten<br />
geeigneten Systemmechanismen, ohne jedoch gleichzeitig ihre Integration<br />
h<strong>in</strong>sichtlich der Unterstutzungdes gesamten Dienstzugangs aus den Augen<br />
zu verlieren. E<strong>in</strong>es der Ergebnisse dieser Untersuchungen ist der Vorschlag
Zusammenfassung und Ausblick 223<br />
der Komb<strong>in</strong>ation von Typmanagement{, Dienstvermittlungs{ undInterzeptionsmechanismen<br />
<strong>in</strong> e<strong>in</strong>em <strong>in</strong>tegrierten Ansatz (siehe Abschnitt 3.5). Dieser<br />
legt sowohl die zur Unterstutzung der e<strong>in</strong>zelnen Dienstzugangsphasen<br />
zu erbr<strong>in</strong>genden Funktionen als auch die gegenseitigen Kooperationsbeziehungen<br />
zwischen den identi zierten Systemmechanismen fest. Die Kooperationsbeziehungen<br />
werden <strong>in</strong>sbesondere bei den im Rahmen des Projektes<br />
Interwork<strong>in</strong>g of Traders untersuchten Formen von Trader{Kooperationen<br />
deutlich, bei denen e<strong>in</strong>e enge Beziehung zwischen den Typmanagern und<br />
den Tradern bei der domanenubergreifenden Dienstvermittlung besteht<br />
(siehe Abschnitt 3.3.3.2). F<strong>in</strong>den derartige Trader{Kooperationen au erdem<br />
noch uber technischeHeterogenitatsgrenzen statt, so bestehen weitere<br />
Beziehungenzuden Interzeptoren, die e<strong>in</strong>e derartige plattformubergreifende<br />
Kooperation erst ermoglichen.<br />
Die Umsetzung der obigen, fur die Unterstutzung koord<strong>in</strong>ierter <strong>Dienstnutzung</strong><br />
<strong>in</strong> o enen heterogenen <strong>verteilten</strong> Dienstemarkten benotigten Systemmechanismen<br />
<strong>in</strong> e<strong>in</strong>em <strong>in</strong>tegrierten Losungsansatz wurde imRahmen dieser Arbeit anhand<br />
der Service Trad<strong>in</strong>g and Coord<strong>in</strong>ation Environment (TRADE) praktisch<br />
demonstriert. Mit TRADE wird vor allem der Nachweis der Realisierbarkeit<br />
der <strong>in</strong> Teil I und IIentwickelten Losungsansatze <strong>in</strong> verteilte Systemumgebungen<br />
auf der Grundlage existierender und derzeit besonders praxisrelevanter verteilter<br />
Systemplattformen erbracht. Neben der praktischen Evaluierung der e<strong>in</strong>zelnen<br />
Systemmechanismen unter den <strong>in</strong> TRADE nachgebildeten realistischen Bed<strong>in</strong>gungen<br />
heterogener verteilter Dienstemarkte ermoglicht die Prototypimplementation<br />
zudem auch Aufschlusse uber die derzeitigen De zite der genutzten Systemplattformen,<br />
die sich vor allem <strong>in</strong> den Bereichen des Typmanagements und<br />
der Dienstvermittlung zeigen (siehe unter anderem Abschnitte 3.2.2 und 3.4.1.4).<br />
Konkrete Untersuchungs{ und Realisierungsgrundlage bilden die beiden <strong>verteilten</strong><br />
Systemplattformen DCE und CORBA, die vor allem aufgrund ihrer weiten<br />
Verbreitung und ihrer zahlreichen bereits standardma ig angebotenen Funktionalitat<br />
zur Unterstutzung genereller verteilter Verarbeitung, beispielsweise den<br />
Namensdiensten <strong>in</strong> DCE, als besonders <strong>in</strong>teressante stellvertretende Beispiele<br />
auch fur andere Systemplattformen gewahlt wurden. Obwohl bei der Umsetzung<br />
e<strong>in</strong>zelner Systemmechanismen, wie beispielsweise des TRADErs und des<br />
Interzeptors, spezi zische Eigenschaften der beiden Systemplattformen ausgenutzt<br />
wurden, lassen sich die hierbei erzielten Ergebnisse vergleichsweise e<strong>in</strong>fach<br />
unddirektauchauf andere verteilte Systemplattformen ubertragen. Dieses wurde<br />
vor allem durch e<strong>in</strong>ehochgradige Modularisierung der e<strong>in</strong>zelnen Losungsansatze<br />
erreicht, wie sie sich unmittelbar <strong>in</strong> dem Aufbau des TRADErs, des Typmanagers,<br />
des Interzeptors und des Koord<strong>in</strong>ationsmanagers widerspiegelt (siehe Teil<br />
II).<br />
Bei zusammenfassender Betrachtung der im Rahmen dieser Arbeit entwickelten<br />
System{ und Beschreibungsmechanismen ergibt sich die <strong>in</strong> Abbildung 6.9<br />
gezeigte Darstellung, welche die Gesamtarchitektur der konzipierten und prototypisch<br />
realisierten <strong>verteilten</strong> TRADE{Systemumgebung zeigt. TRADE erfullt<br />
damit mit den vorgeschlagenen und realisierten Mechanismen die e<strong>in</strong>gangs die-
224 Zusammenfassung und Ausblick<br />
PAMELA-Beschreibung<br />
Trader<br />
Typmanager<br />
DCE-Dienste<br />
Koord<strong>in</strong>ationsmanager<br />
Adm<strong>in</strong>istrative<br />
Heterogenitätsgrenze<br />
Dienstkoord<strong>in</strong>ation<br />
TRADEr<br />
Typmanager<br />
DCE-Dienste<br />
Interzeptor<br />
Technische/<br />
adm<strong>in</strong>istrative<br />
Heterogenitätsgrenze<br />
Diensttypbeschreibungen<br />
Übergang zwischen Entwicklungsund<br />
Ausführungsumgebung<br />
Domänenübergreifender<br />
Dienstzugang<br />
Broker<br />
Typmanager<br />
CORBA-Dienste<br />
Abbildung 6.9: TRADE{Gesamtarchitektur zur Unterstutzung koord<strong>in</strong>ierter<br />
<strong>Dienstnutzung</strong> <strong>in</strong>o enen heterogenen <strong>verteilten</strong> Dienstemarkten<br />
ser Arbeit gestellte Anforderung nach moglichst weitgehender systemtechnischer<br />
Unterstutzung der e zienten Wiederverwendung und Neukomb<strong>in</strong>ation von <strong>in</strong><br />
o enen <strong>verteilten</strong> Dienstemarkten angebotenen Diensten zu neuen <strong>verteilten</strong> Anwendungen.<br />
Ermoglicht wird dieses durch die Bereitstellung der Systemmechanismen<br />
<strong>in</strong> der Ausfuhrungsumgebung, die e<strong>in</strong>e une<strong>in</strong>geschrankte domanenubergreifende<br />
und uber Heterogenitatsgrenzen h<strong>in</strong>ausreichende <strong>Dienstnutzung</strong> realisieren.<br />
Hierzu wurden vor allem entsprechende verteilte Mechanismen zur Unterstutzung<br />
des Diensttypmanagements, der Dienstvermittlung, des Dienstzugri<br />
s und der Dienstkoord<strong>in</strong>ation entwickelt. Die konkretekoord<strong>in</strong>ierte Nutzung<br />
der nun domanenubergreifend zur Verfugung stehenden Dienste von Seiten der<br />
Anwendungsprogrammierer oder Endbenutzer geschieht mit Hilfe der Koord<strong>in</strong>ationssprachePAMELA,<br />
welche e<strong>in</strong>en hohen Grad an Programmierabstraktion<br />
unter anderem durch ihre Konzentration auf die Beschreibung der koord<strong>in</strong>ativen<br />
Aspekte von <strong>Dienstnutzung</strong> bietet. Durch die bereitgestellte weitestgehende<br />
Verteilungsabstraktion spielt esdabei <strong>in</strong> PAMELA <strong>in</strong>sbesondere ke<strong>in</strong>e Rolle,<br />
ob die genutzten Dienste auf Basis von CORBA oder DCE entwickelt wurden.<br />
Zusammengenommen ergibt sich somit fur die Anwendungsprogrammierung die
Zusammenfassung und Ausblick 225<br />
Moglichkeit zur weitgehend une<strong>in</strong>geschrankten Nutzung der <strong>in</strong> o enen heterogenen<br />
Dienstemarkten angebotenen Dienste, wobei samtliche Heterogenitatsaspekte<br />
durch Verwendung des <strong>in</strong> TRADE bzw. von PAMELA bereitgestellten<br />
e<strong>in</strong>heitlichen Diensttypbegri s verborgen werden. Die Ausfuhrung e<strong>in</strong>er derartig<br />
spezi zierten Kooperationsanwendung kann anschlie end automatischdurch den<br />
Koord<strong>in</strong>ationsmanager gesteuert erfolgen. Dieser ubernimmt im Zusammenspiel<br />
mit den Tradern und Typmanagern sowie Interzeptoren samtliche Aufgaben der<br />
Anwendungssteuerung.<br />
Die Art und Weise der Anwendungsentwicklung mittels PAMELA und dem dazugehorigen<br />
Koord<strong>in</strong>ationsmanager sollte hierbei zunachst als e<strong>in</strong> erstes Experiment<br />
angesehen werden, mit dem e<strong>in</strong>e e<strong>in</strong>fache und koord<strong>in</strong>ierte Nutzung der<br />
<strong>in</strong> o enen heterogenen <strong>verteilten</strong> Dienstemarkten angebotenen Dienste erreicht<br />
werden kann. PAMELA bietet hierdurch auch e<strong>in</strong>emogliche Antwort auf die <strong>in</strong><br />
der E<strong>in</strong>leitung vorgestellte Vision ausschlie licher <strong>Dienstnutzung</strong> beider Entwicklung<br />
zukunftiger verteilter Anwendungen. Durch die <strong>in</strong> Abschnitt 6.1.2.4<br />
gezeigten Beispiele e<strong>in</strong>er Hotel{ und e<strong>in</strong>er Taschenrechneranwendung konnte<br />
die Praktikabilitat des Koord<strong>in</strong>ationsansatzes von PAMELA demonstriert werden.<br />
Inwieweit die dort gemachten Erfahrungen <strong>in</strong> dieser Form auch auf andere<br />
Anwendungsbereiche verallgeme<strong>in</strong>erbar s<strong>in</strong>d, mu <strong>in</strong> anderen Anwendungsentwicklungsprojekten<br />
zukunftig noch weiter untersucht werden. In diesem Zusammenhang<br />
ware auch zuuberlegen, <strong>in</strong>wieweit die Anwendungsentwicklung durch<br />
zusatzliche komfortable Entwicklungswerkzeuge noch weiter unterstutzt werden<br />
sollte. So konnte beispielsweise die <strong>in</strong> Abschnitt 4.2 vorgestellte, an Petri{Netzen<br />
angelehnte graphische Notation von Anwendungsvorgangen als Grundlage fur<br />
die Entwicklung e<strong>in</strong>es graphischen Programmierwerkzeuges verwendet werden.<br />
Hierbei konnten unter anderem auch die " drag & drop\{Verfahren des bei der<br />
Taschenrechneranwendung vorgestellten Application Builder herangezogen werden.
Anhang A<br />
Koord<strong>in</strong>ationssprache PAMELA<br />
A.1 Beschreibung der Syntax und Semantik<br />
Dieser Anhang gibte<strong>in</strong>e Ubersicht uber die e<strong>in</strong>zelnen PAMELA{Konstrukte<br />
durch Angabe ihrer grammatikalischen Produktionen. Weiterh<strong>in</strong> wird e<strong>in</strong>e <strong>in</strong>formale<br />
Beschreibung der zugehorigen Semantik gegeben und verschiedene<br />
PAMELA{Programmbeispiele vorgestellt, die jeweils die sprachliche Umsetzung<br />
der <strong>in</strong> Kapitel 4.2 e<strong>in</strong>gefuhrten Modellierungs{ bzw. Beschreibungskonzepte zeigen.<br />
Tabelle A.1 verdeutlichtdiefur die weitere Beschreibung verwendeteNotation <strong>in</strong><br />
Erweiterter Backus{Naur Form. PAMELA{Beschreibungen folgen den gleichen<br />
lexikalischen Regeln wie die CORBA{IDL, die ihrerseits auf der Sprache C++<br />
aufsetzt. Im Rahmen des PAMELA{Entwurfs wurden die von der CORBA{<br />
IDL stammenden Regeln lediglich umneue Schlusselworter zur Beschreibung<br />
von Anwendungsvorgangen erganzt. Daher soll hier auf e<strong>in</strong>e weitere Au istung<br />
der grundlegenden lexikalischen Konventionen verzichtet und stattdessen auf den<br />
CORBA{Standard [OMG91] verwiesen werden.<br />
Symbol Bedeutung<br />
::=<br />
" ist de niert als\<br />
| Alternative<br />
normal e<strong>in</strong> Nicht-Term<strong>in</strong>al<br />
" fett\ e<strong>in</strong> Term<strong>in</strong>al<br />
" der voranstehende Ausdruck kann e<strong>in</strong>{, mehrfach oder<br />
gar nicht auftreten\<br />
+<br />
" der voranstehende Ausdruck kann e<strong>in</strong>{ oder mehrfach auftreten\<br />
fg Gruppierung<br />
[] Option<br />
Tabelle A.1: Konventionen der angefuhrten Grammatik
228 Koord<strong>in</strong>ationssprache PAMELA<br />
Bezeichnung CORBA{Bezeichnung<br />
ident ist e<strong>in</strong> identi er<br />
name entspricht e<strong>in</strong>em scoped name<br />
<strong>in</strong>herit entspricht e<strong>in</strong>em <strong>in</strong>heritance spec<br />
<strong>in</strong>tcon ist e<strong>in</strong>e <strong>in</strong>teger Konstante<br />
charcon ist e<strong>in</strong>e character Konstante<br />
floatcon ist e<strong>in</strong>e oat Konstante<br />
str<strong>in</strong>g ist e<strong>in</strong>e str<strong>in</strong>g Zeichenkette<br />
Tabelle A.2: Abgekurzte Nicht{Term<strong>in</strong>ale der CORBA{Spezi kation<br />
In den aufgefuhrten Produktionen ersche<strong>in</strong>en e<strong>in</strong>ige unde nierte Nicht{<br />
Term<strong>in</strong>ale, die entweder unmittelbar der CORBA{Spezi kation entnommen<br />
oder als Abkurzungen ihrer Entsprechungen <strong>in</strong> der CORBA{Spezi kation<br />
aufzufassen s<strong>in</strong>d. Sie werden im folgenden, beispielsweise die Basisdatentypen<br />
<strong>in</strong>t oder char,nichtweiter erlautert. Tabelle A.2 gibt hierzu e<strong>in</strong>e Ubersicht. Der<br />
zur CORBA{IDL gehorende Praprozessor entspricht dem C++{Praprozessor,<br />
so da er auch <strong>in</strong>PAMELA{Programmen verwendet werden kann, womit unter<br />
anderem das E<strong>in</strong>b<strong>in</strong>den von anderen IDL{Dateien moglich ist. E<strong>in</strong>ige CORBA{<br />
IDL{Konstrukte erhalten im Zusammenhang mit PAMELA{Programmen<br />
e<strong>in</strong>e erweiterte Semantik, auf die im folgenden an den entsprechenden Stellen<br />
h<strong>in</strong>gewiesen wird. E<strong>in</strong>e Zusammenfassung der Grammatik und der reservierten<br />
Worter der Sprache geben Anhange A.1.2 und A.1.3.<br />
process{De nition<br />
E<strong>in</strong> Proze <strong>in</strong> PAMELA wird durch das Schlusselwort process gefolgt von<br />
e<strong>in</strong>em Proze namen beschrieben. Dem Namen ist eventuell noch e<strong>in</strong>e Liste<br />
von " Eltern\{Prozessen angefugt, deren Netzbeschreibung geerbt wird. Bei Namensubere<strong>in</strong>stimmungen<br />
von Proze komponenten haben die jeweils am weitesten<br />
rechts<strong>in</strong>der Vererbungslistestehenden De nitionen Vorang, es sei denn, sie werden<br />
durch den erbenden Proze selbst neude niert. E<strong>in</strong>e Vorwartsdeklaration ist<br />
zulassig. Prozesse konnen nicht<strong>in</strong>e<strong>in</strong>ander verschachteltwerden. Bei Angabe von<br />
mehreren Prozessen werden dem Koord<strong>in</strong>ationsmanager (siehe Abschnitt 6.2)<br />
alle Netzbeschreibungen e<strong>in</strong>zeln an der De nitionsschnittstelle ubergeben. E<strong>in</strong>e<br />
Kopplung verschiedener Netze bzw. Prozesse kann jedoch mittels von export{<br />
und import{Anweisungen erfolgen (siehe Abbildung A.1)).<br />
process decl ::= \process" ident <strong>in</strong>herit \f" process body \g" \�"<br />
| \process" ident \�"<br />
Der Proze rumpf enthalt <strong>in</strong> beliebiger Abfolge beliebig viele Deklarationen von<br />
Markentypen, Stellen und Transitionen. Er darf jedoch nicht leer se<strong>in</strong>, sondern
A.1 Beschreibung der Syntax und Semantik 229<br />
mu nach der optionalen Au istung e<strong>in</strong>oder mehrerer export{ und import{<br />
Anweisungen m<strong>in</strong>destens e<strong>in</strong>e der vorgenannten Deklarationen enthalten.<br />
process body ::= [ extern decls ]<br />
f token decl | place decl | trans decl g +<br />
extern decls ::= f import decl | export decl g +<br />
import{ und export{Deklarationen<br />
Die Import{Sektion des Proze rumpfes ermoglicht die Verknupfung mitanderen<br />
Prozessen durch die geme<strong>in</strong>same Nutzung bestimmter L<strong>in</strong>k{Stellen. Zudem<br />
be<strong>in</strong>haltet sie auch die Deklaration von Dienstschnittstellen, deren Operationen<br />
fur die Nutzung <strong>in</strong>den Transitionen an dieser Stelle e<strong>in</strong>gefuhrt werden, Dieses<br />
geschieht durch das unten erlauterte service{Konstrukt von PAMELA (siehe<br />
auch Abbildung A.2).<br />
import decl ::= \import" \:" import body<br />
import body ::= f l<strong>in</strong>k decl | serv decl g +<br />
export decl ::= \export" \:" export body<br />
export body ::= f l<strong>in</strong>k decl g +<br />
l<strong>in</strong>k decl ::= \l<strong>in</strong>k" name f \," name g \�"<br />
Mit Hilfe der l<strong>in</strong>k{Deklaration werden geme<strong>in</strong>sam zu nutzende Stellen durch<br />
Aufzahlung ihrer Namen e<strong>in</strong>gefuhrt. Genutzt werden konnen diese ausgezeichneten<br />
Stellen dann durch synchrone oder asynchrone Task-Transitionen (siehe<br />
unten). Analog kann e<strong>in</strong> Proze auch Stellen aus se<strong>in</strong>em eigenen Netz anderen<br />
Prozessen mittels der export{Deklaration freigeben. Diensttypbeschreibungen<br />
selbst konnen nicht exportiert werden, da sie nicht von e<strong>in</strong>em Proze selbst<br />
realisiert, sondern nach dem Grundkonzept von PAMELA von au en <strong>in</strong>tegriert<br />
werden.<br />
process CreditCard {<br />
export:<br />
l<strong>in</strong>k newOrder;<br />
...<br />
};<br />
process Amex : CreditCard {<br />
...<br />
};<br />
process Master : CreditCard {<br />
...<br />
};<br />
process Bank {<br />
import:<br />
l<strong>in</strong>k newOrder;<br />
...<br />
};<br />
Abbildung A.1:PAMELA-Beispiel: Verknupfung von Prozessen
230 Koord<strong>in</strong>ationssprache PAMELA<br />
Alle von Prozessen exportierten Stellen werden im geme<strong>in</strong>samen Export{<br />
Namensraum verwaltet, <strong>in</strong>dem jedem enthaltenem Namen se<strong>in</strong> zugehoriger<br />
exportierender Proze name vorangestellt ist. Dadurch kann durch die Angabe<br />
e<strong>in</strong>es entsprechenden Gultigkeitsbereichs (engl. namescope) jede Stelle e<strong>in</strong>deutig<br />
identi ziert werden.<br />
service{Konstrukt<br />
Das service{Konstrukt erlaubt die Angabe e<strong>in</strong>es CORBA{Modulnamens. Dabei<br />
spezi ziert das Modul e<strong>in</strong>en Diensttyp,<strong>in</strong>dem er e<strong>in</strong>e <strong>in</strong>terface{Deklaration<br />
zur Beschreibung der operationalen Schnittstellen und beliebig viele attribute{<br />
Deklarationen zur De nition der Dienstattribute enthalt. 1 Die <strong>in</strong> e<strong>in</strong>em Proze<br />
gewunschten Schnittstellen konnen anschlie end durch e<strong>in</strong>e with{Klausel der<br />
actions{Deklaration selektiert werden.<br />
module ::= \module" ident \f" f attr dcl g \�"<br />
f def<strong>in</strong>ition g + f \�" attr dcl g \g"<br />
serv decl ::= \service" f ident \with" <strong>in</strong>terfaces \�" g +<br />
<strong>in</strong>terfaces ::= ident f \," ident g<br />
module CardService {<br />
<strong>in</strong>terface handleAccount {<br />
boolean checkAccount(<strong>in</strong> long account);<br />
};<br />
...<br />
};<br />
process CreditCard {<br />
import:<br />
service CardService with handleAccount;<br />
...<br />
Abbildung A.2:PAMELA{Beispiel: Nutzung und Integration von Diensttypbeschreibungen<br />
token{De nition<br />
Durch das Schlusselwort token konnen komplex strukturierte Typen als Markierung<br />
der Netz{Stellen de niert werden.<br />
1 Wie <strong>in</strong> Abschnitt 6.1.2.3 bereits angemerkt wurde, ist diese Art der Diensttypbeschreibung<br />
aquivalent zuder ansonsten <strong>in</strong> TRADE ublichen Beschreibung (siehe beispielsweise Abbildung<br />
5.1).
A.1 Beschreibung der Syntax und Semantik 231<br />
token decl ::= \token" ident <strong>in</strong>herit \f" token body \g" [ \�" ]<br />
| \token" ident \�"<br />
token body ::= f type spec declarators \�" g +<br />
Diesem Typnamen kann e<strong>in</strong>e Listeanderer token{Namen nachgestellt werden,<br />
deren De nitionen vererbt werden sollen. Bei vorhandener Namensgleichheit hat<br />
die <strong>in</strong> der Vererbungsliste amweitesten rechts stehende De nition Gultigkeit,<br />
au er der erbende Typ nimmt e<strong>in</strong>e Neude nition vor. Der token{Rumpf enthalt<br />
Bezeichnerdeklarationen, fur die alle <strong>in</strong> der CORBA{IDL vorhandenen Typen<br />
verwendet werden konnen.<br />
...<br />
token tCard {<br />
str<strong>in</strong>g id;<br />
long num;<br />
short acc;<br />
};<br />
...<br />
token tAmex : tCard {<br />
struct i_tag {<br />
str<strong>in</strong>g <strong>in</strong>s_name;<br />
long <strong>in</strong>s_num;<br />
} <strong>in</strong>surance;<br />
};<br />
Abbildung A.3:PAMELA{Beispiel: Typisierung von Marken<br />
places{Deklaration<br />
Vor der Verwendung von Bezeichnern fur die Stellen e<strong>in</strong>es Petri{Netzes mussen<br />
diesen Typen <strong>in</strong> Form von vorher de nierten token zugeordnet werden. Dieses<br />
geschieht <strong>in</strong>nerhalb e<strong>in</strong>oder mehrerer places{Sektionen.<br />
place decl ::= \places" \:" place body<br />
place body ::= f name ident f \," ident g g +<br />
trans{De nition<br />
E<strong>in</strong>e Transition wird durch Angabe des Schlusselwortes trans gefolgt von e<strong>in</strong>em<br />
Bezeichner de niert. Diesem Schlusselwort kann zusatzlich e<strong>in</strong> Spezi zierer<br />
voranstehen, der die Art der Transition festlegt:
232 Koord<strong>in</strong>ationssprache PAMELA<br />
Spezi zierer Auswirkung<br />
Regulare (synchrone) Transition<br />
sync Regulare (synchrone) Transition2 async Asynchrone Transition<br />
<strong>in</strong>it Starttransition e<strong>in</strong>es Netzes<br />
stask Synchrone Task{Transition<br />
atask Asynchrone Task{Transition<br />
transactional Transaktionale Ausfuhrung der Transitionsaktivitaten<br />
Tabelle A.3: Transitionsarten <strong>in</strong> PAMELA<br />
Jeder Proze besitzt grundsatzlich genau e<strong>in</strong>e <strong>in</strong>itiale Transition. Die Varianten<br />
der Task{Transitionen (stask, atask) entsprechen dem im Anwendungsmodell<br />
des Abschnitts 4.2.3.7 de nierten Verhalten.<br />
trans decl ::= [ \[" trans spec \]" ]<br />
\trans" ident \f" trans body \g" [ \�" ]<br />
trans spec ::= \sync" | \async"<br />
| \stask" | \atask"<br />
| \<strong>in</strong>it"<br />
| \transactional"<br />
trans body ::= f get decl | put decl | action decl g +<br />
Der Transitionsrumpf besteht aus e<strong>in</strong>er Folge von e<strong>in</strong>er oder mehreren get{,<br />
put{ bzw. actions{Sektionen. Diese bestimmen die Verknupfungen von Stellen<br />
mit E<strong>in</strong>gangs- und Ausgangskanten und legen au erdem die beim Schalten e<strong>in</strong>er<br />
Transition auszufuhrenden Aktivitaten bzw. Operationsaufrufe bei externen<br />
Diensten fest.<br />
process ...<br />
export:<br />
l<strong>in</strong>k signature;<br />
...<br />
[atask] trans signCard{<br />
get s from signature;<br />
put s to s_pool;<br />
...<br />
};<br />
};<br />
process ...<br />
export:<br />
l<strong>in</strong>k <strong>in</strong>_form, out_form;<br />
...<br />
[stask] trans orderCard {<br />
get f from <strong>in</strong>_form;<br />
put f to checkForm;<br />
get ok_form from pool;<br />
put ok_form to out_form;<br />
};<br />
};<br />
Abbildung A.4: PAMELA{Beispiel: Unterstutzung des Interaktionskonzeptes<br />
2 Die sync und async Varianten s<strong>in</strong>d fur zukunftige Erweiterungen vorgesehen.
A.1 Beschreibung der Syntax und Semantik 233<br />
get{Anweisung<br />
Das Schlusselwort get gefolgt von e<strong>in</strong> oder mehreren Bezeichnern erzeugt e<strong>in</strong>e<br />
entsprechende Anzahl von E<strong>in</strong>gangskanten fur die jeweilige Transition.<br />
get decl ::= \get" get body f [ \get" ] get body g<br />
get body ::= ident f \," ident g \from" ident \�"<br />
| ident f \," ident g \from" ident \if" com expr \�"<br />
Die Bezeichner stehen fur die entlang der Kanten bewegten Marken (token) und<br />
werden als Token{Variablen bezeichnet. Die Stelle, von der die Kante ausgehen<br />
soll, wird durch e<strong>in</strong>e from{Klausel und e<strong>in</strong>em nachgestellten Stellenbezeichner<br />
angegeben. Durch den Bezug auf e<strong>in</strong>e bestimmte Stelle wird der dazugehorigen<br />
Token{Variablen implizit ihr Typ zugewiesen, der vorher der Stelle zugeordnet<br />
wurde.<br />
Durch die Angabe e<strong>in</strong>es optionalen if{Konstruktes konnen zusatzliche Bed<strong>in</strong>gungen<br />
fur das Schalten e<strong>in</strong>es Transition <strong>in</strong> Form von Kantenbed<strong>in</strong>gungen spezi<br />
ziert werden. Dabei nden die weiter unten e<strong>in</strong>gefuhrten Ausdrucke (engl.<br />
expressions) Verwendung, <strong>in</strong> denen logische und vergleichende Operationen auf<br />
den Token{Variablen ausgefuhrt werden konnen.<br />
trans ...<br />
get card from atm if card.acc != 0;<br />
Abbildung A.5: PAMELA{Beispiel: Steuerung des Kontroll usses durch Kantenbed<strong>in</strong>gungen<br />
put{Anweisung<br />
Analog zu den E<strong>in</strong>gangskanten werden mittels der put{Anweisung die Ausgangskanten<br />
e<strong>in</strong>er Transition beschrieben. Falls die hierbei verwendeten Variablenbezeichner<br />
vorher <strong>in</strong> ke<strong>in</strong>er get{Anweisung benutzt wurden, werden sie zu diesem<br />
Zeitpunkt deklariert, wobei sie den Typ der <strong>in</strong> der to{Klausel bezeichneten Stelle<br />
erhalten. S<strong>in</strong>d sie bereitsdurche<strong>in</strong>e E<strong>in</strong>gangskantedeklariert worden, so mu der<br />
Typ der ursprunglichen E<strong>in</strong>gangsstelle und der jetzige Ausgangsstelle identisch<br />
se<strong>in</strong>.<br />
Durch die Angabe e<strong>in</strong>es optionalen with{Konstrukts konnen den Token{<br />
Variablen durch entsprechende Ausdrucke Werte zugewiesen werden (siehe<br />
unten). Ansonsten werden sie als anonyme Marken auf der dazugehorigen<br />
Ausgangsstelle abgelegt.<br />
E<strong>in</strong>e Transition kann mehrere unterschiedlich quali zierte, durch put{Sektionen<br />
gekennzeichnete Ausgangskanten besitzen. Diese beschreiben die regulare Weiterfuhrung<br />
der Transition, die generelle Fehlerbehandlung <strong>in</strong>der error{Sektion
234 Koord<strong>in</strong>ationssprache PAMELA<br />
und die Ergebnisbehandlung bei transaktionalen Transitionen <strong>in</strong>nerhalb der<br />
commit{ oder abort{Sektion (siehe Abbildung A.6).<br />
put decl ::= f [ put cond \:"]<br />
\put" put body f [ \put" ] put body g g +<br />
put cond ::= \commit" | \abort" | \error"<br />
put body ::= ident f \," ident g \to" ident<br />
| ident f \," ident g \to" ident \with" set decl<br />
set decl ::= set expr \�"<br />
| \f" f set expr \�" g + \g"<br />
[transactional] trans Bye {<br />
get g from guestList;<br />
commit:<br />
put g to checkOut;<br />
abort:<br />
put g to wait<strong>in</strong>gRoom;<br />
actions:<br />
par {<br />
checkRoomService(g.num);<br />
checkRestaurant(g.table);<br />
};<br />
};<br />
AbbildungA.6:PAMELA{Beispiel: Transaktion mit unterscheidbaren Ausgangskanten<br />
Ausdrucke<br />
Bei den bereits angesprochenen Ausdrucken lassen sich zume<strong>in</strong>en die <strong>in</strong> der<br />
if{Klausel und die zur Beschreibung von Dienstattributen verwendeten Vergleichsausdrucke<br />
und zumanderen die <strong>in</strong> den put{Sektionen benutzten Zuweisungsausdrucke<br />
unterscheiden.<br />
In beiden Fallen konnen Token{Variablen <strong>in</strong> e<strong>in</strong>er sogenannten " Punkt{<br />
Notation\ genutzt werden, die den Zugri auf Komponenten dieser Variablen<br />
erlaubt. Weiterh<strong>in</strong> s<strong>in</strong>d Konstanten der Basistypen erlaubt. Bei b<strong>in</strong>aren Operatoren<br />
mussen beide Operanden vom selben Typ se<strong>in</strong>, beim unaren not{Operator<br />
s<strong>in</strong>d nur boolesche Operanden zugelassen. Vergleichsausdrucke konnen beliebig<br />
geklammert werden.<br />
com expr ::= dotted ident
A.1 Beschreibung der Syntax und Semantik 235<br />
| set const<br />
| com expr \&&" com expr<br />
| com expr \||" com expr<br />
| \!" com expr<br />
| com expr \==" com expr<br />
| com expr \!=" com expr<br />
| com expr \>" com expr<br />
| com expr \
236 Koord<strong>in</strong>ationssprache PAMELA<br />
Symbol Bedeutung<br />
= Gleichsetzung<br />
+= Addition des rechten Operanden<br />
-= Subtraktion des rechten Operanden<br />
*= Multiplikation mit dem rechten Operanden<br />
/= Division durch den rechten Operanden<br />
%= Modulo{Division durch den rechten Operanden<br />
Tabelle A.5: Zulassige Operatoren <strong>in</strong> Zuweisungsausdrucken<br />
actions{Deklaration<br />
Das Schlusselwort actions kennzeichnet den Abschnitt e<strong>in</strong>er Transitionsbeschreibung,<br />
<strong>in</strong> der die auszufuhrende Aktivitat durch Angabe von Aktionen<br />
<strong>in</strong> Form von Operationsaufrufen mit ihren Parametern und Attributen festgelegt<br />
wird. Hierbei lassen sich mehrere Operationen mittels der par{ und seq{<br />
Konstrukte zuunter Umstanden auch verschachtelten Blocken zusammenfassen,<br />
die entsprechend nebenlau g oder sequentiell ausgefuhrt werden. Als Operationsparameter<br />
werden Token{Variablen mit ihren Komponenten <strong>in</strong> " Punkt{<br />
Notation\ angegeben. Etwaige Ruckgabewerteder aufgerufenen Operationen, die<br />
nicht uber Parameter sondern explizit als Operationsresultat zuruckgeliefert werden,<br />
konnen anschlie end e<strong>in</strong>er Token{Variable zugewiesen werden. Die Typen<br />
des Ruckgabewertes und der Parameter und deren Reihenfolge s<strong>in</strong>d durch die<br />
am Anfang der PAMELA{Beschreibung referenzierten Diensttypbeschreibungen<br />
festgelegt. Die fur die Wertaufnahme verwendeten Variablen mussen dabei<br />
denselben Typ besitzen. Generell konnen nur Operationen genutzt werden, die<br />
Bestandteil e<strong>in</strong>es <strong>in</strong> der service{Anweisung des import{Abschnitts importierten<br />
Diensttyps s<strong>in</strong>d.<br />
action decl ::= \actions" \:" action body<br />
action body ::= f f [ par | seq ] \f" action list \g" action use g<br />
| action list g +<br />
action list ::= f [ dotted ident \=" ]<br />
ident [ \(" param list \)" ] action use g +<br />
param list ::= dotted ident f \," dotted ident g
A.1 Beschreibung der Syntax und Semantik 237<br />
...<br />
trans CheckCard {<br />
...<br />
actions:<br />
readCard(card.id);<br />
par {<br />
ok.a = checkAccount(card.acc);<br />
ok.n = checkNumber(card.num);<br />
} us<strong>in</strong>g handleAccount;<br />
};<br />
};<br />
Abbildung A.7: PAMELA{Beispiel: Umsetzung des Aktionskonzepts<br />
us<strong>in</strong>g{Anweisung<br />
S<strong>in</strong>d die im Rahmen e<strong>in</strong>er PAMELA{Beschreibung verwendeten Operationsbezeichnungen<br />
aller importierten Schnittstellen unterschiedlich, konnen diese e<strong>in</strong>deutigen<br />
Namen ohneweitere Quali zierung benutzt werden. Diese E<strong>in</strong>deutigkeit<br />
kann jedoch beider Nutzung vieler verschiedener Dienstangebote nicht garantiert<br />
werden. In PAMELA exisitiert hierfur die us<strong>in</strong>g{Anweisung, die neben der<br />
Angabe der zur gewunschten Operation gehorigen Schnittstelle e<strong>in</strong>es bestimmten<br />
Diensttyps zusatzlichdieAngabe von gewunschten Dienstattributen erlaubt. Diese<br />
dienen anschlie end dem TRADEr fur die Steuerung se<strong>in</strong>er Dienstauswahl im<br />
Rahmen se<strong>in</strong>es gesta elten Auswertevorganges (siehe unter anderem Abschnitt<br />
5.2.2.3).<br />
action use ::= \us<strong>in</strong>g" name [ \with" com expr ] \�"<br />
| \�"<br />
S<strong>in</strong>d auch die Bezeichner der Schnittstellen nicht e<strong>in</strong>deutig, so kann dem jeweiligen<br />
Schnittstellentypbezeichner der Name se<strong>in</strong>es Diensttyps als Gultigkeitsbereich<br />
voran gestellt werden. Die erwunschten Attribute werden hierbei mittels<br />
der with{Anweisung festgelegt. Die angegebenen Bezeichner mussen denen <strong>in</strong><br />
der zugehorigen Diensttypbeschreibung entsprechen und konnen <strong>in</strong> Ausdrucken<br />
zusammen mit Konstanten undVariablen auftreten. E<strong>in</strong>e us<strong>in</strong>g{Anweisungkann<br />
auch auf e<strong>in</strong>en ganzen Block von Operationen bezogen werden, wobei dann die<br />
angegebene Schnittstelle und die vorgegebenen Dienstattribute fur alle enthaltenen<br />
Operationsaufrufe gultig s<strong>in</strong>d.<br />
actions:<br />
checkAccount(c.acc)<br />
us<strong>in</strong>g handleAccount with responseTime < 90;<br />
Abbildung A.8: PAMELA{Beispiel: Dienstauswahl durch Attributquali zierung
238 Koord<strong>in</strong>ationssprache PAMELA<br />
A.1.1 Darstellung der Programmstruktur<br />
Insgesamt ergibt sich unter Verwendung der oben dargestellten Sprachelemente<br />
die <strong>in</strong> Abbildung A.9 gezeigte pr<strong>in</strong>zipielle Struktur e<strong>in</strong>es PAMELA{Programms.<br />
module sName {<br />
attribute attrib;<br />
<strong>in</strong>terface iName {<br />
void a1Name(<strong>in</strong> long l);<br />
};<br />
};<br />
process pName {<br />
import:<br />
l<strong>in</strong>k lname;<br />
service sName with iName;<br />
export:<br />
l<strong>in</strong>k ...;<br />
token tName {<br />
long v;<br />
...<br />
};<br />
places:<br />
tName plName;<br />
[<strong>in</strong>it] trans tiName {<br />
put mName to plName;<br />
...<br />
};<br />
trans tnName {<br />
get mName from plName if mName.v > 5;<br />
put mName to plName with mName.v = 3;<br />
error:<br />
put mName to plName with mName.v = 0;<br />
actions:<br />
seq {<br />
a1Name(mName.v) us<strong>in</strong>g iName<br />
with attrib
A.1 Beschreibung der Syntax und Semantik 239<br />
A.1.2 Vollstandige Grammatik<br />
Im folgenden wird die <strong>in</strong> Anhang A.1 schrittweise vorgestellte Grammatik von<br />
PAMELA vollstandig angegeben. Die Notation richtet sich nach den oben e<strong>in</strong>gefuhrten<br />
Konventionen.<br />
module ::= \module" ident \f" f attr dcl g \�"<br />
f def<strong>in</strong>ition g + f \�" attr dcl g \g"<br />
process decl ::= \process" ident <strong>in</strong>herit \f" process body \g" \�"<br />
| \process" ident \�"<br />
process body ::= [ extern decls ]<br />
f token decl | place decl | trans decl g +<br />
extern decls ::= f import decl | export decl g +<br />
import decl ::= \import" \:" import body<br />
import body ::= f l<strong>in</strong>k decl | serv decl g +<br />
l<strong>in</strong>k decl ::= \l<strong>in</strong>k" name f \," name g \�"<br />
serv decl ::= \service" f ident \with" <strong>in</strong>terfaces \�" g +<br />
<strong>in</strong>terfaces ::= ident f \," ident g<br />
export decl ::= \export" \:" export body<br />
export body ::= f l<strong>in</strong>k decl g +<br />
token decl ::= \token" ident <strong>in</strong>herit \f" token body \g" [ \�" ]<br />
| \token" ident \�"<br />
token body ::= f type spec declarators \�" g +<br />
place decl ::= \places" \:" place body<br />
place body ::= f name ident f \," ident g g +<br />
trans decl ::= [ \[" trans spec \]" ]<br />
\trans" ident \f" trans body \g" [ \�" ]<br />
trans spec ::= \sync" | \async"<br />
| \stask" | \atask"<br />
| \<strong>in</strong>it"<br />
| \transactional"
240 Koord<strong>in</strong>ationssprache PAMELA<br />
trans body ::= f get decl | put decl | action decl g +<br />
get decl ::= \get" get body f [ \get" ] get body g<br />
get body ::= ident f \," ident g \from" ident \�"<br />
| ident f \," ident g \from" ident \if" com expr \�"<br />
com expr ::= dotted ident<br />
| set const<br />
| com expr \&&" com expr<br />
| com expr \||" com expr<br />
| \!" com expr<br />
| com expr \==" com expr<br />
| com expr \!=" com expr<br />
| com expr \>" com expr<br />
| com expr \
A.1 Beschreibung der Syntax und Semantik 241<br />
action body ::= f f [ par | seq ] \f" action list \g" action use g<br />
| action list g +<br />
action list ::= f [ dotted ident \=" ]<br />
ident [ \(" param list \)" ] action use g +<br />
param list ::= dotted ident f \," dotted ident g<br />
action use ::= \us<strong>in</strong>g" name [ \with" com expr ] \�"<br />
| \�"<br />
A.1.3 Reservierte Schlusselworter<br />
Die folgenden Worter s<strong>in</strong>d <strong>in</strong>PAMELA zusatzlich zuden <strong>in</strong> der CORBA{IDL<br />
de nierten reserviert undkonnen nicht als Bezeichner <strong>in</strong> PAMELA{Programmen<br />
verwendet werden. PAMELA unterscheidet hierbei zwischen Gro - und Kle<strong>in</strong>schreibung.<br />
Schlusselworter verwenden grundsatzlich Kle<strong>in</strong>buchstaben. Kursiv<br />
gesetzte Worter s<strong>in</strong>d fur zukunftige Erweiterungen reserviert und konnen derzeit<br />
noch nicht verwendet werden.<br />
abort actions async atask commit delay error<br />
export from get guard if import <strong>in</strong>it<br />
l<strong>in</strong>k par places priority process put seq<br />
service stask suspend sync task timeout to<br />
token trans transactional us<strong>in</strong>g with<br />
Tabelle A.6: Reservierte Schlusselworter
242 Koord<strong>in</strong>ationssprache PAMELA<br />
A.2 Anwendungsbeispiel: Work ow{Unterstutzung<br />
im Hotel<br />
Die folgenden Abbildungen zeigen die textuelle PAMELA{Beschreibung des Hotelbeispiels<br />
aus Abschnitt 6.1.2.4. Sie dient zur Erganzung der dort gezeigten<br />
graphischen Petri{Netz{Darstellung.<br />
module Card {<br />
attribute str<strong>in</strong>g Company�<br />
<strong>in</strong>terface CardCustomer {<br />
void checkCard(<strong>in</strong> long cardNum)�<br />
void debitCard(<strong>in</strong> long cardNum,<br />
<strong>in</strong> double amount)�<br />
void creditCard(<strong>in</strong> long cardNum,<br />
<strong>in</strong> double amount)�<br />
void getCardBalance(<strong>in</strong> long cardNum,<br />
out double amount)�<br />
}�<br />
<strong>in</strong>terface Management {<br />
void <strong>in</strong>itAccounts()�<br />
}�<br />
}�<br />
module Mail {<br />
attribute long Urgency�<br />
<strong>in</strong>terface Electronic<br />
attribute str<strong>in</strong>g Who�<br />
void notify(<strong>in</strong> long reason,<br />
<strong>in</strong> str<strong>in</strong>g name,<br />
<strong>in</strong> long roomNum,<br />
<strong>in</strong> double amount)�<br />
}�<br />
}�<br />
module HotelService {<br />
<strong>in</strong>terface FrontDesk {<br />
void <strong>in</strong>itAccount(<strong>in</strong> long roomNum)�<br />
void charge(<strong>in</strong> long roomNum,<br />
<strong>in</strong> double amount,<br />
out double total)�<br />
void getBalance(<strong>in</strong> long roomNum,<br />
out double balance)�<br />
void pay(<strong>in</strong> long roomNum,<br />
<strong>in</strong> double amount)�<br />
}�<br />
}�<br />
module Account<strong>in</strong>g {<br />
<strong>in</strong>terface Internal {<br />
void payTax(<strong>in</strong> double a)�<br />
void prepareTaxReturn(<strong>in</strong> double a)�<br />
}�<br />
}�<br />
process Hotel {<br />
export:<br />
l<strong>in</strong>k arrival,departure,order�<br />
import:<br />
l<strong>in</strong>k <strong>in</strong>com<strong>in</strong>g�<br />
service Card<br />
with CardCustomer,Management�<br />
service HotelService<br />
with FrontDesk�<br />
service Mail with Electronic�<br />
token Arriv<strong>in</strong>g {<br />
str<strong>in</strong>g name�<br />
long cardNum�<br />
str<strong>in</strong>g cardType�<br />
long roomType�<br />
}<br />
token Depart<strong>in</strong>g {<br />
str<strong>in</strong>g name�<br />
}<br />
token Order<strong>in</strong>g {<br />
str<strong>in</strong>g customer�<br />
long item�<br />
double price�<br />
}<br />
token Money {<br />
double amount�<br />
}<br />
token Guest {<br />
str<strong>in</strong>g name�<br />
long cardNum�<br />
str<strong>in</strong>g cardType�<br />
long roomNum�<br />
long roomType�<br />
long count�<br />
double total�<br />
}<br />
token Room {<br />
long number�<br />
long type�<br />
}<br />
Abbildung A.10: PAMELA{Programm des Hotelbeispiels (Teil 1)
A.2 Anwendungsbeispiel: Work ow{Unterstutzung im Hotel 243<br />
token NotifyData {<br />
long reason�<br />
str<strong>in</strong>g customerName�<br />
long roomNum�<br />
double amount�<br />
long cardNum�<br />
}<br />
token Dummy {<br />
long i�<br />
}<br />
places:<br />
Room rooms�<br />
Arriv<strong>in</strong>g arrival�<br />
Depart<strong>in</strong>g departure�<br />
Order<strong>in</strong>g order�<br />
Guest guests�<br />
NotifyData notification�<br />
Dummy serviceInit�<br />
Money due�<br />
[<strong>in</strong>it] trans <strong>in</strong>itialize {<br />
put r1 to rooms with<br />
{r1.number = 1� r1.type = 0�}�<br />
put r2 to rooms with<br />
{r2.number = 2� r2.type = 1�}�<br />
put r3 to rooms with<br />
{r3.number = 3� r3.type = 0�}�<br />
}�<br />
[transactional] trans checkIn {<br />
get a from arrival�<br />
get r from rooms<br />
if r.type == a.roomType�<br />
commit:<br />
put data to guests with<br />
{data.roomNum = r.number�<br />
data.roomType = r.type�<br />
data.cardNum = a.cardNum�<br />
data.cardType = a.cardType�<br />
data.name = a.name�}�<br />
}<br />
abort:<br />
put msg to notification with<br />
{msg.reason =4�<br />
msg.customerName = a.name�<br />
msg.roomNum = r.number�<br />
msg.amount = 0.0�<br />
msg.cardNum = a.cardNum�<br />
}�<br />
actions:<br />
<strong>in</strong>itAccount(r.number)�<br />
checkCard(a.cardNum)<br />
us<strong>in</strong>g CardCustomer<br />
with Company == a.cardType�<br />
[transactional] trans processOrder {<br />
get o from order�<br />
get g from guests<br />
if g.name == o.customer�<br />
commit:<br />
put g to guests�<br />
put o to order�<br />
abort:<br />
put g to guests�<br />
put msg to notification with<br />
{msg.reason = 5�<br />
msg.customerName = g.name�<br />
msg.roomNum = o.item�<br />
msg.amount = o.price�<br />
msg.cardNum = g.roomNum�<br />
}�<br />
actions:<br />
charge(g.roomNum,o.price,g.total)�<br />
}<br />
trans checkInOutFailure {<br />
get msg from notification<br />
if msg.reason !=5�<br />
put r to rooms with<br />
r.number = msg.roomNum�<br />
error:<br />
put msg to notification�<br />
actions:<br />
notify(msg.reason,msg.customerName,<br />
msg.cardNum,msg.amount)<br />
us<strong>in</strong>g Electronic with Urgency == 3�<br />
}<br />
trans orderFailure {<br />
get msg from notification<br />
if msg.reason ==5�<br />
put r to rooms with<br />
r.number = msg.roomNum�<br />
error:<br />
put msg to notification�<br />
actions:<br />
notify(msg.reason,msg.customerName,<br />
msg.cardNum,msg.amount)<br />
us<strong>in</strong>g Electronic with Urgency == 1�<br />
}<br />
[transactional] trans checkOut{<br />
get d from departure�<br />
get g from guests if g.name == d.name�<br />
get m from due�<br />
Abbildung A.11: PAMELA{Programm des Hotelbeispiels (Teil 2)
244 Koord<strong>in</strong>ationssprache PAMELA<br />
commit:<br />
put r to rooms with<br />
{r.number = g.roomNum�<br />
r.type = g.roomType�}�<br />
put m to due with m.amount = 0.0�<br />
abort:<br />
put msg to notification with<br />
{msg.reason =2�<br />
msg.amount = m.amount�<br />
msg.customerName = g.name�<br />
msg.roomNum = g.roomNum�<br />
}�<br />
put g to guests�<br />
put m to due with m.amount = 0.0�<br />
put d to departure�<br />
actions:<br />
seq {<br />
getBalance(g.roomNum,m.amount)�<br />
}�<br />
par {<br />
debitCard(g.cardNum,m.amount)<br />
us<strong>in</strong>g CardCustomer<br />
with Company == g.cardType�<br />
pay(g.roomNum,m.amount)�<br />
}�<br />
}�<br />
}�<br />
process Account<strong>in</strong>g {<br />
export:<br />
l<strong>in</strong>k <strong>in</strong>com<strong>in</strong>g�<br />
import:<br />
service Account<strong>in</strong>g with Internal�<br />
token Bill {<br />
double amount�<br />
}<br />
places:<br />
Bill <strong>in</strong>com<strong>in</strong>g,irs�<br />
trans taxPayment {<br />
get b from <strong>in</strong>com<strong>in</strong>g�<br />
put b to irs�<br />
actions:<br />
payTax(b.amount)�<br />
}�<br />
trans taxReturn {<br />
get b from irs�<br />
actions:<br />
prepareTaxReturn(b.amount)�<br />
}�<br />
}�<br />
Abbildung A.12: PAMELA{Programm des Hotelbeispiels (Teil 3)
A.2 Anwendungsbeispiel: Work ow{Unterstutzung im Hotel 245<br />
A.2.1 Graphische Benutzerschnittstellen der Hotelanwendung<br />
Die folgende Abbildung A.13 zeigt die zum Hotelbeispiel gehorigen Benutzerschnittstellen,<br />
mit denen Hotelangestellte und Gaste E<strong>in</strong>gaben durchfuhren<br />
konnen. Diese werden vom Koord<strong>in</strong>ationsmanager uber die Ausfuhrungsschnittstelle<br />
entgegengenommen, der anschlie end entsprechende Folgeaktivitaten im<br />
Anwendungsvorgang <strong>in</strong>itiiert.<br />
Abbildung A.13: Graphische Benutzerschnittstellen der Hotelanwendung
Anhang B<br />
Beschreibung des kanonischen<br />
Typmodells<br />
Dieser Anhang zeigt die gesamte CORBA{IDL{Beschreibung des <strong>in</strong> TRADE<br />
verwendeten kanonischen Typmodells, welches zur Beschreibung von Dienst{<br />
und Beziehungstypen benutzt wird (siehe Abschnitt 5.1.1.1). E<strong>in</strong>e ausfuhrliche<br />
Beschreibung der e<strong>in</strong>zelnen Datenstrukturen gibt [CM95]. Dort ndet sich auch<br />
e<strong>in</strong>e aquivalente Beschreibung des kanonischen Typmodells <strong>in</strong> der DCE{IDL.<br />
#<strong>in</strong>clude "odpTrad<strong>in</strong>gFunction.idl" // references to def<strong>in</strong>itions used<br />
// <strong>in</strong> TRADEr/IWT project<br />
module CanonicalTypeModel {<br />
#<strong>in</strong>clude "corbaExtensions.idl" // def<strong>in</strong>ition of DCE types<br />
(e.g. hyper, unsigned hyper)<br />
/* Bezeichner */<br />
typedef str<strong>in</strong>g Identifier�<br />
typedef sequence IdentifierList�<br />
/* Typbezeichner */<br />
typedef odpTrad<strong>in</strong>gFunction::RepositoryIdType TypeId�<br />
typedef sequence TypeIdList�<br />
enum K<strong>in</strong>dOfType {<br />
DATA_TYPE, CONST_TYPE, TYPEDEF_TYPE, EXCEPTION_TYPE,<br />
ATTRIBUTE_TYPE, OPERATION_TYPE, INTERFACE_TYPE, SERVICE_TYPE,<br />
RELATIONSHIP_TYPE, NO_TYPE<br />
}�
248 Beschreibung des kanonischen Typmodells<br />
/*-------------------------------------------------*/<br />
/* Fundamentale Datentypen */<br />
enum TCK<strong>in</strong>d {<br />
tk_void,<br />
tk_small, tk_short, tk_long, tk_hyper,<br />
tk_usmall, tk_ushort, tk_ulong, tk_uhyper,<br />
tk_float, tk_double,<br />
tk_boolean, tk_char, tk_octet,<br />
tk_iso_lat<strong>in</strong>_1, tk_iso_multil<strong>in</strong>gual, tk_iso_ucs,<br />
tk_any,<br />
tk_object_reference,<br />
tk_b<strong>in</strong>d<strong>in</strong>g_handle, tk_customized_b<strong>in</strong>d<strong>in</strong>g_handle,<br />
tk_context_handle,<br />
tk_error_status,<br />
tk_pipe,<br />
tk_po<strong>in</strong>ter,<br />
tk_struct, tk_union, tk_enum,<br />
tk_array, tk_str<strong>in</strong>g,<br />
tk_identifier<br />
}�<br />
typedef TCK<strong>in</strong>d BasicType�<br />
/* Typen mit Bereichse<strong>in</strong>schraenkungen */<br />
struct SmallBounds {<br />
small lower�<br />
small upper�<br />
}�<br />
struct ShortBounds {<br />
short lower�<br />
short upper�<br />
}�<br />
struct LongBounds {<br />
long lower�<br />
long upper�<br />
}�<br />
struct HyperBounds {<br />
hyper lower�<br />
hyper upper�<br />
}�<br />
struct UsmallBounds {<br />
unsigned_small lower�<br />
unsigned_small upper�
}�<br />
struct UshortBounds {<br />
unsigned short lower�<br />
unsigned short upper�<br />
}�<br />
struct UlongBounds {<br />
unsigned long lower�<br />
unsigned long upper�<br />
}�<br />
struct UhyperBounds {<br />
unsigned_hyper lower�<br />
unsigned_hyper upper�<br />
}�<br />
struct FloatBounds {<br />
float lower�<br />
float upper�<br />
}�<br />
struct DoubleBounds {<br />
double lower�<br />
double upper�<br />
}�<br />
struct CharBounds {<br />
char lower�<br />
char upper�<br />
}�<br />
union RangeType switch(TCK<strong>in</strong>d) {<br />
case tk_small: SmallBounds smb�<br />
case tk_short: ShortBounds shb�<br />
case tk_long: LongBounds lb�<br />
case tk_hyper: HyperBounds hb�<br />
case tk_usmall: UsmallBounds usmb�<br />
case tk_ushort: UshortBounds ushb�<br />
case tk_ulong: UlongBounds ulb�<br />
case tk_uhyper: UhyperBounds uhb�<br />
case tk_float: FloatBounds flb�<br />
case tk_double: DoubleBounds db�<br />
case tk_char: CharBounds cb�<br />
}�<br />
/*-------------------------------------------------*/<br />
/* Objektreferenzen */<br />
typedef Identifier ObjectReference�<br />
249
250 Beschreibung des kanonischen Typmodells<br />
/* Customized B<strong>in</strong>d<strong>in</strong>g Handle */<br />
struct CustomizedB<strong>in</strong>d<strong>in</strong>gHandle{<br />
TypeId type� // TypeCode<br />
Identifier aliasName�<br />
}�<br />
/* Error Status */<br />
const unsigned long ERR_DEF_IN_IDL = 0x01�<br />
const unsigned long ERR_DEF_IN_ACF = 0x02�<br />
const unsigned long ERR_COMM_STATUS = 0x04�<br />
const unsigned long ERR_FAULT_STATUS = 0x08�<br />
typedef unsigned long ErrorStatus�<br />
/*-------------------------------------------------*/<br />
/* Strukturen */<br />
struct StructMember {<br />
Identifier name�<br />
TypeId type� // TypeCode<br />
Identifier aliasName�<br />
}�<br />
typedef sequence StructMemberList�<br />
struct Struct {<br />
Identifier name�<br />
Identifier tag�<br />
StructMemberList members�<br />
}�<br />
/* Unions */<br />
enum K<strong>in</strong>dOfDiscrim<strong>in</strong>ator {<br />
u_small, u_short, u_long, u_hyper,<br />
u_usmall, u_ushort, u_ulong, u_uhyper,<br />
u_char, u_boolean,<br />
u_enum, u_default<br />
}�<br />
union UnionLabelValue switch(K<strong>in</strong>dOfDiscrim<strong>in</strong>ator) {<br />
case u_small: small sm�<br />
case u_short: short sh�<br />
case u_long: long l�<br />
case u_hyper: hyper h�<br />
case u_usmall: unsigned_small usm�<br />
case u_ushort: unsigned short ush�
case u_ulong: unsigned long ul�<br />
case u_uhyper: unsigned_hyper uh�<br />
case u_char: char c�<br />
case u_boolean: boolean b�<br />
case u_enum: Identifier i�<br />
case u_default: short dummy�<br />
}�<br />
typedef sequence UnionLabelValueList�<br />
struct UnionMember {<br />
Identifier name�<br />
UnionLabelValueList values�<br />
TypeId type� // TypeCode<br />
Identifier aliasName�<br />
}�<br />
typedef sequence UnionMemberList�<br />
struct Union {<br />
Identifier name�<br />
Identifier tag�<br />
Identifier c_union_name�<br />
Identifier discrim<strong>in</strong>ator_name�<br />
TCK<strong>in</strong>d discrim<strong>in</strong>ator_k<strong>in</strong>d�<br />
TypeId discrim<strong>in</strong>ator_type� // TypeCode<br />
Identifier aliasName�<br />
UnionMemberList members�<br />
}�<br />
/* Enums */<br />
struct Enum {<br />
Identifier name�<br />
IdentifierList members�<br />
}�<br />
/* Str<strong>in</strong>gs */<br />
enum Str<strong>in</strong>gK<strong>in</strong>d {STR_FIXED,<br />
STR_CONFORMANT_BY_ARRAY,<br />
STR_CONFORMANT_BY_PTR,<br />
STR_CONFORMANT_BY_REF,<br />
STR_OPEN_BY_MAX,<br />
STR_OPEN_BY_SIZE<br />
}�<br />
struct Str<strong>in</strong>g {<br />
Str<strong>in</strong>gK<strong>in</strong>d k<strong>in</strong>d�<br />
unsigned long length� /* k<strong>in</strong>d=STR_FIXED */<br />
Identifier maxsize_is_variable� /* k<strong>in</strong>d=STR_OPEN_BY_MAX oder<br />
251
252 Beschreibung des kanonischen Typmodells<br />
}�<br />
/* Arrays */<br />
const unsigned long ARR_SIZE_IS = 0x01�<br />
const unsigned long ARR_MAX_IS = 0x02�<br />
const unsigned long ARR_FIRST_IS = 0x04�<br />
const unsigned long ARR_LAST_IS = 0x08�<br />
const unsigned long ARR_LENGTH_IS = 0x10�<br />
typedef unsigned long ArrayAttributes�<br />
struct Array {<br />
ArrayAttributes attributes�<br />
TypeId type� // TypeCode<br />
Identifier aliasName�<br />
unsigned long length�<br />
Identifier maxsize_is_variable�<br />
Identifier first_is_variable�<br />
Identifier lastlength_is_variable�<br />
}�<br />
k<strong>in</strong>d=STR_OPEN_BY_SIZE */<br />
/*-------------------------------------------------*/<br />
/* Pipes */<br />
struct Pipe {<br />
TypeId type� // TypeCode<br />
Identifier aliasName�<br />
}�<br />
/* Po<strong>in</strong>ter */<br />
enum Po<strong>in</strong>terK<strong>in</strong>d {REF_POINTER, FULL_POINTER}�<br />
struct Po<strong>in</strong>ter {<br />
Po<strong>in</strong>terK<strong>in</strong>d k<strong>in</strong>d�<br />
TypeId type� // TypeCode<br />
Identifier aliasName�<br />
}�<br />
/* TypeCodes */<br />
enum K<strong>in</strong>dOfDataType {<br />
BASIC_TYPE, RANGE_TYPE,<br />
STRUCT_TYPE, UNION_TYPE, ENUM_TYPE,<br />
STRING_TYPE, ARRAY_TYPE,<br />
OBJECT_REFERENCE_TYPE,
POINTER_TYPE, ERROR_STATUS_TYPE,<br />
CUSTOMIZED_BINDING_HANDLE_TYPE, PIPE_TYPE<br />
}�<br />
union TypeCode switch(K<strong>in</strong>dOfDataType) {<br />
case BASIC_TYPE: BasicType bt�<br />
case RANGE_TYPE: RangeType rt�<br />
case STRUCT_TYPE: Struct s�<br />
case UNION_TYPE: Union u�<br />
case ENUM_TYPE: Enum e�<br />
case STRING_TYPE: Str<strong>in</strong>g str�<br />
case ARRAY_TYPE: Array arr�<br />
case OBJECT_REFERENCE_TYPE: ObjectReference or�<br />
case POINTER_TYPE: Po<strong>in</strong>ter ptr�<br />
case CUSTOMIZED_BINDING_HANDLE_TYPE: CustomizedB<strong>in</strong>d<strong>in</strong>gHandle cbh�<br />
case ERROR_STATUS_TYPE: ErrorStatus err�<br />
case PIPE_TYPE: Pipe p�<br />
}�<br />
/*-------------------------------------------------*/<br />
/* Konstanten */<br />
enum K<strong>in</strong>dOfConst {<br />
c_small, c_short, c_long, c_hyper,<br />
c_usmall, c_ushort, c_ulong, c_uhyper,<br />
c_float, c_double,<br />
c_char, c_boolean,<br />
c_str<strong>in</strong>g, c_enum,<br />
c_context_handle<br />
}�<br />
union ConstValue switch(K<strong>in</strong>dOfConst) {<br />
case c_small: small sm�<br />
case c_short: short sh�<br />
case c_long: long l�<br />
case c_hyper: hyper h�<br />
case c_usmall: unsigned_small usm�<br />
case c_ushort: unsigned short ush�<br />
case c_ulong: unsigned long ul�<br />
case c_uhyper: unsigned_hyper uh�<br />
case c_float: float fl�<br />
case c_double: double d�<br />
case c_char: char c�<br />
case c_boolean: boolean b�<br />
case c_str<strong>in</strong>g: str<strong>in</strong>g str�<br />
case c_enum: Identifier i�<br />
case c_context_handle: short dummy�<br />
}�<br />
struct Const {<br />
Identifier name�<br />
253
254 Beschreibung des kanonischen Typmodells<br />
ConstValue value�<br />
Identifier aliasName�<br />
str<strong>in</strong>g def�<br />
}�<br />
/*-------------------------------------------------*/<br />
/* Typdeklarationen (typedefs) */<br />
struct Typedef {<br />
IdentifierList names�<br />
TypeId type� // TypeCode<br />
Identifier aliasName�<br />
}�<br />
/*-------------------------------------------------*/<br />
/* Attribute */<br />
struct Attribute {<br />
Identifier name�<br />
boolean rdonly�<br />
TypeId type� // TypeCode<br />
Identifier aliasName�<br />
}�<br />
/*-------------------------------------------------*/<br />
/* Ausnahmen (Exceptions) */<br />
typedef StructMember ExceptionMember�<br />
typedef sequence ExceptionMemberList�<br />
struct Exception {<br />
Identifier name�<br />
ExceptionMemberList members�<br />
}�<br />
/* Operationen */<br />
enum ParamAttribute {PARAM_IN, /* [<strong>in</strong>] bzw. <strong>in</strong> */<br />
PARAM_OUT, /* [out] bzw. out */<br />
PARAM_INOUT /* [<strong>in</strong>,out] bzw. <strong>in</strong>out */<br />
}�<br />
struct Parameter {<br />
Identifier name� /* Parametername */<br />
ParamAttribute attr� /* Richtungsattribut */
TypeId type� /* Parametertyp (TypeCode) */<br />
Identifier aliasName�<br />
}�<br />
const unsigned long OPATTR_NORMAL = 0x00�<br />
const unsigned long OPATTR_MAYBE = 0x01�<br />
const unsigned long OPATTR_BROADCAST = 0x02�<br />
const unsigned long OPATTR_IDEMPOTENT = 0x04�<br />
typedef unsigned long OpAttributes�<br />
typedef sequence ParameterList�<br />
struct Operation {<br />
Identifier name�<br />
OpAttributes opattr�<br />
TypeId returntype� // TypeCode<br />
Identifier aliasName�<br />
ParameterList params�<br />
TypeIdList exceptions� // Exceptions<br />
IdentifierList contexts�<br />
IdentifierList semantics�<br />
IdentifierList categories�<br />
}�<br />
/*-------------------------------------------------*/<br />
/* Schnittstellen */<br />
struct Interface {<br />
Identifier name�<br />
TypeIdList baseInterfaces� // Interfaces<br />
TypeIdList def<strong>in</strong>itions� // Consts, Typedefs, Exceptions,<br />
IdentifierList semantics� // Attributes, Operations<br />
IdentifierList categories�<br />
}�<br />
/*-------------------------------------------------*/<br />
/* Dienstattributtypen */<br />
struct Property {<br />
Identifier propertyName�<br />
TypeId propertyType�<br />
boolean dynamic�<br />
}�<br />
typedef sequence PropertyList�<br />
/* Diensttypen */<br />
255
256 Beschreibung des kanonischen Typmodells<br />
struct ServiceType {<br />
Identifier name�<br />
str<strong>in</strong>g uuid�<br />
str<strong>in</strong>g orig<strong>in</strong>alImplementationMiddleware�<br />
TypeId <strong>in</strong>terfaceType� // Interface<br />
PropertyList properties�<br />
IdentifierList semantics�<br />
IdentifierList categories�<br />
}�<br />
/*-------------------------------------------------*/<br />
/* Relationen */<br />
const unsigned long RC_SYMMETRIC = 0x1�<br />
const unsigned long RC_ANTISYMMETRIC = 0x2�<br />
const unsigned long RC_TRANSITIVE = 0x4�<br />
const unsigned long RC_ANTITRANSITIVE = 0x8�<br />
const unsigned long RC_REFLEXIVE = 0x10�<br />
const unsigned long RC_ANTIREFLEXIVE = 0x20�<br />
typedef unsigned long RelationshipCharacteristics�<br />
enum RelationshipStoragePolicy {<br />
MINIMAL_INSTANCES, /* speichereffizient */<br />
ALL_KNOWN_INSTANCES, /* zugriffseffizient */<br />
DEFINITION_ONLY /* Charakteristika werden<br />
nicht ausgenutzt */<br />
}�<br />
typedef str<strong>in</strong>g RelationshipDef<strong>in</strong>ition�<br />
struct Relationship {<br />
Identifier name�<br />
K<strong>in</strong>dOfType between�<br />
K<strong>in</strong>dOfType relatedTypes�<br />
RelationshipCharacteristics characteristics�<br />
RelationshipStoragePolicy storagePolicy�<br />
RelationshipDef<strong>in</strong>ition def<strong>in</strong>ition�<br />
TypeId hierarchyRoot�<br />
str<strong>in</strong>g semantics�<br />
}�<br />
/*-------------------------------------------------*/<br />
/* Allgeme<strong>in</strong>er Typ */<br />
union Type switch (K<strong>in</strong>dOfType) {<br />
case DATA_TYPE: TypeCode dt�<br />
case CONST_TYPE: Const cnst�
case TYPEDEF_TYPE: Typedef tdef�<br />
case EXCEPTION_TYPE: Exception exc�<br />
case ATTRIBUTE_TYPE: Attribute attr�<br />
case OPERATION_TYPE: Operation op�<br />
case INTERFACE_TYPE: Interface <strong>in</strong>tf�<br />
case SERVICE_TYPE: ServiceType svc�<br />
case RELATIONSHIP_TYPE: Relationship rel�<br />
case NO_TYPE: short dummy�<br />
}�<br />
}� // module CanonicalTypeModel<br />
257
Anhang C<br />
Operationale Schnittstelle des<br />
Typmanagers<br />
Dieser Anhang zeigt die operationale Schnittstelle des Typmanagers <strong>in</strong> der<br />
CORBA{IDL. Diese benutzt die im vorherigen Anhang Bvorgestellten Typde<br />
nitionen des kanonischen Typmodells. E<strong>in</strong>e detaillierte Beschreibung der e<strong>in</strong>zelnen<br />
Operationen ist <strong>in</strong> [CM96] gegeben, wo sichauch dieaquivalenteSchnittstellenbeschreibung<br />
des Typmanagers <strong>in</strong> der DCE{IDL ndet.<br />
#<strong>in</strong>clude "canonicalTypeModel.idl"<br />
<strong>in</strong>terface TypeManager {<br />
/*-------------------------------------------------*/<br />
/* Allgeme<strong>in</strong>e Typdef<strong>in</strong>itionen */<br />
enum K<strong>in</strong>dOfError {<br />
SUCCESS,<br />
/* Standardfehler */<br />
OUT_OF_MEMORY,<br />
INVALID_DOMAIN_NAME,<br />
INVALID_TYPEID,<br />
INVALID_INSTANCEID,<br />
CANNOT_CONNECT_TO_REPOSITORY,<br />
CANNOT_CONNECT_TO_DESCLANGUAGEMAPPER,<br />
INTERNAL_ERROR,<br />
UNKNOWN_ERROR,<br />
/* Domaenen */<br />
NAME_ALREADY_EXISTS,<br />
NAME_DOES_NOT_EXIST,<br />
DOMAIN_DOES_NOT_EXIST,<br />
NOT_EMPTY,<br />
/* Typmanager-Policies */
260 Operationale Schnittstelle des Typmanagers<br />
UNKNOWN_POLICY,<br />
INVALID_POLICY_EXPRESSION,<br />
/* Abbildungskomponente */<br />
DESCLANGUAGEMAPPER_NOT_REGISTERED,<br />
/* Anfrage- und Suchschnittstelle */<br />
TYPEID_DOES_NOT_EXIST,<br />
NO_DIRECT_TYPEID,<br />
NO_SERVICE_TYPE,<br />
NO_RELATIONSHIP_TYPE,<br />
INVALID_TYPE,<br />
INVALID_TYPE_DESCRIPTION,<br />
INVALID_RELATIONSHIP_EXPRESSION,<br />
RELATIONSHIP_GIVEN_BY_RULE,<br />
RELATIONSHIP_DEFINED_BY_INSTANCES,<br />
NO_TYPEID_FOUND,<br />
CONVERSION_FAILED,<br />
UNKNOWN_PROPERTY,<br />
INVALID_PROPERTY_VALUE,<br />
/* Typverwaltungsschnittstelle */<br />
INDIRECT_TYPEID,<br />
TYPE_STILL_IN_USE,<br />
NO_KNOWN_DESCRIPTION_LANGUAGE,<br />
RELATIONSHIP_DEMANDED_IN_IDL,<br />
DIFFERENT_OTHER_INFO_ALREADY_EXISTS,<br />
CHARACTERISTICS_VIOLATION,<br />
DEFINITIONRULE_VIOLATION,<br />
INSTANCEID_DOES_NOT_EXIST,<br />
INSTANCE_DOES_NOT_EXIST,<br />
INSTANCE_CAN_STILL_BE_DERIVED<br />
}�<br />
struct Environment {<br />
unsigned short parameterNo�<br />
K<strong>in</strong>dOfError error�<br />
str<strong>in</strong>g errorStr<strong>in</strong>g�<br />
}�<br />
typedef str<strong>in</strong>g Description�<br />
/*-------------------------------------------------*/<br />
/* Allgeme<strong>in</strong>e Funktionen */<br />
void EnvironmentToStr<strong>in</strong>g(<br />
<strong>in</strong> Environment environment,<br />
out Description str<br />
)�<br />
/*-------------------------------------------------*/
* Typmanager-Policies */<br />
enum K<strong>in</strong>dOfPolicyValue { STRING, NUMBER }�<br />
union PolicyValue switch (K<strong>in</strong>dOfPolicyValue) {<br />
case STRING: str<strong>in</strong>g str�<br />
case NUMBER: long number�<br />
}�<br />
struct S<strong>in</strong>glePolicyExpression {<br />
CanonicalTypeModel::Identifier policyName�<br />
PolicyValue policyValue�<br />
}�<br />
typedef sequence PolicyExpression�<br />
void SetDefaultPolicy(<br />
<strong>in</strong> PolicyExpression policyExpression,<br />
out Environment environment /* UNKNOWN_POLICY,<br />
INVALID_POLICY_EXPRESSION */<br />
)�<br />
void GetDefaultPolicy(<br />
out PolicyExpression policyExpression,<br />
out Environment environment<br />
)�<br />
/*-------------------------------------------------*/<br />
/* Domaenen */<br />
typedef CanonicalTypeModel::Identifier Doma<strong>in</strong>�<br />
typedef CanonicalTypeModel::IdentifierList Doma<strong>in</strong>List�<br />
void CreateDoma<strong>in</strong>(<br />
<strong>in</strong> Doma<strong>in</strong> superDoma<strong>in</strong>,<br />
<strong>in</strong> CanonicalTypeModel::Identifier subDoma<strong>in</strong>Name,<br />
<strong>in</strong> Description description,<br />
out Environment environment /* NAME_ALREADY_EXISTS */<br />
)�<br />
void DeleteDoma<strong>in</strong>(<br />
<strong>in</strong> Doma<strong>in</strong> fullDoma<strong>in</strong>Name,<br />
<strong>in</strong> boolean recursive, // RECURSIVE or DOMAIN_ONLY?<br />
<strong>in</strong> boolean always, // DELETE_ALWAYS or DELETE_ONLY_IF_EMPTY?<br />
out Environment environment /* NOT_EMPTY, DOMAIN_DOES_NOT_EXIST */<br />
)�<br />
void SetDoma<strong>in</strong>Description(<br />
<strong>in</strong> Doma<strong>in</strong> fullDoma<strong>in</strong>Name,<br />
<strong>in</strong> Description description,<br />
out Environment environment /* DOMAIN_DOES_NOT_EXIST */<br />
261
262 Operationale Schnittstelle des Typmanagers<br />
)�<br />
void GetDoma<strong>in</strong>Description(<br />
<strong>in</strong> Doma<strong>in</strong> fullDoma<strong>in</strong>Name,<br />
out Description description,<br />
out Environment environment /* DOMAIN_DOES_NOT_EXIST */<br />
)�<br />
void GetSubDoma<strong>in</strong>s(<br />
<strong>in</strong> Doma<strong>in</strong> fullDoma<strong>in</strong>Name,<br />
<strong>in</strong> boolean absolutNames, /* full or relative */<br />
<strong>in</strong> PolicyExpression policyExpression,<br />
out Doma<strong>in</strong>List subDoma<strong>in</strong>s,<br />
out unsigned long totalNoOfSubDoma<strong>in</strong>s,<br />
out Environment environment /* DOMAIN_DOES_NOT_EXIST,<br />
UNKNOWN_POLICY, INVALID_POLICY_EXPRESSION */<br />
)�<br />
void MoveDoma<strong>in</strong>( /* RenameDoma<strong>in</strong> */<br />
<strong>in</strong> Doma<strong>in</strong> fromFullDoma<strong>in</strong>Name,<br />
<strong>in</strong> Doma<strong>in</strong> toDoma<strong>in</strong>Name, /* full or relative */<br />
out Environment environment /* DOMAIN_DOES_NOT_EXIST,<br />
NAME_ALREADY_EXIST */<br />
)�<br />
/*-------------------------------------------------*/<br />
/* Abbildungskomponenten */<br />
void RegisterDescLanguageMapper(<br />
<strong>in</strong> CanonicalTypeModel::Identifier descLanguage,<br />
<strong>in</strong> Description description,<br />
<strong>in</strong> str<strong>in</strong>g str<strong>in</strong>gB<strong>in</strong>d<strong>in</strong>g,<br />
out Environment environment<br />
/* NAME_ALREADY_EXISTS,<br />
CANNOT_CONNECT_TO_DESCLANGUAGEMAPPER*/<br />
)�<br />
void UnregisterDescLanguageMapper(<br />
<strong>in</strong> CanonicalTypeModel::Identifier descLanguage,<br />
out Environment environment<br />
/* DESCLANGUAGEMAPPER_NOT_REGISTERED */<br />
)�<br />
void GetDescLanguages(<br />
out CanonicalTypeModel::IdentifierList descLanguages,<br />
out Environment environment<br />
)�<br />
void GetDescLanguageDetails(<br />
<strong>in</strong> CanonicalTypeModel::Identifier descLanguage,<br />
out Description description,<br />
out str<strong>in</strong>g str<strong>in</strong>gB<strong>in</strong>d<strong>in</strong>g,
out Environment environment /* DESCLANGUAGEMAPPER_NOT_REGISTERED */<br />
)�<br />
/*-------------------------------------------------*/<br />
/* Typverwaltungsschnittstelle: Typbeschreibungen */<br />
struct DescByDescLanguage {<br />
CanonicalTypeModel::Identifier descLanguage�<br />
str<strong>in</strong>g description�<br />
}�<br />
enum TypeDescK<strong>in</strong>d { byTypeId, byCanonicalTypeModel, byDescLanguage }�<br />
union TypeDesc switch (TypeDescK<strong>in</strong>d) {<br />
case byTypeId:<br />
CanonicalTypeModel::TypeId descByTypeId�<br />
case byCanonicalTypeModel:<br />
CanonicalTypeModel::Type descByCanonicalTypeModel�<br />
case byDescLanguage:<br />
DescByDescLanguage descByDescLanguage�<br />
}�<br />
void AddType(<br />
<strong>in</strong> Doma<strong>in</strong> fullDoma<strong>in</strong>Name,<br />
<strong>in</strong> TypeDesc type,<br />
out CanonicalTypeModel::TypeId id,<br />
out Environment environment /* DOMAIN_DOES_NOT_EXIST,<br />
INVALID_TYPE_DESCRIPTION, DESCLANGUAGEMAPPER_NOT_REGISTERED,<br />
CONVERSION_FAILED */<br />
)�<br />
void AddServiceType(<br />
<strong>in</strong> Doma<strong>in</strong> fullDoma<strong>in</strong>Name,<br />
<strong>in</strong> odpTrad<strong>in</strong>gFunction::DescByInterfaceIdType serviceType,<br />
<strong>in</strong> CanonicalTypeModel::Identifier serviceTypeName,<br />
out CanonicalTypeModel::TypeId id,<br />
out Environment environment /* DOMAIN_DOES_NOT_EXIST,<br />
TYPEID_DOES_NOT_EXIST */<br />
)�<br />
void GetDoma<strong>in</strong>(<br />
<strong>in</strong> CanonicalTypeModel::TypeId type,<br />
out Doma<strong>in</strong> doma<strong>in</strong>,<br />
out Environment environment /* INVALID_TYPEID,<br />
TYPEID_DOES_NOT_EXIST */<br />
)�<br />
void SetAliasName(<br />
<strong>in</strong> CanonicalTypeModel::TypeId type,<br />
<strong>in</strong> CanonicalTypeModel::Identifier aliasName,<br />
out Environment environment /* TYPEID_DOES_NOT_EXIST,<br />
NAME_ALREADY_EXISTS */<br />
263
264 Operationale Schnittstelle des Typmanagers<br />
)�<br />
void RemoveAliasName(<br />
<strong>in</strong> CanonicalTypeModel::TypeId type,<br />
<strong>in</strong> CanonicalTypeModel::Identifier aliasName,<br />
out Environment environment /* TYPEID_DOES_NOT_EXIST,<br />
NAME_DOES_NOT_EXIST */<br />
)�<br />
void GetAliasNameList(<br />
<strong>in</strong> CanonicalTypeModel::TypeId type,<br />
out CanonicalTypeModel::IdentifierList aliasNameList,<br />
out Environment environment /* TYPEID_DOES_NOT_EXIST */<br />
)�<br />
void GetTypeId(<br />
<strong>in</strong> Doma<strong>in</strong> fullDoma<strong>in</strong>Name,<br />
<strong>in</strong> CanonicalTypeModel::Identifier aliasName,<br />
out CanonicalTypeModel::TypeId id,<br />
out Environment environment /* DOMAIN_DOES_NOT_EXIST,<br />
NAME_DOES_NOT_EXISTS */<br />
)�<br />
void DeleteType(<br />
<strong>in</strong> CanonicalTypeModel::TypeId type,<br />
<strong>in</strong> boolean recursive,<br />
out Environment environment /* INVALID_TYPEID, TYPEID_DOES_NOT_EXIST,<br />
INDIRECT_TYPEID, RELATIONSHIP_STILL_IN_USE */<br />
)�<br />
void GetType(<br />
<strong>in</strong> CanonicalTypeModel::TypeId type,<br />
<strong>in</strong>out TypeDesc typeDescription,<br />
out Environment environment /* INVALID_TYPEID,<br />
TYPEID_DOES_NOT_EXIST, DESCLANGUAGEMAPPER_NOT_REGISTERED */<br />
)�<br />
void GetServiceType(<br />
<strong>in</strong> CanonicalTypeModel::TypeId type,<br />
out odpTrad<strong>in</strong>gFunction::DescByInterfaceIdType<br />
serviceTypeDescription,<br />
out CanonicalTypeModel::Identifier serviceTypeName,<br />
out Environment environment /* INVALID_TYPEID, TYPEID_DOES_NOT_EXIST,<br />
NO_SERVICE_TYPE */<br />
)�<br />
/*-------------------------------------------------*/<br />
/* Typverwaltungsschnittstelle: Beziehungen */<br />
typedef str<strong>in</strong>g InstanceId�<br />
typedef sequence InstanceIdList�
typedef str<strong>in</strong>g OtherInfo�<br />
265<br />
void AddRelationshipInstance(<br />
<strong>in</strong> CanonicalTypeModel::TypeId relationship,<br />
<strong>in</strong> CanonicalTypeModel::TypeId fromType,<br />
<strong>in</strong> CanonicalTypeModel::TypeId toType,<br />
<strong>in</strong> OtherInfo <strong>in</strong>fo,<br />
out InstanceId <strong>in</strong>stance,<br />
out Environment environment /* INVALID_TYPEID, TYPEID_DOES_NOT_EXIST,<br />
NO_DIRECT_TYPEID, NO_RELATIONSHIP_TYPE, INDIRECT_TYPEID, INVALID_TYPE,<br />
DIFFERENT_OTHER_INFO_ALREADY_EXISTS, CHARACTERISTICS_VIOLATION,<br />
DEFINITIONRULE_VIOLATION */<br />
)�<br />
void DeleteRelationshipInstance(<br />
<strong>in</strong> InstanceId <strong>in</strong>stance,<br />
out Environment environment /* INVALID_INSTANCEID,<br />
INSTANCEID_DOES_NOT_EXIST, RELATIONSHIP_GIVEN_BY_RULE */<br />
)�<br />
void GetInstanceId(<br />
<strong>in</strong> CanonicalTypeModel::TypeId relationship,<br />
<strong>in</strong> CanonicalTypeModel::TypeId fromType,<br />
<strong>in</strong> CanonicalTypeModel::TypeId toType,<br />
out InstanceId <strong>in</strong>stance,<br />
out Environment environment /* INVALID_TYPEID, TYPEID_DOES_NOT_EXIST,<br />
NO_DIRECT_TYPEID, NO_RELATIONSHIP_TYPE, INDIRECT_TYPEID, INVALID_TYPE,<br />
INSTANCE_DOES_NOT_EXIST */<br />
)�<br />
void GetRelationshipInstance(<br />
<strong>in</strong> InstanceId <strong>in</strong>stance,<br />
out CanonicalTypeModel::TypeId relationship,<br />
out CanonicalTypeModel::TypeId fromType,<br />
out CanonicalTypeModel::TypeId toType,<br />
out OtherInfo <strong>in</strong>fo,<br />
out Environment environment /* INVALID_INSTANCEID,<br />
INSTANCEID_DOES_NOT_EXIST */<br />
)�<br />
typedef CanonicalTypeModel::RelationshipStoragePolicy WhichInstances�<br />
struct Instance {<br />
CanonicalTypeModel::TypeId fromType�<br />
CanonicalTypeModel::TypeId toType�<br />
}�<br />
typedef sequence InstanceList�<br />
void GetAllRelationshipInstances(<br />
<strong>in</strong> CanonicalTypeModel::TypeId relationship,<br />
<strong>in</strong> WhichInstances whichInstances,
266 Operationale Schnittstelle des Typmanagers<br />
<strong>in</strong> PolicyExpression policyExpression,<br />
out InstanceList result, // InstanceIdList??<br />
out Environment environment /* INVALID_TYPEID, TYPEID_DOES_NOT_EXIST,<br />
NO_DIRECT_TYPEID, NO_RELATIONSHIP_TYPE,<br />
UNKNOWN_POLICY, INVALID_POLICY_EXPRESSION */<br />
)�<br />
/*-------------------------------------------------*/<br />
/* Anfrage- und Suchschnittstelle */<br />
boolean AreRelated(<br />
<strong>in</strong> CanonicalTypeModel::TypeId relationship,<br />
<strong>in</strong> TypeDesc fromType,<br />
<strong>in</strong> TypeDesc toType,<br />
out Environment environment /* INVALID_TYPEID, TYPEID_DOES_NOT_EXIST,<br />
NO_DIRECT_TYPEID, NO_RELATIONSHIP_TYPE, INVALID_TYPE */<br />
)�<br />
enum K<strong>in</strong>dOfMatch { MATCHALLTERMS,<br />
MATCHANYTERM,<br />
MATCH2TERMS,<br />
MATCH3TERMS,<br />
MATCH4TERMS,<br />
MATCH5TERMS,<br />
NOCATEGORIES }�<br />
struct CategoryExpression {<br />
CanonicalTypeModel::IdentifierList categories�<br />
K<strong>in</strong>dOfMatch k<strong>in</strong>d�<br />
}�<br />
void F<strong>in</strong>dAllRelatedTypes(<br />
<strong>in</strong> CanonicalTypeModel::TypeId relationship,<br />
<strong>in</strong> TypeDesc referenceType,<br />
<strong>in</strong> Doma<strong>in</strong> startSearchAt,<br />
<strong>in</strong> CategoryExpression categoryExpression,<br />
<strong>in</strong> PolicyExpression policyExpression, /* GetMoreRelatedTypes */<br />
out CanonicalTypeModel::TypeIdList relatedTypes,<br />
out Environment environment /* INVALID_TYPEID, TYPEID_DOES_NOT_EXIST,<br />
NO_DIRECT_TYPEID, NO_RELATIONSHIP_TYPE, INVALID_TYPE,<br />
DOMAIN_DOES_NOT_EXIST, UNKNOWN_POLICY, INVALID_POLICY_EXPRESSION */<br />
)�<br />
void F<strong>in</strong>dAllRelatedServiceTypes(<br />
<strong>in</strong> CanonicalTypeModel::TypeId relationship,<br />
<strong>in</strong> odpTrad<strong>in</strong>gFunction::ServiceDescriptionType referenceType,<br />
<strong>in</strong> Doma<strong>in</strong> startSearchAt,<br />
<strong>in</strong> CategoryExpression categoryExpression,<br />
<strong>in</strong> PolicyExpression policyExpression, /* GetMoreRelatedTypes */<br />
out CanonicalTypeModel::TypeIdList relatedTypes,<br />
out Environment environment /* INVALID_TYPEID, TYPEID_DOES_NOT_EXIST,<br />
NO_DIRECT_TYPEID, NO_RELATIONSHIP_TYPE, INVALID_TYPE,
)�<br />
267<br />
DOMAIN_DOES_NOT_EXIST, UNKNOWN_POLICY, INVALID_POLICY_EXPRESSION */<br />
boolean TypeCheckServicePropertyValueList(<br />
<strong>in</strong> odpTrad<strong>in</strong>gFunction::ServiceDescriptionType serviceType,<br />
<strong>in</strong> odpTrad<strong>in</strong>gFunction::PropertyValueListType properties,<br />
out Environment environment /* TYPEID_DOES_NOT_EXIST, NO_SERVICE_TYPE,<br />
UNKNOWN_PROPERTY, INVALID_PROPERTY_VALUE */<br />
)�<br />
/*-------------------------------------------------*/<br />
/* Brows<strong>in</strong>g - Schnittstelle */<br />
boolean AreDirectRelated(<br />
<strong>in</strong> CanonicalTypeModel::TypeId relationship,<br />
<strong>in</strong> CanonicalTypeModel::TypeId fromType,<br />
<strong>in</strong> CanonicalTypeModel::TypeId toType,<br />
out InstanceId <strong>in</strong>stance,<br />
out Environment environment /* INVALID_TYPEID, TYPEID_DOES_NOT_EXIST,<br />
NO_DIRECT_TYPEID, NO_RELATIONSHIP_TYPE, INVALID_TYPE */<br />
)�<br />
struct RelatedType {<br />
CanonicalTypeModel::TypeId type�<br />
boolean symmetric�<br />
Doma<strong>in</strong> doma<strong>in</strong>�<br />
}�<br />
typedef sequence RelatedTypeList�<br />
long F<strong>in</strong>dAllDirectRelatedTypes(<br />
<strong>in</strong> boolean subTypes,<br />
<strong>in</strong> CanonicalTypeModel::TypeId relationship,<br />
<strong>in</strong> TypeDesc referenceType,<br />
<strong>in</strong> Doma<strong>in</strong> startSearchAt,<br />
<strong>in</strong> CategoryExpression categoryExpression,<br />
<strong>in</strong> boolean symmetricTypes,<br />
<strong>in</strong> PolicyExpression policyExpression, /* GetMoreRelatedTypes */<br />
out RelatedTypeList relatedTypes,<br />
out unsigned long totalNoOfRelatedTypes,<br />
out Environment environment /* INVALID_TYPEID, TYPEID_DOES_NOT_EXIST,<br />
NO_DIRECT_TYPEID, NO_RELATIONSHIP_TYPE, INVALID_TYPE,<br />
DOMAIN_DOES_NOT_EXIST, UNKNOWN_POLICY, INVALID_POLICY_EXPRESSION */<br />
)�<br />
long F<strong>in</strong>dAllEquivalentTypes(<br />
<strong>in</strong> CanonicalTypeModel::TypeId relationship,<br />
<strong>in</strong> TypeDesc referenceType,<br />
<strong>in</strong> Doma<strong>in</strong> startSearchAt,<br />
<strong>in</strong> CategoryExpression categoryExpression,<br />
<strong>in</strong> PolicyExpression policyExpression, /* GetMoreRelatedTypes */<br />
out RelatedTypeList equivalentTypes,
268 Operationale Schnittstelle des Typmanagers<br />
out unsigned long totalNoOfEquivalentTypes,<br />
out Environment environment /* INVALID_TYPEID, TYPEID_DOES_NOT_EXIST,<br />
NO_DIRECT_TYPEID, NO_RELATIONSHIP_TYPE, INVALID_TYPE,<br />
DOMAIN_DOES_NOT_EXIST, UNKNOWN_POLICY, INVALID_POLICY_EXPRESSION */<br />
)�<br />
void F<strong>in</strong>dTypes(<br />
<strong>in</strong> Doma<strong>in</strong> startSearchAt,<br />
<strong>in</strong> CanonicalTypeModel::K<strong>in</strong>dOfType whichK<strong>in</strong>d,<br />
<strong>in</strong> CategoryExpression categoryExpression,<br />
<strong>in</strong> boolean searchSubdoma<strong>in</strong>s,<br />
<strong>in</strong> PolicyExpression policyExpression, /* GetMoreTypeIdsInDoma<strong>in</strong> */<br />
out TypeManager::RelatedTypeList types,<br />
out unsigned long totalNoOfTypes,<br />
out Environment environment /* DOMAIN_DOES_NOT_EXIST,<br />
UNKNOWN_POLICY, INVALID_POLICY_EXPRESSION */<br />
)�<br />
}� // <strong>in</strong>terface TypeManager
Anhang D<br />
TRADEr{Schnittstellen<br />
Dieser Anhang zeigt die <strong>in</strong> DCE{IDL beschriebenen operationalen Schnittstelle<br />
des TRADErs. Zunachst wird die Trad<strong>in</strong>g{Schnittstelle des TRADErs angegeben.<br />
Anschlie end beschreibt Anhang D.2 die L<strong>in</strong>k{Management{Schnittstelle<br />
des TRADErs. Beide Schnittstellen bilden die geme<strong>in</strong>same Grundlage fur die<br />
im Rahmen des Projektes Interwork<strong>in</strong>g of Traders kooperierenden Trader (siehe<br />
Abschnitt 5.2.3).<br />
D.1 Trad<strong>in</strong>g{Schnittstelle<br />
[<br />
uuid(003b8c92-74e2-102f-9219-02608c2ec366),<br />
version(1.0),<br />
po<strong>in</strong>ter_default(ptr)<br />
]<br />
<strong>in</strong>terface TRADEr<br />
{<br />
import "iwt_types.idl"� /* IWT type def<strong>in</strong>itions */<br />
/* Def<strong>in</strong>ition of service offer <strong>in</strong>formation given<br />
back by the importOffer operation */<br />
typedef struct {<br />
[ptr] InterfaceIdentifierType *InterfaceIdentifier�<br />
[ptr] PropertyValueListType *servicePropertyValues�<br />
[ptr] PropertyValueListType *serviceOfferPropertyValues�<br />
} ServiceOfferDetailType�<br />
typedef struct ServiceOfferDetailListType {<br />
ServiceOfferDetailType *ServiceOfferDetails�<br />
[ptr] struct ServiceOfferDetailListType *next�<br />
} ServiceOfferDetailListType�
270 TRADEr{Schnittstellen<br />
/* special return code types for the importOffer operation */<br />
typedef enum { ok, partial_ok, not_ok } QualificationType�<br />
typedef enum { INVALID_ARGUMENTS, POLICY_EXCEPTION, NO_OFFERS_IN_SCOPE<br />
} ErrorCodeType�<br />
/*####################################################################<br />
def<strong>in</strong>ition of the importOffer operation,<br />
<strong>in</strong>clud<strong>in</strong>g the context name parameter */<br />
####################################################################*/<br />
void importOffer (<br />
[<strong>in</strong>] OpaqueIdentifierType clientId,<br />
[<strong>in</strong>] ContextNameType contextName,<br />
[<strong>in</strong>] ServiceTypeDescriptionType serviceTypeDescription,<br />
[<strong>in</strong>] PolicySpecificationType importerPolicy,<br />
[<strong>in</strong>] Constra<strong>in</strong>tSpecificationType match<strong>in</strong>gConstra<strong>in</strong>t,<br />
[<strong>in</strong>] PreferenceSpecificationType selectionPreference,<br />
[<strong>in</strong>] PropOfInterestListType servicePropOfInterest,<br />
[<strong>in</strong>] OfferPropOfInterestListType serviceOfferPropOfInterest,<br />
)�<br />
[out] QualificationType *qualification,<br />
[out] ErrorCodeType *errorCode,<br />
[out] ServiceOfferDetailListType *serviceOfferDetailList<br />
/*####################################################################<br />
def<strong>in</strong>ition of the exportOffer operation,<br />
<strong>in</strong>clud<strong>in</strong>g the context name parameter */<br />
####################################################################*/<br />
void exportOffer(<br />
[<strong>in</strong>] OpaqueIdentifierType clientId,<br />
[<strong>in</strong>] ContextNameType contextName,<br />
[<strong>in</strong>] ServiceTypeDescriptionType serviceTypeDescription,<br />
[<strong>in</strong>] PropertyValueListType *servicePropertyValues,<br />
[<strong>in</strong>] PropertyValueListType *serviceOfferPropertyValues,<br />
[<strong>in</strong>] InterfaceIdentifierType *serviceInterfaceId,<br />
[<strong>in</strong>] InterfaceIdentifierType *serviceOfferEvaluatorIfId,<br />
[out] QualificationType *qualification,<br />
[out] ErrorCodeType *errorCode,<br />
[out] OpaqueIdentifierType *serviceOfferIdentifier)�<br />
/*####################################################################<br />
def<strong>in</strong>ition of the withdrawOffer operation,<br />
<strong>in</strong>clud<strong>in</strong>g the context name parameter<br />
#####################################################################*/<br />
void withdrawOffer(<br />
[<strong>in</strong>] OpaqueIdentifierType clientId,
D.1 Trad<strong>in</strong>g{Schnittstelle 271<br />
}<br />
[<strong>in</strong>] ContextNameType contextList,<br />
[out] QualificationType *qualification,<br />
[out] ErrorCodeType *errorCode)�<br />
Weitere wichtige IDL{Beschreibungen be<strong>in</strong>halten die <strong>in</strong> der obigen Schnittstellenbeschreibung<br />
genutzten Typde nitionen.<br />
[<br />
uuid(61323372-e62f-11cd-b678-08002b37748c),<br />
version(1.0),<br />
po<strong>in</strong>ter_default(ptr)<br />
]<br />
<strong>in</strong>terface iwt_types<br />
{<br />
/* def<strong>in</strong>itions for IWT type representation */<br />
import "iwt_ast.idl"�<br />
/*#################################################################*/<br />
/* names are just human readable str<strong>in</strong>gs */<br />
typedef [str<strong>in</strong>g,ptr] char *NameType�<br />
/* opaque identifiers, just a bunch of data */<br />
typedef [str<strong>in</strong>g, ptr] char *OpaqueIdentifierType�<br />
/* type of certa<strong>in</strong> values, to specified elsewhere */<br />
/*typedef [str<strong>in</strong>g, ptr] char *ValueType�*/<br />
/* name list type to determ<strong>in</strong>e properties and contexts by name */<br />
typedef struct NameListType {<br />
NameType name�<br />
[ptr] struct NameListType *next�<br />
} NameListType�<br />
typedef [ptr] NameListType *ContextNameType�<br />
typedef [ptr] NameListType *PropOfInterestListType�<br />
typedef [ptr] NameListType *OfferPropOfInterestListType�<br />
/*#################################################################*/<br />
/* specifies a type for DCE str<strong>in</strong>g b<strong>in</strong>d<strong>in</strong>g�<br />
please note that str<strong>in</strong>g b<strong>in</strong>d<strong>in</strong>g <strong>in</strong>cludes an unique object identifier<br />
and that the b<strong>in</strong>d<strong>in</strong>g is only partial, i.e. endpo<strong>in</strong>ts not <strong>in</strong>cluded */<br />
typedef struct {<br />
[str<strong>in</strong>g, ptr] char *str<strong>in</strong>gB<strong>in</strong>d<strong>in</strong>g�<br />
} DceStr<strong>in</strong>gB<strong>in</strong>d<strong>in</strong>gType�<br />
/* specifies a type for DCE b<strong>in</strong>d<strong>in</strong>g us<strong>in</strong>g the CDS */<br />
typedef struct {<br />
[str<strong>in</strong>g, ptr] char *CdsEntryName�<br />
[str<strong>in</strong>g, ptr] char *objectUuid� /*optional*/<br />
} DceCdsB<strong>in</strong>d<strong>in</strong>gType�
272 TRADEr{Schnittstellen<br />
/* there might be more options for b<strong>in</strong>d<strong>in</strong>gs <strong>in</strong> DCE */<br />
typedef enum { b<strong>in</strong>dByStr<strong>in</strong>g, b<strong>in</strong>dByCds } DceK<strong>in</strong>dB<strong>in</strong>d<strong>in</strong>gType�<br />
typedef union switch( DceK<strong>in</strong>dB<strong>in</strong>d<strong>in</strong>gType dceK<strong>in</strong>dB<strong>in</strong>d<strong>in</strong>g ) dceInterfaceId {<br />
case b<strong>in</strong>dByStr<strong>in</strong>g : DceStr<strong>in</strong>gB<strong>in</strong>d<strong>in</strong>gType *dceStr<strong>in</strong>gB<strong>in</strong>d<strong>in</strong>g�<br />
case b<strong>in</strong>dByCds : DceCdsB<strong>in</strong>d<strong>in</strong>gType *dceCdsB<strong>in</strong>d<strong>in</strong>g�<br />
} DceInterfaceIdentifierType�<br />
/* CORBA <strong>in</strong>terfaces identifier are assumed to be object references<br />
presented as str<strong>in</strong>gs */<br />
typedef [str<strong>in</strong>g, ptr] char *CorbaInterfaceIdentifierType�<br />
/* ANSA <strong>in</strong>terfaces identifier are assumed to be presented as str<strong>in</strong>gs */<br />
typedef [str<strong>in</strong>g, ptr] char *AnsaInterfaceIdentifierType�<br />
/* ONC <strong>in</strong>terfaces identifier are assumed to be a hostname<br />
represented by a str<strong>in</strong>g */<br />
typedef [str<strong>in</strong>g, ptr] char *OncInterfaceIdentifierType�<br />
/* def<strong>in</strong>es a common <strong>in</strong>terface identifier type,<br />
which can be either direct or <strong>in</strong>direct. The <strong>in</strong>direct<br />
<strong>in</strong>cludes a po<strong>in</strong>ter to type description (type manager)<br />
and a value (chunk of data). The direct one which allows<br />
b<strong>in</strong>d<strong>in</strong>g <strong>in</strong> a particular middlerware doma<strong>in</strong> */<br />
typedef enum { DIRECT, INDIRECT } K<strong>in</strong>dType�<br />
typedef enum { DCE_MW, CORBA_MW, ANSA_MW, ONC_MW } MiddlewareType�<br />
typedef union switch( MiddlewareType middleware ) directId {<br />
case DCE_MW: [ptr] DceInterfaceIdentifierType<br />
*dceInterfaceIdentifier�<br />
case CORBA_MW: [ptr] CorbaInterfaceIdentifierType<br />
*corbaInterfaceIdentifier�<br />
case ANSA_MW: [ptr] AnsaInterfaceIdentifierType<br />
*ansaInterfaceIdentifier�<br />
case ONC_MW: [ptr] OncInterfaceIdentifierType<br />
*oncInterfaceIdentifier�<br />
} DirectInterfaceIdType�<br />
typedef struct {<br />
/* identifies the <strong>in</strong>terface of a type manager */<br />
[ptr] DirectInterfaceIdType *typeManagerIdentifier�<br />
/* this one identifies the type def<strong>in</strong>ition with<strong>in</strong> the type manager */<br />
OpaqueIdentifierType <strong>in</strong>ternalIdentifier�<br />
} TypeManagerIdentifierType�<br />
/* an <strong>in</strong>direct <strong>in</strong>terface identifier is determ<strong>in</strong>ed by a 'typeOfIdentifier'<br />
which allows to get the type <strong>in</strong>formation of this <strong>in</strong>terface ident from<br />
a type manager, the 'valueOfIdentifier' is a value of this type */<br />
typedef struct {<br />
[ptr] TypeManagerIdentifierType *typeOfIdentifier�<br />
[str<strong>in</strong>g, ptr] char *valueOfIdentifier�<br />
} IndirectInterfaceIdType�
D.1 Trad<strong>in</strong>g{Schnittstelle 273<br />
typedef union switch( K<strong>in</strong>dType k<strong>in</strong>dInterface ) <strong>in</strong>terfaceId {<br />
case DIRECT: [ptr] DirectInterfaceIdType<br />
*directInterfaceIdentifier�<br />
case INDIRECT: [ptr] IndirectInterfaceIdType<br />
*<strong>in</strong>directInterfaceIdentifier�<br />
} InterfaceIdentifierType�<br />
typedef struct InterfaceIdentifierListType {<br />
[ptr] InterfaceIdentifierType *InterfaceIdentifier�<br />
[ptr] struct InterfaceIdentifierListType *next�<br />
} InterfaceIdentifierListType�<br />
/* computational <strong>in</strong>terface types and service types<br />
are assumed to be stored <strong>in</strong> a type manager */<br />
typedef TypeManagerIdentifierType CompInterfaceTypeIdentType�<br />
typedef TypeManagerIdentifierType ServiceTypeIdentifierType�<br />
/*#################################################################*/<br />
/* DirectValueType is be<strong>in</strong>g used to store values <strong>in</strong><br />
NamedValue-Structures */<br />
typedef Any DirectValueType�<br />
typedef struct {<br />
TypeManagerIdentifierType *ValueTypeId�<br />
char *Value�<br />
} IndirectValueType�<br />
typedef union switch (K<strong>in</strong>dType valueK<strong>in</strong>d) value<br />
{<br />
case DIRECT : DirectValueType *directValue�<br />
case INDIRECT : IndirectValueType *<strong>in</strong>directValue�<br />
} ValueType�<br />
/*#################################################################*/<br />
/* direct relational operators */<br />
typedef enum<br />
{<br />
short_eq, short_lt, short_le, short_gt , short_ge, short_ne,<br />
long_eq, long_lt, long_le, long_gt, long_ge, long_ne,<br />
ushort_eq, ushort_lt, ushort_le, ushort_gt , ushort_ge, ushort_ne,<br />
ulong_eq, ulong_lt, ulong_le, ulong_gt, ulong_ge, ulong_ne,<br />
float_eq, float_lt, float_le, float_gt, float_ge, float_ne,<br />
double_eq, double_lt, double_le, double_gt, double_ge, double_ne,<br />
boolean_eq, boolean_ne,<br />
char_eq, char_lt, char_gt, char_ne,<br />
octet_eq, octet_ne,<br />
struct_eq, struct_ne,<br />
union_eq, union_ne,<br />
enum_eq, enum_ne,<br />
eq_str<strong>in</strong>g_case_sensitive, eq_str<strong>in</strong>g_case_<strong>in</strong>sensitive,<br />
sub_str<strong>in</strong>g_case_sensitive, sub_str<strong>in</strong>g_case_<strong>in</strong>sensitive,<br />
sequence_eq, sequence_ne, sub_sequence,
274 TRADEr{Schnittstellen<br />
array_eq, array_ne, sub_array<br />
} DirectRelationshipIdType�<br />
/* def<strong>in</strong>ition of relationship type */<br />
/* direct relationships are def<strong>in</strong>ed <strong>in</strong> iwt_ast.idl ! */<br />
typedef union switch (K<strong>in</strong>dType relationshipK<strong>in</strong>d ) relationshipIdentifier {<br />
case DIRECT:<br />
[ptr] DirectRelationshipIdType<br />
*directRelationshipIdentifier�<br />
case INDIRECT:<br />
[ptr] TypeManagerIdentifierType<br />
*<strong>in</strong>directRelationshipIdentifier�<br />
} RelationshipIdentifierType�<br />
/*#################################################################*/<br />
/* signature of properties, i.e. property type and property name */<br />
typedef struct {<br />
[ptr] TypeManagerIdentifierType *propertyType�<br />
NameType propertyName�<br />
} PropertySigType�<br />
typedef struct PropertySigListType {<br />
PropertySigType *propertySig�<br />
[ptr] struct PropertySigListType *next�<br />
} PropertySigListType�<br />
/* property values, i.e. property signature and property value */<br />
typedef struct {<br />
/*PropertySigType *propertySig�*/<br />
NameType propertyName�<br />
ValueType *value�<br />
} PropertyValueType�<br />
typedef struct PropertyValueListType {<br />
PropertyValueType *propertyValue�<br />
[ptr] struct PropertyValueListType *next�<br />
} PropertyValueListType�<br />
/*#################################################################*/<br />
/* k<strong>in</strong>d of service description */<br />
typedef enum { byServiceId, byInterfaceId, bySignature } ServiceDescK<strong>in</strong>dType�<br />
typedef struct {<br />
[ptr] CompInterfaceTypeIdentType *compInterfaceTypeIdent�<br />
[ptr] PropertySigListType *servicePropertyTypeList�<br />
} DescByInterfaceIdType�<br />
typedef enum {<br />
DCE_IDL, CORBA_IDL, ANSA_IDL, ONC_IDL, ENCINA_TIDL ,<br />
DCE_AST, CORBA_AST, /* str<strong>in</strong>g representations of abstract syntax trees<br />
used at the DSTC */
D.1 Trad<strong>in</strong>g{Schnittstelle 275<br />
IWT_AST /* servive type represenation based on type codes<br />
proposed by Kay Mueller-Jones, Univ. of Hamburg */<br />
/*,... */}<br />
TypeDescriptionLanguageType�<br />
typedef union switch( TypeDescriptionLanguageType tdl ) td {<br />
case DCE_IDL:<br />
case CORBA_IDL:<br />
case ANSA_IDL:<br />
case ONC_IDL:<br />
case DCE_AST:<br />
case CORBA_AST: [str<strong>in</strong>g, ptr] char *ifTypeDesc�<br />
case IWT_AST: [ptr] SvcTypeDescType *svcTypeDesc�<br />
} TypeDescriptionType�<br />
typedef struct {<br />
[ptr] TypeDescriptionType *typeDescription�<br />
[ptr] PropertySigListType *servicePropertyTypeList�<br />
/* is NULL when IWT_AST type<br />
description is used */<br />
} DescBySignatureType�<br />
typedef union switch( ServiceDescK<strong>in</strong>dType sdkt ) serviceTypeDesc {<br />
case byServiceId: [ptr] ServiceTypeIdentifierType<br />
*serviceTypeIdentifier�<br />
case byInterfaceId: [ptr] DescByInterfaceIdType<br />
*descByInterfaceId�<br />
case bySignature: [ptr] DescBySignatureType<br />
*descBySignature�<br />
} ServiceTypeDescriptionType�<br />
/*#################################################################*/<br />
typedef struct {<br />
[ptr] RelationshipIdentifierType *relationshipIdentifier�<br />
NameType propertyName�<br />
ValueType *value�<br />
} RelationshipType�<br />
/* Rules for specify<strong>in</strong>g policies and constra<strong>in</strong>ts */<br />
typedef enum { exist, relation } RuleIndicatorType�<br />
typedef union switch( RuleIndicatorType ruleIndicator ) simpleRule {<br />
case exist: NameType propertyName�<br />
case relation: [ptr] RelationshipType *relationship�<br />
} SimpleRuleType�<br />
typedef enum { NOT, AND, OR } OperatorType�<br />
typedef enum { SIMPLE, COMPLEX } ComplexityType�<br />
typedef struct RuleType {<br />
union switch( ComplexityType complexity ) rule {<br />
case SIMPLE: SimpleRuleType *simpleRule�
276 TRADEr{Schnittstellen<br />
case COMPLEX: union switch( OperatorType op ) complexRule {<br />
case NOT: [ptr] struct RuleType *unary_rule�<br />
case AND:<br />
case OR:<br />
struct {<br />
[ptr] struct RuleType *left_rule�<br />
[ptr] struct RuleType *right_rule�<br />
} b<strong>in</strong>ary_rule�<br />
} complexRule�<br />
} RuleUnionType�<br />
} RuleType�<br />
/* types derived from rule type */<br />
typedef [ptr] RuleType *PolicySpecificationType�<br />
typedef [ptr] RuleType *Constra<strong>in</strong>tSpecificationType�<br />
typedef [ptr] RuleType *PreferenceSpecificationType�<br />
}<br />
%###############################################################<br />
%###############################################################<br />
%###############################################################<br />
[<br />
uuid(00439d24-8209-1f52-a638-02608c2d4e81),<br />
po<strong>in</strong>ter_default(ptr),version(1.0)<br />
]<br />
<strong>in</strong>terface iwt_ast {<br />
/* flags for specify<strong>in</strong>g operation parameters and results */<br />
const unsigned long DCE_ARG_IN = 0x1�<br />
const unsigned long DCE_ARG_OUT = 0x2�<br />
const unsigned long DCE_ARG_INOUT = 0x4�<br />
const unsigned long DCE_STATIC = 0x8�<br />
const unsigned long DCE_DYNAMIC = 0x10�<br />
/* additional flags - implementation dependent */<br />
const unsigned long DCE_DONT_CARE = 0x10000�<br />
const unsigned long DCE_VAR = 0x20000�<br />
const unsigned long DCE_INITIALIZED = 0x40000�<br />
typedef unsigned long DCE_Flags�<br />
/* type codes for basic data types (similiar as <strong>in</strong> CORBA) */<br />
typedef enum {<br />
tk_null,tk_void,<br />
tk_short,tk_long,tk_ushort,tk_ulong,<br />
tk_float,tk_double,tk_boolean,tk_char,<br />
tk_octet,tk_any,tk_TypeCode,<br />
tk_Pr<strong>in</strong>cipal, tk_objref,<br />
tk_struct,tk_union,tk_enum,tk_str<strong>in</strong>g,
D.1 Trad<strong>in</strong>g{Schnittstelle 277<br />
tk_sequence,tk_array<br />
} TCK<strong>in</strong>d�<br />
typedef struct NVList {<br />
[ptr]struct NamedValue *curr�<br />
[ptr]struct NVList *next�<br />
} NVList�<br />
typedef struct NamedValue{<br />
[str<strong>in</strong>g]char *name�<br />
[ptr]union Any *argument�<br />
unsigned long len�<br />
DCE_Flags argmode�<br />
} NamedValue�<br />
/* def<strong>in</strong>itions of complex data structures */<br />
typedef NVList Struct�<br />
typedef NVList Sequence�<br />
typedef struct EnumList{<br />
[str<strong>in</strong>g]char *name�<br />
short <strong>in</strong>t value�<br />
[ptr]struct EnumList *next�<br />
} EnumList�<br />
typedef struct Enum{<br />
[str<strong>in</strong>g]char *label�<br />
[ptr]EnumList *list�<br />
} Enum�<br />
typedef struct Union{<br />
[str<strong>in</strong>g]char *label�<br />
[ptr]NVList *u�<br />
} Union�<br />
typedef struct Array{<br />
short <strong>in</strong>t length�<br />
[ptr]NVList *a�<br />
} Array�<br />
/* def<strong>in</strong>ition of Any Type represent<strong>in</strong>g dist<strong>in</strong>ct types */<br />
typedef union Any<br />
switch (TCK<strong>in</strong>d type) value {<br />
case tk_null: short <strong>in</strong>t n�<br />
case tk_void: short <strong>in</strong>t v�<br />
case tk_short: short <strong>in</strong>t s�<br />
case tk_long: long <strong>in</strong>t l�<br />
case tk_ushort: unsigned short <strong>in</strong>t us�<br />
case tk_ulong: unsigned long <strong>in</strong>t ul�<br />
case tk_float: float f�<br />
case tk_double: double d�<br />
case tk_boolean: boolean b�
278 TRADEr{Schnittstellen<br />
case tk_char: char c�<br />
case tk_octet: byte o�<br />
case tk_any: [ptr] NamedValue *any�<br />
case tk_TypeCode: TCK<strong>in</strong>d t�<br />
case tk_Pr<strong>in</strong>cipal: [str<strong>in</strong>g,ptr] char *pr<strong>in</strong>cipal�<br />
case tk_objref: [str<strong>in</strong>g,ptr] char *objref�<br />
case tk_struct: [ptr]Struct *st�<br />
case tk_union: [ptr]Union *u�<br />
case tk_enum: [ptr]Enum *e�<br />
case tk_str<strong>in</strong>g: [str<strong>in</strong>g] char *str�<br />
case tk_sequence: [ptr]Sequence *sq�<br />
case tk_array: [ptr]Array *a�<br />
} Any�<br />
/* Flags def<strong>in</strong><strong>in</strong>g operation call semantic */<br />
typedef enum {MAYBE, AT_LEAST_ONCE, AT_MOST_ONCE, EXACTLY_ONCE}<br />
OpFlagsType�<br />
/* Exceptions */<br />
typedef enum {<br />
NO_EXCEPTION,USER_EXCEPTION,SYSTEM_EXCEPTION<br />
} Exception_type�<br />
typedef struct {<br />
Exception_type major�<br />
[str<strong>in</strong>g,ptr]char *identifier�<br />
Any *value�<br />
} Environment�<br />
/* Standard Exception Identifiers */<br />
/* ... (for further specification !!!) */<br />
/* Attribute declarations as NVLists */<br />
typedef NVList AttributeListType�<br />
/* Operation type description */<br />
typedef struct OperationType {<br />
[str<strong>in</strong>g] char *opName�<br />
[ptr] NVList *params�<br />
OpFlagsType opMode�<br />
Environment *execption�<br />
[str<strong>in</strong>g] char *semantics�<br />
} OperationType�<br />
typedef struct OperationListType {<br />
[ptr] OperationType *curr�<br />
[ptr] struct OperationListType *next�<br />
} OperationListType�<br />
/* Interface type description */<br />
typedef struct IfTypeRepType {<br />
[str<strong>in</strong>g] char *ifTypeName�<br />
[ptr] OperationListType *opSignatures�
D.2 L<strong>in</strong>k{Management{Schnittstelle 279<br />
[str<strong>in</strong>g] char *semantics�<br />
} IfTypeRepType�<br />
/* Service type description */<br />
typedef struct SvcTypeDescType {<br />
[str<strong>in</strong>g] char *svcTypeName�<br />
[ptr] IfTypeRepType *ifType�<br />
[ptr] AttributeListType *svcAttributeTypes�<br />
[str<strong>in</strong>g] char *semantics�<br />
} SvcTypeDescType�<br />
}<br />
D.2 L<strong>in</strong>k{Management{Schnittstelle<br />
[<br />
uuid(049d5416-d454-11ce-a8a8-08002b3fae64),<br />
version(1.0),<br />
po<strong>in</strong>ter_default(ptr)<br />
]<br />
<strong>in</strong>terface iwt_lima<br />
{<br />
import "iwt_types.idl"� /* reference to TRADEr/IWT def<strong>in</strong>itions */<br />
import "iwt_import.idl"� /* reference to TRADEr/IWT def<strong>in</strong>itions */<br />
/* add l<strong>in</strong>k */<br />
void addL<strong>in</strong>k([<strong>in</strong>] PropertyValueListType *l<strong>in</strong>kPropValues,<br />
[<strong>in</strong>] InterfaceIdentifierType *targetInterfaceId,<br />
[out] OpaqueIdentifierType **l<strong>in</strong>kId,<br />
[out] QualificationType *qualification,<br />
[out] ErrorCodeType *errorCode)�<br />
/* remove l<strong>in</strong>k */<br />
void removeL<strong>in</strong>k([<strong>in</strong>] OpaqueIdentifierType *l<strong>in</strong>kId,<br />
[out] QualificationType *qualification,<br />
[out] ErrorCodeType *errorCode)�<br />
/* modify l<strong>in</strong>k */<br />
void modifyL<strong>in</strong>k([<strong>in</strong>] OpaqueIdentifierType *l<strong>in</strong>kId,<br />
[<strong>in</strong>] PropertyValueListType *l<strong>in</strong>kPropValues,<br />
[out] QualificationType *qualification,<br />
[out] ErrorCodeType *errorCode)�<br />
/* describe l<strong>in</strong>k */<br />
void describeL<strong>in</strong>k([<strong>in</strong>] OpaqueIdentifierType *l<strong>in</strong>kId,<br />
[out] InterfaceIdentifierType **targetInterfaceId,<br />
[out] PropertyValueListType **l<strong>in</strong>kPropValues,<br />
[out] QualificationType *qualification,
280 TRADEr{Schnittstellen<br />
[out] ErrorCodeType *errorCode)�<br />
/* list l<strong>in</strong>ks */<br />
void listL<strong>in</strong>ks([out] NameListType **l<strong>in</strong>kIds,<br />
[out] QualificationType *qualification,<br />
[out] ErrorCodeType *errorCode)�<br />
}
Anhang E<br />
De nitionsschnittstelle des<br />
Koord<strong>in</strong>ationsmanagers<br />
Dieser Anhang zeigt zunachst die <strong>in</strong> DCE{IDL beschriebene De nitionsschnittstelle<br />
des Koord<strong>in</strong>ationsmanagers. Anschlie end gibt Anhang E.2 e<strong>in</strong> Beispiel<br />
von Registrationskode, welcher vom PAMELA{Sprachubersetzer zum Zugri auf<br />
die De nitionsschnittstelle generiert wurde. Ausfuhrliche Erlauterungen der e<strong>in</strong>zelnen<br />
Operationen des Koord<strong>in</strong>ationsmanagers nden sich sowohl <strong>in</strong> Abschnitt<br />
6.2.2.1 als auch <strong>in</strong> [Bri95] und [Gri95].<br />
E.1 Schnittstellenbeschreibung<br />
[<br />
uuid(0024a0ae-2368-522f-ab0d-08005a018f9d),<br />
version(1.0),<br />
po<strong>in</strong>ter_default(ptr)<br />
]<br />
<strong>in</strong>terface act_netdef{<br />
import "iwt_ast.idl"� // reference to TRADEr/IWT def<strong>in</strong>itions<br />
typedef [context_handle] void *net_handle_t�<br />
typedef [context_handle] void *trans_handle_t�<br />
typedef [context_handle] void *place_handle_t�<br />
typedef [context_handle] void *service_handle_t�<br />
typedef long status_t�<br />
typedef [str<strong>in</strong>g] char *name_t�<br />
typedef [str<strong>in</strong>g] char *serviceName_t�<br />
typedef [str<strong>in</strong>g] char *serviceAttribute_t�
282 De nitionsschnittstelle des Koord<strong>in</strong>ationsmanagers<br />
/****************************************************************<br />
* function : createNet<br />
***************************************************************/<br />
net_handle_t createNet([<strong>in</strong>]name_t name,<br />
[out]status_t *stat)�<br />
/****************************************************************<br />
* function : createPlace<br />
***************************************************************/<br />
place_handle_t createPlace([<strong>in</strong>]net_handle_t net,<br />
[<strong>in</strong>]name_t name,<br />
[<strong>in</strong>,ptr]NamedValue *type,<br />
[out]status_t *stat)�<br />
/****************************************************************<br />
* function : createTransition<br />
***************************************************************/<br />
typedef enum {<br />
am_NOT,<br />
am_AND,<br />
am_OR<br />
} boolop_t�<br />
typedef enum {<br />
EQUAL,<br />
NOTEQUAL,<br />
LESS,<br />
LESSEQUAL,<br />
GREATER,<br />
GREATEREQUAL<br />
} relop_t�<br />
typedef struct {<br />
relop_t relop�<br />
NamedValue *left�<br />
NamedValue *right�<br />
} simpleExpr_t�<br />
typedef enum {<br />
simple,<br />
complex<br />
} exprK<strong>in</strong>d_t�<br />
typedef union expr_t switch (exprK<strong>in</strong>d_t k<strong>in</strong>d) expr{<br />
case complex:<br />
union complexExpr_t *complexEx�<br />
case simple:<br />
simpleExpr_t *simpleEx�<br />
} expr_t�<br />
typedef union complexExpr_t switch(boolop_t boolop)expr{
E.1 Schnittstellenbeschreibung 283<br />
case am_NOT:<br />
expr_t *notExpr�<br />
case am_AND:<br />
struct{<br />
expr_t *left�<br />
expr_t *right�<br />
} andExpr�<br />
case am_OR:<br />
struct{<br />
expr_t *left�<br />
expr_t *right�<br />
} orExpr�<br />
} complexExpr_t�<br />
typedef enum {<br />
regular,<br />
transactional,<br />
synctask,<br />
asynctask,<br />
<strong>in</strong>it<br />
} transition_t�<br />
trans_handle_t createTransition([<strong>in</strong>]net_handle_t net,<br />
[<strong>in</strong>]name_t name,<br />
[<strong>in</strong>]transition_t type,<br />
[<strong>in</strong>,ptr]expr_t *guard,<br />
[out]status_t *stat)�<br />
/****************************************************************<br />
* function : createInputArc<br />
***************************************************************/<br />
void createInputArc([<strong>in</strong>]trans_handle_t transition,<br />
[<strong>in</strong>]place_handle_t place,<br />
[<strong>in</strong>]name_t tokenName,<br />
[<strong>in</strong>,ptr]expr_t *condition,<br />
[out]status_t *stat)�<br />
/****************************************************************<br />
* function : createOutputArc<br />
***************************************************************/<br />
typedef enum{<br />
on_commit,<br />
on_error,<br />
on_abort<br />
} case_t�<br />
void createOutputArc([<strong>in</strong>]trans_handle_t transition,<br />
[<strong>in</strong>]place_handle_t place,<br />
[<strong>in</strong>]name_t tokenName,<br />
[<strong>in</strong>]case_t type,<br />
[out]status_t *stat)�<br />
/****************************************************************
284 De nitionsschnittstelle des Koord<strong>in</strong>ationsmanagers<br />
* function : createServiceCall<br />
***************************************************************/<br />
typedef enum{<br />
SEQ,<br />
PAR<br />
} service_t�<br />
typedef struct {<br />
[str<strong>in</strong>g]char *serviceName�<br />
[str<strong>in</strong>g]char *<strong>in</strong>terfaceName�<br />
[ptr]expr_t *serviceAttr�<br />
[str<strong>in</strong>g]char *operation�<br />
[ptr]NVList *callInputParams�<br />
[ptr]NVList *callOutputParams�<br />
} serviceCall_t�<br />
service_handle_t createServiceCall([<strong>in</strong>]trans_handle_t trans)�<br />
/****************************************************************<br />
* function : addServiceCall<br />
***************************************************************/<br />
service_handle_t<br />
addServiceCall([<strong>in</strong>]service_handle_t ancestor,<br />
[<strong>in</strong>]service_t k<strong>in</strong>d,<br />
[<strong>in</strong>]serviceCall_t service)�<br />
typedef enum {<br />
create,<br />
assign,<br />
add,<br />
subtract,<br />
multiply,<br />
divide,<br />
modulo<br />
} operation_t�<br />
/****************************************************************<br />
* function : addTokenModifier<br />
***************************************************************/<br />
void addTokenModifier([<strong>in</strong>]trans_handle_t transition,<br />
[<strong>in</strong>,str<strong>in</strong>g]char *name,<br />
[<strong>in</strong>]case_t <strong>in</strong>_case,<br />
[<strong>in</strong>]operation_t operation,<br />
[<strong>in</strong>,ptr]NamedValue *nv)�<br />
}
E.2 Aus PAMELA generierter Programmkode 285<br />
E.2 Aus PAMELA generierter Programmkode<br />
Die folgende Abbildung zeigt e<strong>in</strong> Beispiel von Anwendungskode, welcher vom<br />
PAMELA{Sprachubersetzer aus e<strong>in</strong>er gegebenen PAMELA{Beschreibung erzeugt<br />
wurde. Die dort generierten Operationen entsprechen denen der im vorherigen<br />
Anhang beschriebenen De nitionsschnittstelle des Koord<strong>in</strong>ationsmanagers.<br />
/* DO NOT EDIT -- Automatically generated from st.idl */<br />
#<strong>in</strong>clude “am.h”<br />
#ifndef NULL<br />
#def<strong>in</strong>e NULL 0<br />
#endif<br />
class Class_Dealer {<br />
public:<br />
void process_Dealer(void) {<br />
status_t st;<br />
void* Dealer = createNet(“Dealer”, &st);<br />
NamedValue* Dealer_Money = NV_createStruct(“Dealer_Money”);<br />
NamedValue* Dealer_Money_stuff = NV_createStr<strong>in</strong>g(“Dealer_Money_stuff”);<br />
NV_addStructMember(Dealer_Money, Dealer_Money_stuff);<br />
...<br />
void* Dealer_Prices = createPlace(Dealer, “Dealer_Prices”, NV_copyType(Dealer_Money), &st);<br />
void* Dealer_Start = createTransition(Dealer, “Dealer_Start”, <strong>in</strong>it, NULL, &st);<br />
NamedValue* Dealer_Start_m = NV_copyType(Dealer_Owner);<br />
addTokenModifier(Dealer_Start,<br />
“m”,<br />
on_commit, create,<br />
Dealer_Start_m<br />
);<br />
...<br />
void* Dealer_Buy = createTransition(Dealer, “Dealer_Buy”, regular, NULL, &st);<br />
NamedValue* tmp_6 = NV_createLong(“c1.Dealer_Owner_buckets”);<br />
NV_setFlag(tmp_6, DCE_VAR);<br />
NamedValue* Dealer_Buy__Const_1 = NV_createLong(“const”);<br />
NV_setLong(Dealer_Buy__Const_1, 0);<br />
NamedValue* Dealer_Buy_c1 = NV_copyType(Dealer_Owner);<br />
expr_t *Dealer_Buy_Customers_Exp1 = createSimpleExpression(NOTEQUAL,<br />
tmp_6,<br />
Dealer_Buy__Const_1<br />
);<br />
createInputArc(Dealer_Buy, Dealer_Customers, “c1”, Dealer_Buy_Customers_Exp1, &st);<br />
...<br />
void* Dealer_Buy__Actions = createServiceCall(Dealer_Buy);<br />
NVList* Dealer_Buy_CardAgency_CreditCard_debitCard__<strong>in</strong>P_1 = NULL;<br />
NVList* Dealer_Buy_CardAgency_CreditCard_debitCard__outP_1 = NULL;<br />
NamedValue* tmp_9 = NV_createLong(“Class”);<br />
NV_setFlag(tmp_9, DCE_VAR);<br />
NamedValue* Dealer_Buy__Const_2 = NV_createLong(“const”);<br />
NV_addNVListElement(&Dealer_Buy_CardAgency_CreditCard_debitCard__<strong>in</strong>P_1, tmp_10);<br />
serviceCall_t CardAgency_CreditCard_debitCard_SvcInfo_1 = {<br />
“CardAgency”,<br />
“CreditCard”,<br />
createSimpleExpression(EQUAL,<br />
tmp_9,<br />
Dealer_Buy__Const_2<br />
),<br />
“debitCard”,<br />
Dealer_Buy_CardAgency_CreditCard_debitCard__<strong>in</strong>P_1,<br />
Dealer_Buy_CardAgency_CreditCard_debitCard__outP_1<br />
};<br />
void* Dealer_Buy_CardAgency_CreditCard_debitCard_1 = addServiceCall(<br />
Dealer_Buy__Actions,<br />
SEQ,<br />
CardAgency_CreditCard_debitCard_SvcInfo_1<br />
);<br />
} ...<br />
Abbildung E.1:Vom PAMELA{Sprachubersetzer erzeugter De nitionskode
Abbildungsverzeichnis<br />
2.1 Wechselseitige Umwandlung von Dienstbeschreibung und<br />
Dienstreprasentation ::::::::::::::::::::::::: 17<br />
2.2 Aufbau e<strong>in</strong>es Objektes :::::::::::::::::::::::: 19<br />
2.3 Grundlegendes Client/Server{Modell :::::::::::::::: 21<br />
2.4 Konformitat von Schnittstellen ::::::::::::::::::: 27<br />
2.5 DCE{Schnittstellenname ::::::::::::::::::::::: 29<br />
2.6 Erweiterung von Schnittstellenbeschreibungen um Dienstattribute 32<br />
2.7 Konzeptgraph zur Beschreibung der Eigenschaften e<strong>in</strong>es Druckers 33<br />
2.8 Standardisierte Bezeichner fur Konzepte und Relationen :::::: 34<br />
2.9 Transitionssysteme fur die Diensttypen Stack und Variable ::: 36<br />
2.10 Beispiel e<strong>in</strong>er um Vor{ und Nachbed<strong>in</strong>gungen erweiterten COR-<br />
BA IDL :::::::::::::::::::::::::::::::: 39<br />
3.1 Betrachtungsebenen des Dienstzugangs ::::::::::::::: 46<br />
3.2 Heterogenitatsgrenzen beim Zugang zu Diensten : : : : : : : : : : 47<br />
3.3 Mogliche Klienten e<strong>in</strong>es Typmanagers :::::::::::::::: 53<br />
3.4 Hierarchie von Typde nitionen im CORBA{Schnittstellenrepository 55<br />
3.5 Namensbasierter Diensttypgraph <strong>in</strong> ANSA : : : : : : : : : : : : : 56<br />
3.6 Bestandteile e<strong>in</strong>er Diensttypbeschreibung : : : : : : : : : : : : : : 58<br />
3.7 Struktureller Aufbau von Beziehungstypen : : : : : : : : : : : : : 60<br />
3.8 Verwaltung von Typen und Instanzen :::::::::::::::: 63<br />
3.9 Beispiel e<strong>in</strong>er Diensttyphierarchie mit virtuellen Diensttypen ::: 65<br />
3.10 Konformitatsbeziehungen zwischen realen Diensttypen :::::: 66<br />
3.11 Strategien bei der Speicherung von Diensttyphierarchien : : : : : 67<br />
3.12 Typuberprufung zum B<strong>in</strong>dungszeitpunkt : : : : : : : : : : : : : : 69<br />
3.13 Typ{ und Wertuberprufung beim dynamischen Operationsaufruf : 70
288 ABBILDUNGSVERZEICHNIS<br />
3.14 Typ{ und Wertuberprufung beim statischen, generierten Operationsaufruf<br />
:::::::::::::::::::::::::::::::: 71<br />
3.15 Verteiltes Diensttypmanagement ::::::::::::::::::: 72<br />
3.16 Format e<strong>in</strong>es Typbezeichners ::::::::::::::::::::: 73<br />
3.17 Austausch von Dienstbeschreibungen zum B<strong>in</strong>dungszeitpunkt ::: 74<br />
3.18 Der Trader und se<strong>in</strong>e Nutzer ::::::::::::::::::::: 79<br />
3.19 Trader{Kontexte ::::::::::::::::::::::::::: 80<br />
3.20 Bestandteile e<strong>in</strong>es Dienstangebotes ::::::::::::::::: 81<br />
3.21 Rolle des Dienstangebots beim Trad<strong>in</strong>g ::::::::::::::: 82<br />
3.22 Pr<strong>in</strong>zip der gesta elten Auswertung ::::::::::::::::: 84<br />
3.23 Komponenten e<strong>in</strong>er Trader{Kooperation :::::::::::::: 86<br />
3.24 Indirekte Trader{Kooperation :::::::::::::::::::: 87<br />
3.25 Protokollgesteuerte, direkte Trader{Kooperation :::::::::: 89<br />
3.26 Verknupfung von Tradern durch L<strong>in</strong>ks ::::::::::::::: 90<br />
3.27 Weiterreichen e<strong>in</strong>er Dienstanfrage :::::::::::::::::: 91<br />
3.28 Typmanager{unterstutzte Trader{Kooperation ::::::::::: 92<br />
3.29 Ignorante, Typmanager{gesteuerte Trader{Kooperation :::::: 94<br />
3.30 Ignorante, Trader{gesteuerte Trader{Kooperation ::::::::: 95<br />
3.31 Bewu te, Trader{gesteuerte Trader{Kooperation :::::::::: 96<br />
3.32 Bewu te, Typmanager{gesteuerte Trader{Kooperation :::::: 97<br />
3.33 Trader{Kooperation basierend auf standardisierten Diensttypbeschreibungen<br />
::::::::::::::::::::::::::::: 98<br />
3.34 Trader{Kooperation basierend auf standardisierten Diensttypbezeichnern<br />
::::::::::::::::::::::::::::::: 99<br />
3.35 Berucksichtigung von Beziehungstypen bei der Trader{Kooperation100<br />
3.36 Dienstzugri uber organisationelle Heterogenitatsgrenzen h<strong>in</strong>weg : 102<br />
3.37 B<strong>in</strong>dungsuberprufung durch e<strong>in</strong>en Interzeptor :::::::::::104<br />
3.38 Ausschnitt e<strong>in</strong>er Abbildung e<strong>in</strong>er DCE{ auf e<strong>in</strong>e CORBA{<br />
Dienstbeschreibung ::::::::::::::::::::::::::105<br />
3.39 Object Mapp<strong>in</strong>g ::::::::::::::::::::::::::::108<br />
3.40 Statischer, generierter Interzeptor ::::::::::::::::::109<br />
3.41 Dynamischer Interzeptor :::::::::::::::::::::::110<br />
3.42 Ubertragung von Fremdkonzepten ::::::::::::::::::111<br />
3.43 Kooperationsbeziehungen beim Dienstzugang ::::::::::::113
ABBILDUNGSVERZEICHNIS 289<br />
4.1 Grad der <strong>Dienstnutzung</strong> :::::::::::::::::::::::118<br />
4.2 Nebenlau gkeit von Aktivitaten und Aktionen : : : : : : : : : : :122<br />
4.3 Darstellung von Kontroll u konzepten :::::::::::::::126<br />
4.4 Anb<strong>in</strong>dung von Diensten an Transitionen : : : : : : : : : : : : : :127<br />
4.5 Inter- und Intravorgangsnebenlau gkeit : : : : : : : : : : : : : :128<br />
4.6 Wechselseitiger Ausschlu im kritischen Abschnitt :::::::::129<br />
4.7 Strukturierung durch Klienten/Server{Netze : : : : : : : : : : : :130<br />
4.8 Auslosung e<strong>in</strong>er Fehlerbehandlung ::::::::::::::::::131<br />
4.9 Unidirektionale Benutzer<strong>in</strong>teraktion :::::::::::::::::132<br />
4.11 Bidirektionale Benutzer<strong>in</strong>teraktion durch Transitionsverschmelzung133<br />
4.10 Bidirektionale Benutzer<strong>in</strong>teraktion mittels zwei Transitionen :::133<br />
4.12 Commit{ und Abort{Ausgangsstellen zur Transaktionsbehandlung 135<br />
4.13 Entwicklungs{ und Ausfuhrungsumgebung <strong>in</strong> TRADE :::::::141<br />
5.1 Beispiel e<strong>in</strong>er TRADE{Diensttypbeschreibung : : : : : : : : : : :146<br />
5.2 E<strong>in</strong>fugen neuer Konformitatsbeziehungstypen auf der Granularitatsebene<br />
der Schnittstellentypen :::::::::::::::::152<br />
5.3 Graphische Visualisierung e<strong>in</strong>er Diensttyphierarchie : : : : : : : :153<br />
5.4 Komponenten des Typmanagers :::::::::::::::::::157<br />
5.5 Komponenten des TRADErs :::::::::::::::::::::161<br />
5.6 XDS/XOM{basierter Zugri auf Namensdienste im TRADEr :::163<br />
5.7 Komponenten und Informations usse des Attributmanagementsystems<br />
::::::::::::::::::::::::::::::::::165<br />
5.8 Optionen bei der domanenbegrenzten Dienstauswahl : : : : : : : :167<br />
5.9 Die Testumgebung des Projektes Interwork<strong>in</strong>g of Traders : : : : :169<br />
5.10 Der Dienstangebotsmodus des L<strong>in</strong>k{Kon gurationsmanagers :::171<br />
5.11 Angabe von Suchstrategien am Beispiel e<strong>in</strong>es Taxi{Klienten :::173<br />
5.12 Ablauf e<strong>in</strong>er Dienstanfrage im TRADEr im Rahmen e<strong>in</strong>er Trader{<br />
Kooperation ::::::::::::::::::::::::::::::174<br />
5.13 Algorithmus fur die Abwicklung e<strong>in</strong>er Trader{Kooperation im<br />
TRADEr ::::::::::::::::::::::::::::::::174<br />
5.14 Nutzung e<strong>in</strong>es DCE{Dienstes durch e<strong>in</strong>en CORBA{Dienstnehmer 185<br />
5.15 Nutzung e<strong>in</strong>es CORBA{Dienstes durch e<strong>in</strong>en DCE{Dienstnehmer 185<br />
5.16 Dynamische Proxy{Generierung bei der Nutzung e<strong>in</strong>es DCE{<br />
Dienstes durch e<strong>in</strong>en CORBA{Dienstnehmer : : : : : : : : : : : :187
290 ABBILDUNGSVERZEICHNIS<br />
5.17 Architektureller Aufbau des Interzeptors ::::::::::::::189<br />
6.1 Ausschnitt e<strong>in</strong>er PAMELA{Vorgangsbeschreibung :::::::::201<br />
6.2 Vergroberte Petri{Netz{Darstellung des Hotelbeispiels :::::::204<br />
6.3 Der Application Builder aus Benutzersicht :::::::::::::205<br />
6.4 Architektur und Beziehungen des Koord<strong>in</strong>ationsmanagers : : : : :207<br />
6.5 Graphische Adm<strong>in</strong>istrationsschnittstelle des Koord<strong>in</strong>ationsmanagers210<br />
6.6 Objektorientierte Modellierung e<strong>in</strong>es Petri{Netzes :::::::::211<br />
6.7 Algorithmus fur die Ausfuhrung e<strong>in</strong>er Transition ::::::::::214<br />
6.8 Algorithmus fur den Aufruf von Operationen <strong>in</strong>nerhalbe<strong>in</strong>er Transition<br />
::::::::::::::::::::::::::::::::::215<br />
6.9 TRADE{Gesamtarchitektur zur Unterstutzung koord<strong>in</strong>ierter<br />
<strong>Dienstnutzung</strong> <strong>in</strong> o enen heterogenen <strong>verteilten</strong> Dienstemarkten : 224<br />
A.1 PAMELA-Beispiel: Verknupfung von Prozessen ::::::::::229<br />
A.2 PAMELA{Beispiel: Nutzung und Integration von Diensttypbeschreibungen<br />
:::::::::::::::::::::::::::::230<br />
A.3 PAMELA{Beispiel: Typisierung von Marken ::::::::::::231<br />
A.4 PAMELA{Beispiel: Unterstutzung des Interaktionskonzeptes :::232<br />
A.5 PAMELA{Beispiel: Steuerung des Kontroll usses durch Kantenbed<strong>in</strong>gungen<br />
::::::::::::::::::::::::::::::233<br />
A.6 PAMELA{Beispiel: Transaktion mit unterscheidbaren Ausgangskanten<br />
:::::::::::::::::::::::::::::::::234<br />
A.7 PAMELA{Beispiel: Umsetzung des Aktionskonzepts :::::::237<br />
A.8 PAMELA{Beispiel: Dienstauswahl durch Attributquali zierung : 237<br />
A.9 PAMELA{Programmstruktur ::::::::::::::::::::238<br />
A.10 PAMELA{Programm des Hotelbeispiels (Teil 1) ::::::::::242<br />
A.11 PAMELA{Programm des Hotelbeispiels (Teil 2) ::::::::::243<br />
A.12 PAMELA{Programm des Hotelbeispiels (Teil 3) ::::::::::244<br />
A.13 Graphische Benutzerschnittstellen der Hotelanwendung ::::::245<br />
E.1 Vom PAMELA{Sprachubersetzer erzeugter De nitionskode ::::285
Tabellenverzeichnis<br />
5.1 Darstellbarkeit verschiedener Konformitatsbeziehungen mittels<br />
De nitionsregelmustern ::::::::::::::::::::::::151<br />
A.1 Konventionen der angefuhrten Grammatik : : : : : : : : : : : : :227<br />
A.2 Abgekurzte Nicht{Term<strong>in</strong>ale der CORBA{Spezi kation ::::::228<br />
A.3 Transitionsarten <strong>in</strong> PAMELA ::::::::::::::::::::232<br />
A.4 Zulassige Operatoren <strong>in</strong> Vergleichsausdrucken : : : : : : : : : : :235<br />
A.5 Zulassige Operatoren <strong>in</strong> Zuweisungsausdrucken : : : : : : : : : : :236<br />
A.6 Reservierte Schlusselworter :::::::::::::::::::::241
Literaturverzeichnis<br />
[AA91] G. Almgren und M.Anderson. Open System Trader us<strong>in</strong>g X.500.<br />
Telia Research Report Televerket/RC 02.01,Televerket, September<br />
1991. ISA Project.<br />
[AC91] R. Amadio und L. Cardelli. Subtyp<strong>in</strong>g recursive types. In Proceed<strong>in</strong>gs<br />
of the 18th ACM Symposium on Pr<strong>in</strong>ciples of Programm<strong>in</strong>g<br />
Languages, 1991.<br />
[AHU74] A.V. Aho, J.E. Hopcroft und J.D. Ullman. The Design and Analysis<br />
of Computer Algorithms. Addison{Wesley, 1974.<br />
[AL90] P. America und F.van der L<strong>in</strong>den. A parallel object{oriented<br />
language with <strong>in</strong>heritance and subtyp<strong>in</strong>g. In Proceed<strong>in</strong>gs of the<br />
ECOOP/OOPSLA Conference, Ottawa, Canada, S. 21{25, 1990.<br />
[Ame87] P. America. Inheritance and Subtyp<strong>in</strong>g <strong>in</strong> a Parallel Object{<br />
Oriented Language. In European Conference on Object{Oriented<br />
Programm<strong>in</strong>g (ECOOP '87), Paris, France, Lecture Notes <strong>in</strong> Computer<br />
Science 276, S. 234{242. Spr<strong>in</strong>ger{Verlag, 1987.<br />
[Ame91] P. America. Design<strong>in</strong>g an Object{Oriented Programm<strong>in</strong>gLanguage<br />
with Behavioural Subtyp<strong>in</strong>g. In J.W. de Baker, W.P. deRoever<br />
und G. Rozenberg, Hrsg., Foundations of Object{OrientedLanguages,<br />
REX School/Workshop, The Netherlands, 1991, Lecture Notes<br />
<strong>in</strong> Computer Science 489, S. 60{90. Spr<strong>in</strong>ger{Verlag, 1991.<br />
[ANS87] Alvey Advanced Network Systems Architecture Project, 24 Hills<br />
Road, Cambridge, UK. ANSA Reference Manual Release 0.03<br />
(Draft), 1987.<br />
[ANS95] ANSI/NISO. ANSI Z.39.50-1995, 1995.<br />
[BB87] T. Bolognesi und E. Br<strong>in</strong>ksma. Introduction to the ISO Speci cation<br />
Language LOTOS. Computer Networks and ISDN Systems,<br />
14, Heft 1, S. 25{59, 1987.<br />
[BB94] A. Beitz und M. Bearman. An ODP Trad<strong>in</strong>g Service for DCE.<br />
In Proceed<strong>in</strong>gs of the First International Workshop on Services<br />
<strong>in</strong> Distributed and Networked Environments (SDNE), S. 42{49,<br />
Prague, Czech Republic, Juni 1994. IEEE Computer Society Press.
294 LITERATURVERZEICHNIS<br />
[Bea95] M. Bearman. Trad<strong>in</strong>g <strong>in</strong> Open Distributed Environments. In Proceed<strong>in</strong>gs<br />
of the International Conference onOpen Distributed Process<strong>in</strong>g<br />
(ICODP '95), February 1995, Brisbane,Australia, 1995.<br />
[Ber93] P. A. Bernste<strong>in</strong>. Middleware { An Architecture for Distributed<br />
System Services. Technical Report CRL 93/6, Digital Equipment<br />
Corporation, Cambridge Research Lab, 1993.<br />
[Ber95] K. Berg. Software{Wiederverwendung und komponentenbasierte<br />
Software{Entwicklung: 2 Seiten e<strong>in</strong>er Medaille? In F. Huber-<br />
Waschle, H. Schauer und P. Widmayer, Hrsg., GISI 95 { Herausforderungen<br />
e<strong>in</strong>es globalen Informationsverbundes fur die Informatik,<br />
Zurich, 1995, S. 496{503. Spr<strong>in</strong>ger{Verlag, 1995.<br />
[Bet95] M. Betz. Network<strong>in</strong>g Objects with CORBA. Dr. Dobb's Journal,<br />
S. 18{26, November 1995.<br />
[BIBY95] W. Brookes, J. Indulska, A. Bond und Z.Yang. Interoperabilityof<br />
distributed platforms: a compatibility perspective. In K. Raymond<br />
und L. Armstrong, Hrsg., Open DistributedProcess<strong>in</strong>g: Experiences<br />
with distributed environments, Proceed<strong>in</strong>gs of the third IFIP TC<br />
6/WG 6.1 <strong>in</strong>ternational conferenceonopen distributed process<strong>in</strong>g,<br />
1995, S. 67{78. Chapman & Hall, 1995.<br />
[BKR93] A.D. Beitz, P.W. K<strong>in</strong>g und K.A. Raymond. Is DCE a Support<br />
Environment for ODP? In Proceed<strong>in</strong>gs of the IFIP TC6/WG6.1<br />
International Conference onOpen Distributed Process<strong>in</strong>g, S. 188{<br />
202. Elsevier Science Publishers B.V. (North{Holland), 1993.<br />
[BKS91] I. Barth, E. Kovacs und F.Sembach. Trad<strong>in</strong>g andManagement{<br />
Funktionen <strong>in</strong> MELODY. In Tagungsband zum Workshop: Entwicklungstendenzen<br />
von Rechnernetzen, S. 25{34. Gau ig, 1991.<br />
[BN84] A.D. Birrell und B.J. Nelson. Implement<strong>in</strong>g Remote Procedure<br />
Calls. ACM Transactions on Computer Systems, 2,Heft1,S.39{<br />
59, Februar 1984.<br />
[BR92a] M. Bearman und K. Raymond. Federat<strong>in</strong>g traders: An ODP adventure.<br />
In J. de Meer, V. Heymer und R. Roth, Hrsg., Open Distributed<br />
Process<strong>in</strong>g, Proceed<strong>in</strong>gs of the IFIP TC6/WG6.4 International<br />
Workshop on Open Distributed Process<strong>in</strong>g, Berl<strong>in</strong>, 1991, S.<br />
125{141. Elsevier Science Publishers B.V. (North{Holland), 1992.<br />
[BR92b] G.S. Blair und T.Rodden. The Impact of CSCW on Open Distributed<br />
Process<strong>in</strong>g. In J. de Meer, V. Heymer und R.Roth, Hrsg.,<br />
Proceed<strong>in</strong>gs of the International IFIP Workshop on Open Distributed<br />
Process<strong>in</strong>g, S. 143{154. Elsevier Science Publishers B.V.,<br />
North{Holland, Oktober 1992.
LITERATURVERZEICHNIS 295<br />
[BR93] M. Bearman und K.Raymond. Contexts, Views and Rules: An<br />
Integrated Approach toTrader Contexts. In Proceed<strong>in</strong>gs of the<br />
IFIP TC6/WG6.1 International Conference onOpen Distributed<br />
Process<strong>in</strong>g, S. 181{191. Elsevier Science Publishers B.V. (North{<br />
Holland), 1993.<br />
[Bri95] L.M. Br<strong>in</strong>ckmann. Dynamische Koord<strong>in</strong>ation komplexer verteilter<br />
Anwendungsvorgange: Entwurf und Implementation e<strong>in</strong>er petr<strong>in</strong>etzbasierten<br />
Steuerungskomponente. Diplomarbeit, Universitat<br />
Hamburg, Fachbereich Informatik, 1995.<br />
[Bur95] C. Burger. Cooperation policies for traders. In K. Raymond und<br />
L. Armstrong, Hrsg., Open Distributed Process<strong>in</strong>g: Experiences<br />
with distributed environments, Proceed<strong>in</strong>gs of the third IFIP TC<br />
6/WG 6.1 <strong>in</strong>ternational conferenceonopen distributed process<strong>in</strong>g,<br />
1995, S. 208{218. Chapman & Hall, 1995.<br />
[Cam91] APM Ltd. Cambridge. ANSAware 3.0 Implementation Manual,<br />
Februar 1991. Document RM.097.00.<br />
[Car89] L. Cardelli. Typeful Programm<strong>in</strong>g. DEC SRC Research Report,<br />
No. 45, 1989.<br />
[CC91] R.S. Ch<strong>in</strong> und S.T. Chanson. Distributed Object{Based Programm<strong>in</strong>g<br />
Systems. ACM Comput<strong>in</strong>g Surveys, 23, Heft 1, S. 91{124,<br />
1991.<br />
[CDK94] G.F. Coulouris, J. Dollimore und T. K<strong>in</strong>dberg. Distributed Systems<br />
{ Concepts and Design. Addison{Wesley, 2.Ausgabe, 1994.<br />
[CKO92] B. Curtis, M.I. Kellner und J.Over. Process Model<strong>in</strong>g. Communications<br />
of the ACM, 35, Heft 9, S. 75{90, 1992.<br />
[CM95] B. Christiansen und M.Munke. Diensttypmanagement <strong>in</strong>o enen<br />
heterogenen <strong>verteilten</strong> Systemen unter besonderer Berucksichtigung<br />
von DCE und CORBA. Studienarbeit, Universitat Hamburg,<br />
Fachbereich Informatik, 1995.<br />
[CM96] B. Christiansen und M.Munke. Typmanagementunterstutzung<br />
fur Trad<strong>in</strong>g<strong>in</strong>heterogenen <strong>verteilten</strong> Systemumgebungen: Entwurf<br />
und Implementierung e<strong>in</strong>er Typmanagementkomponente. Diplomarbeit,<br />
Universitat Hamburg, Fachbereich Informatik, 1996.<br />
[CMML96] B. Christiansen, M. Munke, K. Muller{Jones und W. Lamersdorf.<br />
Type Management: A Key to Software Reuse <strong>in</strong> Open Distributed<br />
Systems. Zur Vero entlichung e<strong>in</strong>gereicht, 1996.<br />
[Com88] D. Comer. Internetwork<strong>in</strong>g with TCP/IP: Pr<strong>in</strong>ciples, Protocols,<br />
and Architecture. Prentice Hall, Englewood Cli s, New Jersey,<br />
1988.
296 LITERATURVERZEICHNIS<br />
[Cor91] J.R. Corb<strong>in</strong>. The Art of Distributed Applications { Programm<strong>in</strong>g<br />
Techniques for Remote Procedure Call. Spr<strong>in</strong>ger{Verlag, 1991.<br />
[CR91] R.N. Chang und C.V. Ravishankar. A Service Acquisition Mechanism<br />
for the Client/Service Model <strong>in</strong> Cygnus. In Proceed<strong>in</strong>gs of the<br />
11th International Conference on Distributed Comput<strong>in</strong>g Systems,<br />
S. 90{97, Mai 1991.<br />
[CW85] L. Cardelli und P.Wegner. On Understand<strong>in</strong>g Types, Data Abstraction,<br />
and Polymorphism. ACM Comput<strong>in</strong>g Surveys, 17, Heft<br />
4, S. 471{522, Dezember 1985.<br />
[CZ96] D.B. Chapman und E.D. Zwicky. E<strong>in</strong>richten von Internet Firewalls.<br />
O'Reilly, 1996.<br />
[DGSZ94] G. D<strong>in</strong>kho , V. Gruhn, A. Saalmann und M. Zielonka. Bus<strong>in</strong>ess<br />
Process Model<strong>in</strong>g <strong>in</strong>the Work ow ManagementEnvironment Leu.<br />
In Proceed<strong>in</strong>gs of the 10th International Conference on the Entity<br />
Relationship Approach, Lecture Notes <strong>in</strong> Computer Science 881, S.<br />
46{63. Spr<strong>in</strong>ger{Verlag, 1994.<br />
[DHL90] U. Dayal, M. Hsu und R. Lad<strong>in</strong>. Organiz<strong>in</strong>g Long{Runn<strong>in</strong>g Activities<br />
with Triggers and Transactions. In Proceed<strong>in</strong>gs of the ACM<br />
SIGMOD International Conference on Management of Data, S.<br />
204{214, Atlantic City, New Jersey, Mai 1990.<br />
[Dud90] M. Dudet. X.500 Directory for those familar with Trad<strong>in</strong>g Concepts.<br />
Technical Report Number 358.90 SEPT/SCE/SPM/MD {<br />
V2, SEPT, Dezember 1990.<br />
[EF86] W. E elsberg und A. Fleischmann. Das ISO{Referenzmodell fur<br />
o ene Systeme und se<strong>in</strong>e sieben Schichten. Informatik Spektrum,<br />
9, Heft 5, S. 258{286, Oktober 1986.<br />
[Elm91] A.K. Elmagarmid, Hrsg. Database Transaction Models for Advanced<br />
Applications. Morgan Kaufmann Publishers, 1991.<br />
[EM94] B. Elbert und B. Martyna. Client/Server Comput<strong>in</strong>g: Architecture,<br />
Applications, and Distributed Systems Management. Artech<br />
House, 1994.<br />
[EN93] C.A. Ellis und G.J. Nutt. Model<strong>in</strong>g andEnactment ofWork ow<br />
Systems. In Proceed<strong>in</strong>gs of the 14th International Conference on<br />
Application and Theory of Petri Nets, Lecture Notes <strong>in</strong> Computer<br />
Science 691, S. 1{16. Spr<strong>in</strong>ger{Verlag, 1993.<br />
[Fla96] D. Flanagan. Java <strong>in</strong> a Nutshell: A Desktop Quick Reference for<br />
Java Programmers. O'Reilly & Associates, 1996.<br />
[GC92] D. Gelernter und N. Carriero. Coord<strong>in</strong>ation Languages and their<br />
signi cance. Communications of the ACM, 35, Heft 2, S. 97{107,<br />
Februar 1992.
LITERATURVERZEICHNIS 297<br />
[GGL + 95] K. Geihs, H. Grunder, W. Lamersdorf, M. Merz, K. Muller und<br />
A. Puder. Systemunterstutzungfur o ene verteilte Dienstemarkte.<br />
In K. Franke, U. Hubner und W.Kalfa,Hrsg.,Kommunikation <strong>in</strong><br />
Verteilten Systemen: Neue Lander { Neue Netze { Neue Dienste,<br />
Informatik{Aktuell, S. 445{459. Spr<strong>in</strong>ger{Verlag, Februar 1995.<br />
[GHG + 93] J.V. Guttag, J.J. Hornig, S.J. Garland, K.D. Jones,A.Modet und<br />
J.M. W<strong>in</strong>g. Larch: Languages and Tools for Formal Speci cation.<br />
Spr<strong>in</strong>ger{Verlag, 1993.<br />
[GHJV94] E. Gamma, R. Helm, R. Johnson und J. Vlissides. Design Patterns:<br />
Elements of Reusable Object{Oriented Software. Addison{Wesley,<br />
1994.<br />
[Glo89] P. Gloor.Synchronisation <strong>in</strong> <strong>verteilten</strong> Systemen. Teubner Verlag,<br />
1989.<br />
[GMGK + 91] H. Garcia-Mol<strong>in</strong>a, D. Gawlick, J. Kle<strong>in</strong>, K. Kleissner undK.Salem.<br />
Coord<strong>in</strong>at<strong>in</strong>g Activities Through Extended Sagas: A Summary. In<br />
Proceed<strong>in</strong>gs of the 36th IEEE Computer Society International Conference<br />
(Compcon), S. 568{573, 1991.<br />
[GML96] F. Gri el, K. Muller{Jones und W. Lamersdorf. Komponentenbasierte<br />
Entwicklung <strong>in</strong>teroperabler Software auf heterogenen<br />
Middleware{Plattformen. In H.C. Mayr, Hrsg., Beherrschung<br />
von Informationssystemen, Informatik '96, Klagenfurt, September,<br />
1996. R.Oldenbourg Verlag, 1996.<br />
[GR83] A. Goldberg und D. Robson. Smalltalk{80: The Language and Its<br />
Implementation. Addison{Wesley, 1983.<br />
[GR93] J. Gray und A. Reuter. Transaction Process<strong>in</strong>g: Concepts and<br />
Techniques. Morgan{Kaufmann, San Mateo, California, 1993.<br />
[Gra81] J. Gray. TheTransaction Concept: Virtues and Limitations. In<br />
Proceed<strong>in</strong>gs of the 7th International ConferenceonVery Large Data<br />
Bases, S. 144{154. IEEE Computer Society Press, 1981.<br />
[Gre95] K. Greese. Verwaltungvon Diensten mit Hilfe von Verzeichnisdiensten.<br />
Studienarbeit, Universitat Hamburg, Fachbereich Informatik,<br />
1995.<br />
[Gri95] F. Gri el. PAMELA: Entwurf und Realisierung e<strong>in</strong>er Koord<strong>in</strong>ationssprache<br />
fur komplexe verteilte Anwendungen. Studienarbeit,<br />
Universitat Hamburg, Fachbereich Informatik, 1995.<br />
[Gri96] F. Gri el. Integration heterogener verteilter Systemarchitekturen<br />
zur komponentenbasierten Softwareentwicklung. Diplomarbeit,<br />
Universitat Hamburg, Fachbereich Informatik, 1996.<br />
[Gro94] Object Management Group. Common Object Services Speci cations.<br />
John Wiley & Sons, 1994.
298 LITERATURVERZEICHNIS<br />
[Gru91] V. Gruhn. Validation and Ver cation of Software Process Models.<br />
Dissertation, Universitat Dortmund, Fachbereich Informatik, 1991.<br />
auch als Bericht Nr. 394/91 erschienen.<br />
[HA93] H.-G. Heger<strong>in</strong>g und S.Abeck. Integriertes Netz- und Systemmanagement.<br />
Addison{Wesley, 1993.<br />
[HAB + 92] Y. Halabi, M. Ansari, R. Batra, W. J<strong>in</strong>, G. Karabatis, P. Krychniak,<br />
M. Rus<strong>in</strong>kiewicz und L. Suardi. Narada: An Environment<br />
for Speci cation and Execution of Multi{System Applications. In<br />
Proceed<strong>in</strong>gs of the 2nd International Conference on Systems Integration<br />
ICSI '92, S. 680{690. IEEE, Juni 1992.<br />
[Her89] A.J. Herbert. The Computational Projection of ANSA. In S.J.<br />
Mullender, Hrsg., Distributed Systems, Frontier Series, Kapitel 19,<br />
S. 417{437. Addison{Wesley and ACM Press, 1989.<br />
[HH89] R.G. Herrtwich und G. Hommel. Kooperation und Konkurrenz.<br />
Spr<strong>in</strong>ger{Verlag, 1989.<br />
[Hof96] Y. Ho ner. Inter{operability and distributed application platform<br />
design. In A. Schill, C. Mittasch, O. Spaniol und C.Popien,<br />
Hrsg., Distributed Platforms | Proceed<strong>in</strong>gs of the IFIP/IEEE<br />
International Conference on Distributed Platforms: Client/Server<br />
and Beyond: DCE, CORBA, ODP and Advanced Distributed Applications,<br />
S. 342{356. Chapman & Hall, 1996.<br />
[Hog89] D. Hogrefe. Estelle, LOTOS und SDL | Spezi kationssprachen<br />
fur verteilte Systeme. Spr<strong>in</strong>ger{Verlag, 1989.<br />
[IBM93] IBM. Enc<strong>in</strong>a for AIX/6000 Base Reference. IBM, 1993. Order<br />
Number SC23{2464.<br />
[IBR93] J. Indulska, M. Bearman und K. Raymond. AType Management<br />
System for an ODP Trader. In Proceed<strong>in</strong>gs of the IFIP<br />
TC6/WG6.1 International Conference onOpen Distributed Process<strong>in</strong>g.<br />
Elsevier Science Publishers B.V. (North{Holland), 1993.<br />
[ION94] IONA Technologies. The Orbix Programmer's Guide, 1994. Dubl<strong>in</strong>,<br />
Ireland, 1994.<br />
[ISO] ISO 10165-7: Information Technology | Open System Interconnection<br />
| Structure of Management Information | Part 7: General<br />
Relationship Model. International Standardisation Organisation.<br />
[ISO87] Information Process<strong>in</strong>g | Open Systems Interconnection | Speci<br />
cationofAbstract Syntax Notation One (ASN.1). International<br />
Organization for Standardization and International Electrotechnical<br />
Committee, 1987. International Standard 8824.
LITERATURVERZEICHNIS 299<br />
[ISO94] ISO/IEC JTC1/SC21 N 8935rev: Proposed New Question on Type<br />
Description. International Standardisation Organisation, Oktober<br />
1994.<br />
[ISO95] ISO/IEC JTC1/SC21 WG7/Kobe-9: Open Distributed Process<strong>in</strong>g:<br />
Type Repository Function. InternationalStandardisation Organisation,<br />
November 1995. Output ofthe WG7 <strong>in</strong>terim meet<strong>in</strong>g<br />
<strong>in</strong> Kobe.<br />
[Jab93] S. Jablonski. Transaction Support for Activity Management. In<br />
Proceed<strong>in</strong>gs Workshop on High Performance Transaction Process<strong>in</strong>g<br />
Systems, Asilomar, 1993.<br />
[Jab95] S. Jablonski. Work ow{Management{Systeme: Motivation, Modellierung,<br />
Architektur. Informatik Spektrum, 18, Heft 1, S. 13{24,<br />
Februar 1995.<br />
[Jen92] K. Jensen. Coloured Petri Nets: Basic Concepts, Analysis Methods<br />
and Practical Use, Band 1. Spr<strong>in</strong>ger{Verlag, 1992.<br />
[Jen95] K. Jensen. Coloured Petri Nets. Basic Concepts, Analysis Methods<br />
and Practical Use. Volume 2. EATCS Monographs on Theoretical<br />
Computer Science. Spr<strong>in</strong>ger{Verlag, 1995.<br />
[Jon94] K. Jones. Vermittlung und Verwaltung von Diensten <strong>in</strong> o enen<br />
<strong>verteilten</strong> Systemen: E<strong>in</strong> Objekt{ und Architekturmodell. Diplomarbeit,<br />
Universitat Hamburg, Fachbereich Informatik, 1994.<br />
[JR91] K. Jensen und G.Rozenberg, Hrsg. High-Level Petri Nets. Theory<br />
and Application. Spr<strong>in</strong>ger{Verlag, 1991.<br />
[JSS95] B. Janssen, D. Severson und M. Spreitzer. ILU 1.8 Reference<br />
Manual. Xerox Corporation, 1995.<br />
[JV87] E. Jessen und R.Valk. Rechensysteme: Grundlagen der Modellbildung.<br />
Spr<strong>in</strong>ger{Verlag, 1987.<br />
[Kel93] L. Keller. Vom Name{Server zumTrader { E<strong>in</strong> Uberblick uber Trad<strong>in</strong>g<br />
<strong>in</strong><strong>verteilten</strong> Systemen. Praxis der Informationsverarbeitung<br />
und Kommunikation (PIK), 16, Heft 3, S. 122{133, 1993.<br />
[KLS90] H.F. Korth, E. Levy und A.Silberschatz. A Formal Approach to<br />
Recovery by Compensat<strong>in</strong>g Transactions. In Proceed<strong>in</strong>gs of the<br />
16th Conference onVery Large Databases, S. 95{106. Morgan-<br />
Kaufmann, 1990.<br />
[KMV + 90] S. Krakowia, M. Meysembourg, H. Nguyen Van, M. Riveill, C. Roison<br />
und X. Rousset de P<strong>in</strong>a. Design and Implementation of an<br />
Object{Oriented, Strongly Typed Language for Distributed Applications.<br />
Journal of Object{Oriented Programm<strong>in</strong>g, 1, Heft 5, S.<br />
11{21, September 1990.
300 LITERATURVERZEICHNIS<br />
[Kon93] D. Konstantas. Object Oriented Interoperability. In O.M.<br />
Nierstrasz, Hrsg., 7th European Conference on Object{Oriented<br />
Programm<strong>in</strong>g (ECOOP '93), Paris, Lecture Notes <strong>in</strong> Computer<br />
Science 707, S. 80{102. Spr<strong>in</strong>ger{Verlag, 1993.<br />
[Kov92] E. Kovacs. E zienter Zugri auf dynamische Information im<br />
MELODY{Trader. Interner Bericht, Universitat Stuttgart, IPVR,<br />
1992.<br />
[KR88] B.W. Kernighan und D.M. Ritchie. The C programm<strong>in</strong>g language:<br />
ANSI C. Prentice Hall International, 2. Ausgabe, 1988.<br />
[KW94] E. Kovacs und S. Wirag. Trad<strong>in</strong>g and Distributed Application<br />
Management: An Integrated Approach. In Proceed<strong>in</strong>gs of the 5th<br />
IFIP/IEEE International Workshop on Distributed Systems: Operation<br />
and Management, Oktober 1994.<br />
[LA94] F. Leymann und W.Altenhuber. Manag<strong>in</strong>g Bus<strong>in</strong>ess Processes As<br />
An Information Resource. IBM Systems Journal, 33, Heft 2, 1994.<br />
[Lak92] C. Lakos. The LOOPN User Manual. Technical Report TR 92{1,<br />
Department of Computer Science, University ofTasmania, 1992.<br />
[Lam94] W. Lamersdorf. Datenbanken <strong>in</strong> <strong>verteilten</strong> Sytemen: Konzepte,<br />
Losungen, Standards. Vieweg, 1994.<br />
[LC93] G.T. Leavens und Y.Cheon. Extend<strong>in</strong>g CORBA IDL to Specify<br />
Behavior with Larch. Technical Report TR 93{20, IOWA STATE<br />
UNIVERSITY of Science and Technology, Department of Computer<br />
Science, August 1993.<br />
[LHG86] B. Liskov, M. Herlihy und L. Gilbert. Limitations of Synchronous<br />
Communication with Static Process Structure <strong>in</strong> Languages<br />
for Distributed Comput<strong>in</strong>g. In 13th Symposium on Pr<strong>in</strong>ciples of<br />
Programm<strong>in</strong>g Languages, St. Petersburg Beach, Florida, 1986.<br />
[L<strong>in</strong>95] P.F. L<strong>in</strong><strong>in</strong>gton. RM{ODP: The Architecture. In K. Raymond<br />
und L. Armstrong, Hrsg., Open DistributedProcess<strong>in</strong>g: Experiences<br />
with distributed environments, Proceed<strong>in</strong>gs of the third IFIP TC<br />
6/WG 6.1 <strong>in</strong>ternational conferenceonopen distributed process<strong>in</strong>g,<br />
1995, S. 15{33. Chapman & Hall, 1995.<br />
[LMM95] W. Lamersdorf, M. Merz und K.Muller{Jones. Middleware Support<br />
for Open Distributed Applications. In Proceed<strong>in</strong>gs of the First<br />
International Workshop on High Speed Networks and Open Distributed<br />
Platforms, St. Petersburg, Russia, Juni 1995.<br />
[LR94] F. Leymann und D. Roller. Bus<strong>in</strong>ess Process Management With<br />
FlowMark. In Proceed<strong>in</strong>gs COMPCON Spr<strong>in</strong>g 94, San Francisco,<br />
CA., Februar 1994. IEEE.
LITERATURVERZEICHNIS 301<br />
[LW93] B. Liskovund J.M. W<strong>in</strong>g. A New De nition of the Subtype Relation.<br />
In O. Nierstrasz, Hrsg., Proceed<strong>in</strong>gs of the European Conference<br />
on Object Oriented Programm<strong>in</strong>g, ECOOP '93, Berl<strong>in</strong>, Germany,<br />
Lecture Notes <strong>in</strong> Computer Science 707, S. 118{141. Spr<strong>in</strong>ger{<br />
Verlag, 1993.<br />
[Mah95] B. Mahr. Pr<strong>in</strong>ciples of Open Distributed Process<strong>in</strong>g <strong>in</strong>Medic<strong>in</strong>e<br />
|The Berl<strong>in</strong> Approach. In E. Fleck, Hrsg., Open Systems <strong>in</strong><br />
Medic<strong>in</strong>e, S. 6{23. IOS Press, 1995.<br />
[Mar89] M.A. Marsan. Stochastic Petri Nets: an Elementary Introduction.<br />
In Advances <strong>in</strong> Petri Nets, Lecture Notes <strong>in</strong> Computer Science 424,<br />
S. 1{29. Spr<strong>in</strong>ger{Verlag, 1989.<br />
[Mar91] D.S. Marshak. ANSA: A Model for Distributed Comput<strong>in</strong>g. Network<br />
Monitor, 6, Heft 11, November 1991.<br />
[MB92] A. Macartney und G. Blair. Flexible trad<strong>in</strong>g <strong>in</strong> distributed multimedia<br />
systems. Computer Networks and ISDN Systems, 25, Heft<br />
2, S. 145{157, August 1992.<br />
[MC94] T. Malone und K. Crowston. The <strong>in</strong>terdiscipl<strong>in</strong>ary Study of Coord<strong>in</strong>ation.<br />
Comput<strong>in</strong>g Surveys, 26, Heft 1, S. 87{120, 1994.<br />
[Mer96] M. Merz. Elektronische Markte im Internet. TAT {Thompson's<br />
aktuelle Tutorien. Thompson International Publish<strong>in</strong>g, 1996.<br />
[Met93] Meta Software Corporation. Design/CPN Tutorial for UNIX/X-<br />
W<strong>in</strong>dow System Version 2.0, 1993.<br />
[Mil84] R. Milner. A proposal for Standard ML. In Proceed<strong>in</strong>gs of the<br />
Symposium on LISP and Functional Programm<strong>in</strong>g, Aust<strong>in</strong>, Texas,<br />
August 1984, S. 184{197, 1984.<br />
[Mil89] R. Milner. Communications and Concurrency. Prentice{Hall,<br />
1989.<br />
[MJM94] K. Muller, K. Jones und M.Merz. VermittlungundVerwaltungvon<br />
Diensten <strong>in</strong> o enen <strong>verteilten</strong> Systemen. In B. Wol nger, Hrsg.,<br />
Innovationen bei Rechen{ und Kommunikationssystemen | E<strong>in</strong>e<br />
Herausforderung fur die Informatik, Informatik Aktuell, S. 219{<br />
226. Spr<strong>in</strong>ger{Verlag, August 1994.<br />
[MK95] B. Meyer und A.Koch. Ausfuhrbare Policies fur das Management<br />
verteilter Anwendungen | E<strong>in</strong> regelbasierter Ansatz mit MAR-<br />
VEL. In H. Krumm, Hrsg., Entwicklung und Management verteilter<br />
Anwendungssysteme: Tagungsband� 2. Arbeitstre ens der<br />
GI/ITG Fachgruppe Kommunikation und Verteilte Systeme und<br />
der GI Fachgruppe Betriebssysteme� Universitat Dortmund� 9./10.<br />
Oktober 1995, S. 121{129, Munster, 1995. Krehl Verlag.
302 LITERATURVERZEICHNIS<br />
[ML93a] M. Merz und W. Lamersdorf. Cooperation Support for an Open<br />
Service Market. In Proceed<strong>in</strong>gs of the IFIP TC6/WG6.1 International<br />
Conference onOpen Distributed Process<strong>in</strong>g, S.329{340.<br />
Elsevier Science Publishers B.V. (North{Holland), 1993.<br />
[ML93b] M. Merz und W.Lamersdorf. Generic Interfaces to RemoteApplications<br />
<strong>in</strong> Open Systems. In Proceed<strong>in</strong>gs of the International<br />
IFIP Workshop on Interfaces <strong>in</strong> Industrial Production and Eng<strong>in</strong>eer<strong>in</strong>g<br />
Systems, S. 267{281. Elsevier Science Publishers B.V.<br />
(North{Holland), 1993.<br />
[MLM94] M. Merz, W. Lamersdorf und K.Muller. Trusted Third{party<br />
Services <strong>in</strong> COSM. EM { Electronic Markets, 4, Heft 12, S. 7{8,<br />
September 1994.<br />
[MLML96] M. Merz, B. Libermann, K. Muller{Jones und W.Lamersdorf. Interorganizational<br />
Work ow Management with Mobile Agents <strong>in</strong><br />
COSM. In Proceed<strong>in</strong>gs of the First International Conference on<br />
The Practical Application of Intelligent Agents and Multi{Agent<br />
Technology (PAAM '96), London, 1996, S. 405{420, 1996.<br />
[MMaTT96] S. Muller, K. Muller{Jones und W. Lamersdorf an T. Tu. Global<br />
Trader Cooperation <strong>in</strong> Open Service Markets. In Aachen Workshop,<br />
Trends <strong>in</strong> Distributed Systems, October, 1996, 1996.<br />
[MML94a] M. Merz, K. Muller und W. Lamersdorf. Service Trad<strong>in</strong>g andMediation<br />
<strong>in</strong> Distributed Comput<strong>in</strong>gEnvironments. In Proceed<strong>in</strong>gs of<br />
the 14th International Conference on Distributed Comput<strong>in</strong>g Systems<br />
(ICDCS '94), S. 450{457. IEEE Computer Society Press,<br />
1994.<br />
[MML94b] K. Muller, M. Merz und W. Lamersdorf. Der TRADE{Trader: E<strong>in</strong><br />
Basisdienst o ener verteilter Systeme. In C. Popien und B.Meyer,<br />
Hrsg., Neue Konzepte fur die O ene Verteilte Verarbeitung, S. 35{<br />
44. Verlag der August<strong>in</strong>us Buchhandlung, Aachen, September 1994.<br />
[MML95a] M. Merz, K. Muller{Jones und W.Lamersdorf. Mobile Klienten:<br />
Ortsubergreifender Zugang zu Diensten <strong>in</strong> o enen <strong>verteilten</strong> Informationssystemen.<br />
In F. Huber-Waschle, H. Schauer und P. Widmayer,<br />
Hrsg., GISI 95 { Herausforderungen e<strong>in</strong>es globalen Informationsverbundes<br />
fur die Informatik, Zurich, 1995, S.423{430.<br />
Spr<strong>in</strong>ger{Verlag, 1995.<br />
[MML95b] M. Merz, K. Muller{Jones und W. Lamersdorf. Petr<strong>in</strong>etz{<br />
basierte Modellierung und Steuerung unternehmensubergreifender<br />
Geschaftsprozesse. In F. Huber-Waschle, H. Schauer und P. Widmayer,<br />
Hrsg., GISI 95 { Herausforderungen e<strong>in</strong>es globalen Informationsverbundes<br />
fur die Informatik, Zurich, 1995, S.215{222.<br />
Spr<strong>in</strong>ger{Verlag, 1995.
LITERATURVERZEICHNIS 303<br />
[MML95c] M. Merz, K. Muller und W.Lamersdorf. End{user support <strong>in</strong> the<br />
tourist <strong>in</strong>dustry: requirementsand architectures. In Proceed<strong>in</strong>gs of<br />
the International Conference on Information and Communication<br />
Technologies <strong>in</strong> Tourism (ENTER '95), Innsbruck, Osterreich,<br />
Februar 1995. Spr<strong>in</strong>ger{Verlag.<br />
[MML95d] K. Muller{Jones,M.Merz und W. Lamersdorf. Kooperationsanwendungen:<br />
Integrierte Vorgangskontrolle und Dienstvermittlung<br />
<strong>in</strong> o enen <strong>verteilten</strong> Systemen. In F. Huber-Waschle, H. Schauer<br />
und P. Widmayer, Hrsg., GISI 95 { Herausforderungen e<strong>in</strong>es globalen<br />
Informationsverbundes fur die Informatik, Zurich, 1995, S.<br />
518{525. Spr<strong>in</strong>ger{Verlag, 1995.<br />
[MML95e] K. Muller{Jones, M. Merz und W. Lamersdorf. Realisierung von<br />
Kooperationsanwendungen auf der Basis erweiterter Diensttypbeschreibungen.<br />
In H. Krumm, Hrsg., Entwicklung und Management<br />
verteilter Anwendungssysteme: Tagungsband� 2. Arbeitstre ens der<br />
GI/ITG Fachgruppe Kommunikation und Verteilte Systeme und<br />
der GI Fachgruppe Betriebssysteme� Universitat Dortmund� 9./10.<br />
Oktober 1995, S. 21{30, Munster, 1995. Krehl Verlag.<br />
[MML95f] K. Muller{Jones,M.Merz und W. Lamersdorf. The TRADEr: Integrat<strong>in</strong>g<br />
Trad<strong>in</strong>g Into DCE. In K. Raymond und L. Armstrong,<br />
Hrsg., Open Distributed Process<strong>in</strong>g: Experiences with distributed<br />
environments, Proceed<strong>in</strong>gs of the third IFIP TC 6/WG 6.1 <strong>in</strong>ternational<br />
conference onopen distributed process<strong>in</strong>g, 1995, S. 476{<br />
487. Chapman & Hall, 1995.<br />
[MML96] M. Merz, K. Muller{Jones und W. Lamersdorf. Services, Agents,<br />
and Electronic Markets: How dothey Integrate ? In A. Schill,<br />
C. Mittasch, O. Spaniol und C.Popien, Hrsg., Distributed Platforms<br />
| Proceed<strong>in</strong>gs of the IFIP/IEEE International Conference<br />
on Distributed Platforms: Client/Server and Beyond: DCE, COR-<br />
BA, ODP and Advanced Distributed Applications, S. 287{300.<br />
Chapman & Hall, 1996.<br />
[MMML95] M. Merz, D. Moldt, K. Muller und W.Lamersdorf. Work ow Modell<strong>in</strong>g<br />
and Execution with Coloured Petri Nets <strong>in</strong>COSM. In<br />
Workshop on Applications of Petri Nets to Protocols, Proceed<strong>in</strong>gs<br />
16th International Conference on Application and Theory of Petri<br />
Nets, 1995.<br />
[Mof94] J.D. Mo et. Speci cations of Management Policies and Discretionary<br />
Access Control. In M. Sloman, Hrsg., Network and Distributed<br />
Systems Management, Kapitel 17, S. 455{480. Addison{Wesley,<br />
1994.<br />
[Mul95] S. Muller. Abbildung e<strong>in</strong>es Trader{Entwurfs auf e<strong>in</strong>e vorhandene<br />
System{Architektur. Studienarbeit, Fachbereich Informatik, Universitat<br />
Hamburg, Februar 1995.
304 LITERATURVERZEICHNIS<br />
[Mul96] S. Muller. Entwurf e<strong>in</strong>es Kooperationskonzeptes fur Dienstvermittlungskomponenten<br />
<strong>in</strong> o enen <strong>verteilten</strong> Systemen. Diplomarbeit,<br />
Universitat Hamburg, Fachbereich Informatik, 1996.<br />
[Mur89] T. Murata. Petri Nets: Properties, Analysis and Applications. In<br />
Proceed<strong>in</strong>gs of the IEEE, Band 77, S. 541{580, 1989.<br />
[MZP96] B. Meyer, S. Zlat<strong>in</strong>tsis und C.Popien. Enabl<strong>in</strong>g Interwork<strong>in</strong>g between<br />
Heterogeneous Distributed Platforms. In A. Schill, C. Mittasch,<br />
O. Spaniol und C.Popien, Hrsg., Distributed Platforms |<br />
Proceed<strong>in</strong>gs of the IFIP/IEEE International Conference on Distributed<br />
Platforms: Client/Server and Beyond: DCE, CORBA, ODP<br />
and Advanced Distributed Applications, S. 329{341. Chapman &<br />
Hall, 1996.<br />
[ND95] O. Nierstrasz und L. Dami. Component{Oriented Software Technology.<br />
In O. Nierstrasz und D.Tsichritzis, Hrsg., Component{<br />
Oriented Software Composition, Kapitel 1, S. 160{165. Prentice<br />
Hall, 1995.<br />
[NDC95] G. Nilsson, F. Dupuy und M.Chapman. An Overview of the Telecommunications<br />
Information Network<strong>in</strong>g Architecture. In Proceed<strong>in</strong>gs<br />
of the TINA '95 Conference, Melbourne, Australia, 1995.<br />
[Nel81] B.J. Nelson. Remote Procedure Call. Technical Report CSL{81{9,<br />
Xerox PARC, Mai 1981.<br />
[Neu89] G. Neufeld. Descriptive Names <strong>in</strong> X.500. ACM SIGCOM Computer<br />
Communication Review, 19, Heft 4, S. 64{71, 1989.<br />
[Nie93] O. Nierstrasz. Regular Types for Active Objects. In Proceed<strong>in</strong>gs<br />
of the 8th Annual Conference on Object{Oriented Programm<strong>in</strong>g<br />
Systems, Languages, and Applications (OOPSLA '93).ACM press,<br />
1993.<br />
[NM90] J. Nehmer und F.Mattern. Service Model<strong>in</strong>g <strong>in</strong> Distributed Operat<strong>in</strong>g<br />
Systems. In Proceed<strong>in</strong>gs of the 2nd Workshop on Future<br />
Trends on Distributed Comput<strong>in</strong>g <strong>in</strong> the 1990's, S. 70{96, Cairo,<br />
Egypt, September 1990. IEEE.<br />
[NP91] O. Nierstrasz und M.Papathomas. Towards a Type Theory for<br />
Active Objects. In ACM OOPS Messenger, Proceed<strong>in</strong>gs OOPS-<br />
LA/ECOOP '90 Workshop on Object{Based Concurrent Systems,<br />
Band 2, S. 89{93. ACM press, April 1991.<br />
[NS95] E. Najm und J.-B. Stefani. A formal semantics for the ODP computational<br />
model. Computer Networks and ISDN Systems, 27, S.<br />
1305{1329, 1995.<br />
[ODP93] ISO/IEC JTC1/SC21: Work<strong>in</strong>g Document onTopic 9.1 { ODP<br />
Trader. International Standardisation Organisation, November<br />
1993.
LITERATURVERZEICHNIS 305<br />
[ODP94a] ISO/IEC JTC1/SC21 N8409: Work<strong>in</strong>g Document { ODP Trad<strong>in</strong>g<br />
Function. International Standardisation Organisation, Januar<br />
1994.<br />
[ODP94b] ISO/IEC JTC1/SC21 N9122: ISO/IEC 13235: 1994/Draft ODP<br />
Trad<strong>in</strong>gFunction. International Standardisation Organisation, Juli<br />
1994.<br />
[ODP95a] ISO/IEC 13235 { ODP Trad<strong>in</strong>gFunction. International Organisation<br />
for Standardization, International Electrotechnical Commission,<br />
Juni 1995. Draft International Standard.<br />
[ODP95b] Basic Reference Model of Open Distributed Process<strong>in</strong>g |Part<br />
1: Overview. Draft International Standard 10746{1 . International<br />
Organisation for Standardization, International Electrotechnical<br />
Commission, 1995.<br />
[ODP95c] Basic Reference Model of Open Distributed Process<strong>in</strong>g |Part 3:<br />
Architecture. International Standard 10746{3 . International Organisation<br />
for Standardization, International Electrotechnical Commission,<br />
1995.<br />
[Oh96] S.-H. Oh. Entwurf und Entwicklung e<strong>in</strong>er Systemkomponente zur<br />
Ablage von Dienstbeschreibungen <strong>in</strong> heterogenen <strong>verteilten</strong> Systemen.<br />
Diplomarbeit, Universitat Hamburg, Fachbereich Informatik,<br />
1996.<br />
[OMG91] The Common Object Request Broker: Architecture and Speci cation.<br />
Digital Equipment Corporation, Hewlett{Packard Company,<br />
HyperDesk Corporation, NCR Corporation, Object Design Incorporated,<br />
SunSoft Incorporated, 1991.<br />
[OMG92] Object Management Architecture Guide. Object Management<br />
Group, September 1992.<br />
[OMG95] CORBA 2.0/Interoperability { Universal Networked Objects. BNR<br />
Europe Ltd., Digital Equipment Corporation, Expersoft Corporation,<br />
Hewlett{Packard Company, IBM Corporation, ICL, plc., IONA<br />
Technologies, SunSoft Incorporated, 1995.<br />
[OPR96] R. Otte, P. Patrick und M.Roy. Understand<strong>in</strong>g CORBA: The<br />
Common Object Request Broker Architecture. Prentice Hall, 1996.<br />
[OSF92] OSF. Introduction to OSF DCE. Prentice{Hall, Englewood Cli s,<br />
New Jersey, 1992.<br />
[OSF93a] OSF. OSF DCE Application Development Guide. Prentice{Hall,<br />
Inc., Englewood Cli s, New Jersey, 1993.<br />
[OSF93b] OSF. OSF DCE Application Development Reference. Prentice{<br />
Hall, Englewood Cli s, New Jersey, 1993.
306 LITERATURVERZEICHNIS<br />
[Pag91] B. Page. Diskrete Simulation. Spr<strong>in</strong>ger{Verlag, 1991.<br />
[Par72] D.L. Parnas. On the criteria to beused<strong>in</strong>decompos<strong>in</strong>g systems<br />
<strong>in</strong>to modules. Communications of the ACM, 15, S. 1053{1058,<br />
1972.<br />
[Paw91] P. Pawlita. DCE | Verteilte Verarbeitung <strong>in</strong> Multi{Vendor{<br />
Netzen wird Realitat. Praxis der Informationsverarbeitung und<br />
Kommunikation (PIK), 14, Heft 4, S. 249{251, Oktober 1991.<br />
[PB96] A. Puder und C. Burger. New Concepts for Qualitative Trader<br />
Cooperation. In A. Schill, C. Mittasch, O. Spaniol und C.Popien,<br />
Hrsg., Distributed Platforms | Proceed<strong>in</strong>gs of the IFIP/IEEE<br />
International Conference on Distributed Platforms: Client/Server<br />
and Beyond: DCE, CORBA, ODP and Advanced Distributed Applications,<br />
S. 301{313. Chapman & Hall, 1996.<br />
[Pet62] C.A. Petri. Kommunikation mit Automaten. Dissertation, Institut<br />
fur Instrumentelle Mathematik, Universitat Bonn, 1962.<br />
[Pet81] J.L. Peterson. Petri Net Theory and the Model<strong>in</strong>g of Systems.<br />
Prentice{Hall, 1981.<br />
[PGM95] A. Puder, F. Gudermann und S. Markwitz. E<strong>in</strong> Mehrphasen{<br />
Protokoll fur wissensbasierte Dienstvermittlung. In H. Krumm,<br />
Hrsg., Entwicklung und Management verteilter Anwendungssysteme:<br />
Tagungsband� 2. Arbeitstre ens der GI/ITG Fachgruppe<br />
Kommunikation und Verteilte Systeme und der GI Fachgruppe<br />
Betriebssysteme� Universitat Dortmund� 9./10. Oktober 1995,<br />
Munster, 1995. Krehl Verlag.<br />
[PM93] C. Popien und B.Meyer. Federat<strong>in</strong>g ODP Traders: An X.500 Approach.<br />
In Proceed<strong>in</strong>gs of the International Conference on Communications<br />
1993 (ICC'93), Geneva, Switzerland, S. 33{317, 1993.<br />
[Pop95] C. Popien. Dienstvermittlung <strong>in</strong> Verteilten Systemen. Teubner,<br />
1995.<br />
[PS85] J.L. Peterson und A. Silberschatz. Operat<strong>in</strong>g System Concepts.<br />
Addison{Wesley, 1985.<br />
[PSW96] C. Popien, G. Schurmann und K.-H. Wei . Verteilte Verarbeitung<br />
<strong>in</strong> O enen Systemen. Teubner, 1996.<br />
[PZTT91] R. Popescu-Zelet<strong>in</strong>, V. Tschammer und M.Tschichholz. Y distributed<br />
application platform. Computer Communication, 14, Heft 6,<br />
S. 366{374, 1991.<br />
[Rad94] S. Radicati. X.500 Directory Services: Technology and Deployment.<br />
Van Nostrand Re<strong>in</strong>hold, 1994.
LITERATURVERZEICHNIS 307<br />
[RBP + 91] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy und W. Lorenzen.<br />
Object{oriented Modell<strong>in</strong>g and Design. Prentice{Hall, 1991.<br />
[Rei86] W. Reisig. Petr<strong>in</strong>etze: E<strong>in</strong>e E<strong>in</strong>fuhrung. Spr<strong>in</strong>ger{Verlag, 1986.<br />
[Rei93] B. Re<strong>in</strong>wald. Work ow{Management <strong>in</strong> <strong>verteilten</strong> Systemen. B.G.<br />
Teubner Verlagsgesellschaft, 1993.<br />
[RH95] A. Richman und D. Hoang. Accomplish<strong>in</strong>g Distributed Traders<br />
Utiliz<strong>in</strong>g the X.500 Directory. InProceed<strong>in</strong>gs of the 2nd IEEE Malaysia<br />
International Conference on Communications (MICC'95),<br />
November 1995, Malaysia, 1995.<br />
[Ric83] G. Richter. Netzmodelle fur die Burokommunikation. Informatik<br />
Spektrum, 6, Heft 4, S. 28{40, 1983. Teil 1.<br />
[RKF93] W. Rosenberry, D.Kenny und G.Fisher. Understand<strong>in</strong>g DCE.<br />
O'Reilly & Associates, Inc., 1993.<br />
[Ros92] M.T. Rose. The Little Black Book: Mail Bond<strong>in</strong>g with OSI Directory<br />
Services. Prentice{Hall, 1992.<br />
[RTL + 91] R. Ray, E.Tempero, H. Levy, A. Black, N. Hutch<strong>in</strong>son und E. Jul.<br />
Emerald: A General Purpose Programm<strong>in</strong>g Language. Software{<br />
Practice and Experience, 21, Heft 1, S. 91{118, Januar 1991.<br />
[SB93] C. Sibert<strong>in</strong>-Blanc. A Client-Server Protocol for the Composition of<br />
Petri Nets. In Proceed<strong>in</strong>gs of the 14th International Conference on<br />
Application and Theory of Petri Nets, Lecture Notes <strong>in</strong> Computer<br />
Science 691, S. 377{396. Spr<strong>in</strong>ger{Verlag, 1993.<br />
[SB94] C. Sibert<strong>in</strong>-Blanc. Cooperative Nets. In Proceed<strong>in</strong>gs of the 15th International<br />
Conference on Application and Theory or Petri Nets,<br />
Lecture Notes <strong>in</strong> Computer Science 815, S. 471{490. Spr<strong>in</strong>ger{<br />
Verlag, 1994.<br />
[Sch92a] A. Schill. Namensverwaltung <strong>in</strong><strong>verteilten</strong> Systemen { E<strong>in</strong> Uberblick.<br />
Praxis der Informationsverarbeitung und Kommunikation,<br />
15, Heft 1, S. 11{21, 1992.<br />
[Sch92b] A. Schill. Remote Procedure Call: Fortgeschrittene Konzepte und<br />
Systeme {e<strong>in</strong>Uberblick. Informatik{Spektrum, 15, Heft 2, S. 79{<br />
87, April 1992.<br />
[Sch92c] J.M. Schneider. Protocol Eng<strong>in</strong>eer<strong>in</strong>g: A Rule{Based Approach.<br />
Vieweg, 1992.<br />
[Sch93a] A. Scheller. Informationsmodellierung fur verteilte Anwendungen<br />
auf Basis standardisierter Datenmodelle. GMD{Bericht Nr. 214,<br />
Gesellschaft fur Mathematik und Datenverarbeitung, Bonn, 1993.
308 LITERATURVERZEICHNIS<br />
[Sch93b] A. Schill. DCE: Das OSF Distributed Comput<strong>in</strong>g Environment.<br />
Spr<strong>in</strong>ger{Verlag, 1993.<br />
[Sch93c] F. Schwenkreis. APRICOTS { A Prototype Implementation of<br />
a ConTract System { Management ofthe Control Flow andthe<br />
Communication System. In Proceed<strong>in</strong>gs of the 12th Symposium on<br />
Reliable Distributed Systems. IEEE Computer Society Press, 1993.<br />
[SM83] G. Salton und M.J. McGill. Introduction to Modern Information<br />
Retrieval. McGraw{Hill, 1983.<br />
[Sou94] J. Soukup. Tam<strong>in</strong>g C++: pattern classes and persistence for large<br />
projects. Addison{Wesley, 1994.<br />
[Sow84] J.F. Sowa. Conceptual Structures, <strong>in</strong>formation process<strong>in</strong>g m<strong>in</strong>d<br />
and mach<strong>in</strong>e. Addison{Wesley, 1984.<br />
[Spi89] J.M. Spivey. The Z Notation. Prentice Hall, 1989.<br />
[SPM94] O. Spaniol, C. Popien und B.Meyer. Dienste und Dienstvermittlung<br />
<strong>in</strong> Client/Server{Systemen, Band1ofThomson's aktuelle Tutorien.<br />
International Thomson Publish<strong>in</strong>g, Bonn, 1994.<br />
[Spr96] A. Sprenger. Entwicklung e<strong>in</strong>er Trader{Komponente zur Verwaltung<br />
statischer und dynamischer Diensteigenschaften. Diplomarbeit,<br />
Universitat Hamburg, Fachbereich Informatik, 1996.<br />
[Str93] B. Stroustrup. The C++ Programm<strong>in</strong>g Language. Addison{<br />
Wesley, 1993.<br />
[Sun90] Sun Microsystems Incorporated. Network Programm<strong>in</strong>g Guide,<br />
1990.<br />
[SV89] M. Silva undR.Valette. Petri Netsand Flexible Manufactur<strong>in</strong>g. In<br />
Advances <strong>in</strong> Petri Nets, Lecture Notes <strong>in</strong> Computer Science 424,<br />
S. 374{417. Spr<strong>in</strong>ger{Verlag, 1989.<br />
[Svo85] L. Svobodava. Client/Server Model of Distributed Process<strong>in</strong>g.<br />
Technical Report RZ 1350, IBM, Zurich, 1985.<br />
[Tol94] R. Tolksdorf. Coord<strong>in</strong>ation <strong>in</strong> Open Distributed Systems. Dissertation,<br />
Technische Universitat Berl<strong>in</strong>, 1994.<br />
[Tsc94] V. Tschammer. Integration kooperierender Systeme: Architektur<br />
und Dienstplattform fur o ene verteilte Anwendungen. Number<br />
220 <strong>in</strong> Berichte der Gesellschaft fur Mathematik und Datenverarbeitung.<br />
R. Oldenbourg Verlag, 1994.<br />
[TWH90] V. Tschammer,A.Wolisz und J. Hall. Support for Cooperation and<br />
Coherence <strong>in</strong> an Open Service Environment. In Proceed<strong>in</strong>gs of the<br />
2nd IEEE Workshop on Future Trends on Distributed Comput<strong>in</strong>g<br />
<strong>in</strong> the 1990's, S. 222{228, Cairo, Egypt, September 1990. IEEE.
LITERATURVERZEICHNIS 309<br />
[TWW92] V. Tschammer,A.Wolisz und M.Walch. The performance of multiple<br />
traders operat<strong>in</strong>g <strong>in</strong>the same doma<strong>in</strong>. In Proceed<strong>in</strong>gs of the<br />
3rd IEEE Workshop on Future Trends on Distributed Comput<strong>in</strong>g<br />
<strong>in</strong> the 1990's. IEEE, 1992.<br />
[Val87] R. Valk. Modell<strong>in</strong>g ofTask Flow <strong>in</strong> Systems of Functional Units.<br />
Bericht FBI-HH-B-124/87, Universitat Hamburg, 1987.<br />
[VBB95] A. Vogel, M. Bearman und A. Beitz. Enabl<strong>in</strong>gInterwork<strong>in</strong>gofTraders.<br />
In K. Raymond und L. Armstrong, Hrsg., Open Distributed<br />
Process<strong>in</strong>g: Experiences with distributed environments, Proceed<strong>in</strong>gs<br />
of the third IFIP TC 6/WG 6.1 <strong>in</strong>ternational conference onopen<br />
distributed process<strong>in</strong>g, 1995, S. 185{196. Chapman & Hall, 1995.<br />
[Vog94] A. Vogel. Towards the Implementation of Interwork<strong>in</strong>g ofTraders.<br />
http://www.dstc.edu.au/AU/projects/iwt, 1994.<br />
[Vol95] B. Volker. Verwaltung von Schnittstellenbeschreibungen zur Unterstutzung<br />
o ener Client/Server{Kooperationen. Diplomarbeit,<br />
Universitat Hamburg, Fachbereich Informatik, Januar 1995.<br />
[VS87] G. Vissers und G. Scollo. Formal Speci cation <strong>in</strong> OSI. In Proceed<strong>in</strong>gs<br />
of the International Sem<strong>in</strong>ar on Network<strong>in</strong>g <strong>in</strong> Open Systems,<br />
Oberlech, Austria, 1986, Lecture Notes <strong>in</strong> Computer Science<br />
248, S. 338{359. Spr<strong>in</strong>ger{Verlag, 1987.<br />
[Way94] P. Wayner. Agents Away. BYTE, S. 133{138, Mai 1994.<br />
[WB95] A. Waugh und M. Bearman. Design<strong>in</strong>g an ODP Trader Implementation<br />
us<strong>in</strong>g X.500. In K. Raymondund L. Armstrong, Hrsg., Open<br />
Distributed Process<strong>in</strong>g: Experiences with distributed environments,<br />
Proceed<strong>in</strong>gs of the third IFIP TC 6/WG 6.1 <strong>in</strong>ternational conference<br />
onopen distributed process<strong>in</strong>g, 1995, S. 133{144. Chapman<br />
& Hall, 1995.<br />
[Weg87] P. Wegener. Dimensions of object{based language design. ACM<br />
SIGPLAN Notices, 22, Heft 12, S. 168{182, Dezember 1987.<br />
[Whi94] J.E. White. Telescript Technology: The Foundation for the Electronic<br />
Marketplace. White Paper, General Magic Incorporated,<br />
1994.<br />
[W<strong>in</strong>93] A. W<strong>in</strong>ckler. Dezentrale Ablaufsteuerung <strong>in</strong>Verteilten Systemen.<br />
In N. Gerner, H.-G. Heger<strong>in</strong>g und J.Swoboda, Hrsg., Kommunikation<strong>in</strong>Verteilten<br />
Systemen, S. 302{316, Munchen, Mai 1993.<br />
Spr<strong>in</strong>ger{Verlag. ITG/GI{Fachtagung.<br />
[Wir82] N. Wirth. Programmierung <strong>in</strong> Modula{2. Spr<strong>in</strong>ger{Verlag, 1982.<br />
[WR90] H. Wachter und A. Reuter. Grundkonzepteund Realisierungsstrategien<br />
des ConTract{Modells. Informatik Forschung und Entwicklung,<br />
5, S. 202{212, 1990.
310 LITERATURVERZEICHNIS<br />
[WR91] H. Wachter und A.Reuter. The ConTract Model. In A.K. Elmagarmid,<br />
Hrsg., Database Transaction Models for Advanced Applications,<br />
S. 219{263. Morgan Kaufmann Publishers, 1991.<br />
[WT90] A. Wolisz und V. Tschammer. Service Provider Selection <strong>in</strong><br />
an Open Services Environment. In Proceed<strong>in</strong>gs of the 2nd IE-<br />
EE Workshop on Future Trends on Distributed Comput<strong>in</strong>g <strong>in</strong> the<br />
1990's, S. 229{235. IEEE, September 1990.<br />
[WT93] A. Wolisz und V. Tschammer. Performance aspects of trad<strong>in</strong>g <strong>in</strong><br />
open distributed systems. computer communications, 16, Heft 5,<br />
S. 277{287, Mai 1993.<br />
[YV96] Z. Yang und A.Vogel. Achiev<strong>in</strong>g <strong>in</strong>teroperability between COR-<br />
BA and DCE applications us<strong>in</strong>g bridges. In A. Schill, C. Mittasch,<br />
O. Spaniol und C.Popien, Hrsg., Distributed Platforms | Proceed<strong>in</strong>gs<br />
of the IFIP/IEEE International Conference on Distributed<br />
Platforms: Client/Server and Beyond: DCE, CORBA, ODP and<br />
Advanced Distributed Applications, S. 144{155. Chapman & Hall,<br />
1996.<br />
[Zbo96] S. Zbornik. Elektronische Markte, elektronische Hierarchien und<br />
elektronische Netzwerke: Koord<strong>in</strong>ation des wirtschaftlichen Leistungsaustausches<br />
durch Mehrwertdienste auf der Basis von EDI<br />
und o enen Kommunikationssystemen, diskutiert am Beispiel der<br />
Elektronik<strong>in</strong>dustrie. VVK, Universitatsverlag Konstanz, 1996.<br />
[Zit95] M. Zitterbart. Hochleistungskommunikation. R. Oldenbourg Verlag,<br />
Band 1:Technologie und Netze. Ausgabe, 1995.<br />
[ZW95] A.M. Zaremski und J.M. W<strong>in</strong>g. Signature Match<strong>in</strong>g: A tool for<br />
us<strong>in</strong>g software libraries. ACM TOSEM, April 1995.