universität bonn, seminar component and aspect engineering ws 2003/2004, tobias rudorf1 sofa &...

Universität Bonn, Seminar „Component and Aspect Engineering“ WS 2003/2004, Tobias Rudorf 1

SOFA & DCUP

Software Appliances & Dynamic Component Update


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++


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


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


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)


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


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


Hierarchie

While ...

If... Then..

..

Usw.


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


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


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


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


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:


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$


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$>}


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


Primitive & Composed Components Frame (Black-Box) & Architecture (Grey-Box) Component Definition Language (CDL) Type Information Repository (TIR) Connectors Events & Behaviour Protocols

Zusammenfassung


Ein SOFAnode ist eine Umgebung zur Entwicklung Verteilung Ausführung

von SOFA Applikationen

Mehrere SOFAnodes können zu einem SOFAnet verbunden werden

SOFAnodes I


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


SOFAnet

TR

0

MADERUN

OUT

TR

0

MADERUN

OUT

TR

IN

MADERUN

0

TR

IN

MADERUN

0

Schematische Darstellung eines SOFAnets


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


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


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


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


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


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


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


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


Fragen zu SOFA?

universität bonn, seminar component and aspect engineering ws 2003/2004, tobias rudorf1 sofa &...

Documents