Grid Component Model: Vorstellung und Vergleich

Die Seite wird erstellt Aaron Maier

Wissenschaft

Deutsch

Like
Teilen
Einbetten
Vollbild
Folien
HTML Herunterladen
PDF Herunterladen
Missbrauch

←

WEITER LESEN

→

Transkription von Seiteninhalten

Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten

Grid Component Model: Vorstellung und
                   Vergleich

                                  Stefan Kaiser

                                   TU Berlin
                           Fachgebiet Softwaretechnik
                                Berlin, Germany
                         skaiser@mailbox.tu-berlin.de

      Abstract. Es gibt mehrere Komponentenmodelle die Bezug auf Grid-
      Architekturen nehmen. Allerdings gibt es bisher kein Standardmodell,
      das die Besonderheiten des Grid berücksichtigt, um die Entwicklung
      effizienter und performanter Systeme zu ermöglichen. In dieser Arbeit
      wird das Grid Component Model vorgestellt. Es werden die wichtigsten
      Eigenschaften erläutert und das Thema der Formalisierung aufgegriffen.
      Darüber hinaus wird ein Vergleich mit einem anderen Komponenten-
      modell beschrieben.

      Key words: Component Model, GCM, Fractal, CCA, Grid Computing,
      Formalization, Interoperability

1   Einführung
Der Begriff Grid Computing existiert schon seit einigen Jahren und steht für die
Berechnung rechenintensiver Aufgaben in einem verteilten System. Diese Art
des Rechnens bekommt immer mehr Bedeutung in der heutigen Zeit, denn es
werden für die verschiedensten Anwendungen immer mehr Ressourcen benötigt,
die ein Einzelner nicht mehr alleine anbieten kann. Dafür bietet Grid Computing
die Nutzung von Ressourcen verschiedener Parteien und somit eine erfolgreiche
Durchführung der angedachten Aufgaben.
    Um diese Ressourcen nutzen zu können wird allerdings eine Infrastruktur
benötigt, welche das Angebot und die Verteilung der Ressourcen verwaltet. Die
Anwendungen, die diese Ressourcen nutzen, müssen ebenfalls fähig sein mit den
besonderen Eigenschaften eines Grids umzugehen.
    Um einheitliche Software zu schreiben werden Programmiermodelle verwen-
det. In diesen Modellen sind verschiedene Eigenschaften festgelegt an die sich der
Entwickler halten muss. Für komponentenbasierte Systeme gibt es viele solche
Modelle. Einige davon sind auch auf die Architektur eines Grid ausgerichtet oder
es existieren Erweiterungen dafür, um auf die spezifischen Grid-Eigenschaften
einzugehen. Allerdings existiert bisher kein Standardmodell, speziell für Grids,
das zum einen für Grid-Anwendungen und zum anderen für Grid-Plattformen
gleichzeitig verwendet werden kann. Für diese Zwecke wurde das Grid Compo-
nent Model (GCM) entwickelt und soll in dieser Arbeit vorgestellt werden.

2      Grid Component Model: Vorstellung und Vergleich

    Der Aufbau dieser Arbeit gliedert sich in sieben Teile. In Kapitel 2 wird
kurz in das Thema Grid Computing eingeführt, um einen Überblick über den
allgemeinen Anwendungsbereich des GCM zu erhalten. Kapitel 3 beschreibt da-
raufhin die grundlegenden Eigenschaften des Komponentenmodells sowie das
Referenzmodell Fractal. Ausgewählte tiefergehende Themen der Komponenten-
spezifikation werden in Kapitel 4 beschrieben. Das Thema der Formalisierung
wird im darauffolgenden fünften Kapitel betrachtet. Kapitel 6 zieht schließlich
einen Vergleich mit der Common Component Architecture, einem weiteren Kom-
ponentenmodell, und beschreibt Möglichkeiten der Interoperabilität damit. Das
letzte Kapitel fasst die Informationen noch einmal zusammen und gibt einen
Ausblick auf weitere Arbeiten bezüglich des Themas Grid Component Model.

2   Grid Computing

Der Vision des Grid Computing ist ein globales Netzwerk, welches auf der ganzen
Welt verfügbar ist. Ein gern verwendeter Vergleich ist das amerikanische Strom-
netz Power Grid. [7] Ressourcen wie Rechenleistung und Speicherplatz sollen
über das Grid problemlos verfügbar gemacht werden.
    Als Grid Computing wird die Vernetzung von Computern zur gemeinsamen
Nutzung von Rechenleistung und Speicherplatz bezeichnet. [4] Die Vernetzung
erfolgt, wie beim World Wide Web, über das Internet. Der Unterschied liegt
in der Nutzung. Das Web verwendet das Internet zum Informationsaustausch,
Grid Computing verwendet es zum Teilen von Rechenleistung. Dadurch entsteht
eine Art virtueller Supercomputer, der zur Lösung besonders rechenintensiver
Probleme verwendet werden kann. [6]
    Die Einsatzbereiche für Grids sind vielfältig und reichen von wissenschaftli-
chen Breichen der Biologie, Pharmaforschung oder Teilchenphysik über kom-
merzielle Bereiche wie e-Commerce und Webservices bis zum Erstellen von auf-
wendigen Animationen in der Filmbranche. [4, 6]
    Die primäre Aufgabe eines Grid ist dabei nicht der Austausch von Daten,
sondern die gemeinsame Nutzung von Ressourcen. Dazu müssen Richtlinien für
alle beteiligten Individuen oder Institutionen erstellt werden, in denen Rechte
und Bedingungen für die Nutzung der Ressourcen festgelegt sind. Ein solcher
Zusammenschluss von Beteiligten und Richtlinien wird Virtuelle Organisation
genannt. [8]
    Virtuelle Organisationen sind ein zentraler Bestandteil des Grid Comput-
ing. Verschiedene Institutionen oder Individuen können sich darin zusammen-
schließen und treten somit nach außen als einheitliches Unternehmen auf. Da-
durch können die verschiedenen Eigenschaften der Beteiligten flexibel kombiniert
werden, um ein individuelles Problem zu lösen. [5]

Zum besseren Verständnis des Begriffs Grid Computing hilft es die Unterschiede
zu verwandten Themen wie Cluster Computing und Cloud Computing zu ver-
deutlichen. Beim Cluster Computing sind die Ressourcen eine Menge von Com-
putern, die über ein schnelles, meist lokales, Netzwerk verbunden sind. [9] Es

Grid Component Model: Vorstellung und Vergleich      3

besteht somit im Vergleich zum Grid eine höhere Kopplung. Im Cluster gibt
es keine geografische Verteilung über weite Strecken wie im Grid. Typischer-
weise herrscht in einem Cluster auch keine Heterogenität, was im Grid eher
wahrscheinlich ist. [6] Cloud Computing bietet ebenso wie Grid Computing die
Mitbenutzung von Ressourcen an. Die Ressourcen sind beim Cloud Computing
in der Regel im Besitz einer einzigen Partei und an einem gemeinsamen Stan-
dort. Während beim Grid Computing die Ressourcen geografisch verteilt und
im Besitz mehrerer Parteien sind. Cloud Computing ist eher kommerziell aus-
gerichtet. Cloud-Systeme vermieten Ressourcen an Benutzer je nach Bedarf und
auf Anfrage. Auch genügen solche Systeme scheinbar nicht den Anforderungen
an Komplexität und Sicherheit, welche die Forschungsgemeinschaft verlangt. [3]

                            Fig. 1. Grid Architektur

Die Architektur eines Grid kann mit einem Schichtenmodell beschrieben wer-
den, wie in Fig. 1 dargestellt. Jede Ebene hat eine bestimmte Funktionalität.
Die Netzwerk Ebene ist die untereste Schicht und zuständig für die Verbindung
der Ressourcen. Die Ressourcen Ebene stellt die Ressourcen dar, wie Computer
oder Speichersysteme. Die Middleware Ebene bietet den Zugriff auf die darun-
terliegende Ressourcen Ebene und auf der Anwendungs Ebene befinden sich die
Anwendungen der Benutzer, die auf das Grid zugreifen wollen. [4]

3   Grid Component Model
Das Grid Component Model (GCM) wurde vom CoreGRID Network of Excel-
lence vorgeschlagen und entworfen. Das CoreGRID Network of Excellence ist Teil

4         Grid Component Model: Vorstellung und Vergleich

eines europäischen Forschungsnetzwerks für den Bereich umfangreicher verteilter
Grid und Peer-to-Peer Technologien. [10]
    Die Definition eines Programmiermodells speziell für Grids wurde entworfen,
da die Entwicklung nach bisherigen Methoden und Modellen nicht zufrieden-
stellend war. Ein Grid besitzt charakteristische Herausforderungen, die beachtet
werden müssen, um effiziente Grid-Anwendungen zu erstellen. Dazu zählen vor
allem die Heterogenität und Dynamik in Bezug auf Programmierbarkeit, Inter-
operabilität, Code-Wiederverwendung und Effizienz. Bisherige Komponenten-
Modelle können die Anforderungen an Performance und Effizienz nicht erfüllen.
Das neu entworfene Modell soll sowohl für Grid-Anwendungen als auch Grid-
Plattformen angewendet werden. [1, 2]

3.1     Eigenschaften
Ein GCM-konformes Framework muss die folgenden Eigenschaften aufweisen:
    – Es müssen zusammengesetzte Komponenten erstellt werden können, da eine
      Komponente aus mehreren anderen Komponenten bestehen darf.
    – Verschiedene Formen der Kommunikation wie many-to-one und one-to-many
      müssen möglich sein, aber auch asynchrone Methodenaufrufe, eventbasierte
      und streamingbasierte Kommunikation.
    – Unterstützung von autonomem Verhalten von Komponenten zu Selbstkon-
      figuration, -optimierung, und -schutz.
    – Funktionale und nicht-funktionale Anpassungsfähigkeit der Komponenten.
      Dynamisches Hinzufügen, Ändern und Entfernen von Komponenten und
      Komponentenbeziehungen.
    – Es sollen Deployment-Beschreibungen für Komponenten und Komponenten-
      Architekturen auf dem Grid unterstützt werden.
    – Unterstützung einer Verhaltens-Spezifikationen für Komponenten um das
      Verhalten und die Zusammensetzung von Komponenten zu verifizieren.

3.2     Modell-Architektur
Die Architektur des GCM ist auf Interoperabilität ausgelegt und enthält eine
Komponentenspezifikation als XML Dokument. Ebenso eine Run-Time API, die
in verschiedenen Sprachen verfügbar ist, sowie ein XML Dokument in dem Pack-
aging beschrieben wird. [2]
    Die Komponentenspezifikation enthält Definitionen für Schnittstellen, ein-
fache und zusammengesetzte Komponenten. Zusätzlich, auf Grund der geforder-
ten Interoperabilität, gibt es Hinweise für andere Spezifikationen wie Java In-
terfaces, C++ .h, Corba IDL oder WSDL. Schließlich gibt es noch Spezifika-
tionen von Grid-Aspekten wie Parallelität, Verteiltheit, Virtuelle Knoten, sowie
Performance-Ansprüche und Quality of Service-Aspekte.
    Die Run-Time API dient zum Beeinflussen der Komponenten zur Laufzeit.
Dazu gehört die Überwachung, Rekonfiguration, Optimierung und Verwaltung
des Life Cycle. Die Implementierungen der API sollten aufgrund von Effizienz

Grid Component Model: Vorstellung und Vergleich       5

und Ausdrucksfähigkeit sprachabhängig sein, z.B. in Java, C++, C# oder For-
tran.
   Packaging Informationen wie Codeabhängigkeiten, Hardwareanforderungen
oder Versionsabhängigkeiten sind hilfreich für das umfangreiche Deployment im
Grid.

3.3   Fractal
Den Grundstein des GCMs bildet das Fractal Component Model. Fractal ist
ein stark erweiterbares Komponentenmodell und bildet das Referenzmodell für
das GCM. Da Fractal nicht auf Verteiltheit und Grid-spezifische Eigenschaften
ausgelegt ist, wird es um diese Eigenschaften erweitert. Fractal bildet somit die
Basis des GCM. Da GCM Fractal erweitert und nicht komplett neu definiert
ist, sind viele Eigenschaften der Fractal Spezifikation auch für das GCM von
Bedeutung.
     Fractal Komponenten setzen sich aus zwei Teilen zusammen (s. Fig. 2): Con-
tent und Controller. Der Content ist eine abstrakte Entität, die von einem Con-
troller kontrolliert wird. Der Content kann aus Unterkomponenten und Bindings
entstehen. Ein Controller, oder auch Membran genannt, ist eine abstrakte En-
tität, die das Kontrollverhalten einer Komponente verkörpert und kann beliebige
Kontroll-Mechanismen auf der zugehörigen Komponente ausführen. Eine Kom-

           Fig. 2. Zusammengesetzte Komponente in Fractal (aus [1, 2])

ponente besitzt vier Schnittstellen. Zum einen eine Client-Schnittstelle und zum
anderen eine Server-Schnittstelle. Die Client-Schnittstelle zum Senden von Funk-
tionsaufrufen und die Server-Schnittstelle zum Empfangen eingehender Funk-
tionsaufrufe.
    Desweiteren besitzt eine Komponente eine funktionale Schnittstelle und eine
Kontroll-Schnittstelle. Die funktionale Schnittstelle entspricht einer Funktion,
die durch eine Komponente angeboten oder von dieser benötigt wird. Die Kon-
troll-Schnittstelle verwaltet nichtfunktionale Aspekte einer Komponente wie z.
B. Konfiguration oder Rekonfiguration. [2]

6      Grid Component Model: Vorstellung und Vergleich

   In Fractal gibt es verschiedene Conformance-Level. Diese sind abhängig vom
Kontroll-Einfluss auf eine Komponente. Das niedrigste Level ist Level 0. Hier sind
Fractal Komponenten wie einfache Objekte. Die Kontrollmöglichkeiten steigen je
Level und eine Fractal Komponente muss sich an zusätzliche Vorgaben halten.
D. h. bei bestimmten Eigenschaften einer Komponente muss diese bestimmte
Controller implementieren. Das höchstmögliche Level an Kontrolle wird mit mit
Level 3.3 erreicht.

3.4   GCM Conformance Level

Auch im GCM gibt es vier Conformance Level, die sich allerdings von den Fractal
Conformance Level unterscheiden. [2]

Level 0 verlangt minimale Interoperabilität und Integration um GCM Kompo-
   nenten zu bearbeiten und betrachten.
Level 1 nimmt Bezug auf die Programmiersprache. Somit kann eine Implemen-
   tierung z.B. GCM Level 1 Java oder C konform sein. Dieses Level hängt stark
   mit den Fractal Conformance Levels zusammen.
Level 2 stellt eine Implementierung mit voller Funktionsfähigkeit dar. Es wird
   hier noch unterschieden zwischen Unterbereichen für Collective Communi-
   cation, dynamische Controller und autonome Controller.
Level 3 fordert komplette Interoperabilität, indem die komplette GCM-API als
   Webservice verfügbar gemacht wird und somit die Verwaltung der Kompo-
   nenten mit verschiedenen Programmiersprachen durchgeführt werden kann.

4     Spezielle Aspekte des GCM

Es gibt viele interessante Aspekte des GCM, die eine genauere Betrachtung Wert
sind. In dieser Arbeit werden zwei davon vorgestellt. Virtuelle Knoten, um eine
abstrakte Sicht auf die Infrastruktur von Grid-Anwendungen zu bekommen, und
die beiden Kommunikationsschnittstellen Multicast und Gathercast, die für ein
Grid eine hohe Bedeutung in Bezug auf effiziente Entwicklung haben können.

4.1   Virtuelle Knoten

Virtuelle Knoten bieten eine praktische Möglichkeit die Infrastruktur einer Grid-
Anwendung zu spezifizieren. Sie sind nur optionaler Bestandteil des GCM, haben
aber durchaus sinnvolle Einsatzzwecke. Sie abstrahieren die physikalischen Ei-
genschaften und erlauben eine klare Trennung zwischen Design und physikalis-
cher Infrastruktur.
    Die Design-Infrastruktur bildet eine virtuelle Infrastruktur zur Darstellung
der gewünschten Umsetzung einer Komponenten-Infrastruktur. Die physikalis-
che Infrastruktur steht zur Zeit der tatsächlichen Umsetzung zur Verfügung. Sie
greift direkt auf bestimmte Ressourcen zu und verwendet bestimmte Kommuni-
kationsprotokolle. Diese Eigenschaften werden durch die virtuelle Infrastruktur

Grid Component Model: Vorstellung und Vergleich       7

verdeckt und abstrakt dargestellt, um eine einfache und unabhängige Verwen-
dung zu ermöglichen.
    Die Spezifikation von virtuellen Knoten kann Eigenschaften definieren, die
von zugewiesenen physikalischen Knoten erfüllt werden müssen. Virtuelle Kno-
ten können verschiedene Kardinalitäten besitzen. Es gibt einfache und vielfache
virtuelle Knoten. Ein einfacher virtueller Knoten benötigt nur einen einzigen
physikalischen Knoten, ein vielfacher virtueller Knoten benötigt mehrere physi-
kalische Knoten.

Code-Beispiel für den Export zweier virtueller Knoten

Zusätzlich gibt es die Möglichkeit virtuelle Knoten zu exportieren. Durch die
Verwendung von exportierten virtuellen Knoten können Namenskonflikte ver-
mieden werden, da für exportierte virtuelle Knoten ein eigener Name gewählt
werden kann. Wird ein virtueller Knoten exportiert behält er seine Kardinalität
bei.
    Durch das Exportieren können auch zusammengesetzte virtuelle Knoten er-
stellt werden. Das Code-Beispiel zeigt einen virtuellen Knoten VN1 der sich
aus den beiden virtuellen Knoten client-vn und server-vn zusammensetzt. Somit
werden beide Komponenten client und server auf dem selben virtuellen Knoten
ausgeführt. [2]

4.2   Multicast und Gathercast

Eine wichtige Eigenschaft in einem Grid ist die Verteilung von Informationen
an mehrere Parteien. Wird eine Nachricht gesendet, so kann diese an mehrere
Empfänger verteilt werden. Ebenso können mehrere Nachrichten empfangen wer-
den und dann zusammengefasst an einen Empfänger weitergeleitet werden. Diese
Art der gesammelten Kommunikation wird über sog. Sammelschnittstellen er-
reicht. Für die Verteilung der Informationen an mehrere Empfänger gibt es die
Multicast-Schnittstelle und für das Zusammenfassen mehrerer Nachrichten für
einen Empfänger gibt es die Gathercast-Schnittstelle.

Multicast bezeichnet die one-to-many Beziehung zwischen Sender und Empfän-
ger. In diesem Fall wird ein einzelner Aufruf in eine Liste von Aufrufen umge-
wandelt. Somit gibt es im Fall von Rückgabewerten auch immer eine Liste
von Rückgabewerten, anstatt eines Einzelnen. Damit ändert sich auch der Typ

8      Grid Component Model: Vorstellung und Vergleich

der Rückgabe im Gegensatz zu normalen Aufrufen, da als Rückgabewert eine
Liste verwaltet werden muss. Eine Komponente im GCM kann zwei verschiedene
Multicast-Schnittstellen implementieren.
    Die Multicast-Server-Schnittstelle wandelt einen Aufruf in eine Menge von
Aufrufen um. Diese Menge von Aufrufen wird entweder, im Fall einer einfachen
Komponente, an Implementierungs-Code weitergeleitet, oder an Server-Schnitt-
stellen interner Komponenten, im Fall einer zusammengesetzten Komponente.
    Die Multicast-Client-Schnittstelle wandelt einen Aufruf in eine Menge von
Aufrufen um. Dieser Aufruf kommt entweder vom Implementierungs-Code einer
einfachen Komponente oder von einer internen Komponente und wird an ange-
bundene Server-Schnittstellen externer Komponenten weitergeleitet.
    Einer der Hauptgründe für diese Art von Schnittstellen ist die mögliche
parallele Ausführung von Aufrufen, was der Effizienz der entwickelten Grid-
Anwendungen zugute kommt.

Gathercast ist das symmetrische Abbild der Multicast-Schnittstelle. Gather-
cast ist die many-to-one Beziehung zwischen Sender und Empfänger. Es gibt
also mehrere Sender und nur einen Empfänger. Die Schnittstelle wandelt somit
mehrere Aufrufe in nur einen einzigen Aufruf um. Gibt es einen Rückgabewert
beim Aufruf, so wird dieser an die aufrufenden Komponenten weitergeleitet.
Auch bei der Gathercast- Schnittstelle gibt es zwei verschiedene Varianten, die
eine Komponente implementieren kann.
    Die Gathercast-Server-Schnittstelle wandelt eine Menge von Aufrufen in ei-
nen Einzelnen um. Die Menge von Aufrufen kommt von Server-Schnittstellen ex-
terner Komponenten und wird bei zusammengesetzten Komponenten an Server-
Schnittstellen interner Komponenten weitergeleitet und bei einfacher Kompo-
nenten an den Implementierungs-Code.
    Die Gathercast-Client-Schnittstelle wandelt eine Menge von Aufrufen in ei-
nen Einzelnen um. Die Menge an Aufrufen kommt bei zusammengesetzten Kom-
ponenten von Client-Schnittstellen interner Komponenten und bei einfachen
Komponenten aus dem Implementierungs-Code.
    Bei der Gathercast-Schnittstelle ist ein wichtiger Aspekt die Synchronisa-
tion der eingehenden Aufrufe. Die Nachrichten müssen zwischengespeichert wer-
den und es muss gewartet werden bis die Nachricht an die eigentliche Ziel-
Schnittstelle weitergeleitet wird. Die Gathercast-Schnittstelle ist sich bewusst
welche anderen Schnittstellen angebunden sind. Somit können Annahmen er-
stellt und Regeln festgelegt werden. Dadurch ist es beispielsweise möglich die
Nachricht nach einer bestimmten Zahl eingegangener Nachrichten zusammen-
zufassen und weiterzuleiten. Zusätzlich könnte auch ein Time-Out eingeführt
werden, mit dem eine maximale Wartezeit festgelegt wird.

Hängt die Bearbeitung der Aufrufe von der Übergabe bestimmter Parameter
ab, so gibt es eine Optimierungsmöglichkeit der beiden Sammelschnittstellen.
Die Standardverteilung ist die Broadcast-Weitergabe aller Parameter an alle
Zielschnittstellen. Sind einige der Parameter allerdings Wertelisten, so können

Grid Component Model: Vorstellung und Vergleich          9

diese aufgeteilt werden. Jede Zielschnittstelle bekommt somit nur einen Teil der
Parameter und alle arbeiten auf unterschiedlichen Daten. Bei der Multicast-
Schnittstelle werden die Aufrufe somit parallel und mit unterschiedlichen Daten
bearbeitet. Bei der Gathercast-Schnittstelle werden dagegen Aufrufe mit jeweils
verschiedenen Parametern zu einem Aufruf zusammengefasst.

Neben one-to-many und many-to-one ist es auch möglich eine many-to-many
Kommunikation zu realisieren. Dazu müssen die verschiedenen Multicast- und
Gathercast-Schnittstellen in geeigneter Weise kombiniert werden. [2]

5    Formale Spezifikation
Bisher existiert keine formale Spezifikation für das GCM. Allerdings gibt es
zwei Ansätze für das Fractal Komponentenmodell. Diese können somit auch
für das GCM verwendet werden, da Fractal die Grundlage des GCM bildet.
Die erwähnten Formalisierungs-Ansätze sind in [20] und [21] beschrieben. Der
Ansatz in [21] umfasst allerdings nicht alle Eigenschaften der Fractal Spezi-
fikation. [20] bietet dagegen eine vollständige sprachunabhängige formale Spez-
ifikation. Deswegen wird im folgenden nur auf die in [20] vorgestellte formale
Spezifikation eingeganen. Diese wurde in der Spezifikationssprache Alloy 4 [12]
geschrieben.
     Die formale Spezifikation bereinigt einige Unklarheiten und ist in manchen
Aspekten toleranter im Vergleich zur nicht-formalen Spezifikation. Es können
damit formale Überprüfungen von Fractal Designs und Tools durchgeführt wer-
den. Andere Komponentenmodelle können verglichen werden. Das ist bspw. in-
teressant, um herauszufinden ob ein bestimmtes Komponentenmodell eine kor-
rekte Spezialisierung des Fractal Modells darstellt. Darüberhinaus bildet eine for-
male Spezifikation die Basis für eine formale Architektur-Beschreibungs-sprache
für Fractal.

Der Kern des Fractal Modells wird im ersten Teil der formalen Spezifikation
behandelt. Hier wird als erstes der Begriff für eine Komponente definiert. Eine
Komponente wird kell genannt, was eine entfernte Anspielung auf das englische
Wort cell sein soll. Eine Komponente hat die Möglichkeit mit ihrer Umgebung
zu kommunizieren. Die Kommunikation läuft über sog. gates ab. Gates können
somit als die Schnittstellen einer Komponente betrachtet werden. Da eine Kom-
ponente auch aus Unterkomponenten bestehen kann, werden diese als subkells
bezeichnet. Um nun Komponenten und Gates zu definieren, werden zuerst Men-
gen von atomaren Elementen definiert, in denen verschiedene Eigenschaften der
Schnittstellen und Komponenten verwaltet werden.
    module fractal/foundations

    sig Id {}
    sig Val {}
    sig Op extends Id {}

10       Grid Component Model: Vorstellung und Vergleich

Die Namen stehen dabei für Mengen von Bezeichnern, Basiswerten und Transak-
tionsnamen. Die Transaktionsnamen sind als Untermenge der Bezeichner fest-
gelegt. Wie im Code-Beispiel zu sehen, ist es in Alloy möglich Module zu definie-
ren. Diese können dadurch in anderen Modulen importiert und verwendet wer-
den. Mit diesen primitiven Mengen sind nun Gate und Kell definiert:

     sig Gate {
       gid: Id
     }

     sig Kell {
       gates: set Gate,
       sc: set Kell,
       kid: Id
     }

     fact GatesInKellHaveUniqueIds {
       all c:Kell | all i,j:c.gates | i.gid = j.gid implies i = j
     }

Die Definition legt also fest, dass ein Gate einen Bezeichner besitzt. Dieser Bezei-
chner muss aus der vorher definierten Menge Id stammen und wird in der Eigen-
schaft gid verwaltet. Ein Kell-Element hat auch einen Bezeichner kid. Zusätzlich
hat es eine Menge von Gates und die Menge sc an Unterkomponenten. Der
anschließend definierte Alloy fact stellt sicher, dass alle Schnittstellen, die zu
einer Komponente gehören, unterschiedliche Bezeichner besitzen. Damit wurde
die grundlegende Struktur einer Komponente festgelegt. Als nächstes wird die
Komponente mit Transitionen ausgestattet, wozu die Elemente TKell und Tran-
sition definiert werden:

     sig TKell in Kell {
       transitions: set Transition
     }

     sig Transition {
       tsc: set Kell,
       sin: set Signal,
       sout: set Signal,
       res: set Kell
     }

     fact TransMayNotHaveDifferentSubComps {
       all c:TKell | all t:c.transitions | t.tsc = c.sc
     }

TKell ist eine Untermenge von Kell und enthält zusätzlich eine Menge von Tran-
sitionen. Das Element Transition enthält eine Menge an initialen Komponenten

Grid Component Model: Vorstellung und Vergleich           11

tsc, ein Input-Signal sin, ein Output-Signal sout und eine Menge an resultieren-
den Komponenten res. Die Menge an initialen Komponenten stellt dabei die
Menge an Unterkomponenten der Komponente dar, auf der die Transition aus-
geführt wird. Der zugehörige fact stellt dabei sicher, dass es sich bei den initialen
Komponenten um die Unterkomponenten der Transition-Komponente handelt.
Um die Definition des Kerns des Fractal Modells abzuschließen fehlt noch die
Definition des Signal-Elements:
    sig Signal {
      target: Gate,
      operation: Op,
      args: Id -> set Arg
    }

    sig Arg in Id + Val + Gate + Kell {}

    fact SignalsTargetGates {
      all c:TKell | c.transitions.(sin + sout).target in c.gates
    }
Ein Signal enthält eine Zielschnittstelle target, einen Transaktionsnamen oper-
ation und einen Datensatz an verschiedenen Argumenten args. Die Argumente
sind im Element Arg definiert und umfassen die Mengen von Bezeichner, Werte,
Schnittstellen und Komponenten. Der fact SignalsTargetGates stellt sicher, dass
alle Zielschnittstellen einer Transition auch Schnittstellen der zugehörigen Kom-
ponente sind.

Die definierten Eigenschaften spiegeln nur den grundlegenden Teil des Fractal
Modells wider. Die komplette formale Spezifikation findet sich in [20] und wurde
hier nur auszugsweise erwähnt.

6    Vergleich und Interoperabilität mit CCA
Es gibt neben dem Grid Component Model noch weitere Komponentenmodelle,
die sich für die Entwicklung von Grid-Anwendungen eignen. Die wichtigsten sind
dabei die Common Component Architecture (CCA) [14] und das CORBA Com-
ponent Model mit Erweiterungen für Grids [15]. In [16] vergleichen Malawski
und Bubak zwei Komponenten Modelle und testen ihre Fähigkeit zusammen-
zuarbeiten. Sie definieren ein Framework mit dem Fractal Komponenten und
CCA Komponenten interagieren und zeigen damit die Offenheit beider Systeme.
Untermauert werden ihre Behauptungen durch eine Beispiel-Implementierung.

Aus den vorhandenen Komponenten Modellen wurden die beiden Frameworks
GCM und CCA ausgewählt. CCA existiert schon einige Zeit und hat mehrere Im-
plementierungen. GCM dagegen ist aktueller und will ein Standard-Komponen-
tenmodell im Grid-Bereich definieren. Um das zu erreichen muss das Modell

12     Grid Component Model: Vorstellung und Vergleich

die Zusammenarbeit mit existierenden Anwendungen und die Integration bish-
eriger Komponenten ermöglichen. Die Basis von GCM bildet das Fractal Kom-
ponenten Modell, in dem auch die grundlegenden Eigenschaften der Kompo-
nenten und ihr Zusammenspiel definiert sind. Somit stützen sich Malawski und
Bubak hauptsächlich auf Fractal, verwenden aber als Implementierung die GCM-
Implementierung ProActive. In zukünftigen Arbeiten sollen die zusätzlichen As-
pekte des GCM in Betracht gezogen werden. Als CCA-Implementierung kommt
MOCCA [17] zum Einsatz.

Interoperabilität zweier Komponenten Modelle ist das Ziel. Interoperabilität be-
deutet hier die Zusammenarbeit der Modelle in einem heterogenen Kontext.
Der herkömmliche Ansatz dafür besteht in der Integration von Webservices
und somit XML als gemeinsame Sprache um unabhängig Informationen auszu-
tauschen. Der Ansatz aus [16] ist allerdings ein anderer. Hier wird eine neue
Interoperabilitäts-Schicht zwischen bestimmten Komponenten durch Vermittler
und Adapter erzeugt. Somit wird kein zusätzliches überlagerndes Framework
verwendet.

6.1   Analyse der Modelle
Die CCA-Spezifikation definiert verschiedene Kernentitäten des Modells: Kom-
ponenten, Ports und ein Framework. Für die externen Schnittstellen der Kom-
ponenten gibt es verschiedene Ports. Die Client-Schnittstelle wird als uses-Port
bezeichnet und die Server-Schnittstelle als provides-Port. Das Framework besitzt
eine Services-Schnittstelle bei der die Ports registriert werden können. Zum Er-
stellen und vernichten von Komponenten, sowie zum Verbinden der Ports gibt
es die Schnittstelle BuilderService. Neben diesen Schnittstellen gibt es noch op-
tionale Ports, die Interoperabilität erleichtern sollen.

Im Vergleich zu Fractal hat CCA einige Gemeinsamkeiten sowie Unterschiede.
Zu den Gemeinsamkeiten zählt die Trennung von Schnittstelle und Implemen-
tierung. Auch die Zusammensetzung von Anwendungen durch Verbindung der
Client- und Server-Ports ist in beiden Modellen möglich. Beide Modelle un-
terstützen die Fähigkeit zu Reflexion. Die wichtigste Gemeinsamkeit ist allerd-
ings die Übereinstimmung der funktionalen Schnittstellen.
    Unterschiede, die es zu überwinden gilt, liegen in der Kommunikation der
Komponenten mit der Außenwelt. Bei CCA informieren die Komponenten das
Framework über ihre Schnittstellen und bei Fractal wartet eine Komponente bis
sie danach gefragt wird. Verbindungen werden in CCA über den BuilderSer-
vice erstellt und vom Framework verwaltet. Fractal-Komponenten sind dagegen
selbst verantwortlich für ihre Verbindungen. In CCA gibt es kein entsprechen-
des Gegenstück zum Fractal-ContentController, da in CCA zusammengeset-
zte Komponenten nicht explizit definiert sind. Auch gibt es keinen Standard
Life Cycle Mechanismus. CCA unterscheidet nicht zwischen nicht-funktionalen
Schnittstellen wie Fractal, hat aber trotzdem vergleichbare Möglichkeiten der-
artige Eigenschaften zu beeinflussen. Die Erstellung von Komponenten wird in

Grid Component Model: Vorstellung und Vergleich         13

CCA auch vom BuilderService übernommen, während es in Fractal die Factory-
Schnittstelle dazu gibt. Fractal besitzt eine Application Description Language
(ADL). CCA hat sowas nicht standardäßig, allerdings definieren verschiedene
Implementierungen jeweils eigene ADLs um Anwendungen zusammenzusetzen.

Ein Problem für die Interoperabilität beider Modelle ist die Tatsache, dass
Fractal- bzw. GCM-Komponenten einen festen, unveränderlichen Typ besitzen.
Dieser statische Typ kann zur Verifikation der Korrektheit von Komponenten-
verbindungen verwendet werden, ist allerdings ab der Instantiierung nicht mehr
erweiterbar. CCA-Komponenten können jederzeit neue Ports registrieren und
besitzen somit keinen festen Komponententyp. Um diesem Problem zu begeg-
nen schlagen Malawski und Bubak unter anderem vor, dass der Entwickler eine
ADL für die CCA-Komponente erstellen soll. Damit ist es möglich einige Ports,
die während des Komponenten-Life Cycle angeboten werden, für Fractal als op-
tionale Schnittstellen zu definieren. Dieser Lösungsansatz ist möglichst allgemein
gehalten und soll ein gutes Verständnis für die Unterschiede zwischen CCA und
Fractal ermöglichen. Er konzentriert sich außerdem auf die Interaktion zwischen
beiden Modellen. Bei dem genannten Lösungsansatz wird somit ein Mapping
benötigt, das CCA-Ports auf die entsprechenden GCM-Schnittstellen abbildet.

6.2   Integrationsstratiegen

In [16] wird für die Prüfung der Interoperabilität beider Modelle die Integration
des CCA-Modells innerhalb eines GCM- bzw. Fractal-Systems betrachtet. Es
wird unterschieden zwischen der Integration einer einzelnen CCA Komponente
und der eines kompletten CCA-Systems, bestehend aus mehreren Komponen-
ten. Für die Kombination von CCA und Fractal muss ein Framework mehrere
Eigenschaften unterstützen. Das wichtigste ist die Kommunikation vom Fractal-
System zum CCA-System und zurück. Aber auch das Verbinden von Fractal-
Interfaces mit dem CCA-System und sofern es unterstützt wird, der Export von
neuen CCA-Ports.
    Die Integration einer einzelnen CCA-Komponente wird mit Hilfe eines Wrap-
pers durchgeführt. Dieser Wrapper ist eine einfache Fractal Komponente und
ummantelt die CCA-Komponente. Der Wrapper bietet der CCA-Komponente
die Schnittstelle cca.Services. Vor der Instantiierung muss allerdings der Typ der
Fractal-Komponente bekannt sein, der möglicherweise durch eine ADL-Beschrei-
bung ermittelt werden kann. Somit wird die gesamte Kommunikation von einem
Fractal-Framework durchgeführt und kein CCA-Framework benötigt.
    Im Fall der Integration eines gesamten CCA-Systems werden die CCA-Kom-
ponenten in ihrem eigenen Framework erstellt und mit Fractal-Komponenten
in einem Fractal-Framework verbunden. Um eine vollständige Zusammenarbeit
zwischen beiden Frameworks zu erreichen muss das komplette CCA-System in-
nerhalb eines Fractal Frameworks als zusammengesetzte Fractal-Komponente
angesehen werden. Dazu wird wieder ein Wrapper eingesetzt, der das komplette
CCA-System ummantelt.

14     Grid Component Model: Vorstellung und Vergleich

   Der Wrapper erhält die Informationen über das Mapping der Frameworks
und erzeugt sogenannte GluePorts. Diese GluePorts übersetzen die Aufrufe von
Fractal in Aufrufe für CCA und umgekehrt. Nach außen bieten die GluePorts
Fractal-Schnittstellen an und können mit Fractal-Komponenten über den Bind-
ingController verbunden werden, intern werden die CCA-Ports über den Builder-
Service mit den GluePorts verbunden.

6.3   Ergebnis
Die Analyse der beiden Systeme hat die Unterschiede beider Modelle gezeigt.
Doch ist es trotzdem möglich, dass beide Frameworks zusammenarbeiten. Der
Vorteil des beschriebenen Ansatzes ist, dass kein zusätzliches Framework benö-
tigt wird. Zukünftige Arbeiten werden in Richtung Automatisierung und Gen-
eration von Glue-Code zur Laufzeit zielen. Die erweiterten Eigenschaften des
GCM sollen ebenfalls zukünftig behandelt werden.

7     Zusammenfassung
In dieser Arbeit wurde anfangs der Begriff des Grid Computing erläutert und
anschließend das Grid Component Model eingeführt. Es wurde beschrieben wie
sich dieses Modell zusammensetzt, auf welche Eigenschaften bezüglich des Grid
zu achten sind und dass es eine Erweiterung zum Fractal Komponentenmod-
ell darstellt. Zusätzlich wurden bestimmte Aspekte wie virtuelle Knoten sowie
Multicast- und Gathercast-Schnittstellen erläutert. Daraufhin wurde der Kern
einer formalen Spezifikation für Fractal vorgestellt, die somit auch für das GCM
Gültigkeit besitzt. Anschließend wurde ein Vergleich zwischen GCM und dem
CCA Komponentenmodell gezogen und deren Möglichkeiten der Interoperabili-
tät veranschaulicht.

Es gibt viele weiterführende Arbeiten zu Themen des GCM. In [18] wird an-
hand einer Beispielanwendung demonstriert wie sich eine Anwendung mit dem
GCM umsetzen lässt. Dazu wurde ProActive verwendet und versucht eine Grid
Anwendung zu erstellen, die unter anderem auch Multicast- und Gathercast-
Schnittstellen berücksichtigt.
   Mit dem Thema autonome Komponenten beschäftigen sich in letzter Zeit
mehrere Arbeiten. Es geht zum Beispiel in [19] darum, wie autonomes Verhal-
ten in Grid Komponenten implementiert werden kann. In [20] wird der formale
Aspekt von autonomen Komponenten behandelt und ein formale Beschreibung
der adaptiven Operationen erstellt.

Grid Component Model: Vorstellung und Vergleich           15

References
1. Institue on Programming Model: Proposals for a Grid Component Model, Core-
   GRID deliverable D.PM.02 (2006)
2. Institue on Programming Model: Basic features of the Grid Component Model,
   CoreGRID deliverable D.PM.04 (2007)
3. GridTalk: GridBriefings - Grids and clouds: the new computing. http://www.
   gridtalk.org/briefings/gridsandclouds.pdf (letzte Abfrage: 03.06.2009)
4. GridCafé: The place for everybody to learn about grid computing. http://www.
   gridcafe.org (letzte Abfrage: 03.06.2009)
5. Wikipedia: Virtuelle Organisationen. http://de.wikipedia.org/wiki/Virtuelle_
   Organisation (letzte Abfrage: 17.07.2009, oldid=61901799)
6. Wikipedia: Grid Computing. http://de.wikipedia.org/wiki/Grid-Computing
   (letzte Abfrage: 17.07.2009, oldid=60952747)
7. Barth, T.: Grid Computing: Das wahre Web 2.0? http://www.heise.de/tp/r4/
   artikel/27/27029/1.html (letzte Abfrage: 03.06.2009)
8. Foster, I., Kesselman, C.: The Grid: Blueprint for a New Computing Infrastructure.
   2. Auflage, Morgan Kaufmann, San Francisco (2004)
9. Wikipedia: Computercluster. http://de.wikipedia.org/wiki/Computercluster
   (letzte Abfrage: 17.07.2009, oldid=62262354)
10. CoreGRID European Research Network. http://www.coregrid.net (letzte
   Abfrage: 03.06.2009)
11. P. Merle, J.B. Stefani: A formal specification of the Fractal component model in
   Alloy. INRIA Research Report RR-6721 (2008)
12. D. Jackson. Software Abstractions: Logic, Language, and Analysis. MIT Press
   (2006)
13. E. Bruneton, T. Coupaye, and J.B. Stefani: The Fractal Component Model. Tech-
   nical report, Specification v2, ObjectWeb Consortium (2003)
14. R. Armstrong et al.: The CCA component model for high-performance scientific
   computing. Concurr. Comput.: Pract. Exper., 18(2):215-229 (2006)
15. S. Lacour et al.: Deploying CORBA components on a computational grid. Volume
   3083 of LNCS, pages 35-49 (2004)
16. M. Malawski, M. Bubak: Interoperability of grid component models: GCM and
   CCA case study. Towards Next Generation Grids (Proceedings of the CoreGRID
   Symposium 2007), CoreGRID, pages 95-105. Springer (2007)
17. M. Malawski et al.: MOCCA - towards a distributed CCA framework for meta-
   computing. In Proceedings of the 10th HIPS Workshop in Conjunction with IPDPS.
   IEEE (2005)
18. N. Parlavantzas et al.: Componentising a scientific application for the grid. Core-
   GRID Technical Report TR-0031 (2006)
19. M. Aldinucci et al.: Behavioural skeletons in GCM: autonomic management of
   grid components. In D. E. Baz, J. Bourgeois, and F. Spies, editors, Proc. of Intl.
   Euromicro PDP 2008: Parallel Distributed and network-based Processing, pages
   54-63, Toulouse. IEEE (2008)
20. M. Aldinucci, E. Tuosto.: Towards a formal semantics for autonomic components.
   In T. Priol and M. Vanneschi, editors, From Grids To Service and Pervasive Com-
   puting (Proceedings of the CoreGRID Symposium 2008), CoreGRID, pages 31-45,
   Las Palmas. Springer (2008)
21. M. Simonot, M.-V. Aponte.: Modélisation formelle du contrôle en Fractal. ARA
   REVE Project Deliverable 2.3. CNAM-CEDRIC (2007)

Sie können auch lesen