Transcript Seminar-Layout

SOFA & DCUP
Software Appliances & Dynamic Component Update
Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf
1
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
2
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
3
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
4
SOFA-Components

Primitive Component

Composed Component
 Enthält keine weiteren
Subkomponenten sondern
ist direkt implementiert
 Ausschließlich
zusammengesetzt aus
anderen Komponenten
 Enthält letztendlich alle
Funktionalitäten
 Enthält keine eigentlichen
Funktionalitäten, sondern
benutzt und kombiniert die
Funktionalitäten anderer
Komponenten
 Atomare Teile des
Baukastenprinzips
– (Analogie: LEGO-Steine)
 Baukastenprinzip
– (Analogie: Gebilde aus
LEGO-Steinen)
Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf
5
Frame/Black-Box-Ansicht

Das Frame ist die BlackBox-Ansicht einer
Komponente
 Inhalt der Black-Box ist nicht
bekannt, sondern nur die
Funktion
 requires und provides
Interfaces zum Verbinden
mit anderen Komponenten
Provides
Interfaces
Requires
Interfaces
Black-Box
Black-Box-Ansicht einer Komponente
 Baukastenprinzip
Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf
6
Architecture/Grey-Box-Ansicht
subsuming
binding

Die Architecture beschreibt
das Innere eines Frames
1
 Composed Components
bestehen aus miteinander
verknüpften
Unterkomponenten
 Einem Frame können
mehrere Architectures
zugrunde liegen
2
3
delegating
 Verschiedene Versionen
Gray-Box-Ansicht einer Composed Component
exempting
Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf
8
Hierarchie
While ...
If...
Then..
..
Usw.
Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf
9
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
10
Component Definition Language (CDL) II
Interface-Definition
Return-Typ: CentralPlayerServices
Name: Login
Name: login
Eingabe-Typ:
String
Frame-Definition
Name: Client
provided und required
Interfaces werden definiert
Architecture-Definition
inst = Instanzierung
Connectors werden definiert
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;
};
Sourcecode-Beispiel in CDL
(Quelle: SOFA Implementation Manual)
Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf
11
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
12
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 CDLDefinition 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
13
Connectors
Zur Erinnerung:
delegating


Connectors realisieren die
Verbindungen zwischen
Interfaces
SOFA behandelt Connectors
analog zu Komponenten:
binding
 Primitve Connector
 Direkt implementiert
1
2
 Composed Connector
3
 Zusammengesetz aus primitive C.s

Drei vordefinierte Connectors:
 CSProcCall
 EventDelivery
 DataStream
subsuming
exempting
Grey-Box-Ansicht einer Composed Component
Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf
14
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
15
Behaviour

Eine Abfolge von Events, dargestellt durch Event Tokens, nennt man Trace
 Bsp.:
<!m^; ?m$; !n^; ?n$;>
 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 :
{<?.i1.m^; !.i1.m$>,<?.i1.n^; !.i1.n$>}
 Das Interface i1 erwartet entweder den Aufruf von Methode m oder Methode n und antwortet
Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf
16
Behaviour Protocols I

Da Konstrukte wie
{<?.i1.m^; !.i1.m$>,<?.i1.n^; !.i1.n$>}
nicht gut lesbar sind, gibt es Behaviour Protocols
 Behaviour Protocol des obigen Ausdrucks:
Prot-F = ?i1.m + ?i1.n
 ‚?m‘ steht abkürzend für (?m^; !m$)
 ‚+‘ bezeichnet Alternative

Behaviour Protocols werden direkt in CDL Code integriert
Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf
17
Zusammenfassung






Primitive & Composed Components
Frame (Black-Box) & Architecture (Grey-Box)
Component Definition Language (CDL)
Type Information Repository (TIR)
Connectors
Events & Behaviour Protocols
Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf
19
SOFAnodes I

Ein SOFAnode ist eine Umgebung zur
 Entwicklung
 Verteilung
 Ausführung
von SOFA Applikationen

Mehrere SOFAnodes können zu einem SOFAnet
verbunden werden
Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf
20
SOFAnodes II

Ein SOFAnode besteht aus max.
fünf logischen Teilen:
IN
 Template Repository (TR)
 Enthält Implementation und CDL-Code
aller Komponenten
 MADE part
 Umgebung zur Erstellung neuer
RUN
TR
MADE
Komponenten (CDL Compiler, TIR, Code
Generator)
 IN und OUT part
 Zur automatischen Verteilung von
Komponenten zwischen SOFAnodes
 RUN part
OUT
 Laufzeitumgebung
Schematische Darstellung eines SOFAnodes
Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf
21
SOFAnet
0
0
RUN
TR
MADE
RUN
IN
TR
MADE
OUT
OUT
RUN
TR
IN
MADE
RUN
0
TR
MADE
0
Schematische Darstellung eines SOFAnets
Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf
22
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
23
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
24
Dynamic Component Update (DCUP) III
CMA
CBA
Replaceable Part
CMB
Permanent Part
B
Component Border
CMC
C
A
Schematische Darstellung einer DCUP-Komponente
Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf
CM
Component Manager
CB
Component Builder
Control Part
Functional Part
25
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
26
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
27
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
28
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
29
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
30
Fragen zu SOFA?
Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf
31