2 Ein Streifzug über die J2ME

Transkript

1 7 The nice thing about standards is that you have so many to choose from; furthermore, if you don t like any of them, you can just wait for next year s model. Andrew S. Tanenbaum Die Java 2 Micro Edition ist die»kleinste«der drei Java-Editionen und das in mehrerlei Hinsicht. Zum einen ist sie für den Einsatz in kleinen Endgeräten ausgelegt, die erheblich weniger Rechenleistung und Speicherkapazität aufbieten können als die Desktop- und Serversysteme, auf denen die J2SE und J2EE zum Einsatz kommen. Als Folge dieser Ressourcenbeschränkung fällt zum anderen der Funktionsumfang, gemessen an der Zahl der Programmierschnittstellen in den Klassenbibliotheken, bei der Micro Edition zwangsläufig bescheidener aus als bei den mächtigeren Editionen. Ferner ist der Leistungsumfang der Java Virtual Machine eingeschränkt, was sich etwa im Fehlen eines Just-in-Time-Compiler niederschlagen kann. Zu guter Letzt unterstützt die virtuelle Maschine nicht notwendigerweise den vollständigen Java-Sprachumfang, so wie er aus der Standard Edition bekannt ist. Trotzdem erscheint die J2ME häufig als die am schwierigsten zu durchschauende Edition. Das mag zum Teil daran liegen, dass sich die zumeist vorhandenen Erfahrungen aus J2SE-Projekten nicht unverändert auf J2ME-basierte Entwicklungen übertragen lassen. Denn mitunter existieren für eine bestimmte Aufgabe, etwa Netzwerkprogrammierung oder die Gestaltung von Bedienoberflächen, um nur zwei Beispiele zu nennen, in der J2SE und J2ME unterschiedliche Philosophien und Programmierschnittstellen. Zum größeren Teil resultieren die Einstiegshürden aber wohl aus dem Fehlen einer einheitlichen, durchgängigen Spezifikation und einer umfassenden Referenzimplementierung. Vielmehr gibt es mehrere, teilweise aufeinander aufbauende, sich teilweise überlappende und sich zum anderen Teil gegenseitig ausschließende Spezifikationen, die in der Summe unter dem Begriff»J2ME«firmieren. Referenzimplementierungen sind dementsprechend auch nur für einzelne Spezifikationen oder Gruppen von verwandten Spezifikationen erhältlich.

2 8 2.1 Konfigurationen, Profile und optionale Pakete JVM und KVM Zwei Säulen Java Specification Request Um einen ersten Überblick über die Rolle der diversen Konfigurationen, Profile und optionalen Pakete innerhalb des J2ME-Rahmenwerks zu geben und ihre wechselseitigen Abhängigkeiten aufzuzeigen, ist eine grafische Darstellung wie in Abbildung 2 1 recht hilfreich. Sie reflektiert die in Abschnitt angerissene Dreischichtenarchitektur. Die Konfiguration in der unteren Schicht stellt eine Klassenbibliothek und eine virtuelle Maschine eine vollständige Java Virtual Machine (JVM) bei der CDC und eine abgespeckte Kilobyte Virtual Machine (KVM) bei der CLDC für die darüber angesiedelten Profile und optionalen Pakete zur Verfügung. Der Funktionsumfang der Konfiguration spiegelt die Leistungsfähigkeit einer Klasse von Endgeräten wider: Die CLDC ist für stark ressourcenbeschränkte Ablaufumgebungen ausgelegt, die CDC benötigt schon eine etwas mächtigere Grundlage. Die Profile und (in manchen Fällen) die optionalen Pakete sind an eine bestimmte Konfiguration gebunden. Das Foundation Profile setzt beispielsweise bestimmte Klassen und Leistungsmerkmale in der virtuellen Maschine voraus, die bei der CLDC nicht vorhanden sind. Wegen dieser Abhängigkeiten haben sich innerhalb der J2ME de facto zwei getrennte Säulen herausgebildet. Die Spezifikationen der einzelnen Konfigurationen, Profile und optionalen Pakete gehen aus verschiedenen JCP-Gruppen hervor. Startpunkt der Aktivitäten einer Gruppe ist ein so genannter Java Specification Request (JSR), das Resultat ist eine Spezifikation und in der Regel eine dazu korrespondierende Referenzimplementierung. Die Ergebnisse sind unter der Adresse ver- Abb. 2 1 Editionen, Konfigurationen, Profile und optionale Pakete Java 2 Enterprise Edition (J2EE) RMI Java 2 Micro Edition (J2ME) Optionale Pakete WMA MMAPI PDA BT Web Svc. Location SIP API Personal Java 2 Standard Edition (J2SE) Personal Basis Foundation Profile CDC MIDP IMP CLDC Profile JVM JVM KVM

3 2.1 Konfigurationen, Profile und optionale Pakete 9 fügbar. Diese Seite ist jedoch nicht auf die Micro Edition spezialisiert, sondern beinhaltet auch Arbeiten aus dem J2SE- und J2EE-Umfeld. Ist die Gruppennummer bekannt, so ist mit einer speziellen URL ein direkter Zugriff möglich, z. B. für JSR-139. Für die Konfigurationen zeichnen drei Gruppen verantwortlich, die in Tabelle 2 1 zusammengestellt sind. JSR Gegenstand Ver. 30 Connected, Limited Device Configuration (CLDC) Connected, Limited Device Configuration (CLDC) Connected Device Configuration (CDC) 1.0 Tab. 2 1 J2ME-Konfigurationen Die Profile sind in Tabelle 2 2 aufgelistet. Oberhalb der CLDC gibt es neben dem MIDP, auf das im weiteren Verlauf des Buchs in aller Ausführlichkeit eingegangen wird, mit dem Information Module Profile (IMP) noch ein weiteres Profil. Auf der Seite der CDC existieren drei Profile mit einer»zwiebelartigen«struktur: Das Personal Profile enthält das Personal Basis Profile, das seinerseits das Foundation Profile umschließt. JSR Gegenstand Ver. CLDC CDC 37 Mobile Information Device Profile (MIDP) Mobile Information Device Profile (MIDP) Information Module Profile (IMP) IMP Next Generation Foundation Profile Personal Basis Profile Personal Profile 1.0 Tab. 2 2 J2ME-Profile Das Einsatzgebiet des IMP sind Module, die im Bereich Machine-to- Machine-Kommunikation eine bedeutende Rolle spielen. Bezogen auf Datendienste verfügen diese Module über ähnliche Fähigkeiten wie Mobiltelefone, haben aber keine Bedienoberfläche im gewohnten Sinne und unterstützen keine Sprachtelefonie. Meist finden sich IMP- Module als Komponenten in anderen Produkten und Lösungen wie Automaten oder Ortungseinheiten. Mit dem IMP könnte beispielsweise ein Getränkeautomat selbstständig Nachschub anfordern, sobald ein bestimmter Restbestand an Mineralwasser unterschritten wird. Eine Ortungseinheit mit integriertem GPS-Empfänger könnte Machine-to-Machine: IMP

4 10 Profile für die CDC CDC stagniert CLDC für Mobiltelefone auf einen bestimmten Reiz hin (Lichteinfall, Erschütterung, Temperatur usw.) seine aktuelle Position an einen Server melden. Die Klassenbibliothek des IMP 1.0 ist eine echte Teilmenge des MIDP 1.0. Die nächste Version IMP 2.0, deren Spezifikation zum Zeitpunkt der Manuskripterstellung noch nicht vorlag, soll auf dem MIDP 2.0 basieren, wobei zu erwarten ist, dass darüber hinaus einige neue Funktionen einfließen werden. So haben einige Module etwa Leuchtanzeigen oder ein kleines LCD, bei denen es wünschenswert wäre, sie über das IMP ansteuern zu können. Für die CDC-basierten Profile stand die J2SE 1.3 Pate. Sie definieren sich durchweg als mehr oder weniger umfangreiche Teilmengen der Klassenbibliothek der Standard Edition. Das Foundation Profile ist die kleinste dieser Teilmengen, die unter anderem auf den Bereich der grafischen Bedienoberfläche in Gänze verzichtet. Das Personal Basis Profile übernimmt einen Teil der Pakete des Abstract Window Toolkit (AWT), lässt dabei aber Klassen für schwergewichtige Komponenten wie java.awt.button oder java.awt.list weg. Letztere sind schließlich im Personal Profile enthalten. In der vorangehenden Tabelle fällt auf, dass bei den CDC-Profilen im Unterschied zu den CLDC-Profilen noch keine neueren Versionen der Spezifikationen erschienen sind. Tatsächlich wurden bereits entsprechende JCP-Gruppen eingerichtet, die das Ziel hatten, an der Aktualisierung zu arbeiten. Allerdings konnten sich die Teilnehmer nicht auf eine gemeinsame Linie einigen. Ein Hauptargument bestand darin, dass eine Verbreiterung der Klassenbibliotheken mit den Ressourcenbeschränkungen der Endgeräte kaum in Einklang zu bringen wäre. Vielleicht noch schwerwiegender waren grundsätzliche Bedenken in Bezug auf die langfristige Tragfähigkeit der Architektur von CDC und ihrer Profile. Vor diesem Hintergrund erscheint die Entwicklung bei CDC aus heutiger Sicht eher zu stagnieren. Somit dürften die CLDC, das MIDP und das IMP insgesamt die besseren Perspektiven haben. Aus kommerzieller Sicht ist vor allem die millionenfache Verbreitung von Mobiltelefonen, die diese Spezifikationen unterstützen, und das noch zu erwartende Wachstum interessant. Aus technischer Warte erscheint die künftige Weiterentwicklung gesichert. Die diversen optionalen Pakete, die bereits existieren oder sich derzeit in Vorbereitung befinden, untermauern diese Prognose. In Tabelle 2 3 sind einige dieser optionalen Pakete, von denen eine verabschiedete Spezifikation oder zumindest ein öffentlich zugänglicher Entwurf vorhanden ist, zusammengestellt.

5 2.1 Konfigurationen, Profile und optionale Pakete 11 JSR Gegenstand Ver. 75 PDA Optional Packages Java APIs for Bluetooth Wireless Messaging API (WMA) Mobile Media API (MMAPI) Webservices API Location API SIP API Wireless Messaging API (WMA) 2.0 Tab. 2 3 Optionale Pakete für die CLDC Kapitel 11 geht näher auf optionale Pakete ein. In Kurzform lassen sie sich folgendermaßen charakterisieren: Optionale Pakete Die PDA Optional Packages bieten einerseits Programmierschnittstellen für den Umgang mit Dateien und andererseits Grundfunktionen für die Implementierung von Applikationen wie Terminkalender und Adressbuch. Die Java APIs für Bluetooth erlauben es, eine im Endgerät vorhandenes Bluetooth-Infrastruktur über Java anzusprechen. Das Wireless Messaging API unterstützt das Versenden und Empfangen von Mitteilungen wie Kurznachrichten (SMS) und ab Version 2.0 multimediale Mitteilungen (MMS). Das Mobile Media API ist im Bereich der Medienverarbeitung angesiedelt. Mit seiner Hilfe können Audio- und Videodateien wiedergegeben und aufgezeichnet werden (vgl. Kapitel 10). Das Webservices API vereinfacht die Nutzung von entfernten Diensten über das Simple Object Access Protocol (SOAP). Das Location API ermöglicht es, den aktuellen Ort und die Bewegungsgeschwindigkeit des Endgeräts zu bestimmen. Das SIP API ist eine Programmierschnittstelle für das vielseitige Session Initiation Protocol (SIP), das sich für viele Anwendungen eignet, die ein Sitzungskonzept benutzen [RSL02]. Als Beispiel sei ein Instant-Messaging-Client genannt. Da die Gerätehersteller unterschiedliche Schwerpunkte setzen, kann die Verfügbarkeit der optionalen Pakete von Hersteller zu Hersteller und innerhalb einer Produktlinie von Modell zu Modell variieren. Die Portabilität von Applikationen, die von optionalen Paketen Gebrauch machen, ist deshalb in der Praxis eingeschränkt. Eine weitere, auf JSR-185 zurückgehende Spezifikation, Java Technology for the Wireless Industry (JTWI), ist ein Versuch, eine Java Technology for the Wireless Industry

6 12 Abb. 2 2 Referenzarchitektur nach JSR-185, Java Technology for the Wireless Industry MIDP 2.0 (JSR-118) MIDlet-Suites, OEM-Anwendungen WMA 1.1 (JSR-120) MMAPI 1.1 (*) (JSR-135) Optionale Pakete OEM- Klassen Nativer Browser Natives AMS / OTA Native Anwendungen CLDC 1.0 (JSR-30) / CLDC 1.1 (JSR-139) Betriebssystem Hardware (*) Subset gemeinsame Basis für Applikationen zu legen, deren Ansprüche die Leistungsmerkmale der Konfiguration und des Profils übersteigen. JTWI stellt eine Art»Gütesiegel«dar: Ein JTWI-kompatibles Gerät implementiert den in JSR-185 festgelegten Funktionsumfang und muss dies in einer umfangreichen Test-Suite nachgewiesen haben. Wie in der JTWI-Referenzarchitektur in Abbildung 2 2 zum Ausdruck kommt, werden neben der CLDC 1.0 oder 1.1 und dem MIDP 2.0 mit dem Wireless Messaging API und (Teilen des) Mobile Media API zwei optionale Pakete gefordert. Diese Pakete betreffen die Grundfunktionalität, die jedes gängige Mobiltelefon beherrscht. Daher liegt der Wunsch, diese Funktionen auch in Java nutzen zu können, auf der Hand. Zusätzliche optionale Pakete und proprietäre Java- Klassenbibliotheken dürfen ebenfalls vorhanden sein. Darüber hinaus bringt JSR-185 einige Konkretisierungen für Aspekte, bei denen die CLDC- und MIDP-Spezifikationen noch Interpretationsspielraum lassen. Während die CLDC beispielsweise nur definiert, dass die Systemuhr über System.currentTimeMillis() ausgelesen werden kann, macht JTWI Vorgaben für die Taktrate der Uhr. 2.2 Anforderungen an die Hardware In Bezug auf ihre Rechenleistung liegen mobile Endgeräte heute in einer ähnlichen Größenordnung wie Heimcomputer vor etwa 20 Jahren. Die Mindestaustattung für ein J2ME-konformes Gerät ist in den Spezifikationen recht detailliert festgehalten, wobei es den einzelnen Herstellern natürlich überlassen bleibt, mehr zu bieten. Im Wesentlichen richten sich die Anforderungen an:

7 2.2 Anforderungen an die Hardware 13 die Speicherkapazität das Display die Eingabemöglichkeiten die Netzwerkanbindung die Multimedia-Fähigkeiten Die für die CLDC, die darauf aufbauenden Profile MIDP und IMP sowie JTWI vorgeschriebenen Werte sind in Tabelle 2 4 zusammengestellt. Merkmal CLDC 1.0 CLDC 1.1 MIDP 2.0 IMP 1.0 JTWI Speicher: - ROM - RAM - Persistent Display: - Auflösung - Farbtiefe Eingabemöglichkeiten Netzwerkanbindung Multimedia 128 kb 32 kb 160 kb 32 kb 256 kb 128 kb 8 kb Bit Tastatur oder Touchscreen 128 kb 32 kb 8 kb Optional Drahtlos, bidirektionale Kommunikation, geringe Bandbreite, keine permanente Verbindung Abspielen von Tönen 256 kb Bit Abspielen von MIDI Tab. 2 4 Hardware-Anforderungen von CLDC, MIDP und IMP Die Tabelle differenziert zwischen drei Speicherarten mit unterschiedlichen Aufgaben: Speicher Im ROM sind Klassenbibliotheken und bei der CLDC auch die virtuelle Maschine implementiert. Das RAM entspricht dem Arbeitsspeicher, der den Applikationen zur Verfügung steht. Der persistente Speicher ist für Anwendungsdaten vorgesehen, die dauerhaft gespeichert werden müssen. Die Speicheranforderungen der Profile sind additiv zu denen der Konfiguration. So benötigt beispielsweise ein Endgerät, in dem die CLDC 1.0 und das MIDP 2.0 realisiert sind, einen RAM-Speicher mit einer Kapazität von 160 kb: 32 kb für die CLDC plus 128 kb für das MIDP. Unterstützt das Gerät darüber hinaus auch noch JTWI entsprechend JSR-185, sind weitere 256 kb fällig.

8 Connected, Limited Device Configuration Die Connected, Limited Device Configuration ist eine Konfiguration für kleine, mobile Terminals wie Mobiltelefone, Smartphones und PDAs, die über eine begrenzte Rechenleistung, eine geringe Speicherkapazität und eine drahtlose Kommunikationsschnittstelle mit niedriger Bandbreite, oftmals bps oder weniger, verfügen. Der Ressourcenlimitierung entsprechend definiert die CLDC: eine Java Virtual Machine mit eingeschränktem Funktionsumfang eine dazu korrespondierende Teilmenge der Sprache Java eine minimale Klassenbibliothek Mittlerweile liegt die CLDC-Spezifikation in zwei Versionen vor. Viele aktuelle Implementierungen basieren noch auf der Version 1.0, die als Grundlage für die Profile MIDP 1.0 und MIDP 2.0 ausreicht. Die CLDC 1.1 hebt einige Einschränkungen hinsichtlich des Sprachumfangs und der Fähigkeiten der virtuellen Maschine auf, erfordert dafür aber auch eine um 32 kb höhere Kapazität im ROM Die Kilobyte Virtual Machine KVM = JVM - x Das wichtigste Entwurfsziel für die virtuelle Maschine der CLDC bestand darin, die essenziellen Eigenschaften der Programmiersprache Java zu unterstützen und gleichzeitig mit einer Speicherkapazität von insgesamt 160 bis 512 kb auszukommen. Entsprechend dem ihr zugedachten Speicherbudget heißt diese virtuelle Maschine Kilobyte Virtual Machine (KVM). Ausgangspunkt für die Spezifikation der KVM ist die JVM der J2SE [LiY99]. Die KVM definiert sich durch Weglassungen: Sie erfüllt alle Eigenschaften der JVM außer denjenigen, die in der CLDC-Spezifikation explizit genannt werden. Für die CLDC 1.0 betreffen die Einschränkungen die folgenden Bereiche: Fließkomma-Arithmetik: Die KVM verarbeitet keine Fließkommazahlen. Begründet wird diese Restriktion dadurch, dass viele CLDC-Geräte über keine Hardware-Unterstützung für Fließkomma-Arithmetik verfügen und eine softwareseitige Implementierung zu rechen- und speicherintensiv wäre. In Programmen, die auf der KVM ablaufen, dürfen dementsprechend die Datentypen float und double sowie die entsprechenden Literale und Operationen nicht verwendet werden. Native Funktionen: Das Java Native Interface (JNI), das in der J2SE Aufrufe nativer Funktionen ermöglicht, ist in der KVM nicht

9 2.3 Connected, Limited Device Configuration 15 vorhanden. Zum einen wäre eine vollständige Implementierung zu umfangreich, zum anderen sollen Anwendungen gar nicht in der Lage sein, die ihnen zugedachte «Sandbox«durch Zugriffe auf interne Funktionen des Endgeräts zu verlassen. Laden von Klassen: Die KVM verwendet einen fest eingebauten Class Loader. Die Möglichkeit, ihn durch einen benutzerdefinierten Class Loader zu ersetzen, besteht nicht. Introspektion (Reflection): Die Fähigkeit, Metadaten über die Struktur von Klassen, Methoden und Variablen zur Laufzeit bereitzustellen, ist in der KVM nicht vorhanden. Programmierschnittstellen wie Serialisierung von Objekten oder eine Remote Method Invocation (RMI), die auf der Introspektion aufgebaut sind, können daher nicht auf die CLDC aufgesetzt werden. Nebenläufigkeit: Die KVM unterstützt nebenläufige Threads, jedoch keine Thread-Gruppen und Daemon Threads. Das in der J2SE verwirklichte Gruppenkonzept ermöglicht es, Threads in hierarchisch untergliederten Einheiten zusammenzufassen und bestimmte Thread- Operationen auf größere Einheiten anzuwenden. In der CLDC muss dies durch einzelne Thread-Aufrufe nachgebildet werden. Die J2SE differenziert ferner zwischen User und Daemon Threads. Die Daemon-Eigenschaft wirkt sich auf das Terminierungsverhalten einer Applikation aus: Der Programmlauf endet mit dem Abschluss des letzten User Thread; etwaige Daemon Threads werden dabei abgebrochen. Garbage Collection: Ein Garbage Collector ist zwar vorhanden, er besitzt aber nicht die Fähigkeit, beim Verdrängen eines Objekts anwendungsspezifische Aufräumarbeiten anzustoßen (»Finalization«). Konsequenterweise gibt es in der Klasse java.lang.object auch keine finalize()-methode, in der diese Aufräumarbeiten bei der J2SE untergebracht sind. Weak References: Im Zusammenhang mit dem Garbage Collector ist weiterhin zu beachten, dass die»weak References«aus dem Paket java.lang.ref in der CLDC nicht zur Verfügung stehen. (Weak References sind Verweise, die im Gegensatz zu herkömmlichen Verweisen ein Verdrängen des Zielobjekts nicht verhindern.) Fehlerbehandlung: Die KVM bietet den aus der J2SE bekannten Exception-Mechanismus zur Fehlerbehandlung. Hierbei werden zwei Kategorien von Ausnahmen unterschieden: geprüfte und ungeprüfte Ausnahmen. Geprüfte Ausnahmen repräsentieren Fehlersituationen, die die Anwendung durch geeignete try-catch-blöcke behandeln muss. Ungeprüfte Ausnahmen können auf dieselbe Weise verarbeitet werden, jedoch kann eine explizite Behandlung

10 16 auch entfallen. Eine spezielle Unterkategorie von ungeprüften Ausnahmen sind die»harten Fehler«unter der Oberklasse java.lang.error. Die KVM unterstützt die meisten der in der J2SE definierten Fehler nicht. Die CLDC-Spezifikation schreibt vor, dass die entsprechenden Fehlerfälle entweder auf implementierungsabhängige Weise zu behandeln sind oder als Instanz einer»ähnlichen«ausnahme an das Anwendungsprogramm gemeldet werden. javac ist zu großzügig Durch diese Einschränkungen vereinfacht sich die Implementierung der KVM im Vergleich zu einer vollwertigen Java Virtual Machine erheblich. Mit dem Verzicht auf die Fließkomma-Arithmetik entfallen z. B. sämtliche Bytecodes für float- und double-operationen. Zum Laden, Speichern, Konvertieren, Addieren, Multiplizieren, Dividieren usw. sind in der Summe immerhin 46 verschiedene Bytecodes zu veranschlagen. Im Umkehrschluss bedeutet das aber auch, dass eine.class-datei, wie sie der J2SE-Compiler javac produziert, unter Umständen Bytecodes enthält, die die KVM nicht verarbeiten kann. Man könnte zwar einen speziellen Compiler für die CLDC bauen, der alle Restriktionen berücksichtigt und ungültige Quelltexte ablehnt. In der Praxis nimmt man jedoch die Asymmetrie zwischen Compiler und virtueller Maschine in Kauf und setzt den eigentlich zu großzügigen Compiler aus der J2SE ein. Etwaige über den Funktionsumfang der KVM hinausreichende Bytecodes in einer.class-datei werden durch den Bytecode-Verifikator abgewiesen Die Bytecode-Verifikation Bytecode-Verifikation in zwei Phasen Für ressourcenbeschränkte mobile Endgeräte ist der konventionelle Bytecode-Verifikator der J2SE ungeeignet. Denn seine Implementierung erfordert mindestens 50 kb Speicherplatz für den Binärcode und, in Abhängigkeit der überprüften.class-datei, zwischen 30 und 100 kb Arbeitsspeicher zur Laufzeit. Darüber hinaus benötigt der eingesetzte iterative Algorithmus zur Datenflussanalyse ein hohes Maß an Rechenleistung. In der CLDC kommt ein alternativer Ansatz zur Anwendung, der sich mit einem kleineren Speicherbudget begnügt. Der Bytecode-Verifikator der KVM umfasst nur etwa 10 kb Binärcode und benötigt zur Laufzeit ca. 100 Byte Arbeitsspeicher für eine typische.class-datei. Wie Abbildung 2 3 zeigt, findet die Überprüfung einer.class-datei in zwei aufeinander folgenden Phasen statt:

11 2.3 Connected, Limited Device Configuration 17 Entwicklungsumgebung HelloCLDCWorld.java HelloCLDCWorld.class Prä- verifikator HelloCLDCWorld.class javac Download Ablaufumgebung (KVM) Abb. 2 3 Zweiphasige Bytecode- Verifikation in der CLDC Laufzeitverifikator Der Präverifikator fügt spezielle Attribute in die.class-datei ein, die die anschließende Laufzeitverifikation vereinfachen. Das Ergebnis des Präverifikatorlaufs ist eine gültige.class-datei mit zusätzlichen»stackmap«-attributen, die sich in einem Größenzuwachs um etwa 5 bis 15 % niederschlagen. Das Format der Ausgabedatei ist voll kompatibel zur J2SE, sodass präverifizierter Bytecode auch in einer herkömmlichen JVM ablauffähig ist: Die zusätzlichen Attribute werden einfach ignoriert. Der Präverifikator muss noch eine weitere Form der Manipulation an der.class-datei vornehmen, um den Laufzeitverifikator zu entlasten. Subroutinenaufrufe werden mit einer»inlining«-technik durch äquivalente Codesequenzen substituiert. Subroutinen sind durch die Bytecodes jsr, jsr_w, ret und wide ret gekennzeichnet. Durch das Inlining verschwinden alle diese Bytecodes aus der.class-datei. Der Laufzeitverifikator gewährleistet die Typsicherheit. Jedweder Code, der den Laufzeitverifikator passiert, kann das Java-Typsystem nicht verletzen und besitzt keine Möglichkeit, auf ungültige Speicherbereiche zuzugreifen. Der Laufzeitverifikator akzeptiert nur präverifi- Interpreter 1. Der Präverifikator verarbeitet zunächst die vom Compiler generierte.class-datei. Der Präverifikator hat die Aufgabe, zeitund ressourcenintensive Überprüfungen vorzunehmen und eine semantisch äquivalente.class-datei zu erzeugen, die sich zur Laufzeit effizient überprüfen lässt. Üblicherweise läuft der Präverifikator in der Entwicklungsumgebung, in der der Quellcode geschrieben und übersetzt wird. 2. Der Laufzeitverifikator erhält eine präverifizierte.class-datei und überprüft die darin enthaltenen Bytecodes, bevor sie im Interpreter zur Ausführung gelangen. StackMap-Attribute Inlining

12 18 Abb. 2 4 CLDC-Klassenbibliothek J2SE CLDC Klassen und Interfaces außerhalb der J2SE dürfen den Namensraum java.* nicht benutzen javax.microedition.io java.lang, java.util, java.io zierte.class-dateien. Fehlende oder inkorrekte»stackmap«-attribute führen dazu, dass der Bytecode abgelehnt und erst gar nicht an den Interpreter weitergegeben wird Die Klassenbibliothek Zwei Teilbereiche Die Bibliothek der CLDC umfasst grundlegende Klassen und Interfaces, die ein gemeinsames Fundament für die Anwendungsentwicklung auf der einen Seite und für die Definition von weitergehenden Profilen auf der anderen Seite schaffen. Der überwiegende Teil der Bibliothek ist eine Teilmenge der J2SE-Bibliothek, woraus ein gewisses Maß an Aufwärtskompatibilität resultiert. Auch wenn die Aufwärtskompatibilität eine wünschenswerte Eigenschaft darstellt, führen starke interne Abhängigkeiten in den J2SE-Klassen, insbesondere in den Bereichen Sicherheit, Ein-/Ausgabe, Bedienoberflächen, Kommunikation und Persistenz, dazu, dass für die CLDC teilweise auch neue Programmierschnittstellen definiert werden mussten. Die CLDC-Bibliothek lässt sich, wie Abbildung 2 4 zeigt, in zwei Bereiche unterteilen: in die aus der J2SE-Bibliothek übernommenen Deklarationen in den Paketen java.lang, java.util und java.io in die CDLC-spezifischen Deklarationen in javax.microedition.io Eine Kurzcharakterisierung der Pakete ist Tabelle 2 5 zu entnehmen. Tab. 2 5 Pakete der CLDC Paket java.lang java.util java.io javax.microedition.io Inhalt Fundamentale Klassen Kollektionen, Datum und Uhrzeit, Zufallszahlengenerator Stream- und Reader-Klassen für Ein- und Ausgaben Generic Connection Framework

13 2.3 Connected, Limited Device Configuration 19 Tabelle 2 6 enthält eine Zusammenstellung der in der CLDC 1.0 verfügbaren Klassen und Interfaces. Die Namen von Interfaces erscheinen in Kursivschrift. Ausnahmen sind in der Tabelle nicht berücksichtigt. java.lang java.util java.io javax.microedition.io Object Vector InputStream Connection Class Stack OutputStream StreamConnectionNotifier Runtime Hashtable ByteArrayInputStream InputConnection System Enumeration ByteArrayOutputStream OutputConnection Thread Calendar DataInput StreamConnection Runnable Date DataOutput ContentConnection String TimeZone DataInputStream DatagramConnection StringBuffer Random DataOutputStream Connector Throwable PrintStream Boolean Reader Byte Writer Short InputStreamReader Integer OutputStreamReader Long Character Math Tab. 2 6 Klassen und Interfaces in der CLDC 1.0 (ohne Ausnahmen) java.lang, java.util und java.io umfassen jeweils nur eine Teilmenge des gleichnamigen Pakets der J2SE. Das bedeutet, dass zum einen nicht alle Klassen, Interfaces und Ausnahmen der J2SE übernommen wurden. Zum anderen bieten die verfügbaren Klassen nicht notwendigerweise alle Methoden und Konstanten an, die es in der entsprechenden Klasse in der J2SE gibt. Die Weglassungen sind zum überwiegenden Teil motiviert durch: Limitationen der KVM Bereinigung von veralteten Deklarationen Unter anderem stehen die folgenden Methoden in der CLDC 1.0 nicht zur Verfügung: Einschränkungen In java.lang.object fehlen finalize() und clone() Die Wrapper-Klassen java.lang.byte, java.lang.integer usw. verzichten auf Konvertierungsfunktionen für Fließkommazahlen wie floatvalue() und doublevalue().

14 20 In java.lang.math gibt es keine Rechenfunktionen mit Fließkommazahlen wie abs(), acos(), asin(), atan(), atan2() etc. In java.util.date wurden tostring() und zahlreiche obsolete Methoden gestrichen Neuerungen in der CLDC 1.1 Mit der voranschreitenden Weiterentwicklung im Bereich der mobilen Endgeräte nimmt auch die Rechenleistung und Speicherkapazität stetig zu. Dementsprechend wurde die KVM in der Nachfolgeversion CLDC 1.1 mit zusätzlichen Fähigkeiten ausgestattet: Fließkomma-Arithmetik Weak References Zusätzliche Klassen Die Implementierung der KVM wächst dadurch um 32 kb an. Sinnvollerweise sollte der eingesetzte Zentralprozessor Fließkommazahlen beherrschen. Andernfalls emuliert die KVM die diesbezüglichen Bytecodes softwareseitig, was natürlich Performanzeinbußen mit sich bringt. Um die neuen Fähigkeiten für Anwendungsprogramme nutzbar zu machen, wurden der Klassenbibliothek zusätzliche Klassen und Ausnahmen sowie weitere Methoden zu den bereits in der CLDC 1.0 vorgesehenen Klassen hinzugefügt. Alle diese Klassen, Methoden und Konstanten stammen aus der J2SE-Bibliothek. Die neuen Klassen und Ausnahmen sind: java.lang.float java.lang.double java.lang.noclassdeffounderror (Ausnahme) java.lang.ref.reference java.lang.ref.weakreference Die Fließkomma-Arithmetik wird unter anderem durch die folgenden Deklarationen unterstützt: In java.lang.math: Konstanten E und PI, Methoden cos(), sin(), tan(), sqrt() usw. In den Wrapper-Klassen wie java.lang.byte, java.lang.integer usw.: floatvalue() und doublevalue() In java.lang.string: valueof(float f) und valueof(double d)

15 2.4 Mobile Information Device Profile 21 Daneben gibt es noch einige weitere neue Methoden, z. B.: java.util.date überschreibt die von java.lang.object geerbte Methode tostring(), sodass das Ergebnis eines Methodenaufrufs wie in der J2SE eine lesbare Datums- und Zeitangabe darstellt. java.lang.thread enthält jetzt die Methode interrupt(), mit der sich ein Thread unterbrechen lässt. 2.4 Mobile Information Device Profile Das wichtigste Profil für die CLDC ist das Mobile Information Device Profile, das Eingang in zahlreiche Mobiltelefone der Mittel- und Oberklasse gefunden hat. Mit dem MIDP 1.0 und MIDP 2.0 liegen derzeit zwei Versionen der Spezifikation vor. Beide sind sowohl mit der CLDC 1.0 als auch mit der CLDC 1.1 als Unterbau verträglich Die Klassenbibliothek Die MIDP-Klassenbibliothek ist als Ergänzung der Klassenbibliothek der CLDC zu verstehen. Zusammen bieten sie eine recht umfangreiche Sammlung von Programmierschnittstellen, mit denen sich vollwertige Anwendungen für mobile Endgeräte implementieren lassen. Die Schwerpunkte der APIs liegen in den Bereichen: Das MIDP ergänzt die CLDC Steuerung des Applikationslebenszyklus Bedienoberflächen 2D-Spiele Medienverarbeitung Kommunikation Verwaltung persistenter Daten Die Funktionalität verteilt sich auf eine Reihe von Java-Paketen, die in Tabelle 2 7 überblicksartig zusammengefasst sind. Zum Teil sind das Pakete, die bereits in der CLDC definiert sind und im MIDP einfach um zusätzliche Deklarationen erweitert werden. Zum überwiegenden Teil handelt es sich jedoch um neue Pakete. Im oberen Bereich der Tabelle sind die aus der CDLC stammenden Pakete zu sehen. Die rechte Spalte beschreibt die zusätzlichen Inhalte, die im MIDP hinzukommen. Im unteren Bereich der Tabelle stehen die neuen Pakete mit einer Charakterisierung ihres Inhalts. Auf die Verwendung der neuen Pakete gehen die folgenden Kapitel noch detailliert ein.

16 22 Tab. 2 7 Pakete im MIDP Paket java.lang java.util java.io javax.microedition.io javax.microedition.midlet javax.microedition.lcdui javax.microedition.lcdui.game javax.microedition.media javax.microedition.media.control javax.microedition.pki javax.microedition.rms Inhalt Das MIDP fügt IllegalStateException zu diesem Paket hinzu. Die Erweiterung war erforderlich, weil java.util.timer in manchen Situationen eine IllegalStateException auslöst. Neu sind hier die beiden Klassen Timer und TimerTask. Keine Erweiterungen gegenüber der CLDC Das Generic Connection Framework ist im MIDP um Deklarationen für die Protokolle UDP, HTTP, HTTPS und SSL sowie für die Kommunikation über serielle Schnittstellen erweitert. Grundfunktionalität für Applikationen, unter anderem Steuerung des Lebenszyklus Das Lowest Common Denominator User Interface (LCDUI) unterstützt die Implementierung von Bedienoberflächen. Das Game API vereinfacht die Programmierung von 2D-Spielen. Das MIDP 2.0 Media API (M2MAPI) dient der Wiedergabe und Aufzeichnung von Medien. Dieses Paket repräsentiert Zertifikate einer Public Key Infrastructure. Die Zertifikate werden unter anderem bei sicheren Verbindungen über SSL und HTTPS eingesetzt. Das Record-Management-System (RMS) ist eine einfache, satzorientierte Datenbankschnittstelle, über die sich persistente Daten im Endgerät verwalten lassen Der Begriff der MIDlet-Suite MIDlet MIDlet-Suite Anwendungen für das MIDP heißen MIDlets. Ein MIDlet ist eine gewöhnliche Java-Klasse, die von der abstrakten Klasse MIDlet aus der MIDP-Bibliothek abgeleitet ist und Implementierungen für die Lebenszyklusmethoden zum Starten, Pausieren und Beenden enthält. Daneben kann die Anwendung weitere benutzerdefinierte Klassen und Interfaces umfassen. Ein oder mehrere MIDlets bilden eine MIDlet-Suite. Eine MIDlet- Suite ist die kleinste installierbare Einheit; isolierte MIDlets sind für den Zweck der Installation ungeeignet. Die Zugehörigkeit eines MIDlet zu einer MIDlet-Suite hat verschiedene Auswirkungen, und zwar unter anderem die folgenden:

17 2.4 Mobile Information Device Profile 23 Berechtigungen zur Verwendung sensibler Teile der Programmierschnittstellen (z. B. für das Versenden von Kurznachrichten) werden auf MIDlet-Suite-Ebene eingestellt. Alle MIDlets in einer MIDlet-Suite verfügen somit über dieselbe Berechtigungsstufe; eine feinere Differenzierung ist nicht möglich. Persistente Datenbestände, die von einem MIDlet angelegt werden, sind für die anderen MIDlets sichtbar und zum Lesen, Überschreiben und Löschen freigegeben. Dagegen lässt sich der Zugriff für MIDlets aus anderen MIDlet-Suites sperren oder auf lesende Operationen beschränken. Innerhalb einer MIDlet-Suite werden Klassenvariablen, das heißt Variablen, die als static vereinbart sind, von allen MIDlets geteilt. Über diesen Mechanismus ist prinzipiell eine Kommunikation zwischen mehreren gleichzeitig ablaufenden MIDlets realisierbar, sofern sich diese in derselben MIDlet-Suite befinden. Eine MIDlet-Suite wird als.jar-archiv verpackt (vgl. Abb. 2 5), dessen Inhalt sich zusammensetzt aus: den präverifizierten.class-dateien der enthaltenen MIDlets, ggf. weiteren Ressourcen wie Icons, Grafiken, Hilfetexten usw. und einem Manifest..class-Dateien Ressourcen Paketieren.jar-Archiv Abb. 2 5 Paketieren Manifest Das Manifest ist eine Textdatei mit dem Namen MANIFEST.MF, die Metainformationen in Form von Attributvereinbarungen enthält. Hier kommt ein einfaches Beispiel für ein vollständiges Manifest: Manifest MIDlet-Name: Meine MIDlet-Suite MIDlet-Version: 1.0 MIDlet-Vendor: dpunkt.verlag MicroEdition-Profile: MIDP-2.0 MicroEdition-Configuration: CLDC-1.0 MIDlet-1: Hallo MIDP Welt, /icons/dpunkt.png, kap2.hellomidpworld Dieses Manifest gehört zu einer MIDlet-Suite mit einem einzigen MIDlet, dessen Implementierung in der Klasse kap2.hellomidpworld vorliegt. Das Attribut MIDlet-1 legt daneben noch einen externen Namen für das MIDlet und ein Icon fest. Die übrigen Attribute, beginnend von oben, definieren den Namen der MIDlet-Suite, ihre Versionsnummer,

18 24 Attribute Tab. 2 8 Attribute für MIDlet-Suites im MIDP 1.0 den Anbieter sowie das Profil und die Konfiguration, die erforderlich sind, um das MIDlet starten zu können. Eine vollständige Liste aller Attribute, die für MIDP 1.0 relevant sind, findet sich in Tabelle 2 8; die mit MIDP 2.0 eingeführten Ergänzungen sind im anschließenden Abschnitt dokumentiert. Die zweite Tabellenspalte drückt aus, ob das jeweilige Attribut im Manifest vorhanden sein muss ( ), optional ist ( ) oder keine Bedeutung hat (kein Symbol). Attribut JAR JAD Beschreibung MIDlet-Name Extern sichtbarer Name der MIDlet-Suite MIDlet-Version Versionsnummer der MIDlet-Suite MIDlet-Vendor Name des Anbieters MicroEdition-Profile Name und Versionsnummer des Profils, mit dem die MIDlets lauffähig sind (z. B.»MIDP-2.0«) MicroEdition-Configuration Name und Versionsnummer der Konfiguration, die die MIDlets benötigen (z. B.»CLDC-1.0«) MIDlet-<n> Externer Name, ein optionales Icon sowie der vollqualifizierte Klassenname des n-ten MIDlet der MIDlet-Suite MIDlet-Jar-URL URL zum Laden des.jar-archivs MIDlet-Jar-Size Größe des.jar-archivs in Bytes MIDlet-Icon Icon (als Pfadname einer.png-datei im.jar-archiv) zur externen Repräsentation der MIDlet-Suite MIDlet-Description Textuelle Beschreibung der MIDlet-Suite MIDlet-Info-URL URL, unter der weitere Informationen über die MIDlet-Suite stehen MIDlet-Data-Size Mindestgröße (in Bytes) des persistenten Speichers, den die MIDlet-Suite benötigt, um korrekt arbeiten zu können MIDlet-Install-Notify URL, an die nach dem Installieren der MIDlet-Suite ein HTTP-POST-Request abgesetzt werden soll MIDlet-Delete-Confirm Eine Mitteilung an den Benutzer, die vor dem Deinstallieren der MIDlet-Suite eingeblendet wird MIDlet-Delete-Notify URL, an die nach dem Deinstallieren der MIDlet-Suite ein HTTP-POST-Request geschickt werden soll Anwendungsspezifische Attribute Weitere Parameter für MIDlets; die Attributnamen dürfen jedoch nicht mit»midlet-«oder»microedition-«beginnen

19 2.4 Mobile Information Device Profile 25 Die dritte Spalte bezieht sich auf den Applikationsdeskriptor der MIDlet-Suite, der neben dem.jar-archiv vorhanden sein kann (aber nicht muss). Für den Applikationsdeskriptor, eine Datei mit der Endung.jad, gilt dieselbe Syntax wie für das Manifest und auch bei den vorgesehen Attributen gibt es weitgehende Übereinstimmung. Der Mehrwert des Applikationsdeskriptors wird beim Installieren der MIDlet- Suite deutlich: Mit der relativ kompakten.jad-datei existiert ein Mechanismus, wichtige Informationen über eine MIDlet-Suite in der Zielumgebung bekannt zu machen noch bevor das umfangreichere.jar-archiv übertragen wird. Unter Umständen zeigt sich nach dem Laden des Applikationsdeskriptors, dass eine Installation des.jar- Archivs gar nicht möglich ist, etwa weil das erforderliche Profil nicht implementiert oder nicht mehr genügend Speicherplatz frei ist. Wie aus Tabelle 2 8 ersichtlich ist, müssen MIDlet-Name, MIDlet- Version und MIDlet-Vendor sowohl im Manifest als auch im Applikationsdeskriptor (mit jeweils übereinstimmenden Werten) erscheinen. Die Attribute MicroEdition-Profile, MicroEdition-Configuration und MIDlet-<n> müssen ebenfalls definiert werden, wobei das gemäß der MIDP-Spezifikation wahlweise innerhalb des Manifests oder des Applikationsdeskriptors erfolgen kann. Da nicht auszuschließen ist, dass sich manche Implementierungen nicht an diese Vorgabe halten, ist es ratsam, diese Attribute in beiden Dateien anzugeben. MIDlet-Jar-URL und MIDlet-Jar-Size werden nur ausgewertet, wenn sie in der.jad-datei stehen; dort sind sie aber verpflichtend einzutragen. Weitere Attribute, einschließlich anwendungsspezifischer Größen, können im Applikationsdeskriptor und/oder im Manifest stehen. Falls ein bestimmtes Attribut sowohl im Applikationsdeskriptor als auch im Manifest auftaucht und unterschiedliche Werte angegeben sind, so gilt der Wert im Applikationsdeskriptor. Diese Aussage ist allerdings nur für MIDlet-Suites gemäß dem MIDP 1.0 haltbar. Im Kontext des MIDP 2.0 ist, wie der folgende Abschnitt zeigt, eine differenziertere Betrachtungsweise notwendig. Applikationsdeskriptor Notwendige Attribute Applikationsdeskriptor geht vor MIDlet-Suites im MIDP 2.0 Mit dem MIDP 2.0 wurde das Konzept von Trusted MIDlet-Suites eingeführt. Manche Methoden in den Klassenbibliotheken, beispielsweise für das Aufbauen einer Netzwerkverbindung zu einem entfernten Server, sind solchen vertrauenswürdigen Programmen vorbehalten. MIDlet-Suites nach dem MIDP 1.0 gelten als nicht vertrauenswürdig. Trusted MIDlet-Suite

20 26 Für Trusted MIDlet-Suites sind widersprüchliche Attributwerte im Manifest und im Applikationsdeskriptor nicht zulässig. Diskrepanzen bei einem oder mehreren Attributen führen zum Abbruch des Installationsvorgangs. Signaturen und Zertifikate X.509 Die MIDP-Spezifikation geht recht ausführlich darauf ein, wie Trusted MIDlet-Suites mit einer Public Key Infrastructure (PKI) nach dem X.509-Standard realisiert werden. Grundlage für PKI-Verfahren sind asymmetrische Verschlüsselungsalgorithmen wie RSA von Rivest, Shamir und Adleman [RSA78], die mit einem Paar von korrespondierenden Schlüsseln arbeiten. Zum Verschlüsseln eines Dokuments wird einer dieser beiden Schlüssel verwendet, für das Entschlüsseln der andere. Ein Schlüssel ist privat, also nur dem Inhaber bekannt, der andere öffentlich, also allgemein zugänglich. Ein Zertifikat ist ein öffentlicher Schlüssel, der durch eine Certificate Authority wie Veri- Sign unterzeichnet wurde. Durch ihre Unterschrift bürgt die Certificate Authority für die Echtheit des Zertifikats. Um zu einem beliebigen Dokument eine Signatur hinzuzufügen, berechnet man eine Prüfsumme über den Inhalt, verschlüsselt diese mit dem privaten Schlüssel und hängt das Ergebnis an das Dokument an. Mithilfe des Zertifikats, das ja den korrespondierenden öffentlichen Schlüssel enthält, kann die Gültigkeit der Signatur überprüft werden. Signatur nicht Eine Voraussetzung für eine Trusted MIDlet-Suite ist das Vorhandensein einer Signatur. Als Unterzeichner kann beispielsweise der hinreichend für Vertrauenswürdigkeit Mobilfunkbetreiber auftreten, der die MIDlet-Suite vertreibt, oder der Softwarehersteller, der sie entwickelt hat. Eine gültige Signatur ist jedoch nicht hinreichend für die Vertrauenswürdigkeit, schließlich sagt sie nichts über die Seriosität des Anbieters aus. Welche signierten MIDlet-Suites als vertrauenswürdig gelten und welche Berechtigungen ihnen eingeräumt werden, ist in der Praxis gerätespezifisch. Signatur erzeugen Realisierungstechnisch ist eine Signatur nichts anderes als ein weiteres Attribut, das in den Applikationsdeskriptor eingebracht wird. Die Erzeugung geht auf folgende Weise vonstatten (siehe Abb. 2 6): Über den Inhalt des.jar-archivs wird eine Prüfsumme berechnet. Die Prüfsumme wird mit dem privaten Schlüssel verschlüsselt. Das Ergebnis wird als Base64-enkodierte Zeichenkette im Attribut MIDlet-Jar-RSA-SHA1 des Applikationsdeskriptors eingetragen. Das.jar-Archiv wird nicht modifiziert.

21 2.4 Mobile Information Device Profile 27 Entwicklungsumgebung Ablaufumgebung Abb. 2 6 Signatur erzeugen und überprüfen Signieren Prüfsumme.jar-Archiv Prüfsumme Applikationsdeskriptor Applikationsdeskriptor (signiert) Überprüfen In der Praxis laufen diese Schritte automatisiert ab. Das dafür zuständige JadTool gehört zum Lieferumfang sowohl der MIDP-Referenzimplementierung als auch des J2ME Wireless Toolkit (siehe Kapitel 3). Der Mehrwert der Signatur kommt bei der Installation der Applikation zum Tragen. Zum einen ist die Signatur ein Hilfsmittel, um die Identität des Anbieters festzustellen. Zum anderen lassen sich mit ihrer Hilfe nachträgliche Manipulationen im.jar-archiv entdecken. Anwendungen von unbekannten oder unseriösen Anbietern und solche, die von Dritten verändert wurden, können so bereits während des Installationsvorgangs verworfen werden, um Schlimmeres zu verhindern. Zur Überprüfung der Signatur wird zunächst der Inhalt des Attributs MIDlet-Jar-RSA-SHA1 gelesen, einer Base64-Dekodierung unterzogen und mittels des öffentlichen Schlüssels entschlüsselt. Das Ergebnis ist die erwartete Prüfsumme des.jar-archivs im Klartext. Als Nächstes wird die Prüfsumme des.jar-archivs neu berechnet und mit der erwarteten Prüfsumme verglichen. Stimmen beide Werte überein, so kann von der Integrität des.jar-archivs ausgegangen werden. Der für die Überprüfung notwendige öffentliche Schlüssel ist in aller Regel nicht in der Ablaufumgebung gespeichert. Angesichts der begrenzten Speicherkapazität eines MIDP-Geräts wäre es alles andere als praktikabel, stets die aktuellen Schlüssel sämtlicher relevanter MIDlet-Anbieter vorzuhalten. Die Spezifikation schreibt deshalb vor, dass das Zertifikat des Unterzeichners gleich im Applikationsdeskriptor mitgeliefert wird, und zwar im Attribut MIDlet-Certificate-1-1. Da der Applikationsdeskriptor nicht notwendigerweise aus einer vertrauenswürdigen Quelle stammt, muss man einkalkulieren, dass es sich bei diesem Zertifikat um eine Fälschung handeln könnte. Bevor es als authentisch gelten kann, muss das Zertifikat also seinerseits erst eine Überprüfung durchlaufen. Das geht so: Es wird erwartet, dass das Zertifikat durch eine anerkannte Certificate Authority signiert wurde. JadTool Signatur überprüfen Wo ist der öffentliche Schlüssel?

22 28 Zertifikatketten Tab. 2 9 MIDP-2.0-spezifische Attribute: Signaturen Die so genannten»root-zertifikate«der wichtigsten Certificate Authorities sind im Endgerät fest hinterlegt. Mit dem Root-Zertifikat der entsprechenden Certificate Authority kann die Gültigkeit der Signatur festgestellt werden. Der Mechanismus ist sogar nicht flexibler: Tatsächlich lassen sich im Applikationsdeskriptor ganze Zertifikatketten unterbringen, in denen jeweils ein Glied zur Überprüfung der Signatur des Vorgängers dient. In folgendem Beispiel ist diese Möglichkeit von Vorteil: Der Softwareanbieter A besitzt ein Zertifikat vom Mobilfunkbetreiber B und signiert damit seine Anwendung. Das Zertifikat von B trägt die Signatur der Certificate Authority C, deren (Root-)Zertifikat in den Endgeräten installiert ist. Der Applikationsdeskriptor muss demzufolge die Zertifikate A und B enthalten, um eine lückenlose Kontrolle im Endgerät zu ermöglichen. Für diesen allgemeinen Fall werden weitere Attribute wie MIDlet-Certificate-1-2 usw. verwendet. Prinzipiell könnte auch eine zweite Zertifikatkette (und weitere) in den Applikationsdeskriptor eingetragen werden, sodass auch Attribute wie MIDlet-Certificate-2-1, MIDlet-Certificate-2-2 usw. möglich sind. Tabelle 2 9 fasst die Attribute für Signaturen und Zertifikate nochmal zusammen. Attribut JAR JAD Beschreibung MIDlet-Jar-RSA-SHA1 Signatur MIDlet-Certificate-<n>-<m> Zertifikat Berechtigungen Über zwei weitere Attribute können signierte MIDlet-Suites Berechtigungen für sensible Programmierschnittstellen anfordern (siehe Tab. 2 10). Tab MIDP-2.0-spezifische Attribute: Berechtigungen Attribut JAR JAD Beschreibung MIDlet-Permissions Berechtigungen, die zum Ausführen der MIDlet-Suite zwingend erforderlich sind MIDlet-Permissions-Opt Berechtigungen, die wünschenswert, aber verzichtbar sind Selbst wenn diese Attribute rein formal auch im Manifest stehen können, erscheint es in der Praxis sinnvoller, sie im Applikationsdeskriptor unterzubringen. Denn so lässt sich bei der Installation frühzeitig überprüfen, ob der MIDlet-Suite alle notwendigen Berechtigungen zustehen. Beispielsweise bedeutet der folgende Eintrag, dass die Anwendung auf die seriellen Schnittstellen des Endgeräts zugreifen möchte:

23 2.4 Mobile Information Device Profile 29 MIDlet-Permissions: javax.microedition.io.connector.comm Falls der MIDlet-Suite diese Berechtigung nicht zusteht, wird die Installation abgebrochen, ohne das.jar-archiv herunterzuladen. Weitere Einzelheiten zum Berechtigungskonzept und seiner Verwendung bei der MIDlet-Programmierung liefert Unterkapitel 4.4. Push Registry Eine weitere nützliche Neuheit im MIDP 2.0 ist die Push Registry. Dahinter verbirgt sich ein neuer Aktivierungsmechanismus: Während MIDlets im MIDP 1.0 nur durch den Benutzer aktiviert werden konnten, vermag das MIDP 2.0, MIDlets beim Eintreten von bestimmten Ereignissen automatisch zu starten. Die betreffenden MIDlets werden über ein spezielles Attribut im Manifest oder im Applikationsdeskriptor bei der Push Registry angemeldet (siehe Tab. 2 11). Einzelheiten zur Verwendung beschreibt Unterkapitel 8.5. Attribut JAR JAD Beschreibung MIDlet-Push-<n> Spezifikation eines MIDlet zur Aktivierung durch die Push Registry Push Registry Tab MIDP-2.0-spezifische Attribute: Push Registry Over-the-Air Provisioning Vorgänge wie die Installation von MIDlet-Suites, das Einspielen einer neuen Version einer vorhandenen MIDlet-Suite und ihre Deinstallation laufen unter der Kontrolle der so genannten Application Management Software (AMS) ab. Die AMS ist eine essenzielle Komponente in jedem MIDP-kompatiblen Gerät. In ihren Verantwortungsbereich fällt auch die Steuerung des MIDlet-Lebenszyklus, zu dem Aktionen wie das Starten, Pausieren und Beenden gehören. Die Installation vollzieht sich in mehreren Schritten und involviert, wie das Sequenzdiagramm in Abbildung 2 7 zeigt, neben der AMS einige weitere Akteure: AMS Installationsvorgang Der JAD-Server bietet den Applikationsdeskriptor an. Der JAR-Server stellt das.jar-archiv zur Verfügung. Der Notification-Server nimmt Rückmeldungen über den Installationserfolg entgegen. Der Datenaustausch zwischen der AMS, die als Client agiert, und den Servern läuft über HTTP. Vielfach werden die drei serverseitigen Rollen von einem einzigen Web-Server ausgefüllt. Da sich die AMS in einem mobilen Endgerät befindet, das über eine Funkschnittstelle mit

24 30 Abb. 2 7 OTA-Provisioning AMS JAD- Server JAR- Server Notification- Server GET /midlet.jad 200 OK GET /midlet.jar 200 OK POST /install-notify 900 Success 200 OK MIDlet-Jar-URL MIDlet-Install-Notify der Außenwelt kommuniziert, bezeichnet man den Installationsvorgang im Englischen auch als Over-the-Air Provisioning oder kurz OTA-Provisioning. Der erste Schritt besteht darin, dass die AMS den Applikationsdeskriptor midlet.jad lädt und die darin definierten Attribute auswertet. Eines der Attribute, MIDlet-Jar-URL, liefert eine Adresse, von der das.jar-archiv bezogen werden kann. Ist das Attribut MIDlet-Install-Notify vorhanden, so sendet die AMS nach dem Laden des Archivs eine Rückmeldung an die in MIDlet-Install-Notify spezifizierte URL. Daraus geht hervor, ob die Installation fehlerfrei abgeschlossen wurde. Diese Information ist insbesondere bei kommerziellen Angeboten mit kostenpflichtige Anwendungen wichtig. Schließlich soll der Kaufpreis nur abgebucht werden, wenn die Anwendung vollständig beim Kunden angekommen ist. Andernfalls kann sich der Anbieter darauf vorbereiten, nach dem Versand der Rechnungen eine Flut von Reklamationen zu bearbeiten. Nach einer erfolgreichen Installation wird beispielsweise ein HTTP-POST-Request wie der folgende abgesetzt: POST HTTP/1.1 Host: foo.bar.com Content-Length: Success Der Statuswert im Bereich von 900 bis 999 wird im Request-Body übertragen. Der Wert 900 steht für einen fehlerfreien und vollständigen Abschluss des Installationsvorgangs, alle andere Werte repräsentieren Fehlerfälle.