Software ubiquitärer Systeme - TU Dortmund...1 Software ubiquitärer Systeme Anwendungsentwicklung...

11

Software ubiquitärer SystemeAnwendungsentwicklung mit Java

Olaf SpinczykArbeitsgruppe Eingebettete Systemsoftware

Lehrstuhl für Informatik 12TU Dortmund [email protected]://ess.cs.uni-dortmund.de/~os/

http://ess.cs.tu-dortmund.de/DE/Teaching/SS2013/SuS/

mailto:[email protected]

06.3 – Anwendungsentwicklung mit Java 22

Motivation● Probleme mit C und C++

● effizienter Code aber unsicher● eingeschränkte Portabilität

- verschiedene Betriebssysteme und GUI-Bibliotheken: z.B. in Mobiltelefonen Symbian OS, Windows CE, Linux Varianten

● Sichere C++ Dialekte● weniger effizienter Code● mangelnde Verbreitung/Standardisierung

● Was ist die Alternative?

Ein Java für eingebettete Systeme!Ein Java für eingebettete Systeme!


Die Java-Familie● Je nach Anforderungen der Anwendungen bzw. Leistungsfähigkeit

der Geräte bedient Oracle verschiedene Anwendungsdomänen mit unterschiedlichen Java Plattformen.

Quelle: [1]

Nicht nur die Bibliothekensondern auch die virtuellenMaschinen unterscheidensich.

Nicht nur die Bibliothekensondern auch die virtuellenMaschinen unterscheidensich.


Inhalt● Motivation

● Java Micro Edition● Java Card● Alternativen

● Android● .NET Compact

● Zusammenfassung


Die Java Micro Edition● Kurz: Java ME

● Sun Microsystems, Juni 1999

● Zielmarkt● Pager

● Mobiltelefone, Smartphones

● PDAs

● Fernseher, Videorekorder, CD Player

● Alle besseren Mobiltelefone unterstützen heute Java ME

● Abgespeckte Version der Standard Edition (Java SE)● Weniger Speicherverbrauch

● Keine schwergewichtigen Klassen (swing, awt, …)

● Optimierte virtuelle Maschine (KVM)

Java 2Standard EditionAPI

JavaMicro EditionAPI


Java ME Architektur● Die von Java ME abgedeckte Domäne ist riesig

● unterschiedlichste Geräte und Geräteklassen (Ressourcen)

● unterschiedlichste Anwendungen (Anforderungen)

● Um die Java ME zu strukturieren, wurden zwei grundlegende Konzepte definiert:

Konfigurationen und Profile

LeistungsschwacheGeräte

LeistungsstärkereGeräte

...

Konfigurationen:Horizontale Aufteilungdes Marktes

Profile: Vertikale Marktaufteilung


Java ME Konfigurationen● Definiert Geräteklassen anhand verfügbarer Ressourcen

● CPU-Klasse, Speicher, Netzwerkanbindung

● Entscheidet über …● die verwendete virtuelle Maschine sowie

● APIs für elementare Funktionen.

➔ … die Java Ausführungsumgebung

● Bisher wurden zwei Konfigurationen festgelegt● CLDC: Connected Limited Device Configuration

- z.B. Mobilfunkgeräte, um die 500 KB Speicher, einfache Applikationen

- spezielle VM

● CDC: Connected Device Configuration

- z.B. Smart Phones ab 2 MB Speicher, Set-Top-Boxes, High-End PDAs


Java ME Profile● Hängen von der jeweiligen

Anwendungsdomäne ab

● Definieren verfügbare APIs● Sorgen für Portabilität

● Haben Abhängigkeiten

● Beispiele:● MIDP (Mobile Information Device P.)

- Netzwerk-Kommunikation

- Einfache Benutzerschnittstelle

- Datenspeicherung

● Personal Profile- Komplettes AWT

- Ausführungsumgebung für Applets

Quelle [1]


Java ME für Mobilgeräte

● KVM - Kilobyte Virtual Machine● 40 – 80 KB groß (je nach Compiler)● Implementiert in C (ca. 36.000 Zeilen)● Für Geräte mit mindestens …

- 160 KB Speicher und

- 16 oder 32 Bit CPU

Betriebssystem

CLDC

Java VM (KVM)

MIDP

HerstellerspezifischeAPIs


KVM: Was fehlt?● Unterstützung für Object.finalize()

● Wird auch praktisch nicht verwendet

● Fehlerbehandlungsfähigkeiten (eingeschränkt)● Es gibt lediglich 3 Fehler-Klassen

- java.lang.Error, java.lang.OutOfMemory und java.lang.VirtualMachineError

● Java Native Interface (JNI)● Zur Vermeidung von Sicherheitsproblemen und

wegen des Overheads

● Benutzerdefinierte Class Loader● Reflection-Mechanismus● Threading-Fähigkeiten (eingeschränkt)

● Keine Thread Groups und Daemon Threads)

● Verifikation von Class Files● Einsatz eines Pre-Verifiers


Entwicklungsprozess

Java-Quelltext

Java Class-Dateien

Pre-verifizierteClass-Dateien

JAR-Paket

Anwendung aufdem Gerät

Compile

Preverification

Packaging

Deployment

javac ...

preverify ...

jar ...

emulator ...



● CLDC - Connected Limited Device Configuration ● Low-Level Funktionalität

- Umgang mit der Laufzeitumgebung, Ein-/Ausgabe

● Besteht aus of java.io, java.lang, java.util, java.microedition.io- Allerdings nur Teilmengen der aus Java SE bekannten Klassen!

- Die Semantik bleibt aber erhalten

Betriebssystem

Java VM (KVM)

MIDP


CLDC



● MIDP – Mobile Information Device Profile ● MIDP stellt Kernfunktionen für Mobilgeräte zur Verfügung

- Netzwerkkommunikation

- Datenhaltung

- Benutzerschnittstelle

Betriebssystem

Java VM (KVM)


CLDC

MIDP


Mobile Information Device Profile● Minimalanforderungen

● Bildschirmauflösung von mind. 96x54 Pixeln● Keypad, Tastatur oder Touch Screen● 256 KB nicht-flüchtiger Speicher● 128 KB RAM● 8 KB nicht-flüchtiger Speicher für persistente Daten● Bi-direktionale Netzwerkverbindung

● MIDP 2.0 Packages● javax.microedition.lcdui, javax.microedition.lcdui.game,

javax.microedition.media, javax.microedition.media.control, javax.microedition.midlet, javax.microedition.pki, javax.microedition.rms

● Ausführung von Midlets● Java ME-Applikationen bestehen aus 1 bis N MIDlets


Java ME: Midlet-Lebenszyklus● MIDlets werden wie Applets von der Umgebung gesteuert

Paused

Destroyed

Active

Konstruktor

destroyApp()notifyDestroyed() pauseApp()

notifyPaused()

destroyApp()notifyDestroyed()

startApp()


Java ME: Midlet-Beispiel

// Zur Vereinfachung ohne Exceptions ...public class HelloMIDlet extends MIDlet implements CommandListener { private Form mMainForm; public HelloMIDlet() { mMainForm = new Form("HelloMIDlet"); mMainForm.append(new StringItem(null, "Hello, MIDP!")); mMainForm.addCommand(new Command("Exit", Command.EXIT, 0)); mMainForm.setCommandListener(this); } protected void destroyApp(boolean arg0) { } protected void pauseApp() { } protected void startApp() { Display.getDisplay(this).setCurrent(mMainForm); } public void commandAction(Command arg0, Displayable arg1) { notifyDestroyed(); }}

Man erbt von MIDlet.Man erbt von MIDlet.

Diese Methoden werden vomApplication Management System(AMS) des Mobilgeräts aufgerufen.

Diese Methoden werden vomApplication Management System(AMS) des Mobilgeräts aufgerufen.

So wird das AMS angewiesendas MIDlet zu beenden.So wird das AMS angewiesendas MIDlet zu beenden.


Java ME: Demo● Zum Bauen von Midlets benutzt man das …

Java ME SDK (aktuell 3.3)● Demo-Applikationen● Emulator● Alle sonstigen Werkzeuge


Java ME: Fazit● Pro

● Durch Konfigurationen und Profile wird eine Familie von Java-Lösungen bereitgestellt

- Damit skaliert der Ressourcenverbrauch

● Standardisierte domänenspezifische Bibliotheken

● Die kvm benötigt erstaunlich wenig Speicher

● Contra● Die kvm ist leider langsam

● Leichte Einschränkungen bzgl. der Sprache müssen hingenommen werden

- z.B. kein Reflection

● Entwickler müssen sich mit anderen Bibliotheken anfreunden




● Android● .NET Micro/Compact Framework

● Zusammenfassung


Java Card: Hardware● Eine Java-Lösung für Smart Cards

(Chipkarten mit Prozessor)

● Hardware-Eigenschaften● Stromversorgung durch Lesegerät● Interaktion lediglich mit dem Lesegerät

- Serielle Schnittstelle, Standardprotokoll

● Enthalten Universalprozessor- 8-32 Bit, 3,5-5 MHz

● Extrem wenig Speicher- 16-32 KB ROM

- 0,5-1 KB RAM

- 8-16 KB EEPROM

➔ Definitiv zu klein für Java ME!

C1

C2

C3

C4

C6

C7

C8

C5 GroundVppI/ORFU

VccResetClockRFU


Java Card: Anwendungen● Einsatzgebiete

● Krankenkassenkarten● Bankkarten (EC)● Handy-SIM-Karten● Ausweise➔ Ziel: nur eine Karte für viele Applikationen

● Anforderungen an die Java Card Plattform● Sicherheit und Zuverlässigkeit

- Verwaltung und Isolierung der Applikationen auf der Karte

● Extrem geringer Ressourcenverbrauch● Für die Domäne passende standardisierte Packages● Portabilität● Kompatibilität mit existierenden Standards


Java Card: Was fehlt?● Dynamisches Klassenladen

● Security Manager

● Garbage Collection

● Threads

● Klonen von Objekten

● Mehrdimensionale Felder

● Datentypen char, double, float und long

● Die Java Card API beschränkt sich auf folgende Pakete● java.lang, javacard.framework, javacard.security, javacardx.crypto


Java Card: Applets ...● sind persistente Zustandsautomaten, die auf Nachrichten

des Lesegeräts reagieren.

● haben (mindestens) folgende Methoden● install

- Erzeugung und Registrierung der Applet-Instanz

● select- Das Lesegerät spricht das Applet an

● process- Interpretation der Nachrichten (APDUs) vom Lesegerät

● deselect- Das Lesegerät beendet die Kommunikation mit dem Applet


Java Card: Fazit● Pro

● Plattformunabhängige Entwicklung für Smart Cards

● Unterstützung mehrerer Applikationen auf einer Karte

● Dynamische Installation/Deinstallation von Applets

● Standardisierte Bibliotheken

● Nutzbarkeit von Java Know-How

● Contra● Die Sprache ist zwar Java, das Programmiermodell aber nicht.

● Essentielle Sprachelemente fehlen

● Deutliche Nachteile hinsichtlich der Performance

● Vergleichsweise hohe Ressourcenanforderungen



● Java 2 Micro Edition● Java Card● Alternativen


● Zusammenfassung


Android● Open Handset Alliance (primär Google), 2007

● T-Mobile, Motorola, Samsung, ...

● Vision:“... accelerate innovation in mobile andoffer consumers a richer, less expensive,and better mobile experience.”

● Infrastruktursoftware-Plattform für Smartphones● Open Source

● Diverse Produkte inzwischen verfügbar


Android: Architektur● Linux und Java – aber anders ...


Android: Architektur● Linux und Java – aber anders ...

Die Dalvik-VM führt Java-Programmeaus, deren Bytecode in Dalvik-Bytecodeübersetzt wurde.

Die Dalvik-VM führt Java-Programmeaus, deren Bytecode in Dalvik-Bytecodeübersetzt wurde.


Android: Die Dalvik-VM● Benannt nach einer isländischen Stadt● Hauptunterschiede

● Java-Bytecode ist stapelbasiert, Dalvik-Bytecode ist registerbasiert- Java-Bytecode lässt sich nicht (direkt) ausführen

- Ein Übersetzungschritt ist erforderlich

● Dalvik Code wurde bis Android 2.2 nur interpretiert- Heute Trace-basierter JIT-Compiler

● Gründe● Kompaktheit des Codes● JIT-Compiler wurde als unnötig erachtet, da die Performance-

kritischen Teile nativ ausgeführt werden (Kernel/Libraries)- inzwischen können Anwendungen auch „native code“ verwenden

- JIT darf nicht zu viel Speicher benötigen

● Lizenzrechte?


Android: Größen (statisch)● common system libraries

● (U) 21445320 — 100%

● (J) 10662048 — 50%

● (D) 10311972 — 48%

● web browser app● (U) 470312 — 100%

● (J) 232065 — 49%

● (D) 209248 — 44%

● alarm clock app● (U) 119200 — 100%

● (J) 61658 — 52%

● (D) 53020 — 44%

(U) unkomprimierte jar-Datei(J) komprimierte jar-Datei(D) unkomprimierte dex-Datei

(U) unkomprimierte jar-Datei(J) komprimierte jar-Datei(D) unkomprimierte dex-Datei

Quelle: Dan Bornstein, Dalvik VM Entwickler

Der Grund ist allerdings nichtnur der kompaktere Bytecode,sondern auch eine schlaueresDateiformat.

Der Grund ist allerdings nichtnur der kompaktere Bytecode,sondern auch eine schlaueresDateiformat.


Android: Größen (dynamisch)

● JIT arbeitet Trace-basiert● Übersetzung auf Ebene von

Basisblöcken(statt ganzen Prozeduren)

● Ein Translation Cachepro Prozess (VM-Instanz)

● Trade-off zwischenPerformance undSpeicherbedarfakzeptabel

Quelle: A JIT Compiler for Android’s Dalvik VM Ben Cheng, Bill Buzbee, May 2010


Android: Fazit● Android ist für Smartphones ausgelegt

● Skalierbarkeit ist kein Thema

● Annahme: typische 64-512 MB Speicher, 250-1000 MHz CPU

● Android zeigt, dass die Java-VM nicht unbedingt perfekt geeignet ist, um kleine Systeme zu bauen● Dalvik-Bytecode ist signifikant kleiner


.NET Framework für eingeb. Systeme?● Microsoft● Ermöglicht .NET auf

Windows CE/Mobile-Geräten● Moderne Zwischensprache (MSIL)

für mehrere Quellsprachen- C#, VB, J#, C++, …

- Ausgelegt auf JIT-Compiler

● Anwendungsentwicklungin MS Visual Studio

● Diverse Bibliotheken- Benutzerschnittstelle, Kommunikation, …

- Allerdings an diversen Stellen beschnitten

➔ Größenreduktion des .NET Frameworks …● Compact: erfordert 12 MB● Micro: erfordert 256 KB Flash, 64KB RAM (läuft ohne OS, kein JIT)

Quelle: msdn.microsoft.com





● Zusammenfassung


Zusammenfassung● Java-Umgebungen bilden eine Produktlinie

● Skalierbarkeit von 8 Bit Chipkarten bis 64 Bit Serversystemen

● Bei den kleineren Varianten gibt es Einschränkungen● z.B. keine Garbage Collection bei Java Card

● Es gibt auch Alternativen● Dalvik- und MSIL-Programme haben kompakteren Code

● Java ME wird im Mobiltelefonbereich langsam verdrängt


Literatur[1] M. de Jode, Programming Java 2 Micro Edition on Symbian

OS, ISBN 0-470-09223-8, Wiley, 2004.[2] Java Card Platform Specification 2.2.2, Sun Microsystems.

Software ubiquitärer Systeme - TU Dortmund...1 Software ubiquitärer Systeme Anwendungsentwicklung...

Documents

Transcript of Software ubiquitärer Systeme - TU Dortmund...1 Software ubiquitärer Systeme Anwendungsentwicklung...