Teil

1 Java basierte Komponentenmodelle
1.1 Grundlagen
1 Java basierte Komponentenmodelle
Software Komponenten
Software Komponenten
Szyperski
Eine Softwarekomponente ist ein wiederverwendbares Stück Software
I
hat eine gut spezifizierte Schnittstelle
I
kann in nicht-vorhergeplanten Kontexten eingesetzt werden
I
ist eine eigenständig vermarktbare Einheit
I
Standard-Konventionen für die Schnittstellen von
Software-Komponenten
I
I
Ziele: Einfache Verwendbarkeit + Wiederverwendbarkeit
Software-Komponenten sind selbst-beschreibend
I
Automatische Analyse von Schnittstelle und Eigenschaften möglich
I
Beispiele
I
I
1.1 Grundlagen
Dialog einer graphischen Oberfläche
I
Module einer Textverarbeitung (z.B. Rechtschreibkorrektur)
I
Modul welches ein Gerät integriert (z.B. Drucker)
I
I
Introspection / Reflection - Mechanismen
Interface-Repository
Namens-Konventionen
Zusammenstellung zu komplexen Anwendungen mit grafischen
Werkzeugen (Builder-Tools)
I
Software-Baukasten
Klassen == Komponenten ?
c Rüdiger Kapitza
WS 08/09
1 Java basierte Komponentenmodelle
MW
I 1-1
c Rüdiger Kapitza
1.1 Grundlagen
1 Java basierte Komponentenmodelle
Software Komponenten
I 1-2
1.1 Grundlagen
Richtlinien für Software-Komponenten
I
I
I
I
I
I
I
I
I
I
MW
I 1-3
Namenskonventionen
Repositories, Introspection-Mechanismus
Schnittstellen-Semantik
Programmiermethodik
Beispiele Komponentenarchitekturen für Java
I
WS 08/09
MW
Software Komponenten
I
c Rüdiger Kapitza
WS 08/09
JavaBeans
EJB – Enterprise Java Beans
Spring
Jini
OSGi
CORBA Component Model
c Rüdiger Kapitza
WS 08/09
MW
I 1-4
1 Java basierte Komponentenmodelle
1.1 Grundlagen
1 Java basierte Komponentenmodelle
Java im Kontext von Komponentensystemen
Java Beans
Ziele der Sprache
I Lösung der verbreiteten Probleme bei der Entwicklung und Verteilung
von Software
I
I
I
1.2 Java Beans
I
verschiedene Betriebssysteme (Unix, Windows, MacOS, ?)
verschiedene Hardware-Architekturen
Java Beans ist eine Schnittstellen-Spezifikation für
wiederverwendbarer Software-Komponenten in Java
I
I
Java: Sprache und Ausführungsumgebung für sichere,schnelle und
sehr robuste Anwendungen auf verschiedenen Plattformen in
heterogenen verteilten Netzen
I
definiert Java-Komponenten
und wie sie zusammenarbeiten
Eine Bean ist eine beliebige Java-Klasse, die den Java
Beans-Konventionen folgt
Wesentliche Eigenschaften für Komponenten
I
objektorientiert
I
Polymorphismus bei Methodenaufrufen
sehr flexibel (dynamisches Laden und Binden)
I
I
I
Die offizielle Definition von Sun:
A Java Bean is a reusable software component that can be visually manipulated in builder tools.
Kann auch problematisch sein! ⇒ OSGi
Reflection/Introspection Mechanismus
c Rüdiger Kapitza
WS 08/09
1 Java basierte Komponentenmodelle
MW
I 1-5
1 Java basierte Komponentenmodelle
I
I
I
I
die Verknüpfungspunkte für Beans
I
Adapter
I
Datenbank-Schnittstelle
Timer
I
I
Introspection
I
Knöpfe, Regler, Textfenster
HTML rendering Bean
zur Schnittstellenanpassung, wenn Beans nicht einfach
zusammenpassen
I
I
I
I
I
WS 08/09
MW
I 1-7
löst Ereignisse in bestimmten Abständen aus
kann komplexe Zeit-Logik kapseln
Softwarekomponenten, die Geräte/Geräteteile repräsentieren
I
statt eines Interface-Repositories: einfach in die Bean reinschauen was
sie kann
c Rüdiger Kapitza
1.2 Java Beans
Unsichtbare Beans
I
I
I 1-6
Grafische Beans einer Benutzeroberfläche
I
initiale Einstellung von Eigenschaften (Zustand) einer Bean
Methoden Ereignisse (Events)
I
MW
Beispiele
Eigenschaften (Properties)
I
WS 08/09
1.2 Java Beans
Architektur
I
c Rüdiger Kapitza
Schalter
Sensoren, Aktautoren
Video-Rekorder
Kaffeemaschine
c Rüdiger Kapitza
WS 08/09
MW
I 1-8
1 Java basierte Komponentenmodelle
1.2 Java Beans
1 Java basierte Komponentenmodelle
Properties
I
I
I
I
I
Properties
Beschreiben Eigenschaften von Komponenten
Jede Property hat
I
I
einen Namen – symbolische, aussagekräftige Beschreibung der
Eigenschaft (Color, Font, usw.)
private Color color; (Instanzvariable der Bean-Klasse)
einen Typ – Java-Klasse, kapselt den Wert
Constraints – optionale Einschränkungen (z.B. read-only)
I
I
I
WS 08/09
1 Java basierte Komponentenmodelle
MW
informieren andere Objekte über Zustandsänderungen
(PropertyChange event)
Constrained properties
I
I 1-9
repräsentieren ein Feld, set/get-Methoden haben einen
index-Parameter
Bound properties
I
I
repräsentieren einen einzelnen Wert, Zugriff mit set/get-Methoden
Indexed properties
I
get-Methode zum Lesen
public Color getColor() return color;
set-Methode für Modifikationen
public void setColor(Color newColor) {
color = newColor;
repaint();
}
c Rüdiger Kapitza
Simple properties
I
Namens-Konventionen für Methoden zum Zugriff (Methoden der
Beam- Klasse)
I
1.2 Java Beans
nicht erlaubte Zustandsänderungen können zurückgewiesen werden
c Rüdiger Kapitza
1.2 Java Beans
WS 08/09
1 Java basierte Komponentenmodelle
Events
MW
I 1 - 10
1.2 Java Beans
Events
Umsetzung des Source-Listener Design-Patterns
I Source-Objekt informiert Listener über Zustandsänderungen
I
I
EventSource hat Methoden für Listener, um sich zu
registrieren/abzumelden
Beispiel:
public void addTimerListener(TimerListener l)
public void removeTimerListener(TimerListener l)
I
I
I
I
PropertyChangeSupport
I
add/remove
gleicher Name Methode wie Parameter
Parameter muss EventListener Schnittstelle implementieren
I
automatisches Versenden von notification-Events, immer wenn sich der
Wert einer Property ändert
VetoableChangeSupport
I
EventObject
I
I
I
ermöglicht das Zurückweisen von Property-Werten, die außerhalb des
gültigen Bereichs liegen
kapselt Informationen ber Ereignis
EventListener
I
Klasse die EventListener-Interface implementiert (Subtyp von
java.util.EventListener)
c Rüdiger Kapitza
WS 08/09
MW
I 1 - 11
c Rüdiger Kapitza
WS 08/09
MW
I 1 - 12
1 Java basierte Komponentenmodelle
1.2 Java Beans
1 Java basierte Komponentenmodelle
Adaptor
I
I
I
I
I
Introspection
Anpassung von Methoden einer Bean an Ereignisse einer anderen
I
I
Adapter implementiert passendes Event-Listener Interface
Adapter registriert sich für Events von Bean 1
Event 1 wird ausgelöst : Bean 1 ruft Methode die im event-Interface
festgelegte Methode event1Happend()bei allen registrierten
Event-Listener-Objekten auf
event1Happend() im Adapter ruft method2() an Bean 2 auf
I
Automatische Analyse von Eigenschaften einer Bean
I
Ab Java 1.1 Reflection API
I
I
I
I
Adapter-Objekt kann Daten evtl. manipulieren (z. B. umrechnen)
I
I
Einfache Adapter können automatisch erzeugt werden
I
WS 08/09
1 Java basierte Komponentenmodelle
MW
I 1 - 13
I
I
I
I
WS 08/09
MW
I 1 - 14
1.3 OSGi
OSGi – Open Services Gateway initiative
I
Zustand = Properties
Eingänge = Methoden
Ausgänge = Events
wenn Stecker-Buchse nicht passen: Adapter
I
OSGi ist ein dynamisches Modulsystem für Java
Entwicklung und Standardisierung durch ein Konsortium
I
I
I
Probleme Defizite
Zusammenstecken einfacher Komponenten zu komplexen
Komponenten
I
c Rüdiger Kapitza
1 Java basierte Komponentenmodelle
Beans sind zusammensteckbare Software-Bausteine
I
Entwickler kann Properties und Events explizit spezifizieren
1.2 Java Beans
Zusammenfassung
I
get/set Methoden für Properties
add/remove Methoden für Events
andere Methoden für normale Methoden
Alternative: Information in einer BeanInfo-Klasse (ähnlich wie ein
Interface-Repository)
I
c Rüdiger Kapitza
Analyse von Java-Klassen zur Laufzeit
Instanzvariablen: Name & Typ
Methoden: Name, Parameter, Ergebnis-Typ
JavaBeans Namens-Konventionen
I
I
1.2 Java Beans
Usprünglich für Java-basierte eingebettete Systeme gedacht
Aktuell Entwicklung zum Standard zur Modularisierung von
komplexen Java-Anwendungen
I
I
hierarchische Beans
Z.B. IBM, Siemens, Nokia, SAP, etc.
Z. B. Eclipse und Websphere
Spezifikation unter http://www.osgi.org/
I
Ankoppeln neuer Software-Komponenten an laufende Anwendungen
I
Software-Komponenten im verteilten System
OSGi website
I
Aktualisierung von laufenden Komponenten
I
Keine Unterstützung für die Verwendung von Code verschiedener
Hersteller/Entwickler
OSGi technology provides a service-oriented, component-based environment for
developers and offers standardized ways to manage the software lifecycle. These
capabilities greatly increase the value of a wide range of computers and devices
that use the Java platform.
c Rüdiger Kapitza
WS 08/09
MW
I 1 - 15
c Rüdiger Kapitza
WS 08/09
MW
I 1 - 16
1 Java basierte Komponentenmodelle
1.3 OSGi
1 Java basierte Komponentenmodelle
Klassen Laden in Java
1.3 OSGi
Eigene ClassLoader Implementierungen
I
I
Ableitung von java.lang.ClassLoader
loadClass() lädt Klassen bleibt aber erhalten
p u b l i c s y n c h r o n i z e d C l a s s l o a d C l a s s ( S t r i n g name ) t h r o w s C l a s s N o t F o u n d E . . {
I
Alle Klassen werden durch einen Class Loader in die Java
Laufzeitumgebung geladen
I
Komplexe Applikationen verfügen oft über meherere Class Loader
I
I
C l a s s c = f i n d L o a d e d C l a s s ( name ) ; // A l r e a d y l o a d e d t h i s c l a s s ?
i f ( c == n u l l ){ // Can t h e c l a s s be l o a d e d by a p a r e n t ?
try{
i f ( p a r e n t == n u l l ){
c = V MCl assLoad er . l o a d C l a s s ( name , r e s o l v e ) ;
i f ( c != n u l l )
return c ;
}else{
r e t u r n p a r e n t . l o a d C l a s s ( name , r e s o l v e ) ;
}
} c a t c h ( C l a s s N o t F o u n d E x c e p t i o n e ){ }
// S t i l l n o t found , we h a v e t o do i t o u r s e l f .
c = f i n d C l a s s ( name ) ;
Integration von Programmcode bzw. Komponenten verschiedener
Firmen und Entwickler
Laden von Klassen über das Netzwerk bzw. zur Integration von neuen
Funtionalitäten
}
resolveClass (c );
return c ;
}
I
findClass() wird implementiert
I
WS 08/09
1 Java basierte Komponentenmodelle
MW
I 1 - 17
c Rüdiger Kapitza
WS 08/09
1.3 OSGi
1 Java basierte Komponentenmodelle
Probleme bei der Verwendung von mehreren Class Loader
I
I
I
Bundle 2
Bundle n
Services
Service Registry
Life Cycle
Modules
Java Runtime Environment
Operating System / Hardware
Ziel von OSGi:
I
1.3 OSGi
OSGi Framework
ClassLoader weisen jeder Klasse eine Id zu die bei gleichem Namen zur
ClassCastExecption führt
Wo werden statische Variablen verwaltet?
JNI
C/C++
Klassen dürfen innerhalb eines Anwendungskontextes nur einmal
geladen werden
I
I 1 - 18
Framework
Bundle 1
I
MW
Security
c Rüdiger Kapitza
Legt fest welche Klassen geladen werden
Sichere Verwendung von Java Modulen unterschiedlicher Hersteller
und Versionen
Kontrollierte Verwendung von Class Loader
c Rüdiger Kapitza
WS 08/09
MW
I 1 - 19
c Rüdiger Kapitza
WS 08/09
MW
I 1 - 20
1 Java basierte Komponentenmodelle
1.3 OSGi
1 Java basierte Komponentenmodelle
Framework
1.3 OSGi
Framework
Life Cycle Layer
Security Layer
I
Ergänzung zur Java 2 Security Architektur
I
Code Authentifizierung durch Signaturen (Herkunft, Unterzeichner)
I
Verwaltung des Lebenszyklus von Bundles
I
Bundles können zur Laufzeit installiert, gestartet, gestoppt und
deinstalliert werden
install
INSTALLED
update
refresh
STARTING
Module Layer
I
Einheit der Modularisierung: Bundle
I
Bundles werden als Java ARchive (JAR) Datei ausgeliefert
I
I
refresh
update
resolve
uninstall
Enthlt alle nötigen Resourcen (evtl. inkl. weiterer JARs)
Bundlebeschreibung und Abhängigkeiten als Manifest Datei
(META INF/MANIFEST.MF)
start
ACTIVE
RESOLVED
uninstall
stop
UNINSTALLED
c Rüdiger Kapitza
WS 08/09
1 Java basierte Komponentenmodelle
MW
I 1 - 21
c Rüdiger Kapitza
1.3 OSGi
WS 08/09
1 Java basierte Komponentenmodelle
Framework
STOPPING
MW
I 1 - 22
1.3 OSGi
Manifest
Life Cycle Layer
I
I
Bundle - Repräsentiert ein installiertes Bundle
Bundle Context - Ausführungskontext eines Bundles
I
I
I
Manifest enthält alle Information zur Integration eines Bundels
Zugriff auf Informationen des Framework und die Service Registry
Installieren anderer Bundles
I
I
Bundle Activator
I
Activator Klasse ist der Einstiegspunkt
Jedes Bundle hat eigenen Classloader und Class Space
I
Starten und Stoppen des Bundles
I
I
Service Layer
I
I
Service Registry zum Registrieren, Finden und Binden von Diensten
I
Dienste sind Java-Objekte, registriert mit ihrem/ihren Interface(s)
I
Bundles können Dienste registrieren, suchen und ihren Zustand
abfragen
c Rüdiger Kapitza
WS 08/09
MW
I 1 - 23
I
Classpath ergibt sich aus: RTE + Framwork + Bundle Classpath
Bundle-Classpath - Intra-Bundle Classpath für eingebettete JARs
Import-Package - Importierte Pakete von anderen Bundles
Require-Bundle - Importiert alle Pakete des angegebenen Bundles
Export-Package - Pakete die von diesem Bundle exportiert werden
c Rüdiger Kapitza
WS 08/09
MW
I 1 - 24
1 Java basierte Komponentenmodelle
1.3 OSGi
1 Java basierte Komponentenmodelle
Auflösen der Abhängikeiten zwischen Bundles
Auflösen der Abhängikeiten zwischen Bundles
I
Jedes Bundle besitzt einen eigenen Classloader
I
I
Auflösung aller im Manifest beschriebenen Abhängigkeiten
I
I
I
I
I
I
Lade Klasse XYZ
JAVA.* ?
Alle Importe verdrahtet sind
Alle benötigten Pakete verfügbar sind und ihre Exporte verdrahtet
boot delegation?
Nach dem Auflösen kann Bundle geladen und ausgeführt werden
c Rüdiger Kapitza
WS 08/09
1 Java basierte Komponentenmodelle
MW
I 1 - 25
1.3 OSGi
Zusammenfassung
I
I
Einfaches Komponentensystem
Löst deployment-Probleme
I
I
I
und verfügt damit über einen eigenen Namensraum
Suchreihenfolge
Importierte und exportierte Pakete
Benötigte Bundles (import aller Pakete)
Fragmente (Teil eines größeren logischen Bundles)
Ein Bundle ist resolved wenn
I
Es können Komponenten aus verschiedenen Quellen miteinander
kombiniert werden
Entwickelt sich zum de facto Standard für Java
Offene Fragen
I
I
Verteiltes Interaktionsmodel
Dynamisches Laden von entfernten Code
I
c Rüdiger Kapitza
Bisher zentrale proprietre Lösungen
WS 08/09
MW
1.3 OSGi
I 1 - 27
Java Runtime Paket?
Beauftrage Parent-Classloader!
Enthalten in org.osgi.framework.bootdelegation?
Beauftrage Parent-Classloader!
importiert?
Importiert durch Import-Package?
Beauftrage entfernten Bundle-Classloader!
Classpath?
Im Bundle Classpath?
Beauftrage eigenen Bundle-Classloader!
c Rüdiger Kapitza
WS 08/09
MW
I 1 - 26