Java Card - Embedded System Software
Werbung
Software ubiquitärer Systeme Anwendungsentwicklung mit Java Olaf Spinczyk Arbeitsgruppe Eingebettete Systemsoftware Lehrstuhl für Informatik 12 TU Dortmund [email protected] http://ess.cs.uni-dortmund.de/~os/ http://ess.cs.tu-dortmund.de/DE/Teaching/SS2012/SuS/ 1 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 Ein Java Java für für eingebettete eingebettete Systeme! Systeme! 06.3 – Anwendungsentwicklung mit Java 2 Die Java-Familie ● Je nach Anforderungen der Anwendungen bzw. Leistungsfähigkeit der Geräte bedient Sun verschiedene Anwendungsdomänen mit unterschiedlichen Java Plattformen. Nicht Nicht nur nur die die Bibliotheken Bibliotheken sondern sondern auch auch die die virtuellen virtuellen Maschinen Maschinen unterscheiden unterscheiden sich. sich. Quelle: [1] 06.3 – Anwendungsentwicklung mit Java 3 Inhalt ● Motivation ● Java 2 Micro Edition Java Card Alternativen ● ● Android ● .NET Compact ● ● Zusammenfassung 06.3 – Anwendungsentwicklung mit Java 4 Die Java 2 Micro Edition ● Kurz: J2ME ● ● Sun Microsystems, Juni 1999 Zielmarkt ● Pager ● Mobiltelefone, Smartphones ● PDAs ● Fernseher, Videorekorder, CD Player Java 2 Standard Edition API Java Micro Edition API ● Alle besseren Mobiltelefone unterstützen heute Java ME ● Abgespeckte Version der Standard Edition (J2SE) ● Weniger Speicherverbrauch ● Keine schwergewichtigen Klassen (swing, awt, …) ● Optimierte virtuelle Maschine (KVM) 06.3 – Anwendungsentwicklung mit Java 5 J2ME Architektur ● Die von J2ME abgedeckte Domäne ist riesig ● unterschiedlichste Geräte und Geräteklassen (Ressourcen) ● unterschiedlichste Anwendungen (Anforderungen) Um die J2ME zu strukturieren, wurden zwei grundlegende Konzepte definiert: Konfigurationen und Profile Leistungsstärkere Geräte Konfigurationen: Horizontale Aufteilung des Marktes ... ● Leistungsschwache Geräte Profile: Vertikale Marktaufteilung 06.3 – Anwendungsentwicklung mit Java 6 J2ME 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 06.3 – Anwendungsentwicklung mit Java 7 J2ME 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] 06.3 – Anwendungsentwicklung mit Java 8 J2ME für Mobilgeräte MIDP Herstellerspezifische APIs CLDC Java VM (KVM) Betriebssystem ● 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 06.3 – Anwendungsentwicklung mit Java 9 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) ● ● ● ● Benutzerdefinierte Class Loader Reflection-Mechanismus Threading-Fähigkeiten (eingeschränkt) ● ● Zur Vermeidung von Sicherheitsproblemen und wegen des Overheads Keine Thread Groups und Daemon Threads) Verifikation von Class Files ● Einsatz eines Pre-Verifiers 06.3 – Anwendungsentwicklung mit Java 10 Entwicklungsprozess Java-Quelltext Compile javac ... Preverification preverify ... Packaging jar ... Deployment emulator ... Java Class-Dateien Pre-verifizierte Class-Dateien JAR-Paket Anwendung auf dem Gerät 06.3 – Anwendungsentwicklung mit Java 11 J2ME für Mobilgeräte MIDP Herstellerspezifische APIs CLDC Java VM (KVM) Betriebssystem ● 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 J2SE bekannten Klassen! - Die Semantik bleibt aber erhalten 06.3 – Anwendungsentwicklung mit Java 12 J2ME für Mobilgeräte MIDP Herstellerspezifische APIs CLDC Java VM (KVM) Betriebssystem ● MIDP – Mobile Information Device Profile ● MIDP stellt Kernfunktionen für Mobilgeräte zur Verfügung - Netzwerkkommunikation - Datenhaltung - Benutzerschnittstelle 06.3 – Anwendungsentwicklung mit Java 13 J2ME: 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 ● J2ME-Applikationen bestehen aus 1 bis N MIDlets 06.3 – Anwendungsentwicklung mit Java 14 J2ME: Midlet-Lebenszyklus ● MIDlets werden wie Applets von der Umgebung gesteuert Konstruktor Paused destroyApp() notifyDestroyed() startApp() pauseApp() notifyPaused() Destroyed 06.3 – Anwendungsentwicklung mit Java Active destroyApp() notifyDestroyed() 15 J2ME: Midlet-Beispiel Man Man erbt erbt von von MIDlet. MIDlet. // 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) { Diese Diese Methoden Methoden werden werden vom vom } Application Application Management Management System System protected void pauseApp() { (AMS) (AMS) des des Mobilgeräts Mobilgeräts aufgerufen. aufgerufen. } protected void startApp() { Display.getDisplay(this).setCurrent(mMainForm); } public void commandAction(Command arg0, Displayable arg1) { notifyDestroyed(); So So wird wird das das AMS AMS angewiesen angewiesen } das das MIDlet MIDlet zu zu beenden. beenden. } 06.3 – Anwendungsentwicklung mit Java 16 J2ME: Demo ● Zum Bauen von Midlets benutzt man das … Java ME SDK (aktuell 3.0.5) Demo-Applikationen ● Emulator ● Alle sonstigen Werkzeuge ● 06.3 – Anwendungsentwicklung mit Java 17 J2ME: Fazit ● Pro ● Durch Konfigurationen und Profile wird eine Familie von JavaLö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 06.3 – Anwendungsentwicklung mit Java 18 Inhalt ● Motivation ● Java 2 Micro Edition Java Card Alternativen ● ● Android ● .NET Compact ● ● Zusammenfassung 06.3 – Anwendungsentwicklung mit Java 19 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 ➔ Vcc Reset Clock RFU C1 C2 C3 C4 C5 C6 C7 C8 Ground Vpp I/O RFU Definitiv zu klein für J2ME! 06.3 – Anwendungsentwicklung mit Java 20 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 ● 06.3 – Anwendungsentwicklung mit Java 21 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 06.3 – Anwendungsentwicklung mit Java 22 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 06.3 – Anwendungsentwicklung mit Java 23 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 06.3 – Anwendungsentwicklung mit Java 24 Inhalt ● Motivation ● Java 2 Micro Edition Java Card Alternativen ● ● Android ● .NET Compact ● ● Zusammenfassung 06.3 – Anwendungsentwicklung mit Java 25 Android ● Open Handset Alliance (primär Google), 2007 ● T-Mobile, Motorola, Samsung, ... ● Vision: “... accelerate innovation in mobile and offer consumers a richer, less expensive, and better mobile experience.” ● Infrastruktursoftware-Plattform für Smartphones ● ● Open Source Diverse Produkte inzwischen verfügbar 06.3 – Anwendungsentwicklung mit Java 26 Android: Architektur ● Linux und Java – aber anders ... 06.3 – Anwendungsentwicklung mit Java 27 Android: Architektur ● Linux und Java – aber anders ... Die Die Dalvik-VM Dalvik-VM führt führt Java-Programme Java-Programme aus, aus, deren deren Bytecode Bytecode in in Dalvik-Bytecode Dalvik-Bytecode übersetzt übersetzt wurde. wurde. 06.3 – Anwendungsentwicklung mit Java 28 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 Performancekritischen Teile nativ ausgeführt werden (Kernel/Libraries) ● - inzwischen können Anwendungen auch „native code“ verwenden - JIT darf nicht zu viel Speicher benötigen ● Lizenzrechte? 06.3 – Anwendungsentwicklung mit Java 29 Android: Größen (statisch) ● ● ● common system libraries ● (U) 21445320 — 100% ● (J) 10662048 — 50% ● (D) 10311972 — 48% (U) (U) unkomprimierte unkomprimierte jar-Datei jar-Datei (J) (J) komprimierte komprimierte jar-Datei jar-Datei (D) (D) unkomprimierte unkomprimierte dex-Datei dex-Datei web browser app ● (U) 470312 — 100% ● (J) 232065 — 49% ● (D) 209248 — 44% alarm clock app ● (U) 119200 — 100% ● (J) 61658 — 52% ● (D) 53020 — 44% Der Der Grund Grund ist ist allerdings allerdings nicht nicht nur nur der der kompaktere kompaktere Bytecode, Bytecode, sondern sondern auch auch eine eine schlaueres schlaueres Dateiformat. Dateiformat. Quelle: Dan Bornstein, Dalvik VM Entwickler 06.3 – Anwendungsentwicklung mit Java Android: Größen (dynamisch) Quelle: A JIT Compiler for Android’s Dalvik VM Ben Cheng, Bill Buzbee, May 2010 ● JIT arbeitet Trace-basiert Übersetzung auf Ebene von Basisblöcken (statt ganzen Prozeduren) ● Ein Translation Cache pro Prozess (VM-Instanz) ● ● Trade-off zwischen Performance und Speicherbedarf akzeptabel 06.3 – Anwendungsentwicklung mit Java 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 06.3 – Anwendungsentwicklung mit Java 32 .NET Compact Framework ● ● 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 Anwendungsentwicklung in MS Visual Studio ● Diverse Bibliotheken ● - Benutzerschnittstelle, Kommunikation, … - Allerdings an diversen Stellen beschnitten ➔ Größenreduktion des .NET Frameworks von 20 MB auf 1,35 MB! 06.3 – Anwendungsentwicklung mit Java 33 Inhalt ● Motivation ● Java 2 Micro Edition Java Card Alternativen ● ● Android ● .NET Compact ● ● Zusammenfassung 06.3 – Anwendungsentwicklung mit Java 34 Zusammenfassung ● Java-Umgebungen bilden eine Produktlinie ● ● Bei den kleineren Varianten gibt es Einschränkungen ● ● Skalierbarkeit von 8 Bit Chipkarten bis 64 Bit Serversystemen z.B. keine Garbage Collection bei Java Card Es gibt auch Alternativen ● Dalvik- und MSIL-Programme haben kompakteren Code ● J2ME scheint im Mobiltelefonbereich langsam verdrängt zu werden 06.3 – Anwendungsentwicklung mit Java 35 Literatur [1] [2] M. de Jode, Programming Java 2 Micro Edition on Symbian OS, ISBN 0-470-09223-8, Wiley, 2004. Java Card Platform Specification 2.2.2, Sun Microsystems. 06.3 – Anwendungsentwicklung mit Java 36
