SOFA & DCUP

1. SOFA & DCUP Software Appliances & Dynamic Component Update

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

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

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

5. 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) SOFA-Components

6. 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 Frame/Black-Box-Ansicht Provides Interfaces Requires Interfaces Black-Box Black-Box-Ansicht einer Komponente

7. 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 subsuming binding delegating exempting Architecture/Grey-Box-Ansicht 1 2 3 Gray-Box-Ansicht einer Composed Component

8. While ... If... Then.. .. Hierarchie Usw.

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

10. Component Definition Language (CDL) II Interface-Definition Name: Login Return-Typ: CentralPlayerServices Name: login Eingabe-Typ: String 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; }; Frame-Definition Name: Client provided und required Interfaces werden definiert Architecture-Definition inst = Instanzierung Connectors werden definiert Sourcecode-Beispiel in CDL (Quelle: SOFA Implementation Manual)

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

12. Type Information Repository (TIR) II • Die Versions-Wahl beim Kompilieren geschieht nach folgenden Prioritäten: • Der Entwickler hat die gewünschte Version direkt in der CDL-Definition vorgeschrieben • Dem Namen der Komponente wird im aktiven Profil eine Version zugeordnet • Die neueste Version wird gewählt

13. 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 delegating binding exempting Connectors Zur Erinnerung: 1 2 3 subsuming Grey-Box-Ansicht einer Composed Component

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:

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

16. 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 Protocolswerden direkt in CDL Code integriert {<?.i1.m^; !.i1.m$>,<?.i1.n^; !.i1.n$>} Prot-F = ?i1.m + ?i1.n

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

18. SOFAnodes I • Ein SOFAnode ist eine Umgebung zur • Entwicklung • Verteilung • Ausführung von SOFA Applikationen • Mehrere SOFAnodes können zu einem SOFAnet verbunden werden

19. 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 SOFAnodes II IN RUN TR MADE OUT Schematische Darstellung eines SOFAnodes

20. SOFAnet 0 0 RUN MADE TR RUN MADE TR OUT OUT IN IN RUN MADE TR RUN MADE TR 0 0 Schematische Darstellung eines SOFAnets

21. 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

22. 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

23. Control Part Functional Part Dynamic Component Update (DCUP) III Replaceable Part CMB CMA CBA Permanent Part B Component Border CMC CM Component Manager C CB Component Builder A Schematische Darstellung einer DCUP-Komponente

24. 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

25. 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

26. 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 QuiescentState erlaubt

27. 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

28. 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

29. Fragen zu SOFA?