Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf 1
SOFA & DCUP
Software Appliances & Dynamic Component Update
Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf 2
Das SOFA-Project
SOFA steht für „Software Appliances“
Gründer des SOFA-Projects: Abteilung für Software-Entwicklung der Karls-Universität Prag,
Tschechische Republik Ziel: Entwicklung einer Software-Umgebung mit besonderem
Augenmerk auf die „Beziehung zwischen Software-Anbieter und Software-Benutzer“
Aktueller Entwicklungsstand: Prototyp in Java 2 Experimentelle Implementation in C++
Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf 3
Ziele und Prinzipien von SOFA
Dynamischer Download von Komponenten
Dynamisches Update von Komponenten zur Laufzeit (DCUP)
Komponenten-Hierarchie
Einsatz auf verteilten Systemen
Verschiedene Komponenten-Versionen parallel
Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf 4
SOFA Component Model
Grundlegende Eigenschaften von SOFA Applikationen sind durch das SOFA Component Model fest definiert.
Eine SOFA Komponente besteht grundsätzlich aus:
Provided und Required Interfaces Frame (black-box view) Architecture (gray-box view) Connectors Behaviour protocols
Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf 5
SOFA-Components
Primitive Component
Enthält keine weiteren Subkomponenten sondern ist direkt implementiert
Enthält letztendlich alle Funktionalitäten Atomare Teile des
Baukastenprinzips
– (Analogie: LEGO-Steine)
Composed Component
Ausschließlich zusammengesetzt aus anderen Komponenten
Enthält keine eigentlichen Funktionalitäten, sondern benutzt und kombiniert die Funktionalitäten anderer Komponenten Baukastenprinzip
– (Analogie: Gebilde aus LEGO-Steinen)
Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf 6
Frame/Black-Box-Ansicht
Das Frame ist die Black-Box-Ansicht einer Komponente
Inhalt der Black-Box ist nicht bekannt, sondern nur die Funktion
requires und provides Interfaces zum Verbinden mit anderen Komponenten Baukastenprinzip
Black-Box
Provides Interfaces
Requires Interfaces
Black-Box-Ansicht einer Komponente
Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf 8
Architecture/Grey-Box-Ansicht
Die Architecture beschreibt das Innere eines Frames
Composed Components bestehen aus miteinander verknüpften Unterkomponenten
Einem Frame können mehrere Architectures zugrunde liegen Verschiedene Versionen
2
1
3
binding
delegating
subsuming
exempting
Gray-Box-Ansicht einer Composed Component
Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf 9
Hierarchie
While ...
If... Then..
..
Usw.
Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf 10
Component Definition Language (CDL) I
CDL ist die SOFA-Sprache zur Definition von Komponenten
CDL dient zur Beschreibung von : Interfaces Frames Architectures Bindings Protocols
Basiert auf OMG IDL OMG = Object Management Group IDL = Interface Definition Language
Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf 11
interface Login { CentralPlayerServices login(in string who);};frame Client { provides: Client iClient; requires: Login iLogin; CentralPlayerServices iCPS;};architecture CUNI GameGen implements GameGenerator { inst GameGeneratorDBServices aGGDBS; inst ConfigurationFileParser aConfig; inst GameGeneratorFunctionality func; bind func:iConfig to aConfig:iConfig; bind func:iGGDB to aGGDBS:iGGDB; subsume aGGDBS:iDatabase to iDatabase;};
Component Definition Language (CDL) II
Sourcecode-Beispiel in CDL
(Quelle: SOFA Implementation Manual)
Return-Typ: CentralPlayerServicesName: login
Eingabe-Typ: String
Interface-DefinitionName: Login
Frame-DefinitionName: Client
provided und required Interfaces werden definiert
Architecture-Definitioninst = Instanzierung
Connectors werden definiert
Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf 12
Type Information Repository (TIR) I
CDL-Beschreibungen werden im Type Information Repository (TIR) kompiliert und verwaltet
Jedes Element im TIR ist eindeutig identifiziert durch Seinen Namen
Definiert in der CDL-Spezifikation
Seine Specification Version Die Version eines neuen Elements wird automatisch anhand des TIR-Inhalts und
des gewählten Profiles berechnet.
Ein Profile ist eine Liste von Tupeln der Art (Name, Version) Bestimmt die richtige Version beim Kompilieren
Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf 13
Type Information Repository (TIR) II
Die Versions-Wahl beim Kompilieren geschieht nach folgenden Prioritäten:
1) Der Entwickler hat die gewünschte Version direkt in der CDL-Definition vorgeschrieben
2) Dem Namen der Komponente wird im aktiven Profil eine Version zugeordnet
3) Die neueste Version wird gewählt
Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf 14
Connectors
2
1
3
binding
subsuming
delegating
exempting
Grey-Box-Ansicht einer Composed Component
Connectors realisieren die Verbindungen zwischen Interfaces
SOFA behandelt Connectors analog zu Komponenten: Primitve Connector
Direkt implementiert
Composed Connector Zusammengesetz aus primitive C.s
Drei vordefinierte Connectors: CSProcCall EventDelivery DataStream
Zur Erinnerung:
Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf 15
Events
Es gibt vier verschiedene Events, die bei der Kommunikation zwischen Komponenten auftreten können
In dem von uns betrachteten Modell werden Events mit atomaren Event Tokens behandelt:
Event Name Event Token für Methode m
Methodenaufruf senden !m^
Methodenaufruf empfangen ?m^
Antwort senden !m$
Antwort empfangen ?m$
Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf 16
Behaviour
Eine Abfolge von Events, dargestellt durch Event Tokens, nennt man Trace Bsp.:
Ruft Methode m auf, wartet auf Return, ruft Methode n auf und wartet auf Return
Die Menge aller möglichen Traces einer SOFA Einheit nennt man Behaviour Bsp. für das Interface i1 :
Das Interface i1 erwartet entweder den Aufruf von Methode m oder Methode n und antwortet
<!m^; ?m$; !n^; ?n$;>
{<?.i1.m^; !.i1.m$>,<?.i1.n^; !.i1.n$>}
Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf 17
Behaviour Protocols I
Da Konstrukte wie
nicht gut lesbar sind, gibt es Behaviour Protocols
Behaviour Protocol des obigen Ausdrucks:
‚?m‘ steht abkürzend für (?m^; !m$) ‚+‘ bezeichnet Alternative
Behaviour Protocols werden direkt in CDL Code integriert
{<?.i1.m^; !.i1.m$>,<?.i1.n^; !.i1.n$>}
Prot-F = ?i1.m + ?i1.n
Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf 19
Primitive & Composed Components Frame (Black-Box) & Architecture (Grey-Box) Component Definition Language (CDL) Type Information Repository (TIR) Connectors Events & Behaviour Protocols
Zusammenfassung
Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf 20
Ein SOFAnode ist eine Umgebung zur Entwicklung Verteilung Ausführung
von SOFA Applikationen
Mehrere SOFAnodes können zu einem SOFAnet verbunden werden
SOFAnodes I
Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf 21
SOFAnodes II
Ein SOFAnode besteht aus max. fünf logischen Teilen:
Template Repository (TR) Enthält Implementation und CDL-Code
aller Komponenten
MADE part Umgebung zur Erstellung neuer
Komponenten (CDL Compiler, TIR, Code Generator)
IN und OUT part Zur automatischen Verteilung von
Komponenten zwischen SOFAnodes
RUN part Laufzeitumgebung
TR
IN
MADERUN
OUT
Schematische Darstellung eines SOFAnodes
Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf 22
SOFAnet
TR
0
MADERUN
OUT
TR
0
MADERUN
OUT
TR
IN
MADERUN
0
TR
IN
MADERUN
0
Schematische Darstellung eines SOFAnets
Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf 23
Dynamic Component Update (DCUP) I
DCUP ist eine Erweiterung von SOFA-Komponenten und ermöglicht sicheres Updaten zur Laufzeit
Eine DCUP-Komponente besteht aus zwei Teilen:
Permanent Part Kein Update möglich Bei allen Versionen einer Komponente identisch
Replaceable Part Austauschbar Verschiedene Versionen einer Komponente unterscheiden sich hier
Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf 24
Dynamic Component Update (DCUP) II
DCUP-Komponenten enthalten zwei Kontrollobjekte:
Component Manager (CM) Kontrolliert den Lebenszyklus der Komponente zur Laufzeit Gehört zum Permanent Part der Komponente Der CM ist für jede Version einer Komponente gleich
Component Builder (CB) Zuständig für die Inneren Abläufe der Komponente:
– Bei Primitive Components: Implementation
– Bei Composed Components: Subkomponenten Gehört zum Replaceable Part der Komponente Kann für jede Version einer Komponente unterschiedlich sein
Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf 25
Dynamic Component Update (DCUP) III
CMA CBA
CMB
CMC
A
B
C
Replaceable Part
Permanent Part
Component Border
CM Component Manager
CB Component Builder
Schematische Darstellung einer DCUP-Komponente
Control Part
Functional Part
Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf 26
Prototyp in Java 2
Eine SOFA-Komponente wird in Java durch folgende Objekte dargestellt:
Component Manager Wird als erstes initialisiert Registriert und verwaltet die Komponente Verantwortlich für das dynamische Update/DCUP
Component Builder Erstellt Subkomponenten und Verbindungen bei Composed Components Erstellt die Objekte zur Implementierung bei Primitive Components
Weitere Objekte zur Implementierung der Funktionalität Nur bei Primitive Components
Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf 27
Deployment Descriptor
Component Deployment Descriptor (CDD) Beschreibt eine einzelne Komponente „Grundgerüst“ wird automatisch erstellt aus CDL-Definitionen Der Entwickler ergänzt:
Die Versionsnummer der Komponente (Primitive) Die Versionsnummern der Subkomponenten (Composed)
Application Deployment Descriptor (ADD) Beschreibt die gesamte Baum-Hierarchie der Applikation Rekursiv erstellt aus dem CDD und den CDDs der
Subkomponenten
Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf 28
Quiescent State
Die Thread Registry im CM registriert alle threads
Quiescent State einer Komponente bedeutet Kein thread wird in der Komponente ausgeführt Die Komponente wartet nicht auf einen Aufruf durch eine andere
Komponente
Updates sind ausschließlich bei Quiescent State erlaubt
Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf 29
Ablauf eines dynamischen Updates
Update-Flag wird gesetzt Alle eingehenden Methoden-Aufrufe werden geblockt
CM wartet bis Quiescent State erreicht ist
CM ersetzt CB, Subkomponenten usw.
Update-Flag wird zurückgesetzt Neue Version der Komponente steht bereit Alle geblockten Aufrufe werden abgearbeitet
Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf 30
Warum Prototyp?
In dem Java-Prototyp fehlen immer noch einige Features
Im SOFAnode fehlt z.B.:
Automatische Verteilung zwischen SOFAnodes
TR fehlt. Stattdessen: Ein http-Server stellt die Komponenten-Klassen zur Verfügung TIR stellt die Komponenten-Spezifikationen zur Verfügung
Speichern und Wiederherstellen des Komponenten-Status während des dynamischen Updates und des Terminierens fehlt
Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf 31
Fragen zu SOFA?