Vorlesung Informatik 2 - Hochschule Esslingenrau/vorlesungen/Informatik2/...konzepte.pdf · Andreas Rau, 11.06.10 D:\home\ar\fhte\vorlesungen\informatik2\folien\informatik2-theorie-konzepte.odp

$Page 1: Vorlesung Informatik 2 - Hochschule Esslingenrau/vorlesungen/Informatik2/...konzepte.pdf · Andreas Rau, 11.06.10 D:\home\ar\fhte\vorlesungen\informatik2\folien\informatik2-theorie-konzepte.odp$
Andreas Rau, 11.06.10 D:\home\ar\fhte\vorlesungen\informatik2\folien\informatik2-theorie-konzepte.odp #1

Vorlesung Informatik 2Fachhochschule für Technik Esslingen

Studiengang Wirtschaftsinformatik

Fortgeschrittene KonzepteDr. rer. nat. Andreas Rau

http://www.hs-esslingen.de/[email protected]


In diesem Teil der Vorlesung sollen am Beispiel der GUI Programmierung weitergehende und allgemeine Konzepte vermittelt werden. Dazu gehört u.a. das Lokalitätsprinzip und die Einführung von inneren Klassen, die praktische Anwendung des Konzepts von Model-View-Controller sowie eine Reihe von Anwendungsmustern (Design-Patterns).

Inhalt


Grundprinzipien Oberfläche ist aus Elementen zusammengesetzt (Komposition) Benutzerinteraktion wird durch Basiselemente abgewickelt (Delegation) Hauptprogramm wird "zurückgerufen" wenn etwas passiert (Observer)

Bei der Einführung in Informatik 1 wurden verschiedene Klassen und Interfaces für das Hauptfenster (JFrame) und die Events/Listener, z.B. von Buttons, eingeführt (ActionEvent/ActionListener). Allerdings trat als Empfänger der Events stets die Fensterklasse auf. Dies kann bei komplexeren Oberflächen verschiedene Probleme mit sich bringen:

Mangelnde Verständlichkeit (Button und Aktion voneinander entfernt) Mangelnde Übersicht (viele Aktionen in einer Listener-Methode) Schlechte Wiederverwendbarkeit (alles oder nichts) Behinderung der Arbeitsteilung (alles in einer gemeinsamen Methode)

Die Beachtung von Grundprinzpien der Programmierung kann hier helfen

Rückblick: Eventbasierte GUI-Programmierung


Hintergrund des Lokalitätsprinzips ist es, zusammengehörige Dinge im Programm möglichst nahe beieinander zu beschreiben und dabei gleichzeitig globale Abhängigkeiten (insbesondere Ursache-Wirkung) und Auswirkungen zu minimieren (wie in der realen Welt). Dadurch wird u.a. das Verständnis erleichtert (man kann Programmteile isoliert lesen und verstehen) sowie die Wartbarkeit verbessert (lokale Änderungen haben keine globalen Nebenwirkungen).

Beispiel: lokale Variablen Schleifenvariablen

Mit dem Lokalitätsprinzip eng verknüpft ist das Prinzip "One thing at a time", d.h. die Beschränkung von Methoden bzw. Klassen auf eine klar definierte Aufgabe.

Lokalitätsprinzip und "One thing at a time"


Angewandt auf die GUI Programmierung folgt aus diesen Prinzipien der Wunsch (a) für jeden Button einen eigenen Listener zu definieren und (b) dies möglichst nahe bei der Definition des Buttons zu tun.

Prinzipiell wäre es möglich, das Ziel (a) zu erreichen, indem man für jeden Button eine eigene Listener-Klasse implementiert. Dies wäre jedoch nicht nur umständlich sondern würde auch das Ziel (b) unberücksichtigt lassen (1 File pro Klasse) sowie zu einer unübersichtlichen Vielfalt von Klassen führen.

Um diesen Widerspruch aufzulösen wurden die Inner Classes eingeführt. Sie gestatten die einfache Definition von eigenständigen Hilfsklassen aus einer bestehenden Klasse heraus, wobei der Zusammenhang zwischen der Hauptklasse und der Hilfsklasse stets klar ist.

Hinweis: Inner Classes sind „syntaktischer Zucker“, d.h. eine bequeme Schreibweise für etwas, was man auch so hätte realisieren können.

Inner Classes(1) - Motivation


Inner Classes(2) – Anwendungsbeispiel/vorherpublic class ButtonsBuiltIn extends JFrame implements ActionListener { JButton button1, button2, button3; // buttons as instance variables public ButtonsBuiltIn() { super( "BuiltIn"); setDefaultCloseOperation( EXIT_ON_CLOSE); getContentPane().setLayout( new GridLayout( 1, 3)); button1 = new JButton( "La"); button1.addActionListener( this); getContentPane().add( button1); // same for button2 and button3... pack(); } public void actionPerformed( ActionEvent e) { if (e.getSource() == button1) { System.out.println( "La"); } // same for button2 and button3... } public static void main( String[] args) { new ButtonsBuiltIn().show(); }}


Inner Classes(3) – Anwendungsbeispiel/nachher

public class ButtonsInner extends JFrame { public ButtonsInner() { super( "Inner"); setDefaultCloseOperation( EXIT_ON_CLOSE); getContentPane().setLayout( new GridLayout( 1, 3)); JButton button1 = new JButton( "La"); // button as local variable button1.addActionListener( new ActionListener() { public void actionPerformed( ActionEvent e) { System.out.println( "La"); } }); getContentPane().add( button1); // same for button2 and button3... pack(); } public static void main(String[] args) { new ButtonsInner().show(); } }

kürz

er u

nd k

ompa

kter

!


Der new-Aufruf im Beispiel erzeugt an Ort und Stelle eine neue anonyme Klasse sowie eine Instanz derselben. Als Platzhalter für den Klassenname kann entweder (a) der Name einer Klasse oder (b) der Name eines Interfaces verwendet werden. Dies bewirkt folgendes:

(a) die neue Klasse erbt von der angegebenen Klasse(b) die neue Klasse erbt von Object und implementiert das Interface

Die neue Klasse kann also nicht gleichzeitig erben und implementieren! Hinter dem new-Aufruf kann ein Klassenrumpf angegeben werden, um Methoden zu definieren und/oder zu überschreiben. Der Name der neuen Klasse wird vom Compiler automatisch generiert (vgl. class-File).

Folgen der Anonymität: Die neue Klasse kann keinen Konstruktor mit Parametern* haben Die neue Klasse kann keine öffentlichen spezielle Methoden haben Es ist nicht möglich mehr als eine Instanz zu erzeugen Es gibt keine Variablen mit dem Typ der Klasse(!)

Inner Classes(4) – Eine erste Erklärung


Neben der gezeigten Verwendung in GUIs gibt es noch viele weitere Fälle, in denen Inner Classes nützlich sind. Mit Inner Classes kann mann

Klassen, die zusammenarbeiten, noch enger zusammen bringen und dabei durch die Verschachtelung deren Hierarchie klar machen wobei der Namensraum des Pakets nicht "verschmutzt" wird. Vielmehr agiert dabei die umgebende Klasse als neue Art von Namensraum.

Beispiele:Daten oder Iteratoren in Collections

Außerdem kann man mit Inner Classes als Objekt verpackte Funktionen dynamisch an der Stelle erzeugen, an der sie benötigt werden.

Beispiele:Comparatoren, Runnables (kommt später) oder ... ActionListener

Inner Classes(4a) – Anwendungsbereiche für Inner Classes


Insgesamt existieren 4 Varianten von Inner Classes: Neben den gezeigten und vorrangig bei der GUI Programmierung eingesetzten anonymen Klassen (anonymous classes) gibt es noch geschachtelte Klassen (nested classes), Mitgliedsklassen (member classes) und lokale Klassen (local classes). Diese unterscheiden sich insbesondere bzgl. ihres Verhältnisses zur äußeren Klasse.

Bei genauer Betrachtung zeigt sich, dass die Eigenschaften dieser Varianten aufeinander aufbauen und dabei Schritt für Schritt den Weg von einer unabhängigen "Schwesterklasse" im gleichen Paket oder gar File zu einer immer stärker integrierten "Symbiontenklasse*" vollziehen. Dabei erwirbt die Inner Class Zug um Zug nahezu alle Eigenschaften und Rechte der bekannten Klassenelemente wie Klassen- und Instanzmethoden sowie den Zugriff auf Klassen-, Instanz- und lokale Variablen.

* Der Begriff "Tochterklasse" wird bereits für die Vererbung verwendet.

Inner Classes(5) - Variantenübersicht


Zielsetzung:Zusammenfassung von Klassen und deren Hilfsklassen ohne den globalen Namensraum zu "verschmutzen". Die äußere Klasse funktioniert dabei analog zu einem Paket, d.h. der voll qualifizierte Klassename der inneren Klasse ist "package(s).OuterClass.NestedClass". Die Objekterzeugung erfolgt ganz normal über den new-Operator. Nested Classes sind im Grund ganz normale Klassen, die in den Gültigkeitsbereich einer anderen Klasse eingebettet sind und dadurch besondere Zugriffsrechte auf private Elemente haben.

Wirkung:Integration auf Klassenebene, Zugriff auf Klasse direkt (auf Instanz indirekt)

Anwendungsbeispiel:public class MyMap { public static class KeyValuePair { Object key, value; } List data = ArrayList<KeyValuePair>() // ...}

Inner Classes(6) – Nested Classes


Zielsetzung:Zusammenfassung von Klassen mit Hilfsklassen; enge Zusammenarbeit zwischen beiden Klassen. Eine Instanz einer Member Class gehört stets zu einer Instanz der äußeren Klasse und ist mit besonderen Zugriffsrechten auf diese Instanz ausgestattet. Realisiert ist dies durch einen unsichtbaren Verweis auf die Instanz der äußeren Klasse auf die in der inneren Klasse mittels "OuterClass.this" zugegriffen werden kann. Um diesen Verweis zu initialisieren, müssen Instanzen der inneren Klasse stets mittels "OuterObject.new MemberClass()" für eine Instanz der äußeren Klasse erzeugt werden.

Wirkung:Integration auf Instanzebene, direkter Zugriff auf Klasse und „Vaterinstanz“

Anwendungsbeispiel:public class MyCollection { public class MyIterator implements Iterator { // kann auf MyCollection zugreifen }}

Inner Classes(7) – Member Classes


Hintergrund:Jede Objektmethode bekommt die Pseudovariable this als unsichtbaren Parameter übergeben. Der Aufruf

obj.setFoo( value)

kann also interpretiert werden als

setFoo( obj, value) // wobei this = obj

In gleicher Art und Weise bekommt der Konstruktor einer Member Class eine unsichtbare Referenz der äußeren Klasse übergeben, d.h. der Aufruf

obj.new MemberClass()

kann interpretiert werden als

new MemberClass( obj)

Man spart sich also den manuellen Verdrahtungsaufwand (s. Beispiel n. Folie)

Daraus folgt: ohne Objektreferenz geht es nicht, da sonst ein Parameter fehlen würde. Jedoch kann man ein vorangestelltes this immer weglassen (=Default).

Inner Classes(7a) – Member Classes


public class Outer { int id;

public static class NestedInner { Outer o;

public NestedInner( Outer o) { this.o = o; }

public void test() { System.out.println( o.id); } }

public class InnerMember { public void test() { System.out.println( id); // Outer.this.id } }

public static void main( String[] args) { Outer o = new Outer(); new NestedInner( o).test(); o.new InnerMember().test(); }}

Inner Classes(7b) – Member Classes


Zielsetzung:Engstmögliche Kapselung von Hilfsklassen in einer Methode. Typischerweise nur wenige Instanzen (aber mehr als eine). Da die Sichtbarkeit von lokalen Klassen ohnehin auf die umgebende Methode beschränkt ist, ist die Angabe des Zugriffsmodifizierers bei der Klassendeklaration überflüssig.

Wirkung:Integration in einer Methode, Zugriff auf Klasse+“Vaterinstanz“+lokale Variablen

Anwendungsbeispiel:public class OuterClass {

public void someMethod() { class LocalClass { // body... }

LocalClass instance = new LocalClass(); // use it... }}

Inner Classes(8) – Local Classes


Hintergrund:Instanzen von Local Classes erhalten genau wie Instanzen von Member Classes eine unsichtbare Referenz auf das umgebende Objekt. Wie wird jedoch der Zugriff auf die lokalen Variablen realisiert?

Das Problem ist einerseits, dass lokale Variablen nicht wie Instanzvariablen über eine Referenz greifbar sind, und anderseits, dass ein lokales Objekt noch weiterexistieren kann, nachdem die erzeugende Methode längst schon beendet ist (d.h. die lokalen Variablen zerstört sind).

Der einzige Ausweg aus diesem Dilema besteht darin, die verwendeten lokalen Variablen ebenfalls in die Instanz hineinzukopieren! Um sich mit der dadurch keine neuen Probleme einzuhandeln müssen diese dazu final sein, damit sie sich Kopie und Original nicht auseinanderentwickeln können.

Inner Classes(8a) – Local Classes


Zielsetzung:Namenlose "Wegwerfklassen" für einmalige Anwendung; maximale Bequemlichkeit bei der Deklaration, nur eine Instanz. Die Deklaration der Klasse und die Instantiierung der Instanz erfolgen in einem Schritt.

Wirkung:Vereinfachung der Integration in einer Methode gegen Einschränkungen

Deklarationsbeispiel:public class OuterClass { public void sortPersons( ArrayList persons) { Collections.sort( persons, new Comparator() { public int compare(Object o1, Object o2) { return ((Person)o1).name.compareTo( ((Person)o2).name); } public boolean equals( Object o) { return false; } }); }}

Inner Classes(9) – Anonymous Classes


Inner Classes(10a) – Verdrahtung

Frame

this

sampleField

NestedClass

this

frame

MemberClass

this Frame.this


Mit Inner Classes kennen wir nun alle Gültigkeitsbereiche in Java:

Der Zugriff auf andere Bereiche ist nur von Innen nach Außen möglich!

Inner Classes(10b) - Zugriffsrechte

Paket

Datei

Klasse

Objekt

Instanzmethode

Block/Kontrollstruktur

Klassenmethode

Block/Kontrollstruktur

Nested Class

Member Class

Local/Anonymous Class* Local/Anonymous Class*

*Zugriff auf lokale Variablen nur wenn final


Inner Classes(11) – Vergleich

Sichtbarkeit nach Außen

Ja Viele

Ja Einige

Nein, da nur in Methode Ja Wenige

Genau Eine

Klassenname, Konstruktor, sowie zusätzl. Methoden

StatischeEigenschaften

SpezielleZugriffsrechte

AnzahlInstanzen

Nested Class;vollwertige Klasse

Je nach ZugriffsmodifierKlassenmethoden Klassenvariablen

Klassenvariablen da keine Referenz

Member Class; gekoppelte Klasse

Je nach ZugriffsmodifierKeine, da nicht eigenständig

Klassenvariablen Instanzvariablen

Local ClassKeine, da nicht eigenständig

Klassenvariablen Instanz- und finale lokale

Variablen

Anonymous ClassNein, da kein Klassenname

Nein, da kein Klassenname

Keine, da nicht eigenständig

Klassenvariablen Instanz- und finale lokale

Variablen


Bereits aus Informatik 1 bekannt: JLabel, statische Anzeige von Text und Bildern(neu) JButton, Schaltfläche mit Text und Bildern(neu) JTextField, Einfaches Eingabefeld

Neue GUI Elemente JCheckBox, unabhängige Ja/Nein Auswahl JRadioButton, abhängige Ja/Nein Auswahl JSlider, Schieberegler horizontal oder vertikal JList, Listenanzeige

Neue Hilfsklassen Box, Vereinfachung für BoxLayout mit Struts und Glue BorderFactory, Erzeugung von verschiedenen Umrandungen ImageIcon, Anzeige von Bildern auf Labels und Buttons ButtonGroup, Verwaltung von RadioButtons JScrollPane, Verpackung von großen Komponenten, z.B. Listen

Details siehe Vorlesungsbeispiele, Java Buch, Java Tutorial und API-Referenz

Weitere GUI Elemente


Bei der Implementierung von GUIs in Java spielt das Konzept des Layout-Managers eine wichtige Rolle. Im Unterschied zu den Container Klassen von Swing, die Components "einfach nur enthalten" ist ein LayoutManager für die räumliche Anordnung bzw. Ausrichtung vom Components zuständig.

Entscheidend dabei ist, dass diese Anordnung (1) nach einem bestimmten Prinzip und (2) dynamisch erfolgt. Dadurch erleichtern LayoutManager die Erzeugung von bestimmten Anordnungen und sorgen dafür, dass das zugrundeliegende Layout-Prinzip auch bei Änderungen, z.B. der Fenstergröße, erhalten bleibt und tragen so zu Produktivität, Wartbarkeit und Ergonomie bei.

Jeder LayoutManager basiert auf einem Prinzip (Absolute, Flow, Box, Grid, GridBag). Komplexe Layouts beinhalten jedoch mehrere Prinzipien. Zu ihrer Realisierung werden verschiedene Komponenten bzw. deren LayoutManager kombiniert und verschachtelt. Dies plant sinnvollerweise vorab mit einer Skizze.

Vorgehensweise:Flacher Entwurf -> Hierarchische Zerlegung (Skizze) -> Implementierung

LayoutManager Revisited


NullLayoutcontainer.setLayout( null);component.setBounds( x, y, width, height);container.add( component);

Funktion manuelle absolute PositionierungHinweise Unflexibel, nur in Verbindung mit fester Fenstergröße sinnvoll

FlowLayoutcontainer.setLayout( new FlowLayout())

Funktion Komponenten "fließen" wie Wörter; Zeilen in sich zentriertHinweise Praktisch z.B. für Toolbars

BoxLayoutcontainer.setLayout( new BoxLayout( container, BoxLayout.Y_AXIS));container.add( component);

Funktion Komponenten werden (wie in einer Kiste) horiz. oder vert. gestapeltHinweise Für einfache Spalten/Zeilenstruktur

LayoutManager Zusammenfassung(1)


BorderLayoutcontainer.setLayout( new BorderLayout());container.add( component, BorderLayout.NORTH);

Funktion Einteilung des Containers in Zonen (NORTH..WEST, CENTER)Hinweise Als Top-Level Layout für Toolbar (NORTH), Statusbar (SOUTH), ...

GridLayoutcontainer.setLayout( new GridLayout( rows, cols));container.add( component); // Zeilenweise

Funktion Aufteilung des Containers als Gitter (alle Zellen gleich groß)Hinweise Für Tastenfelder oder Anzeigen (z.B. Taschenrechner)

GridBagLayoutcontainer.setLayout( new GridBagLayout());GridBagConstraints gbc = new GridBagConstraints();// gbc konfigurieren mit anchor, fill, gridx/y, weightx/y, ...container.add( component, gbc);

Funktion Aufteilung des Containers als flexibles GitterHinweise Mächtigstes aber auch aufwendigstes Layout, z.B. für Formulare



Weitere Layoutmanager (vgl. API Doku)

CardLayout, gestapelte Ebenen (nur eine sichtbar) OverlayLayout, gestapelte Ebenen (alle sichtbar) GroupLayout, (vertikales und horizontales Raster, für GUI Builder)

Panels mit besonderen Layout-Eigenschaften

JScrollPane, scrollbares Panel (für Tabellen, Bäume, ...) JTabbedPane, Panel mit Karteireitern JSplitPane, Panel mit flexibler horiz. oder vert. Aufteilung

Weitere Hinweise und Beispiele zu den einzelnen LayoutManagern finden sich Im Buch In der API-Doku der jeweiligen Klasse Im Java Tutorial



Tipps zum Aufbau von GUIsDie Wahrscheinlichkeit für Fehler steigt mit der Komplexität des Layouts. Deswegen: Layout vorher auf Papier planen um für jeden Bereich das am Besten geeignete und einfachste Layout auswählen zu können.

Bei der Verschachtelung von Layouts wirken inneres und äußeres Layout zusammen. Dabei können neue Fehler entstehen. Um diese zu vermeiden bzw. leichter finden zu können sind folgende Tipps hilfreich:

Layout Top-Down und Schritt für Schritt aufbauen Layouts/Panels nicht tiefer verschachteln als nötig Für jeden Teilbereich möglichst einfaches Layout wählen Zuerst Top-Level Layout mit Dummies (leeren Panels) testen Dabei Panels einfärben um das Verhalten besser beobachten zu können Dann Teilbereiche als eigene Methoden realisieren und einbauen Korrektheit jedes Teilbereichs zuerst in eigenem Fenster testen



Man kann Panels und Komponenten in einem Layout mischen, nicht jede Komponente muss in ein einzelnes Panel. Als Instanzvariablen müssen nur solche Komponenten realisiert werden, auf die später zugegriffen werden muss. Dies sind gilt normalerweise für Komponenten mit Inhalt/Zustand wie Eingabe- oder Auswahlfelder. Labels und Buttons kann man dagegen meist als lokale Variablen realisieren.

Das GridBagLayout ist am mächtigsten/flexibelsten aber auch am aufwendigsten und macht nur dann Sinn, wenn man (1) mehreren Komponenten hat und (2) diese in unterschiedlich großen Zellen unterbringen möchte oder (3) gezielt Einfluss auf das Verhalten beim Ändern der Fenstergröße nehmen möchte.

Hinweis zu GridBagConstraints:Das Attribut fill funktioniert nur im Zusammenspiel mit den Attributen weightx und weighty. Das Attribut fill regelt ob überschüssiger Platz auf die anderen Elemente verteilt wird, die Attribute weightx und weighty regeln wie der Platz auf die anderen Elemente verteilt wird. Der Standardwert ist weightx = weighty = 0, d.h. ohne explizite Zuweisung werden alle Elemente nicht angepasst.



Bei der Implementierung von GUIs hat sich das Prinzip der Aufteilung in Model (Datenspeicherung), View (Anzeige) und Controller (Eingabeverarbeitung) allgemein bewährt. In Java wird dieses Prinzip in der abgewandelten Form Model-ViewController angewandt.

Bei näherer Betrachtung der Klassenbibliothek fällt auf, dass sich dies bis auf die Komponentenebene durchzieht. So hat selbst jeder Button ein darunterliegendes AbstractButtonModel in dem bei ToggleButtons, CheckBoxes und RadioButtons der aktuelle Zustand gespeichert wird. Bei Controls wie Listen, Tabellen oder Bäumen ist die Notwendigkeit für ein Modell schon naheliegender.

Die Klassenbibliothek enthält Default-Modelle (Default<ControlTyp>Model), welche die normale Verwendung aller Controls abdecken. Diese sind oftmals von abstrakten Modellen (Abstract<ControlTyp>Model) abgeleitet. Daher muss man nur selten ein eigenes Modell völlig neu schreiben und nimmt somit die Trennung oftmals gar nicht wahr. Viele fortgeschrittene Möglichkeiten erschließen sich jedoch nur durch eigene Modelle. Dies gilt insbesondere für Tabellen und Bäume. Diese Controls benötigen fast immer ein eigenes Modell.

Model-View-Controller Revisited


Delegate

Kommunikationsschema bei MVC

View Controller

Model

Applikationslogik

get setevent

fire event setget

Benutzeranzeige Benutzereingaben Erläuterungen:

View und Controller bilden gemeinsam den Delegate. Dieser dient zur Interaktion des Benutzers mit dem damit verknüpften und als Referenz gespeicherten Modell.

Die View liest Daten über get-Methoden vom Modell, führt ggf. Updates mit Hilfe von set-Methoden durch und wird über events über Änderungen informiert

Der Rest der Applikation kann ebenfalls über get- und set-Methoden auf das Modell zugreifen. Dabei werden ggf. Events durch das Modell ausgelöst (dies ist bei eigenen Modellen zu beachten, vgl. z.B. AbstractTableModel). In Ausnahmefällen kann ein Event jedoch auch explizit ausgelöst werden.


Listboxes (JList) zur reinen Anzeige können einfach mit Arrays befüllt werden. Ein eigenes ListModel ist nur nötig, wenn die Liste dynamisch verändert werden soll.

Beim Einsatz von Tabellen (JTable) muss mit Ausnahme von trivialen Tabellen mit Standarddatentypen ein eines eigenen TableModel implementiert werden, um Zeilen und Spalten in der Tabelle auf Fachobjekte und deren Attribute abzubilden.

Auch bei Bäumen (JTree) ist Handarbeit notwendig, u.a. zum Aufbau der Baumstruktur samt Inhalt vor der Übergabe im Konstruktor. Dazu dienen in den meisten Fällen Instanzen der Klasse DefaultMutableTreeNode, in die beliebige eigene Objekte als Inhalt eingehängt werden können. Alternativ kann ein geschlossenes TreeModel ähnlich zu TableModel definiert werden. Eine Übergabe der Daten als geschlossenes Objekt (z.B. Array) wie bei Listen und Tabellen ist hier jedoch aufgrund der strukturellen Komplexität nicht möglich.

Die Objekte in Listboxen, Tabellen und Bäumen werden stets mit Hilfe der Methode toString() angezeigt. Diese muss also in geeigneter Weise implementiert werden.

Auch die anderen Controls wie Buttons (JButton) oder Textfelder (JTextField) arbeiten übrigends mit Modellen – nur sieht und braucht man sie nicht so oft!

Modelle für Listen, Tabellen und Bäume


Die Struktur der Modelle wird in der Klassenbibliothek durch entsprechende Interfaces definiert, z.B. ListModel. Zu diesen gibt es i.d.R. eine Default-Implementierung, z.B. DefaultListModel, welche die meisten Anwendungsfälle abdeckt.

Allen Modellen gemein ist, dass die im zugehörigen Interface beschriebenen Methoden streng auf die Bedürfnisse des zugehörigen Controls zugeschnitten sind. Dies kann man an den Modellen für Listboxes, Tabellen und Bäume sehr schön erkennen:

Eine Listbox dient primär der Anzeige, deshalb enthält das zugehörige Modell nur die lesenden Methoden getSize() und getElementAt(). Deswegen kann man über das Listbox-interne "Not-Modell" auch keine Elemente hinzufügen oder löschen!

Tabellen können editiert werden, deshalb umfasst ihr Modell neben lesenden auch schreibende Methoden und auch die Strukturbeschreibung erfordert mehrere Methoden: getColumnNames(), getColumnCount(), getRowCount(), getValueAt(), setValueAt(), isColumnEditable().

Bei Bäumen ist das Modell verrückterweise wieder einfacher, da Bäume nicht editiert werden können und eine einfache rekursive Struktur haben: getRoot(), getChildCount(), getChild() sowie getIndexOfChild() und isLeaf().




Liste Tabelle Baum

Verwendungszweck

AnpassbarkeitBasisfunktionalität nur Anzeige/Selektion Anzeige/Selektion, Pflege Anzeige/Selektion

Erweiterte Funktionalität keine

Struktur

Zugriff Index Zeile, Spalte PfadangabeGUI Element

Basisklasse

Implementierung

Auflistung von Objekten, z.B. über ihren Namen

Auflistung von Objekten inkl. ihrer Eigenschaften

Darstellung hierarchisch strukturierter Objekte

Renderer Renderer, Editor Renderer, Editor

Spalten vertauschenSortieren, Filtern

Knoten auf-/zuklappen

Eindimensionale Liste von Objekten

Zweidimensionale Matrix aus Zeilen und Spalten. Dabei entsprechen Zeilen verschiedenen Objekten und die Spalten deren Eigenschaften (mit einem gleichartigen Datentyp)

Rekursive Struktur von Objekten in Vater-Kind Beziehung. Ein Vater kann mehrere Kinder haben, jedes Kind hat genau einen Vater.

JList JTable JTree

Modelschnittstelle ListModel TableModel TreeModelTreeNode

AbstractListModel AbstractTreeModelDefaultListModel DefaultTreeModel DefaultTreeModel,

DefaultMutableTreeNode

Gegenüberstellung von Liste, Tabelle und Baum


Um das Erscheinungsbild von Listenelementen, Tabellenzellen und Baumknoten zu beeinflussen werden sog. Renderer und Editoren verwendet. Dies sind im Grunde gewöhnliche Oberflächenelemente die bei der Tabelle bzw. dem Baum registriert oder aus überladenen Methoden zurückgeliefert werden. Diese werden jedoch nicht für jedes Element einzeln instanziiert. Stattdessen dient ein einziger Renderer als "Stempel" zur sukzessiven Darstellung aller Elemente. Der Editor wird an der jeweils ausgewählten Stelle eingeblendet.

Damit ergibt sichfolgende Struktur

Für Tabellen existiert ein Default Renderer und ein Default Editor die intern abhängig vom Datentyp einer Zelle verschiedene Komponenten verwenden. Der Default Renderer verwendet normalerweise ein Label und der Default Editor ein Textfield. Mit diesen Komponenten können Zellen mit Strings dargestellt bzw. editiert werden. Für boolsche Werte wird dagegen eine Checkbox zur Anzeige und Editierung verwendet. Bei Bäumen besteht der Default Renderer neben einem Label zusätzlich aus einem Icon.

Renderer und Editoren

View

Renderer

Editor

Model


Entwurfsmuster (Patterns) dienen wie Bibliotheken (Libraries) der Wiederverwendung und damit der Erhöhung der Produktivität und der Vermeidung von Fehlern. Im Unterschied zu Bibliotheken können Entwurfsmuster jedoch nicht durch direkten Einbau wiederverwendet werden.

Fasst man eine Bibliothek als Sammlung von Bausteinen(=Lösungen) auf, so entspricht ein Entwurfsmuster einer Bauanleitung(=Lösungsweg) die für individuelle Probleme einer bestimmten Klasse verwendet und angepasst werden kann. Anpassungen, die nur die Typisierung betreffen, lassen sich in anderen Programmiersprachen durch die Unterstützung von Schablonen (Templates) automatisieren. Dies gibt es in Java erst seit Version 5.

Durch die Notwendigkeit zur immer neuen Implementierung scheinen Entwurfsmuster zunächst gegenüber Bibliotheken im Nachteil zu sein. Tatsächlich kann die damit verbundene Flexibilität aber auch ein Vorteil sein. Die größte Stärke von Entwurfsmustern liegt jedoch in ihrer Anwendbarkeit für Architekturen. Bibliotheken sind dagegen meist auf Funktionen beschränkt und reichen nur als Frameworks in den Bereich der Architekturen hinein.

Entwurfsmuster (Patterns) und Schablonen (Templates)


Das Observer-Pattern wird in Java im Zusammenhang mit Listern an vielen Stellen eingesetzt. Grundidee dieses Patterns ist die Kommunikation zwischen zwei Objekten, deren Klassen sich nicht gegenseitig kennen (sollen).

Dabei tritt das eine Objekt als Datenquelle und das andere als Beobachter derselben auf. Die Abhängigkeit geht daher stets vom Beobachter zur Datenquelle, nicht umgekehrt. Viele Beobachter können an derselben Datenquelle interessiert sein.

Die Implementierung dieses Patterns in Java basiert stets auf einem Interface: Das Interface definiert Methoden zur Informationsübertragung Der Beobachter implementiert dieses Interface Die Datenquelle ruft diese Methoden auf

Die Kontaktaufnahme erfolgt über eine Methode zur Registrierung von Beobachtern bei der Datenquelle. Dabei sieht die Datenquelle von jedem Beobachter nur das Interface, muss die wahre Klasse also nicht kennen. Zum Transport der Information wird oftmals ein eigenes (Event-)Objekt übergeben. Dies ist jedoch nicht zwingend notwendig.

Das Observer-Pattern


Obwohl in Java beide vorrangig für GUIs eingesetzt werden basieren sowohl Modelle als auch Events auf allgemeinen Prinzipien:

Modell: "Ich verwalte Daten und kommuniziere deren Veränderungen" Event: "Ich repräsentiere eine Information über ein Ereignis"

Man kann diese Prinzipien z.B. im Rahmen des Observer-Patterns auch für andere Dinge äußerst sinnvoll einsetzen. Diesem Umstand wurde z.B. in der Programmiersprache Smalltalk dadurch Rechnung getragen, dass es direkt unter Object eine allgemeine Klasse mit dem Namen Model gab. In Java gibt es stattdessen eine Klasse Observable sowie ein Interface Observer.

Das Beispiel zum Model-View-Controller in Informatik 1 war also ein Sonderfall: Im Allgemeinen kann man in Java sehr leicht verschiedene GUIs auf dasselbe Model aufsetzen. Die Umstellung einer textbasierten Anwendung erfordert aber i.d.R. die Anpassung fundamentaler Datenstrukturen auf entsprechende Modelle. So ist es z.B. nicht möglich, ein gewöhnliches Array dynamisch mit einer Listbox zu verbinden. Dafür ist ein DefaultListModel nötig.

Beobachtungen


Java kann in verschiedenen Anwendungsbereichen eingesetzt werden. Dazu existieren verschiedene Java Umgebungen:

J2SE (Standard Edition), für Desktop Anwendungen J2EE (Enterprise Edition), für Webapplikationen mit Datenbanken J2ME (Micro Edition), für mobile Geräte wie PDAs und Handys

Diese unterscheiden sich im wesentlichen von der mitgelieferten Laufzeitumgebung bzw. Klassenbibliothek wobei J2EE eine Erweiterung und J2ME ein Subset von J2ME ist.

Während die virtuelle Maschine stets hauptsächlich der Abstraktion von der Hardware realisiert dient bei J2ME die Klassenbibliothek explizit zur Entkopplung der Applikation von dem jeweiligen Betriebssystem. Dazu sind im Rahmen des MIDP (Mobile Information Device Profile) verschiedene Basisdienste standardisiert, die von den unterschiedlichen Geräteherstellern implementiert werden müssen. Zusammen mit CLDC unterstützt MIDP sowohl die Realisierung von Oberflächen als auch gerätespezifische Dienste wie den Versand von SMS.

Exkurs: J2ME und MIDP(1)


Die Entwicklung von J2ME Applikationen kann entweder mit dem Wireless Toolkit (WTK) von Sun oder einem Plugin für eine Entwicklungsumgebung, z.B. Netbeans erfolgen. Beide beinhalten neue Compiler, Debugger sowie ein Emulationswerkzeug mit dem die Applikation auf dem PC getestet werden kann.

Aufgrund der beschränkten Rechenleistung und Resourcen mobiler Geräte werden darin Schritte wie die Codeprüfung in den Compilationsschritt verlagert und der Umfang der Laufzeitumgebung ist stark eingeschränkt. So stehen z.B. keine floating-Point Operationen zur Verfügung.

In Anlehnung an Applets werden J2ME Applikation als Midlets bezeichnet. Sie werden in als .jar-File verteilt und durch ein separates .jad-File beschrieben. Sinn des .jad-Files ist die kompakte Beschreibung der Applikation als Entscheidungsgrundlage für einen möglicherweise kostspieligen Download. Beide Files zusammen bilden eine sog. Midlet Suite (siehe Vorlesungsbeispiel).

Details zur J2ME Entwicklung siehe die Dokumentation zum WTK und MIDP.



Gegenüberstellung von Oberflächen: Desktop/Applets/Midlets

Desktop Applet Midlet

Startmethode main() init()/start() startApp()

Hauptklasse JFrame JApplet Midlet

Container Container Container ScreenJPanel JPanel Form... ... Canvas

Komponenten JComponent JComponent ItemJLabel JLabel StringItemJTextfield JTextfield TextFieldJRadioButton JRadioButton ChoiceGroup... ... ...



Gegenüberstellung von Oberflächen: Desktop/Applets/Midlets

Desktop Applet Midlet

Interaktion JButton JButton Command

Observer ActionListener ActionListener CommandListener[am Button] [am Button] [am Screen]

Zeichnen paint(Graphics) paint(Graphics) paint(Graphics)

Sonstiges:Bei Desktop und Applet volle Kontrolle über Inhalte sowie Layout/MenüstrukturBei Midlet nur Inhalte und automatische Umsetzung gemäß Plattformphilosophie



Moderne Betriebssysteme unterstützen die quasi gleichzeitige Ausführung mehrerer Programme. Diese wird erreicht, indem die Rechenzeit des Prozessors zeitlich unter diesen Programmen aufgeteilt wird. Die Programme (inkl. dem Betriebssystem selbst) wechseln sich so schnell ab, das der Eindruck der Gleichzeitigkeit entsteht. Für echt gleichzeitige Ausführung mehrerer Programme sind mehrere Prozessoren erforderlich. Weitere Voraussetzung für die gleichzeitige Ausführung mehrerer Programme ist deren Unabhängigkeit.

Parallele ablaufende Programme werden vom Betriebssystem als sog. Prozesse verwaltet. Zur Aufteilung der Rechenleistung gibt es verschiedenen Verfahren:

● Batch Betrieb (keine Aufteilung)● Timesharing (feste Zeitscheiben)● Prioritätsgesteuert (wichtige Programme zuerst/öfter)● Kooperation (Programme geben Prozessor freiwillig ab)

Scheduling Verfahren, bei denen einem Programm der Prozessor "unfreiwillig" entzogen wird, nennt man preemptive.

Threads – Hintergrund


Beim Wechsel zwischen zwei Prozessen (Kontextwechsel, engl. context switch) muss deren Zustand gesichert bzw. wiederhergestellt werden. Der dazu notwendige Aufwand führt zu "Reibungsverlusten" die umso größer sind, (1) desto größer der Kontext ist und (2) je öfter gewechselt wird.

Bei Betriebssystemprozessen umfasst der Kontext

● Stack● Programmzähler● Inhalt der Prozessorregister● Allokierte Betriebsmittel● Arbeitsspeicher des Prozesses● Programmcode des Prozesses

Das ist eine ganz Menge, weswegen Betriebssystemprozesse auch als schwergewichtige Prozesse bezeichnet werden.



Bei neueren Betriebssystemen ist eine zeitliche Aufteilung auch innerhalb eines Programms möglich. Dabei laufen mehrere Kontrollflüsse (Threads) quasi-parallel ab, teilen sich jedoch den Programmcode und den Arbeitsspeicher. Sie werden daher als leichtgewichtige Prozesse bezeichnet. Auch Java bietet Threads an und bildet Sie wenn möglich auf Betriebssystemthreads ab.

Die gemeinsamen Ressourcen der Threads erleichtern die Umschaltung, können jedoch auch zu Konflikten führen. Daher sind ggf. besondere Synchronisationsmaßnamen notwendig.


Prozess 1 Prozess 2Prozess 3

Stack Stack Stack StackProgrammzähler Programmzähler Programmzähler ProgrammzählerProzessorregister Prozessorregister Prozessorregister Prozessorregister

Betriebsmittel Betriebsmittel BetriebsmittelArbeitsspeicher Arbeitsspeicher ArbeitsspeicherProgrammcode Programmcode Programmcode

Thread 1 Thread 2

heavyweight heavyweight lightweight



Zustandsübergänge

Ähnlich für Prozesse und Threads.

Sowohl vorhandene als auch nicht vorhandene Übergänge sind für das Verständnis interessant!

kill

ready-to-run

runningblocked

dead

unknown

schedulepreempt

block

release

finish/killkill

create


In Java werden Threads mit Hilfe der Klasse Thread implementiert und gesteuert. Zustandsübergänge werden durch die virtuelle Maschine gesteuert und können über Methodenaufrufe und spezielle Ereignisse beeinflußt werden.

Erzeugung● Möglichkeit 1: Eigene Klasse von Thread ableiten und run() überschreiben● Möglichkeit 2: Thread-Objekt erzeugen und Runnable Objekt übergeben

Starten● Aufruf von t.start()

Unterbrechen/Pausieren● Aufruf von t.yield()● Aufruf von t.sleep() // kann InterruptedException werfen, siehe unten

Abbrechen/Beenden● Aufruf von t.interrupt() // wirft InterruptedException „in den Thread“● Ablauf der run()-Methode

Threads – Implementierung


public class ThreadExample extends Thread {

public void run() { for (int i=0; i<10; ++i) { System.out.print( "T"); yield(); } }

public static void main(String[] args) { Thread t1 = new ThreadExample(); Thread t2 = new Thread( new Runnable() { public void run() { for (int i=0; i<10; ++i) { System.out.print( "R"); yield(); } } }); t1.start(); t2.start(); for (int i=0; i<10; ++i) { System.out.print( "M"); yield(); } }}

Threads – Beispiel 1


public class Sleeper {

public static void main(String[] args) { for (int i=0; i<10; ++i) { System.out.print( "M"); try { Thread.sleep(1000); } catch (InterruptedException ex) { } } }}



In Programmen mit einer graphischen Oberfläche existiert ein separater Thread für GUI Aktualisierung und GUI Events (z.B. Listener). Dieser arbeitet in einer Endlosschleife alle GUI Ereignisse ab und darf nicht für andere Aufgaben genutzt werden, da sonst u.U. die Benutzeroberfläche (zeitweise) blockiert wird! Im Umkehrschluss sollte kein normaler Thread direkt auf die Benutzeroberfläche zugreifen (Ausnahmen sind nur vor der Anzeige der Oberfläche möglich!).

Kopplung/Entkopplung GUI->Non: Neuer Thread, z.B. SwingWorker Non->GUI: SwingUtilities.invokeLater()

Das Java Tutorial enthält weitere interessante Hinweise zum Thema!!!

Threads – GUI Thread

AnyThreadAnyThreadAnyThread

GuiThreadEvent-Queue

GUI

Events einstellenz.B. repaint() Events abarbeiten

GUI bearbeiten


import java.awt.event.*;import javax.swing.*;

public class EventThreadDemo extends JFrame { public EventThreadDemo() { JButton button = new JButton( "Klick!"); button.addActionListener( new ActionListener() { public void actionPerformed( ActionEvent e) { Thread worker = new Thread( new Runnable() { public void run() { // do something that takes long } }); worker.start(); } }); getContentPane().add( button); pack(); }

public static void main(String[] args) { SwingUtilities.invokeLater( new Runnable() { public void run() { new EventThreadDemo().setVisible( true); } }); }}



Zweck der Synchronisation Ablaufsteuerung / Koordination von Threads Schutz kritischer Abschnitte (Bearbeitung gemeinsamer Daten)

Instrumente zur Ablaufsteuerung sleep() - festgelegte Zeit abwarten wait()/notify() - einschläfern und aufwecken von Threads join() - Rendezvouz (Staffelholz-Übergabe) yield() - Prozessor freiwillig abgeben

Instrumente zum Schutz kritischer Abschnitte ( z.B. ConcurrentModification) synchronized Abschnitt (mit beliebigem Monitorobjekt) synchronized Methoden (für aktuelles Objekt) gemeinsam benutzte Attribute (neuer Modifier "volatile")

Methoden bzw. Klassen, die diese Schutzmechanismen verwenden nennt man reentrant (mehrfach betretbar) bzw. thread-safe (Thread-sicher).

Da die Absicherung Zeit kostet aber nicht immer notwendig ist, gibt es in der Klassenbibliothek von einigen Klassen zwei Varianten (z.B. ArrayList/Vector).

Threads – Synchronisation


import java.awt.*;import java.awt.event.*;import javax.swing.*;import java.util.*;

public class DigitalClock extends JFrame {

JLabel timeLabel = new JLabel( "12:00:00");

public DigitalClock() { super( "DigitalClock"); setDefaultCloseOperation( EXIT_ON_CLOSE); timeLabel.setFont( new Font( "Arial", Font.BOLD, 64)); add( timeLabel); pack(); } public static void main( String[] args) throws InterruptedException { DigitalClock clock = new DigitalClock(); clock.setVisible( true);

while ( true) { GregorianCalendar cal = new GregorianCalendar (); int h = cal.get( Calendar.HOUR); int m = cal.get( Calendar.MINUTE); int s = cal.get( Calendar.SECOND); StringBuilder sb = new StringBuilder(); if ( 0==h) h = 12; if ( h<10) sb.append( '0'); sb.append( Integer.toString( h)); sb.append( ":"); if ( m<10) sb.append( '0'); sb.append( Integer.toString( m)); sb.append( ":"); if ( s<10) sb.append( '0'); sb.append( Integer.toString( s)); clock.timeLabel.setText( sb.toString()); Thread.sleep( 1000); } }}

Threads – Beispiel: Digitaluhr


import java.awt.*;import java.awt.event.*;import javax.swing.*;import java.util.*;

public class AnalogClock extends JFrame {

public AnalogClock() { super( "AnalogClock"); setDefaultCloseOperation( EXIT_ON_CLOSE); add( new JComponent() { public void paint( Graphics g) { super.paint(g); GregorianCalendar cal = new GregorianCalendar (); int hh = cal.get( Calendar.HOUR); int mm = cal.get( Calendar.MINUTE); int ss = cal.get( Calendar.SECOND);

int dx, dy; int w = getWidth(); int h = getHeight(); g.fillOval( w/2-10, h/2-10, 20, 20); // draw sec hand dx = (int)(w/3 * Math.sin( 2*Math.PI/60*ss)); // lt. trigonometrischer Betrachtung am Kreis (Bogenmaß)! dy = (int)(w/3 * Math.cos( 2*Math.PI/60*ss)); // lt. trigonometrischer Betrachtung am Kreis (Bogenmaß)! g.drawLine( w/2, h/2, w/2+dx, h/2-dy); } }); setSize( 400, 400); }

public static void main( String[] args) throws InterruptedException { AnalogClock clock = new AnalogClock(); clock.setVisible( true); while ( true) { clock.repaint(); Thread.sleep( 1000); } }}

Threads – Beispiel: Analoguhr (Fragment)


import java.awt.*;import java.awt.event.*;import javax.swing.*;

public class GuiThreadDemo extends JFrame {

public GuiThreadDemo() { super( "GuiThreadDemo"); setDefaultCloseOperation( EXIT_ON_CLOSE);

setLayout( new FlowLayout()); ActionListener dauerListener = new ActionListener() { public void actionPerformed( ActionEvent e) { final JProgressBar progressBar = new JProgressBar(0, 100); final JDialog dialog = new JDialog( GuiThreadDemo3.this, true); dialog.setLayout( new FlowLayout()); dialog.add( progressBar); JButton abortButton = new JButton( "abort");

final Thread worker = new Thread() { public void run() { try { for ( int i=0; i<=100; ++i) { final int j = i; Thread.sleep( 50); SwingUtilities.invokeLater( new Runnable() { public void run() { progressBar.setValue( j); } }); } System.out.println( "Fertig!"); } catch ( InterruptedException ex) { // will never happen } finally { dialog.dispose(); } } };

Threads – Beispiel: Dialog mit Fortschrittsanzeige(Teil 1)


abortButton.addActionListener( new ActionListener() { public void actionPerformed( ActionEvent e) { System.out.println( "Button geklickt!"); worker.interrupt(); } }); dialog.add( abortButton); dialog.addWindowListener( new WindowAdapter() { public void windowClosing( WindowEvent e) { System.out.println( "Fenster gekillt!"); worker.interrupt(); } }); dialog.pack();

worker.start(); dialog.setVisible( true); } }; JButton button1 = new JButton( "Dauerlauf 1"); button1.addActionListener( dauerListener); add( button1); pack(); } public static void main( String[] args) { new GuiThreadDemo3().setVisible( true); }}

Threads – Beispiel: Dialog mit Fortschrittsanzeige(Teil 2)


Weitere Anwendungsbeispiele:● Produzenten / Konsumenten (fehlt noch)

Threads – Beispiele


Alle Programme verarbeiten Daten in irgendeiner Form. Diese Daten sollen in der Regel über die Lebensdauer des Programms hinaus gespeichert werden. Damit ist die dauerhafte Speicherung von Daten eine immer wiederkehrende Aufgabenstellung. Man spricht in diesem Zusammenhang auch von Persistenz (engl. to persist = continue to exist).

Prinzipiell gibt es viele Möglichkeiten, Daten zu speichern. Eine davon, die Serialisierung von Objekten haben wir bereits kennengelernt. Mit zunehmender Datenmenge steigen jedoch sowohl die Anforderungen an die Speicherung (Stichwort Transaktionen) als auch an die Geschwindigkeit des Zugriffs auf die gespeicherten Daten. Damit steigt auch die Komplexität der zugehörigen Mechanismen bzw. Algorithmen. Simple Verfahren stoßen hier an Ihre Grenzen.

Datenbanken sind auf die Funktionen Datenspeicherung und Datenzugriff spezialisierte (und hoch komplexe) Programmsysteme. Sie gestatten die Wiederverwendung von über Jahre gewachsenem Wissen und ausgereiften Algorithmen in verschiedensten Anwendungsbereichen und sind heute für jedermann erschwinglich und verfügbar (z.B. Access, mySQL)!

Datenbanken und JDBC(1) - Motivation


Moderne (Web)Applikationen folgen typischerweise einer 3-Schicht Architektur:

Grundlage dieser Aufteilung sind definierte Schnittstellen zwischen den Komponenten. Hintergedanken dabei sind wie bei Objekten die Spezialisierung und Wiederverwendbarkeit bzw. Austauschbarkeit von Komponenten einer Schicht sowie die Möglichkeit zur Lastverteilung durch Einsatz verschiedener Rechner. Da es sich jedoch zunächst um eine logische Aufteilung handelt können auch mehrere Komponenten auf einem Rechner betrieben werden.

Datenbanken und JDBC(2) – 3 Tier Architektur

Presentation

Application

Persistence

(Webserver)

(Applicationserver)

(Datenbankserver)


Allgemein gesprochen sind Daten typischerweise in Datensätzen organisiert (z.B. eine Person, ein Artikel, ...). Diese entsprechen den Objekten in der Software. In relationalen Datenbanken wird die Darstellung von Daten mit Hilfe von Tabellen (mathematisch) formalisiert. Jedoch lassen sich Objekte eigentlich nicht formal exakt auf Tabellen abbilden (u.a. wegen der Vererbung).

Es gibt jedoch eine Abbildung, die für Praxis ausreichend ist: Dabei entspricht eine Tabelle einer Art von Datensätzen sprich einer Klasse. Eine Zeile entspricht einem Objekt dieser Klasse und die Spalten der Tabelle bilden dessen Attribute ab (vergleiche dazu die Visualisierung von Objekten mit Swing-Tabellen).

Die eindeutige Identität eines Objekts (vgl. Informatik 1) muss über ein spezielles Attribut (Primärschlüssel) abgebildet werden. Kann diese Eindeutigkeit nicht über ein oder mehrere der vorhandenen Objekte dargestellt werden, muss ein neues Attribut eingeführt werden (typischerweise eine Nummer, z.B. Matrikelnummer, Personalnummer, Artikelnummer, ...). Der Primärschlüssel dient auch zur Speicherung von Verweisen zwischen Objekten A->B (Fremdschlüssel). Dazu gibt es in der Tabelle A eine Spalte, die den Primärschlüssel der Tabelle B enthält.

Datenbanken und JDBC(3) - Datenorganisation


Datenbanken und JDBC(4a) – Beispiel 1

:A

:B

1

1

A1:A

A2:A

A3:A

:A

:B

B1:B

B2:B

Tabelle A

1 A1 22 A2 13 A3 NULL

Tabelle B

1 B12 B2

idA name idB

idB name

Klassenmodell Konkrete Objektbeziehungen Datenmodell Konkrete Werte

Bei einer 1:1 Beziehung sind Klassenmodell und Datenmodell strukturell identisch. Der Verweis kann wahlweise in der einen oder der anderen Tabelle abgelegt werden.

1

1


Datenbanken und JDBC(4b) – Beispiel 2

:A

:B

1

n

A1:A

A2:A

A3:A

:A

:B

B1:B

B2:B

Tabelle A

1 A12 A23 A3

Tabelle B

1 B1 12 B2 1

idA name

idB name idA


Bei einer 1:n Beziehung sind Klassenmodell und Datenmodell immer noch strukturell identisch. Der Verweis muss jedoch auf der n-Seite der Beziehung abgelegt werden (viele verweisen auf einen), da in jeder Tabellenzelle nur ein Wert abgelegt werden kann (sog. 1ste Normalform).

1

n


Datenbanken und JDBC(4c) – Beispiel 3

:A

:B

n

m

A1:A

A2:A

A3:A

:A

:AB

:B

B1:B

B2:B

Tabelle A

1 A12 A23 A3

Tabelle AB

1 11 22 13 13 2

Tabelle B

1 B12 B2

id name

idA idB

idB name


Bei einer n:m Beziehung kann die strukturelle Identität zwischen Klassenmodell und Datenmodell nicht mehr aufrechterhalten werden. Da in jeder Tabellenzelle nur ein Wert abgelegt werden kann müssen die Verweise in einer neuen Zwischentabelle abgelegt werden. Diese transformiert die n:m Beziehung in eine n:1 Beziehung und eine 1:m Beziehung.

n

m

1

1


Datenbanken und JDBC(4d) – Beispiel 4

Objekte Tabellen

:Auftrag AuftragAuftragsnummer #Auftragsnummer DatumDatum

:Position PositionPositionsnummer #%Auftragsnummer #Positionsnummer Anzahl %ArtikelnummerAnzahl

:Artikel ArtikelArtikelnummer #Artikelnummer Bezeichnung PreisBezeichnungPreis

1..n

Dieses Beispiel zeigt nochmals die Implementierung von Beziehungen sowie die Verwendung von fachlichen Primärschlüsseln. Dabei erhält die Auftragsposition einen zusammengesetzten Primärschlüssel. Eine Verwendung von zusammengesetzten Fremdschlüsseln ist aus Aufwandsgründen nicht sinnvoll. Wird auf eine Tabelle mit einem zusammengesetzten Schlüssel verwiesen ist es daher sinnvoll, einen einfachen technischen Primärschlüssel einzuführen.

zusammengesetzter PrimärschlüsselFremdschlüssel

FremdschlüsselPrimärschlüssel

Primärschlüssel


JDBC-Treiber

ODBC-Treiber

Der Zugriff auf relationale Datenbanken ist prinzipiell über die Abfragesprache SQL (Structured Query Language) standardisiert. Die Standardisierung von SQL umfasst jedoch nur die eigentlichen Kommandos, nicht jedoch die Schnittstelle zum Austausch von Kommandos und Resultaten. Die technische Schnittstelle und deren Einbindung in eine Programmiersprache ist also zunächst herstellerspezifisch (proprietär, engl. proprietor = owner). Zur Überwindung dieser Hürde existieren weitere Standards, namentlich ODBC (Open Database Connection) und JDBC (Java Database Connection).

Speziellere Treiber bieten i.d.R. zusätzliche Funktionalität und höhere Effizienz.

Datenbanken und JDBC(5) – Datenzugriff / SQL

X-Datenbank

X-Treiber


Tabelle erzeugenCREATE TABLE person (

id INT NOT NULL PRIMARY KEY,name VARCHAR(30) NOT NULL,vorname VARCHAR(39) NOT NULL

)

Datensatz einfügenINSERT INTO person (id, name, vorname) VALUES (5, 'Meier', 'Klaus')

Datensatz aktualisierenUPDATE person SET name = 'Maier' WHERE id = 5

Datensatz abfragenSELECT * FROM person WHERE name = 'Maier'

Datensatz löschenDELETE FROM person WHERE id = 5

Tabelle löschenDROP TABLE person

Datenbanken und JDBC(5) – Datenzugriff / SQL


Zum Zugriff auf eine Datenbank aus einem Java Programm werden die Klassen bzw. Interfaces im Paket javax.sql sowie ein JDBC Treiber (dieser implementiert die speziellen Klassen bzw. Interfaces für eine Datenbank) benötigt.

Der Ablauf ist dabei stets wie folgt: Treiber registrieren Verbindung zur Datenbank herstellen Befehl(e) erzeugen Befehl(e) abschicken Ergebnisse bearbeiten

Die dabei verwendeten Interfaces sind DriverManager Connection Statement bzw. PreparedStatement ResultSet

Datenbanken und JDBC(5) – Prinzip der Einbindung in Java


Class.forName( "sun.jdbc.odbc.JdbcOdbcDriver"); // Treiber ladenConnection con = DriverManager.getConnection(

"jdbc:odbc:personal", // Datenbank URL"administrator", // Benutzername"geheim" // Passwort

);Statement stmt = con.createStatement(); // Statement erzeugenint result = stmt.executeUpdate( // Update durchführen "INSERT INTO person (id name vorname)" + "VALUES (2, 'Meier', 'Klaus')");ResultSet rs = stmt.executeQuery( // Abfrage durchführen "SELECT id name vorname FROM person WHERE name = 'Meier'");while (rs.next()) { // Über Ergebnisse iterieren (je eine Zeile) int id = rs.getInt(1); String name = rs.getString(2); String vorname = rs.getString(3); // Ergebnisse verwenden}stmt.close();con.close();

Datenbanken und JDBC(6) – Beispielprogramm (Auszug)


Datenbanken und JDBC(7) – Fachklassen

Bei der Arbeit mit Datenbanken kann man folgendermassen vorgehen

Definition von Fachklassen (z.B. Person) mit entsprechenden Instanzvariablen Abbildung der Fachklassen auf Tabellen mit Instanzvariablen als Spalten

Beim Zugriff auf die Datenbank werden üblicherweise stets ganze Objekte einer Fachklasse gelesen oder geschrieben. Dies hat den Vorteil, dass man innerhalb des Programms bequem mit den Fachobjekten arbeiten kann.

Um die Fachklassen dabei unabhängig von der verwendeten Datenbank- bzw. Speichertechnologie zu halten wird dabei der eigentliche Datenbankzugriff üblicherweise in einer separaten Klasse durchgeführt. Dies kann in einfachen Programmen eine oder mehrere spezielle Klassen (DAOs) mit Methoden wie

Person fetchPerson( <Primärschlüssel>) void storePerson( Person p)

sein. Bei vernetzten Objekten mehrere fetch- und store-Methoden gegenseitig hintereinander aufrufen um ein ganzes Objektnetz zu laden oder zu speichern.


Datenbanken und JDBC(8) – Fachklassen

public class Person { public class Adresse {int id; int id;String name; String strasse;String vorname; String postleitzahl;Adresse adresse; String ort;

} }

public class Database {

public Person fetchPerson( <Primärschlüssel>) { // ... ResultSet rs = statement.executeQuery( ...); int id = rs.getInt( "id"); String name = rs.getString( "name"); // ... int addressId = rs.getInt( "address_id"); return new Person(

id,name,vorname,fetchAdresse( addressId) // Kaskadierung:

); // outside-in beim lesen } // inside-out beim schreiben

}


*** fehlt noch ***

Datenbanken und JDBC(9) – Java Persistence Architecture (JPA)


Vor wenigen Jahren noch die Ausnahme, heute quasi Standard: Die Vernetzung von Rechnern. Damit verbunden sind neue Möglichkeiten wie der weltweite Zugriff und Austausch von Daten aber auch neue Herausforderungen wie die Realisierung verteilter Anwendungen oder die Gefahren durch böswillige Anwender und -Programme.

Netze können nach verschiedenen Kriterien klassifiziert werden: Geographische Ausdehnung (LAN, WAN, ...) Topologie (Bus, Stern, Netz, Ring, ...) Hardware/Verkabelung (Ethernet, WLAN, ISDN, DSL über Koax, Twisted Pair, ...) Software/Protokoll (TCP/IP, NetBios, IPX, AppleTalk, ...)

Größere (Firmen)netze sind i.d.R. in Segmente unterteilt, die durch besondere Hardwarekomponenten verbunden sind:

Hub, "Mehrfachsteckdose", verteilt alles an alle Switch "Intelligente Mehrfachsteckdose" – verteilt gezielt an angeschlossene Stationen Router "Mehrfachsteckdose mit Weitblick" – verteilt auch über Zwischenstationen Bridge "aktives Verlängerungskabel" – leitet Signale weiter und verstärkt sie.

Netz heisst also nicht immer Internet; verteilte Applikationen gibt es nicht nur im Browser.

Netzwerke – Grundlagen


Ein Modell zur einheitlichen Beschreibung und leichteren Vergleichbarkeit von Netzen

Verbindungskomponenten benötigen nur Schichten 1-3

Protokolle auf Schicht 4 können unterschieden werden verbindungsorientiert (wie Telefon), Bsp. TCP paketorientiert (wie Post), Bsp. UDP

Die TCP/IP Protokollfamilie beinhaltet sowohl ein verbindungsorientiertes Protokoll (TCP) und ein paketorientiertes Protokoll (UDP) die beide(!) auf dem paketorientierten Protokoll (IP) in Schicht 3 basieren.

Zum detaillierteren Vergleich ISO/OSI vs TCP/IP siehe Wikipedia, OSI-Modell (de.wikipedia.org/wiki/OSI-Modell

Netzwerke – ISO/OSI Referenzmodell

Rechner 1 Rechner 2

Schicht 7Schicht 6Schicht 5Schicht 4Schicht 3 RouterSchicht 2 Bridge/SwitchSchicht 1 <-> Hub/Repeater <->

Application Layer AnwendungsschichtPresentation Layer Darstellungsschicht

Session Layer SitzungsschichtTransport Layer TransportschichtNetwork Layer Vermittlungsschicht

Data Link Layer BitsicherungsschichtPhysical Layer Physikalische Schicht

Eselsbrücke: All people seem to need data processing


Mit verteilten Anwendungen ergeben sich vielfältige neue Möglichkeiten:

Lastverteilung (für höhere Leistung oder Zuverlässigkeit) Datenaustausch (auch zwischen verschiedenen Systemen)

Die Realisierung verteilter Anwendungen birgt jedoch auch neue Herausforderungen:

Verbindung (Aufbau, Datenaustausch, Abbau) Kommunikation (Ablauf, Kodierung) Adaption (verschiedene Hardwareplatformen oder Betriebssysteme) Synchronisation (mehrere Rechner laufen echt parallel)

Für die Adaption verschiedener Rechnerplatformen und Betriebssysteme sowie für Teile der Kommunikationssteuerung stehen Standardprotokolle bzw. Standardbibliotheken zur Verfügung. Synchronisation, Steuerung des Kommunikationsablaufs und Kodierung der Daten müssen jedoch zu grossen Teilen selbst implementiert werden.

Die Sprache Java wurde gezielt auch für die Anwendung im Netz konzipiert (vgl. Applets, Servlets). Daher stehen in Java eine mächtige Bibliothek für die Netzwerkkommunikation zur Verfügung.

Netzwerke – Verteilte Anwendungen


Sockets implementieren eine Punkt-zu-Punkt Verbindung und sind ein bewährtes Konzept aus der Unix-Welt. Über eine solche Verbindung können beliebige Daten in beide Richtungen übertragen werden. Das klingt wie ein Stream, und tatsächlich läßt sich ein Socket in Java wie ein Stream bedienen und sogar mit anderen Streams verketten.

Sockets basieren auf TCP/IP. Die Endpunkte eines Sockets werden beschrieben durch (1) ihre IP-Adresse und (2) den Port. Die IP-Adresse identifiziert den Rechner (das Haus), der Port einen "Dienst" auf diesem Rechner (Briefkasten bzw. Hausbewohner). Die Portnummern 1-1024 sind für Standarddienste reserviert (z.B. Port 80 für http). Die darüberliegenden Ports können für eigene Applikationen genutzt werden.

Es ist jedoch auch möglich, Standarddienste aus einem eigenen Programm über einen Socket anzusprechen. Eine Liste bekannter Dienste findet sich in der Datei C:\WINNT\system32\drivers\etc\services" (Windows) bzw. "\etc\services" (Unix). Darin findet sich u.a. auch der Eintrag 666/udp für das PC Spiel Doom ;-)

Netzwerke – Sockets


Sockets (dt. Steckdosen) werden in Java durch die Klassen ServerSocket und Socket repräsentiert. Der Ablauf einer Verbindung ist dabei wie folgt

Der Server erzeugt einen ServerSocket ("kauft ein Telefon") Der Server bindet den ServerSocket an einen Endpunkt ("steckt es ein") Der Server wartet, bis sich ein Client verbinden will, und akzeptiert dann die Verbindung Der Client erzeugt einen Socket ("kauft auch ein Telefon") Der Client verbindet diesen Socket mit dem Endpunkt beim Server ("ruft an")

Die Endpunkte werden dabei repräsentiert durch Instanzen der Klasse InetAddress bzw. InetSocketAddress. InetAddress stellt hierzu Hilfsmethoden zur Auflösung von symbolischen Adressen (hostnames) zur Verfügung. Der ServerSocket dient nur zum Verbindungsaufbau und kann dannach für weitere Verbindungen verwendet werden.

Zum Datenaustausch stellen die Sockets auf beiden Seiten entsprechende Input- bzw. Outputstreams zur Verfügung. Der genaue Ablauf der Kommunikation sowie die Kodierung der Daten sind Sache des Programmierers. Um die Verbindung zu beenden werden die beiden Sockets durch Aufruf der Methode close() geschlossen.

Anmerkung: Neben den "normalen" Socketklassen gibt es auch spezielle für SSL, etc.

Netzwerke – Prinzip von Sockets in Java


Die folgenden Codebeispiele illustrieren die Schritte bei der Kommunikation Server: ServerSocket erzeugen ServerSocket listener = new ServerSocket();

Server: ServerSocket an einen (lokalen) Endpunkt binden listener.bind(new InetSocketAddress(60120)); // und an einen lokalen Port binden

Server: Auf Client warten Socket socket = listener.accept();

Client: Socket erzeugen Socket socket = new Socket(); Client: Verbindung zum Server aufbauen socket.connect(new InetSocketAddress(InetAddress.getByName(hostname), port), 5000); Server+Client: Streams für Ein-/Ausgabe erzeugen BufferedWriter bw = new BufferedWriter(new OutputStreamWriter(socket.getOutputStream()));

BufferedReader br = new BufferedReader(new InputStreamReader(socket.getInputStream()));

Server+Client: Verbindungsabbau socket.close();

Wie bei der Ein-/Ausgabe mit Streams können auch beim Umgang mit Sockets ggf. IOExceptions auftreten und müssen entsprechend abgefangen und behandelt werden. Vollständige Beispielprogramme siehe Übung (SimpleServer.java, SimpleClient.java)

Netzwerke – Implementierung von Sockets in Java


Ein Socket stellt nur einen Kommunikationskanal bereit! Ablauf und Inhalte der Kommunikation müssen vom Programmierer selbst festgelegt werden, d.h. es muss ein Protokoll definiert werden. Dabei sind u.a. folgende Gesichtspunkte zu berücksichtigen:

1) Effizienz (bzgl. Bandbreite) z.B. binäre Kodierung von Daten oder Kompression (ZIP o.ä.) Wichtig bei geringer Bandbreite bzw. hohen Kosten (z.B. GPRS Datentarif) oder geringem Speicher auf dem Endgerät (Eingangs-/Ausgangskorb)

2) Kompatibilität (bzgl. Programmiersprachen / Plattformen) z.B. Kodierung von Zahlen mit 32 / 64Bit, Big-/Little Endian, … Wichtig, wenn viele verschiedene Kommunikationsteilnehmer möglich sein sollen

3) Lesbarkeit (u.a. Beim Debugging) z.B. durch textuelle Kodierung als Name+Wert oder XML Wichtig, um Komplexität zu vermeiden / Akzeptanz zu erreichen

Die historische Entwicklung geht dabei weg von proprietären Binärprotokollen hin zu offenen textbasierten Protokollen. Die Welt ist offener, Bandbreite ist billiger geworden.

Beispiel für ein Protokoll: http (s. ???); Client-/Serverbeispiel

Netzwerke – Protokoll Implementierung


Ein Socket stellt nur einen Kommunikationskanal bereit! Ablauf und Inhalte der Kommunikation müssen vom Programmierer selbst festgelegt werden, d.h. es muss ein Protokoll definiert werden. Dabei sind u.a. folgende Gesichtspunkte zu berücksichtigen:

1) Effizienz (bzgl. Bandbreite) z.B. binäre Kodierung von Daten oder Kompression (ZIP o.ä.) Wichtig bei geringer Bandbreite bzw. hohen Kosten (z.B. GPRS Datentarif) oder geringem Speicher auf dem Endgerät (Eingangs-/Ausgangskorb)

2) Kompatibilität (bzgl. Programmiersprachen / Plattformen) z.B. Kodierung von Zahlen mit 32 / 64Bit, Big-/Little Endian, … Wichtig, wenn viele verschiedene Kommunikationsteilnehmer möglich sein sollen

3) Lesbarkeit (u.a. Beim Debugging) z.B. durch textuelle Kodierung als Name+Wert oder XML Wichtig, um Komplexität zu vermeiden / Akzeptanz zu erreichen

Die historische Entwicklung geht dabei weg von proprietären Binärprotokollen hin zu offenen textbasierten Protokollen. Die Welt ist offener, Bandbreite ist billiger geworden.

Netzwerke – Protokoll Implementierung


Stärken von Sockets Kommunikation zwischen "beliebigen" Platformen, Betriebssystemen und Applikationen Einfacher Verbindungsaufbau

Schwächen von Sockets Kodierung/Dekodierung muss vollständig selbst implementiert werden Aufwendige Protokollimplementierung

Die Freiheit bei der Protokollgestaltung resultiert also in der Verantwortung, dies auch zu tun. Das kann je nach Applikation mehr oder weniger aufwendig sein. Die Übungsklasse "PhoneServer" implementiert ein einfaches Protokoll. Für die meisten Anwendungen ist dieser Aufwand jedoch "zu lästig". Modernere Verfahren wie RMI oder Web Services bieten mehr Konfort und gleichzeitig mehr Sicherheit.

Da ein Socket nur eine Punkt-zu-Punkt Verbindung repräsentiert, kann ein Server Clients zunächst nur hintereinander bedienen. Es ist jedoch möglich, mit Hilfe von Threads mehrere Clients über dieselbe Portnummer(!) parallel zu bedienen (sog. threaded Server, vgl. Übungsklasse "ThreadedServer"). Die richtige Anzahl und Koordination der Threads, z.B. bei einem Webserver wie Apache, ist jedoch ein Kunst für sich...

Weitere Detailinformationen siehe API, Tutorial und Buch!

Netzwerke – Stärken und Schwächen von Sockets


Anstelle der aufwendigen Implementierung eines Protokolls und Befehle zu Kodieren, zu Verschicken und zu Dekodieren wäre es oftmals praktischer, Objekte auf einem anderen Rechner direkt aufrufen zu können. Tatsächlich bietet Java einen Mechanismus, mit dem dies möglich ist: Remote Method Invocation (RMI).

Ziel von RMI ist es, entfernte Objekte genauso wie lokale Objekte aufrufen zu können und damit das Netzwerk aus algorithmischer Sicht "wegzuabstrahieren". Erreicht wird dies durch einen im Grunde simplen Trick:

ein lokales Objekt A möchte mit einem entfernten Objekt B kommunizieren das lokale Objekt B' tut so als wäre es B und nimmt den Aufruf entgegen der Inhalt des Aufrufs wird von B' im Hintergrund an ein entferntes Objekt B'' geschickt B'' setzt die übertragenen Daten in einen Aufruf von B um Das Ergebnis wird von B'' an B' zurückgeschickt B' liefert das Ergebnis an A

Das Objekt merkt also gar nicht, das B' nur so tut als ob. Voraussetzung dafür ist, dass B' kompatibel zu B ist, z.B. indem es von B erbt oder dieselbe Schnittstelle implementiert. Das Herstellen der Verbindung zwischen A und B (=Erstellung von B', B'') erfolgt über eine zentrale Registry bei sich Objekte mit einer Dienstkennung registrieren können.

Netzwerke – Prinzip von Remote Method Invocation


Prinzip der Umsetzung von RMI in Java lautet wie folgt: Für die Dienste des Servers wird ein Interface R definiert. Die Serverklasse B implementiert dieses Interface Der lokale Stellvertreter B' wird mit Hilfe des rmic (RMI Compiler) erzeugt Die Clientklasse A verwendet das Interface zum Zugriff auf B

Als weitere Einschränkungen gelten dabei: Das Serverinterface muss von java.rmi.Remote abgeleitet sein Die Serverklasse muss von einer RMI-Klasse erben*, z.B. UnicastRemoteObject

Der Programmablauf ist dann folgendermaßen Die RmiRegistry wird zuerst gestartet (Aufruf "rmiregistry" im DOS Fenster) Der Server wird gestartet und registriert sich bei der RmiRegistry Der Client wird gestartet und fragt bei der RmiRegistry nach Die RmiRegistry liefert einen Stellvertreter des Servers zurück Client und Server kommunizieren über den Stellvertreter

Den Stellvertreter B' nennt man auch Stub oder Proxy (Stellvertreter). Sein Gegenüber B'' wird als Skeleton bezeichnet und ist in Java2 (also seit Java 1.4.x) nicht mehr notwendig. Seine Aufgabe wird direkt vom entfernten Laufzeitsystem übernommen.

* Alternative: manueller export über UnicastRemoteObject.export() oder Verwendung von "aktivierbaren" Objekten (siehe Google ;-)

Netzwerke – Prinzip von Remote Method Invocation in Java


Server Rechner

Netzwerke – Ablauf bei RMI

Client Rechner

Naming("Gelbe Seiten")

Server Programm Client Programm

1: bind( <Name>)2: lookup( URL*)returns remote ref

3: ref.method(params)

Hinweis: Die Klassendefinitionen für Parameter sind auf beiden Seiten nötig!*URL Format: rmi://<rechnername>/<Name>

Startreihenfolge:Naming Service, Server, Client

Nachrichtenaustausch:


Netzwerke – Ablauf eines RMI Aufrufs (Modell)

Proxy Objektwird aufgerufen und übergibt Methodenname und Parameter an Runtime

Lokales Objektruft Methode in Remote Objekt auf (in Wirklichkeit nur den Proxy)

RMI RuntimeKodiert Methodenname und Parameter für Übertragung (Marshalling)

Socket(!)Transportiert kodierte Daten

RMI RuntimeDekodiert Methodenname und Parameter (Unmarshalling)

Remote Objektwird durch RMI Runtime aufgerufen und liefert Rückgabewert


Nachfolgende Codebeispiele illustrieren die konkrete Implementierung von RMI in Java:

Interface definieren public interface ServerInterface extends java.rmi.Remote { // Methoden } Serverklasse implementieren public class ServerImpl extends java.rmi.server.UnicastRemoteObject implements ServerInterface { // Methoden } Server bei RmiRegistry registrieren java.rmi.Naming.rebind( "<Kennung>", new ServerImpl()) Anfrage des Client bei der RmiRegistry ServerInterface object = java.rmi.Naming.lookup( "<Kennung>");

Mit dem entfernten Objekt kann wirklich wie mit jedem anderen Objekt gearbeitet werden, einschließlich GarbageCollection. Neben den "normalen" Ergebnissen werden dabei auch Exceptions transparent über das Netzwerk transportiert(!). Daneben können allerdings verschiedene Exceptions bei der (an sich versteckten) Kommunikation auftreten, die unter der Klasse RemoteException subsummiert werden. Daher müssen alle remote Methoden diese in ihrer Signatur tragen (throws RemoteException). Ein einfaches vollständiges Anwendungsbeispiel findet sich in Übung 10.

Netzwerke – Implementierung von RMI in Java


Für RMI steht ein spezieller Security Manager zur Verfügung. Dieser soll z.B. dafür sorgen, dass evtl. bösartige remote geladene Klassen nicht zuviele Rechte haben.

Der RMI Security Manager kann wie folgt installiert werden:

if(System.getSecurityManager() == null) { System.setSecurityManager(new RMISecurityManager()); }

Das Verhalten des Security Managers wird über eine sog. Policy gesteuert die in einer separaten Datei hinterlegt ist und auf der Kommandozeile angegeben werden kann

java -Djava.security.policy=<policyfilename> <MainClass>

Die Syntax der Policy ist in der Datei docs/guide/security/PolicyFiles.html beschrieben.Um eine Policy zu definieren ohne die Syntax zu lernen kann das policytool program aus dem JDK verwendet werden.

Java sucht außerdem in $JAVA_HOME/lib/security/java.policy nach einer systemweiten Policy. Wenn auf der Kommandozeile keine Policy angegeben wird, sucht die JVM auch noch nach einer Benutzerspezifischen Policy in $USER_HOME/java.policy.

Netzwerke – RMI Security Manager


Das Sicherheitskonzept von Java gestattet RMI per Default nur auf dem localhost. Zur Kommunikation zwischen mehreren Rechnern muss beim Aufruf von Server und Client eine entsprechende Security-Policy angegeben werden.

Server aufrufen:>java -Djava.security.policy=rmi.policy MyServer

Client aufrufen:>java -Djava.security.policy=rmi.policy MyClient

Datei "rmi.policy":grant codeBase "file:/home/src/myproject" { permission java.security.AllPermission;};

Optional können über weitere Parameter auch eine gemeinsame Codebasis und der Hostname für den Naming Service angegeben werden:

-Djava.rmi.server.codebase=file:/c:/home/ann/public_html/classes/compute.jar -Djava.rmi.server.hostname=zaphod.east.sun.com

Außerdem müssen ggf. noch Ports in Firewalls freigeschaltet werden (Default 1099)

Netzwerke – RMI zwischen mehreren Rechnern


Ein Programm kann mehr als ein remote Interface definieren. Nach dem Zugriff auf das erste remote Objekt können weitere remote Objekte per Rückgabewert von den Methoden des ersten Objekts zurückgeliefert (oder per Parameter an diese übergeben) werden.

Es wird also nicht jedes remote Objekt an einen Namen gebunden sondern nur ein Dienstobjekt welches als Einstieg bzw. Fassade dient. Das ist auch sinnvoll, damit die anderen Objekte dynamisch erzeugt und gelöscht werden können. Das Dienstobjekt muss hingegen die ganze Zeit "am Leben bleiben". Der Garbage Collector verhält sich übrigends auch für remote Objekte "vernünftig"...

Auch "normale" Objekte können als Parameter oder Rückgabewert von remote Methoden auftauchen. Von diesen wird dabei jedoch eine Kopie im jeweils anderen Programm erstellt. Damit dies möglich ist, müssen die zugehörigen Klassen serialisierbar sein, d.h. das Marker-Interface Serializable implementieren. Bei der Übertragung spricht man jedoch nicht von Serialisierung sondern eben von Marshalling/Unmarshalling.

Wir erinnern uns: Bei Methodenaufrufen innerhalb eines Programms gilt für Objekte stets Call-By-Reference. Bei remote Methodenaufrufen gilt dies nur für remotable Objekte. Objekte die nicht remote sondern "nur" serialisierbar sind werden per Call-By-Value übertragen(!). Dies ist jedoch meist kein Problem (man muss es nur wissen).

Netzwerke – Call-by-Value und Call-by-Reference bei RMI


Obwohl RMI einerseits bequemer ist als Sockets, kann man doch einiges falsch machen

Checkliste Naming Service (neu*) gestartet? Server bei Naming Service registriert? Alle Parameter und Exceptions(!) Serialisierbar bzw. Remoteable? Gleiche Klassendefinitionen für Client und Server Rechnern? Remote Methoden mit RemoteException? Gegen Remote Interface programmiert? Korrekte IP-Adresse / Hostname in URL? Security Policy installiert (nur bei mehreren Rechnern)? RMI Port in Firewall(s) freigeschaltet?

siehe auch http://www.cs.man.ac.uk/~fellowsd/work/usingRMI.html

* nach Änderung der Klassendefinitionen

Netzwerke – Fallstricke bei RMI


Wie vieles in Java haben auch die Ideen hinter RMI eine Vorgeschichte: Der Wunsch, Funktionen auch komfortabel über das Netzwerk aufrufen zu können ist nicht neu. Bereits in der Programmiersprache C gab es sog. RPCs (Remote Procedure Calls). Dabei wurden aus einer Schnittstellenbeschreibung mit Funktionssignaturen in IDL (Interface Definition Language) ebenfalls Stubs und Skeletons generiert und bei einem RPC Dienst auf dem Rechner registriert. Allerdings war es nicht möglich, dynamisch remote Funktionen oder gar Objekte zu definieren.

Um dies zu ermöglichen wurde wenig später CORBA (Common Objekt Request Broker Architecture) entwickelt. Dabei vermittelt ein Request Broker Anfragen zwischen Objekten auf verschiedenen Rechnern. Dazu kommt ein spezielles Protokoll (IIOP, Internet Inter Orb Protocol) zum Einsatz. Auch heute noch gibt es am Markt zahlreiche freie und kommerzielle Implementierungen dieser Architektur.

CORBA definiert Standards zur Objektkommunikation zwischen verschiedenen Rechnern und Programmiersprachen(!). Der Betrieb ist jedoch nicht immer trivial (u.a. wg. der Firewallproblematik). Dies ist bei Webservices einfacher, da das zugrundeliegende SOAP (Simple Object Access Protokoll) über http und tcp transportiert und von Firewalls üblicherweise durchgelassen wird. Die grundlegende Idee ist jedoch bei CORBA, Webservices und RMI gleich, nur die Ausgestaltung variiert.

Einschub – RPCs, CORBA und Webservices


Die erweiterten GUI Komponenenten (Swing), Threads sowie die Mechanismen zur Datenbankenanbindung (JDBC) sowie zur Kommunikation über Netzwerke (Sockets/RMI) sind Grundlage für die Entwicklung moderner und leistungsfähiger Anwendungen. Die Java Bibliothek bietet jedoch noch vieles mehr wie z.B. Klassen zur XML Verarbeitung, Klassen zum Zeichnen auf dem Bildschirm (Java2D), Funktionen zur Verarbeitung von Bildern und Sounds, kryptographische Algorithmen sowie weitergehende Funktionen zu den in der Vorlesung behandelten Themen. All diese lassen sich bei Bedarf aus der Online-Hilfe, dem Java Tutorial sowie weiteren Quellen im Netz erschließen.

Zusammenfassung

Documents

Vorlesung Informatik 2 - Hochschule Esslingenrau/vorlesungen/Informatik2/...konzepte.pdf · Andreas Rau, 11.06.10 D:\home\ar\fhte\vorlesungen\informatik2\folien\informatik2-theorie-konzepte.odp