JavaME Profile und optionale Pakete
Werbung
Westfälische Wilhelms-Universität Münster Ausarbeitung JavaME Profile und optionale Pakete im Rahmen des Seminars Mobile Java Peter Grosskopf Themensteller: Prof. Dr. Herbert Kuchen Betreuer: Michael Poldner Institut für Wirtschaftsinformatik Praktische Informatik in der Wirtschaft Inhaltsverzeichnis 1 Einleitung...............................................................................................................3 1.1 1.1.1 1.1.2 1.1.3 2 Einführung in die JavaME..............................................................................4 Konfigurationen, die Grundlage von Profilen .............................................5 Profile ........................................................................................................6 Optionale Pakete ........................................................................................7 MIDP .....................................................................................................................8 2.1 2.1.1 2.1.2 2.1.3 2.2 2.2.1 2.3 2.3.1 2.3.2 Grundlagen ....................................................................................................8 Architektur.................................................................................................9 Hardwareanforderungen...........................................................................10 Softwareanforderungen ............................................................................12 MIDP 1.0 .....................................................................................................13 Funktionalität und Pakete .........................................................................13 MIDP 2.0 .....................................................................................................14 Unterschiede zur Vorversion ....................................................................14 Sicherheitsaspekte....................................................................................15 3 Optionale Pakete...................................................................................................17 4 Ausblick ...............................................................................................................20 Literaturverzeichnis.....................................................................................................22 II Kapitel 1: Einleitung 1 Einleitung Die Programmiersprache Java hat sich im letzten Jahrzehnt zu einer der führenden Programmierumgebungen weltweit entwickelt. Die J2SE (Java 2 Standard Edition) ermöglicht die Entwicklung von Anwendungen für Stand-Alone-PCs. Die Durchdringung von Anwendungsszenarien im betrieblichen Umfeld wird durch die J2EE (Java 2 Enterprise Edition) unterstützt. Mit den Spezifikationen dieser Edition lassen sich komplexe Webanwendungen und Server-Backends programmieren. Mit zunehmender Zeit begannen sich die verschiedenen Java-Versionen immer weiter zu vermischen. Die Grenzen der Plattformen sind fließend, zumal Rich-Clients via Internet auf die Backends der J2EE zugreifen. Die rasante Verbreitung von Handys und PDAs rücken mobile Endgeräte als Clientsysteme immer weiter in den Fokus. Neue Anwendungsmöglichkeiten für Softwareprodukte werden realisierbar. Ein denkbares Szenario wäre beispielsweise, dass ein Außendienstler mit seinem PDA oder Mobiltelefon auf die Serverinfrastruktur seines Unternehmens zugreifen kann, um Informationen abzurufen. Buzzwords wie „Ubiquitous Computing“, vor allem aber „Location Based Services“ [Heise02a] sind momentan allerorten zu vernehmen. Um die Lücke im Java-Portfolio zu schließen, wurde im Jahre 2000 die Java Micro Edition (JavaME) eingeführt. Ziel ist es, die Java-Programmierung für mobile Endgeräte und Embedded Systems zu ermöglichen. Da der Mobilfunkmarkt stark umkämpft ist, ist eine Minimierung der Herstellungskosten erforderlich. Dies führt zum Einbau preisgünstiger Komponenten und damit zu einer Limitierung der Ressourcen wie Rechenleistung und Speicherkapazität [Sc07, S.3]. Die Herausforderung und gleichzeitiges Designziel der JavaME ist es, eine Java-Version für begrenzte Ressourcen zu konzipieren, da sich J2SE und J2EE aufgrund der knappen Speicherressourcen auf mobilen Geräten nicht nutzen lassen. Zugleich müssen unterschiedliche Bedienkonzepte berücksichtigt werden, zumal diese sich von Hersteller zu Hersteller mitunter sehr stark unterscheiden. Die gegebenen Rahmenbedingungen haben zu einer spezifischen Architektur der JavaME geführt. Im ersten Teil der Arbeit wird zunächst in die Architektur und das Design der JavaME eingeführt. Aufbauend auf diesen Grundlagen werden Profile erläutert, welche maßgeblich für die Anwendungsentwicklung im Mobile-Bereich eine Rolle spielen. In Kapitel 2 wird das MIDP im Detail beschrieben. Dieses Profil ist das 3 Kapitel 1: Einleitung am weitesten verbreitete Profil; von daher lohnt sich ein vertiefender Einblick. Um weitergehende Funktionalität zu bieten, werden optionale Pakete benötigt. Kapitel 3 gibt einen Überblick über die wichtigsten optionalen Pakete. 1.1 Einführung in die JavaME Bei der Entwicklung einer Technologie für Java auf mobilen Systemen wurde eine Architektur entworfen, welche es ermöglicht, eine möglichst breite Masse an Geräten anzusprechen. Kennzeichnend Schichtenarchitektur, wie für man diese sie Architektur auch aus ist anderen die Wahl Bereichen einer der Softwareentwicklung, wie der Entwicklung von Web-Applikationen, kennt. Typisch für eine solche ist, dass jede Schicht bestimmte Funktionalitäten bereitstellt. Auf diese kann die darüber liegende Schicht zugreifen; die Zugriffe erfolgen also top-down. Der Vorteil einer solchen Schichtenarchitektur ist es, dass Vereinbarungen zwischen den Schichten in Form von Schnittstellen bzw. Interfaces getroffen werden. Es ist somit leicht möglich, die Schichten auszutauschen, so lange die Schnittstellen eingehalten werden. Wie Abbildung 1 zeigt, besteht die JavaME aus drei Schichten: aus Konfigurationen, Profilen und optionalen Paketen [Sun06a]. Abb.1: JavaME – Schichtenarchitektur. Welche Aufgaben diese Schichten im Einzelnen übernehmen, wird im folgenden Kapitel beschrieben. 4 Kapitel 1: Einleitung 1.1.1 Konfigurationen, die Grundlage von Profilen „Mobile Geräte haben Eigenschaften, aber nicht alle Eigenschaften sind auf allen Geräten verfügbar“ [BM02, S.33]. Ziel der JavaME ist daher, eine Grundfunktionalität der Programmiersprache Java zu bieten und dabei eine einfache Portierbarkeit zwischen den Systemen und Interoperabilität zwischen den Geräten sicherzustellen. Die Java Laufzeitumgebung wird also so angepasst, dass sie zu den entsprechenden Eigenschaften passt. Die erste Schicht, die Konfiguration, abstrahiert von den heterogenen Plattformen. Eine Konfiguration ist eine Spezifikation, die eine Software-Umgebung für eine Palette von Geräten mit bestimmten Merkmalen (Speicher, Prozessor, Networking) definiert [To02, S.5]. Sie besteht aus einer Kombination von einer speziellen ‚Java Virtual Machine’ und einem API, die eine möglichst breite Masse an Geräten unterstützt [BM02, S.33]. Die Vorgabe von bestimmten Merkmalen dient dazu, einen kleinsten gemeinsamen Nenner zu definieren [BM02, S.35]. Nur so kann sichergestellt werden, dass jedes Gerät von jedem Hersteller ohne Anpassungen eine Java-Konfiguration unterstützen kann. Die JavaME beinhaltet zwei verschiedene Konfigurationen: die CLDC (Connected Limited Device Configuration) und die CDC (Connected Device Configuration). CLDC: Die CLDC ist eine Konfiguration für Geräte mit langsamen Prozessoren, wenig Speicherplatz und unzuverlässigen Netzwerkverbindungen [BM02, S.20]. Sie 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, welche Gegenstand des nächsten Kapitels sein werden, auf der anderen Seite schaffen [Sc07, S.17]. Bei der CLDC handelt es sich um eine Konfiguration, welche in Bezug auf den Sprachumfang nur eine Teilmenge der J2SE beinhaltet [Sun06], da die Zielplattform eher kleine, mobile Computer sind und die Hardwareanforderungen so reduziert werden können. Für die CLDC musste daher eine eigene, spezielle Virtual Machine entwickelt werden, die KVM (Kilobyte Virtual Machine). Da die CLDC am weitesten verbreitet ist, liegt der Fokus dieser Arbeit primär auf ihr.. CDC: Die CDC ist eine Konfiguration für größere, teilweise nicht mobile Geräte, wie Set-Top-Boxen und Embedded-Systems mit mindestens 2 Megabyte Speicher [BM02, S.20]. Der Sprachumfang der CDC ist im Gegensatz zur CLDC nicht reduziert. 5 Kapitel 1: Einleitung Die beiden Konfigurationen sind ein Versprechen an den Programmierer, nur für wenige Plattformen entwickeln zu müssen. Er kann sich also auf zwei Plattformen konzentrieren. Die Hersteller hingegen haben den Vorteil, dass sie eine klare Vorgabe haben, welche Spezifikationen ihre Geräte erfüllen müssen, um Java-fähig zu sein. 1.1.2 Profile Die zweite Schicht bilden die Profile. Sie greifen auf die Basisdienste, welche die Konfiguration anbietet, zu, erweitern die Konfiguration allerdings um zusätzliche Features für einen bestimmten Typ von Geräten oder ein bestimmtes vertikales Marktsegment [To02, S.7]. Die zusätzlichen Funktionen werden in Form von APIs (Application Programming Interfaces) zur Verfügung gestellt [Sun06a]. Diese „Higherlevel“-APIs können Aufgaben wie Benutzerschnittstellen, Persistenz oder gerätespezifische Funktionen übernehmen [Sun06a]. Ein Profil ist spezifisch für die zugrunde liegende Konfiguration [Sc07, S.6]. Dies liegt daran, dass sie wie bereits erwähnt die Konfiguration von bestimmten Typen oder Klassen von Geräten erweitern. Für CLDC und CDC gibt es verschiedene Beispiele für Profile. Tabelle 1 listet Profile für die CLDC; Tabelle 2 beschreibt Profile der CDC. Profil MIDP (JSR-37 bzw. 118) Beschreibung Die typische Kombination von Konfiguration und Profil ist CLDC plus MIDP. MIDP steht für ‚Mobile Information Device Profile‘. Das MIDP ist ein Profil, welches Geräte wie Mobiltelefone mit „Higherlevel“-APIs wie UI (Benutzerschnittstellen) und Persistenz ausstattet. IMP (JSR-195) IMP steht für ‚Information Module Profile‘. Es ermöglicht Javafähigen Geräten die Maschine-zu-Maschine-Kommunikation. Es steht ein Subset vom MIDP für Geräte mit wenig oder keinen grafischen Benutzerschnittstellen zur Verfügung. Dieses Profil kann beispielsweise in Getränkeautomaten integriert werden. Der Automat könnte dann den Nachschub selbstständig ordern [Sc07, S.10]. IMP-Next Eine Weiterentwicklung des IMP. IMP-NG ist nur ein Subset der Generation MIDP 2.0. Es werden u.a. die verbesserten Networking- und (JSR-228) Sicherheitsfeatures des MIDP 2.0 aufgegriffen. Tabelle 1: Profile für die CLDC 6 Kapitel 1: Einleitung Profil Beschreibung Personal Profile (JSR-62 Enthält u.a. das AWT (Abstract Window Toolkit) um bzw. 216) eine mächtigere Benutzerschnittstelle zu unterstützen. Es sind dann beispielsweise auch Applets lauffähig. Personal Basis Profile (JSR- Untermenge des Personal Profile. Bietet die 129 bzw. 217) Kernfunktionalität und minimale Grafikunterstützung. Foundation Profile (JSR-46 Untermenge des Personal Basis Profile. Bietet bzw. 219) beispielsweise Netzwerkfunktionalität ohne dabei eine Benutzerschnittstelle zu liefern. Tabelle 2: Profile für die CDC 1.1.3 Optionale Pakete Die optionalen Pakete bilden die oberste der drei Schichten. Sie dienen der Erweiterung der Funktionalität, welche das Profil bietet. Wichtig wird dies an der Stelle, wo speziellere Funktionen eines Endgeräts genutzt werden sollen. Es werden also von bestimmten optionalen Paketen bestimmte Leistungsmerkmale des Gerätes vorausgesetzt, welche einer universellen Verbreitung entgegenstehen. Anwendungen, die optionale Pakete voraussetzen, nähern sich stark nativen Applikationen mit ihrer eingeschränkten Portabilität an [Sc07, S.283]. Im Gegensatz zu der recht überschaubaren Anzahl an Konfigurationen und Profilen, gibt es eine Vielzahl an optionalen Paketen für die JavaME. So werden beispielsweise anwendungsspezifische Erweiterungen für 3D-Grafik, Web Services, Multimedia oder Messaging für Entwickler nutzbar. Um wichtige optionale Pakete zu einem größeren Paket zusammenzuführen, beschäftigt sich der JSR-248 mit der Erstellung der ‚Mobile Service Architecture‘. Diese bezweckt, dass viele der optionalen Pakete weiter verbreitet werden und somit die Basis der Möglichkeiten wächst, welche die JavaME bietet. Optionale Pakete werden in Kapitel 3 nochmals aufgegriffen und genauer vorgestellt. Hierbei wird ein Fokus darauf gelegt, welche Pakete es gibt und was sie leisten. 7 Kapitel 2: MIDP 2 MIDP Nachdem im vorangegangen Kapitel der Aufbau der JavaME beschrieben wurde, wird nun ein vertiefender Einblick in ein exemplarisches Profil vorgenommen. Hierbei wurde das MIDP ausgewählt, zumal es sich dabei um das erste fertig gestellte Profil handelt [Sun06a], welches Sun auf den Markt brachte. Auch ist es das Profil, was momentan am weitesten verbreitet ist. Das MIDP beschreibt eine Spezifikation für mobile Geräte, so genannte MID‘s (Mobile Information Devices). Hiermit sind in erster Linie tragbare Computer, wie Handys und PDAs gemeint. Da für diese Geräte nur die CLDC als Konfiguration in Frage kommt, wird deutlich, dass das MIDP als Erweiterung der Basisdienste dieser Konfiguration entwickelt wurde. Das MIDP liegt in den Versionen 1.0 (JSR-37) und 2.0 (JSR-118) bzw. 2.1 (JSR-118, update) in der finalen und in der Version 3.0 (JSR-271) in der Entwurfsversion vor. Nachdem im folgenden Abschnitt weitere grundlegende Informationen zum MIDP gegeben werden, werden die Versionen 1.0 und 2.0 genauer beschrieben. In diesem Rahmen wird ein Fokus auf die verfügbare Funktionalität und die Bibliotheken gesetzt und die Unterschiede der beiden Spezifikationen herausgestellt. Der mögliche Leistungsumfang des MIDP 3.0 wird im Ausblick am Ende der Arbeit beschrieben. 2.1 Grundlagen Alle Versionen des MIDP werden im Java Community Process (JCP) definiert, diskutiert und zu einer Spezifikation gebracht, wie z.B. die Version 1.0 des MIDP im Jahre 2000. Ziel ist, eine Spezifikation zu erstellen, welche eine erweiterte Architektur vorgibt und eine offene Entwicklungsumgebung von mobilen Anwendungen für Dritte bereitstellt [Sun06b]. Der Fokus liegt auf der Anwendungsprogrammierung, nicht auf der Systemprogrammierung. Bezogen auf das MIDP, sind im JCP sind viele namhafte Firmen aus dem Mobilfunkbereich beteiligt, wie z.B. AOL, Fujitsu, Nokia, NTT DoCoMo, Palm, Siemens und Sony, welche sich von der Technologie weitere Einsatzchancen für ihre Produkte und Dienstleistungen erhoffen. Auch Sun selber beteiligt sich an der Entwicklung der Standards, da eine weitere Verbreitung der JavaPlattform im Interesse der Firma ist und man selbst als Technologieprovider fungiert. Sobald eine Spezifikation im JCP zum Abschluss gebracht wurde, stellt Sun eine MIDP-Referenzimplementierung (MIDP-RI) öffentlich zum Download bereit. Es liegt 8 Kapitel 2: MIDP dann im Aufgabenbereich der Gerätehersteller, eine Portierung für ihre Geräte vorzunehmen [Sc07, S.35]. Das Modell zur Steuerung des Applikationslebenszyklus von MIDP-Anwendungen, ist sehr stark an das der im Webumfeld bekannten Applets angelehnt. Daher werden die auf Basis des MIDP entwickelten Anwendungen MIDlets genannt. MIDlets durchlaufen in ihrem Lebenszyklus verschiedene Zustände. Diese Zustände lassen sich über die MIDP API steuern bzw. aktivieren. MIDlets lassen sich somit in ihrem Aufbau nicht mit herkömmlichen Java-Applikationen vergleichen, zumal diese mittels der main()-Methode aktiviert werden, welche im MIDP-Programmiermodell nicht vorgesehen ist. Ein oder mehrere MIDlets bilden eine größere Einheit, eine MIDlet-Suite. Diese wird als .jar-Archiv verpackt und zur Verteilung angeboten. 2.1.1 Architektur Um den Aufbau des MIDP im Detail zu verstehen, ist es wichtig, sich ein Bild von der Architektur dieses Profils zu machen. Diese Architektur ist in der Spezifikation des MIDP 2.0 (Quelle: [Sun06b]) wie nachfolgend beschrieben. Hinweis: Diese Darstellung befindet sich ebenfalls in der Spezifikation zum MIDP 1.0 und ist daher für beide Versionen gültig. Abb. 2: Die Architektur des MIDP. Quelle: MIDP 2.0 Spezifikation [Sun06b] 9 Kapitel 2: MIDP Die Architektur zeigt eine „high-level“-Sicht, wie das MIDP in ein Endgerät integriert ist. Die Basis bildet das MID, also die Hardware des Endgeräts selbst. Darauf aufbauend befindet sich die Systemsoftware (Native System Software), welche auch AMS (Application Management Software) genannt wird. Diese bildet die Grundlage für sämtliche Anwendungssoftware, vor allem für MIDlets, zumal diese von der AMS gesteuert werden. Die AMS liefert die nötigen Schnittstellen zur Hardware. Herstellerspezifische Bibliotheken ermöglichen die Benutzung der einzelnen Funktionen des Endgeräts. Die nächste Schicht wird von der CLDC vereinnahmt. Auf der CLDC bauen zwei Typen von APIs auf: Die MIDP APIs, welche in diesem Kapitel noch weiter erläutert werden, und OEM-spezifische APIs. OEM-spezifische APIs sind vom Gerätehersteller implementierte APIs. Diese sind notwendig, weil das MIDP nicht alle Funktionalitäten eines Geräts ausschöpfen kann, da es möglichst viele Geräte unterstützen soll. Applikationen, die OEM-spezifische APIs nutzen, sind allerdings nicht mehr interoperabel bzw. plattformunabhängig. Ziel der weiteren Entwicklung des MIDP ist es daher, möglichst viele APIs und Funktionen in die eigene Referenzimplementierung aufzunehmen. Auf den OEM-spezifischen APIs und auf dem MIDP bauen die Anwendungsprogramme auf, welche für das Endgerät programmiert werden. Neben den MIDP und OEM-API-nutzenden Anwendungen sind auch native Anwendungen möglich, welche allerdings keine der Funktionalitäten nutzen, die die Java-Technologie anbietet. Native Applikationen sind daher auch nicht Teil dieser Arbeit. 2.1.2 Hardwareanforderungen „In Bezug auf ihre Rechenleistung liegen mobile Endgeräte heute in einer ähnlichen Größenordnung wie Heimcomputer vor weniger als 20 Jahren.“ [Sc07, S.12] Trotz der rapiden Entwicklung der Rechenleistung ist es auf mobilen Systemen noch nicht möglich, Java-Programme für Desktopsysteme auszuführen. Die Ausführung eines „Hallo Welt“ Java-Programms verlangt beispielsweise bereits 16 MB Speicher [To02, S.11]. 16 MB freien Arbeitsspeicher für ein Java-Programm und im Hintergrund laufende JVM können mobile Systeme nicht bereitstellen. Die Konsequenz für die JavaME wurde bereits an anderer Stelle angedeutet: Der Umfang der Sprache muss so weit reduziert werden, dass die Hardwareanforderungen sinken und die Entwicklung für mobile Geräte möglich wird. Das Ergebnis ist eine minimale Hardwarevoraussetzung, die ein Gerät mitbringen muss, um Java-Programme ausführen zu können. „Minimal“ 10 Kapitel 2: MIDP ist hierbei so zu verstehen, dass Gerätehersteller nach oben Luft für eigene Leistungsmerkmale und Innovationen haben. Die Anforderungen richten sich in erster Linie an folgende Komponenten: Speicher, Display, Eingabemöglichkeiten, Netzwerkanbindung und Multimedia-Fähigkeiten [Sc07, S.12]. Abbildung 3 listet die einzelnen Anforderungen auf. Hinweis: Die Speicheranforderungen sind additiv zu verstehen. Beispiel: Das MIDP 1.0 braucht mit der CLDC 1.0 als Basis 256 KB ROM-Speicher. Abb. 3: Hardwareanforderungen. Quelle: Schmatz [Sc07, S.13] Wie man der obigen Abbildung entnehmen kann, muss das Endgerät bestimmte Mengen an Speicher besitzen. ROM steht für ‚Read Only Memory’. In diesem nicht beschreibbaren Speicher sind die Klassenbibliotheken und auch die JVM untergebracht. Es müssen also zwischen 256 KB und 416 KB Speicher zur Verfügung stehen, um den minimalen Anforderungen für eine bestimmte Zusammenstellung von Konfiguration (CLDC) und Profil (MIDP) zu entsprechen. RAM (Random Access Memory) ist der Arbeitsspeicher, der erforderlich ist, damit Anwendungen ausgeführt werden können. Hier sollten zwischen 64 KB und 160 KB vorhanden sein. Persistenter Speicher lässt sich mit dem Speicherplatz vergleichen, welcher beispielsweise bei herkömmlichen Computersystemen in Form von Festplattenspeicher zur Verfügung steht. Da mobile 11 Kapitel 2: MIDP Geräte keine Festplatten besitzen, muss eine andere Form von Speicher vorhanden sein, z. B. Flashspeicher, damit Anwendungen Daten dauerhaft speichern können. Für den Betrieb des MIDP sollten dafür mindestens 8 KB vorhanden sein. Zusätzlich zu den Speicheranforderungen ist es erforderlich, dass das Gerät über ein Display, Eingabemöglichkeiten, Netzwerkanbindung und rudimentäre Multimediafunktionen verfügt. 2.1.3 Softwareanforderungen Neben den Hardwareanforderungen spielen auch Softwareanforderungen eine Rolle, welche sich auf den Leistungsumfang der Native System Software des mobilen Geräts beziehen Diese Software kann sich von Gerät zu Gerät, bzw. von Hersteller zu Hersteller beachtlich unterscheiden. Beispielsweise kann ein MID ein multiprozessfähiges Betriebssystem mit einem hierarchischen Dateisystem besitzen, oder nur ein thread-basiertes ohne ein wirkliches Dateisystem. Daher werden in der MIDP Spezifikation folgende Anforderungen beschrieben: Merkmal Kernel Beschreibung Muss die Steuerung der Hardware ermöglichen (z.B. Interrupthandling, Exceptions und Prozessmanagement) Speicher Lesen und nicht flüchtiges Speichern von Daten muss möglich sein (für Record Management System API) Networking Der Zugriff auf die Networking-Fähigkeiten der Hardware muss sichergestellt sein (für Networking API) Timer Die Berechnung von Timestamps z.B. bei Schreibzugriffen in persistenten Speicher, wird angeboten. Grafik Eine Darstellungsmöglichkeit von Bitmaps muss möglich sein. Input Benutzereingaben müssen erfassbar sein. AMS Der Lebenszyklus von Applikationen muss steuerbar sein. Tabelle 3: Softwareanforderungen. Quelle: MIDP 2.0 Spezifikation [Sun06b] 12 Kapitel 2: MIDP 2.2 MIDP 1.0 2.2.1 Funktionalität und Pakete Das MIDP dient der Erweiterung der Bibliotheken der CLDC 1.0 aber auch CLDC 1.1 und der Bereitstellung von APIs, welche über den Funktionsumfang der Konfiguration hinausgehen [Sc07, S.21]. Welche Basisklassen des CLDC erweitert werden, um bestimmte von den MIDP-APIs benötigte Funktionen zu liefern, schildert Tabelle 4. Die CLDC bietet keine Funktionen zur Interaktion von Programmen mit Benutzern. Somit bietet das MIDP zusätzlich Benutzerschnittstellen, aber auch Persistenzfunktionen [To02, S.44]. In Tabelle 5 sind die drei zusätzlichen Pakete des MIDP und ihr jeweiliger Funktionsumfang beschrieben. Paket Inhalt Eine IllegalStateException wird hinzugefügt, da diese java.lang in manchen Situationen von java.util.Timer ausgelöst wird [Sc07, S.21]. Die beiden Klassen Timer und TimerTask werden java.util hinzugefügt. java.io Keine Erweiterungen javax.microedition.io Das MIDP erweitert die Funktionen des GenericConnection Framework. Hierbei wird eine Untermenge des HTTPProtokolls unterstützt. Implementiert wird sie mit IP-basierten Protokollen wie TCP/IP und mit nicht-IP-basierten Protokollen wie WAP und i-mode. Tabelle 4: Erweiterungen der Pakete der CLDC. Quellen: Schmatz [Sc07, S.21] und MIDP 1.0 Spezifikation [Sun00]. Paket Inhalt javax.microedition.midlet Dieses Paket liefert die nötigen Funktionen, damit der Lebenszyklus von Anwendungen gesteuert werden kann. Es wird aber auch vorgegeben, wie MIDlets verpackt werden und wie sie auf Ressourcen zugreifen. 13 Kapitel 2: MIDP Paket Inhalt javax.microedition.lcdui Lowest Common Denominator User Interface; dieses Paket liefert die nötigen Bibliotheken, um Benutzerschnittstellen für kleine, mobile Computer zu bauen. Hierfür wird eine High-Level-API geliefert. Zum Zeichnen ist zudem eine Low-Level-API vorhanden. javax.microedition.rms Mit dem Record-Management-System lassen sich persistente Daten im Endgerät verwalten. Dafür steht eine einfache, Verfügung. satzorientierte Diese Datenbankschnittstelle kümmert sich darum, zur die Datenintegrität zu wahren, während des normalen Betriebes, aber auch bei Batteriewechsel und Reboot. Tabelle 5: Zusätzliche Pakete im MIDP. Quellen: Schmatz [Sc07, S.21] und MIDP 1.0 Spezifikation [Sun00] 2.3 MIDP 2.0 Das MIDP 2.0 hat seit dem Jahre 2002 Gültigkeit. 2006 wurde noch nachgebessert zur Version 2.1. Generell baut diese Spezifikation auf der Version 1.0 auf. Es wurden allerdings noch weitere Pakete hinzugefügt, bzw. bestimmte Basisklassen erweitert. Der folgende Abschnitt behandelt die Neuerungen der Version 2.0. 2.3.1 Unterschiede zur Vorversion Seit der Version 1.0 des MIDP hat sich besonders eine Anwendungskategorie herausgebildet, welche eine Nachbesserung der API verlangte: die Handyspiele [Heise02b]. Um die Entwicklung dieser Programme gezielt zu unterstützen, wurde in der Version 2.0 des MIDP das Paket javax.microedition.lcdui.game hinzugefügt. Da die Anwendungen für mobile Geräte zunehmend komplexer werden, auch weil sie sich in die weiteren Java-Editionen wie J2SE oder J2EE integrieren, wurden die Layoutmöglichkeiten von Benutzerschnittstellen verbessert. Bildschirmobjekte können mit dem MIDP 2.0 besser positioniert werden. Auch besteht nun, wie bei der Erstellung von Benutzerschnittstellen für Webanwendungen, die Möglichkeit, eigene GUI Elemente zu erstellen. Wichtig für den Consumer-Bereich 14 Kapitel 2: MIDP sind polymorphe Klingeltöne. So werden nun Klassen von der MIDP Media API hinzugefügt, welche diesen Bereich für die Programmierung ebenfalls nutzbar macht. Inhalt dieser API ist aber primär die Wiedergabe und Steuerung von Multimediainhalten. Eine Spezifikation zum OTA-Provisioning (OTA = Over The Air) wird vom MIDP 2.0 auch angeboten. Diese ermöglicht, dass Anwendungen direkt über das Internet geladen und installiert werden können. Neu sind auch Push-Dienste (Erweiterung von javax.microedition.io). Darunter fallen allerdings nicht Anwendungsszenarien wie Email-Push. Sie bedeuten vielmehr, dass MIDlets bei asynchronen Ereignissen automatisch starten. So würde der Getränkeautomat, welcher in Tabelle 1 als Beispiel erwähnt wurde, automatisch eine neue Order ausführen, wenn ein bestimmter Füllstand erreicht ist. Die Push Registry, welche diese Ereignisse steuert, ist Bestandteil der AMS, welche auch den gesamten Lebenszyklus eines MIDlets steuert. Im MIDP 1.0 konnten Anwendungen nur vom Benutzer gestartet werden. Mit dem MIDP 2.0 kommen zwei neue Möglichkeiten dazu, eine Aktivierung durch eingehende Netzwerkaufrufe und durch einen Timer-Alarm. [Sc07, S.221 ff.] Tabelle 6 gibt einen Überblick über die neuen Pakete. Paket Inhalt javax.microedition.lcdui.game Vereinfachte Programmierung von 2D-Spielen javax.microedition.media Multimediaunterstützung: Teile der Mobile Media API (JSR-135, siehe „Optionale Pakete“) werden aufgenommen. Es werden allerdings nur Audioformate unterstützt. [Sc07, S.261 ff.] javax.microedition.media.control Wiedergabe von Audio javax.microedition.pki Repräsentiert Zertifikate einer PKI (Public Key Infrastructure). Diese Zertifikate werden u.a. bei sicheren Verbindungen über SSL und HTTPS benötigt. Tabelle 6: Neue Pakete in der MIDP Version 2.0. Quelle: Schmatz [Sc07, S.21] 2.3.2 Sicherheitsaspekte Sicherheitsaspekte haben beim Design der JavaME von Anfang an eine große Rolle gespielt. Neben den low-level Sicherheitsfeatures, die die KVM bietet (2-Phasen 15 Kapitel 2: MIDP Class-Verification) und der Application-Level Sicherheit, die das Sandbox-Modell von Java liefert (Schutz des Hostsystems vor schadhaften Anwendungen), bringt das MIDP 2.0 noch weitere Features mit, welche an dieser Stelle dediziert vorgestellt werden sollen. Zumal MIDlets häufig Internetverbindungen nutzen, können Verbindungen beispielsweise HTTPS verschlüsselt werden, um mögliche Angriffszenarien in diesem Kontext zu unterbinden. Zudem bietet das MIDP 2.0 das Konzept der vertrauenswürdigen MIDlet-Suites. Vertrauenswürdige MIDlet-Suites verfügen über erweiterte Rechte und können so auch auf sensible Methoden der Klassenbibliotheken zugreifen, um beispielsweise Dateien im Dateisystem zu löschen. Eine MIDlet-Suite wird als vertrauenswürdig eingestuft, wenn zum Zeitpunkt der Installation zwei Voraussetzungen erfüllt sind: Der Urheber muss authentifizierbar sein und seinerseits auch als vertrauenswürdig gelten [Sc07, S.25]. Die Authentifizierung wird dann mit Hilfe von Verfahren einer Public Key Infrastructure (PKI) durchgeführt. Damit das Endgerät nicht sämtliche Zertifikate vorhalten muss, schreibt die Spezifikation vor, dass das Zertifikat des Urhebers gleich von ihm mitgeliefert werden muss. Aufbauend auf dem Konzept der vertrauenswürdigen MIDlet-Suites bietet das MIDP 2.0 ein ausgefeiltes System von Berechtigungen und Sicherheitsdomänen. Abhängig von dem Grad der Vertrauenswürdigkeit verfügen Anwendungen abgestuft über mehr oder weniger Rechte. Generell gibt es vier Domänen: Unidentified Third Party, Identified Third Party, Operator (Mobilfunktbetreiber) und Manufacturer (Hersteller des Geräts). Die Zuordnung zu einer Sicherheitsdomäne erfolgt zum Zeitpunkt der Installation. Die Benutzung der Basisklassen *.midlet, *.lcdui, *.lcdui.game, *.rms, *.media und *.media.control (* = javax.microedition) erfordert keine besonderen Berechtigungen. Einschränkungen betreffen lediglich die Klassen zur Netzwerkkommunikation (javax.microedition.io), um den Anwender vor Anwendungen zu bewahren, die Daten ausspähen und über eine Netzwerkverbindung versenden [Sc07, S.318]. 16 Kapitel 3: Optionale Pakete 3 Optionale Pakete Optionale Pakete dienen der Erweiterung von Funktionen, welche nicht durch das Profil erfüllt werden. Da der Markt mobiler Geräte stark umkämpft ist, bauen die Hersteller immer mehr Features und Innovationen in ihre Produkte ein. Diese müssen letztlich auch über APIs zu erreichen sein, um die Leistungsmerkmale der Ablaufumgebung ausschöpfen zu können [Sc07, S.283]. Ein Beispiel ist z.B. Bluetooth, welches nicht mit dem MIDP ansteuerbar ist, sondern nur über ein optionales Paket. Neue Anwendungsszenarien für mobile Geräte führen ebenfalls zur Entwicklung neuer optionaler Pakete. Beispielsweise können Anwendungen mit einem Server über Webservices kommunizieren. Diese Funktionalität wird allerdings nur von optionalen Paketen geboten. Optionale Pakete bieten den Vorteil der Erweiterung der nutzbaren Funktionen, allerdings wird dieser Vorteil mit einer verschlechterten Portabilität eingekauft. Die Anwendung ist so nicht mehr universell auf allen Endgeräten nutzbar. Es gibt eine Fülle von optionalen Paketen, welche sich frei miteinander kombinieren lassen. Vorteilhaft kommt dabei die Schichtenarchitektur der JavaME zum Tragen: Es lassen sich beliebig viele Pakete oberhalb des Profils „andocken“. Da die Zugriffe top-down erfolgen, ist dem MIDP nicht bekannt, wie viele und welche optionale Pakete zum Einsatz kommen. Die Anzahl der Kombinationen ist beträchtlich. Dies führt zu einer Fragmentierung der Gerätefunktionen, schließlich integrieren die Hersteller nicht notwendigerweise alle dieselben Pakete [Sc07, S.284]. Da es im Zuständigkeitsbereich der Hersteller liegt, die Implementierungen dieser Pakete, wie auch beim MIDP, zu übernehmen, entscheiden diese, welche Pakete sie für implementierenswert halten. Daher entstand die Bestrebung, mehrere optionale Pakete zu einem größeren Paket zusammenzulegen. Diese Initiative wurde im Jahre 2004 im JSR-248 „Mobile Service Architecture“ (MSA) beschlossen. Die MSA lässt sich als Standardisierungsbemühung verstehen, um die Portabilität mobiler Java Anwendungen zu wahren. Auch lässt sie sich als Grundlage der nächsten Generation Java-fähiger Mobiltelefone bezeichnen [BM02, S.20]. Ziel ist neben der Zusammenlegung auch, „Unklarheiten und Interpretationsspielräume in den Spezifikationen der optionalen Pakete“ zu beseitigen, die ansonsten auch zu inkompatiblen Implementierungen hätten führen können [BM02, S.284]. Die Chance, 17 Kapitel 3: Optionale Pakete welche durch die MSA für den Entwickler erwächst, ist, in Zukunft noch mächtigere, herstellerunabhängige Anwendungen entwickeln zu können [BM02, S.284]. Die MSA setzt sich im Wesentlichen aus folgenden Komponenten zusammen: CLDC 1.1, MIDP 2.1, JTWI 1.0 (Java Technology for the Wireless Industry, JSR-185) und weiteren optionalen Paketen aus den einzelnen JSRs. Da die Implementierung aller Pakete sehr umfangreich ist und viele Firmen diesen zusätzlichen Aufwand nicht auf sich nehmen wollen, hat man sich auf eine leichtgewichtige Teilmenge geeinigt. Diese wird mit MIDP-Subset betitelt [BM02, S.284]. Die weiteren Ausführungen zu den Inhalten der einzelnen Pakete der MSA stützen sich auf den Ausführungen von Schmatz [BM02, S.285 ff.]. Da die Spezifikation noch nicht verabschiedet ist, kann es noch zu inhaltlichen Verschiebungen kommen. MSA-Subset: JSR 75 Bezeichnung PIM Optional Ver. Inhalt 1.0 Verwaltung persönlicher Daten, wie Adressen. 1.0 Umgang mit Dateien und Verzeichnissen, die auf Package 75 File Connection Optional Package einem beliebigen Speichermedium vorliegen. 82 Bluetooth APIs 1.1 Kommunikation über die Bluetooth Schnittstelle 135 Mobile Media 1.1 Medienverarbeitung wird ermöglicht. Audio- und API Videodateien können aufgezeichnet und wiedergegeben werden 184 Mobile 3D 1.1 Graphics API 205 Wireless Programmierschnittstellen zur Darstellung von 3DGrafiken und 3D-Animationen 2.0 Senden und Empfangen von SMS und MMS 1.0 Darstellung von Vektorgrafiken, welche auch im Messaging API 226 Scalable 2D Vector Graphics SVG-Format vorliegen können. API Tabelle 7: MSA-Subset. Quelle: Schmatz [BM02, S.285 ff.] 18 Kapitel 3: Optionale Pakete Zusätzliche Pakete, die nicht Teil des Subsets sind: JSR 172 Bezeichnung Webservices API Ver. Inhalte 1.0.1 Nutzung entfernter Dienste über das SOAPProtokoll 177 Security and trust 1.0 Services API 179 Location API Kryptografische Verfahren und Funktionen zum Zugriff auf die Inhalte der SIM-Karte 1.0.1 Bestimmung des aktuellen Ortes und der Bewegungsgeschwindigkeit des Endgeräts 180 SIP API 1.0.1 Nutzung des SIP-Protokolls für beispielsweise Instant Messaging oder SIP-Telefonie 211 Content Handler 1.0 API Verbesserte Integration der bestehenden Anwendungen eines Mobiltelefons. Registratur von bestimmten Anwendungen zu Content Typen (z.B. MP3) 229 Payment API 1.0 Abwicklung von Bezahlvorgängen 234 Advanced 1.0 Neue 238 Controls. Auch fortgeschrittene Multimedia Leitungsmerkmale in den Bereichen Audio, Video, Supplements Kamera und Tuner Mobile 1.0 Internationalization Internationalisierung und Lokalisierung von Anwendungen API Tabelle 8: Zusätzliche Pakete. Quelle: Schmatz [BM02, S.285 ff.] Neben den optionalen Paketen, welche in der MSA enthalten sind, soll auch noch ein weiteres Erwähnung finden: JSR 253 Bezeichnung Inhalt Mobile Telephony API Handling von Anrufen und Netzwerkdiensten, z.B. (MTA) um ein Conferencing-Tool zu entwickeln [Sun05a] 19 Kapitel 4: Ausblick 4 Ausblick Die Technologie entwickelt sich rasant und nimmt mit der Zeit noch an Geschwindigkeit zu. In den nächsten Jahren werden die Hersteller von Mobiltelefonen immer mehr Funktionen einbauen. Die Architektur der JavaME bietet für die zukünftigen Entwicklungen genug Spielraum nach oben. Kapitel 1 hat gezeigt, dass die drei Schichten Konfiguration, Profil und optionale Pakete aufgrund ihrer Schichtenarchitektur genug Flexibilität dafür bieten. Das MIDP, welches Kapitel 2 behandelt, bietet zahlreiche Funktionen, die eine Anwendungsentwicklung für mobile Geräte möglich macht, so lange man die Hardwarevoraussetzungen im Auge behält. Der Funktionsumfang des MIDP 2.0 wurde auch, wie Kapitel 2.3.2 zeigt, in Bezug auf Sicherheitsaspekte erweitert. Diese sollen den Nutzer von mobilen Applikationen vor potentiellen Angreifern schützen. Wichtig wird dies vor allem dann, wenn sich mobile Anwendungen auch im Business-Umfeld weiter verbreiten. Sicherheitsaspekte sind hier immer ein wichtiges Entscheidungskriterium für oder gegen eine Investition. Die optionalen Pakete, welche Kapitel 3 behandelt, bieten bereits jetzt vielfältige, zusätzliche Einsatzmöglichkeiten für mobile Java-Anwendungen. Die Java Service Requests im Java Community Process, welche die Spezifikationen für optionale Pakete definieren, werden stetig weiterentwickelt, um auch in Zukunft noch zusätzliche JavaPakete zu bieten. So werden die bisherigen optionalen Pakete in ihrem Funktionsumfang aufgestockt und es werden neue Pakete, je nach benötigter Funktionalität, entstehen. In den nächsten Jahren wird eine neue Version des MIDP veröffentlicht. Mit der Version 3.0 (JSR-271) wird sich wieder viel ändern [Sun05b]: Es sollen mehrere MIDlets in einer VM laufen können, manche davon auch ohne Benutzerschnittstelle. MIDlets sollen auch zur Boot-Zeit starten können, ohne dass der Benutzer dieses Ereignis anstößt. Bessere Inter-MIDlet-Kommunikation soll geliefert werden. Bisher können nur MIDlets innerhalb einer MIDlet-Suite miteinander kommunizieren, indem sie Klassenvariablen miteinander teilen. Zudem soll die Unterstützung hochwertiger und großer Displays weiter gehen und die Entwicklung performanter Spiele vereinfacht werden. 20 Kapitel 4: Ausblick Letztlich wird sich die Weiterentwicklung der JavaME daran richten, was der Markt verlangt. Es obliegt also der Kreativität der Anwender und Marktanbieter, was in den nächsten Jahren noch alles passieren wird. 21 Literaturverzeichnis [BM02] Ulrich Breymann, Heiko Mosemann: JavaME – Anwendungsentwicklung für Handys, PDA und Co., 1st. ed., Carl Hanser Verlag, 2006. [Heise02a] Heise: Das Handy kennt den Weg – Location Based Services, 2002. http://www.heise.de/mobil/artikel/50855. Abrufdatum 2006-12-03. [Heise02b] Heise: Software für Handys, 2002. http://www.heise.de/mobil/artikel/50904. Abrufdatum 2006-12-03. [Sc07] Klaus-Dieter Schmatz: Java Micro Edition – Entwicklung mobiler JavaMEAnwendungen mit CLDC und MIDP, 2nd. ed., dpunkt.verlag, 2007. [Sun00] Sun: Mobile Information Device Profile for JavaTM 2 Micro Edition, 2000. http://jcp.org/en/jsr/detail?id=37. Abrufdatum 2006-12-03. [Sun05a] Sun: Mobile Telephony API (MTA) for JavaTM 2 Micro Edition, 2005. http://jcp.org/en/jsr/detail?id=253. Abrufdatum 2006-12-03. [Sun05b] Sun: Mobile Information Device Profile 3.0, 2005. http://jcp.org/en/jsr/detail?id=271. Abrufdatum 2005-12-03. [Sun06a] Sun: Java ME Technologies, 2006. http://java.sun.com/javame/technologies/index.jsp. Abrufdatum 2006-12-03. [Sun06b] Sun: Mobile Information Device Profile for JavaTM 2 Micro Edition, 2006. http://jcp.org/en/jsr/detail?id=118. Abrufdatum 2006-12-03. [To02] Kim Topley: J2ME in a Nutshell, 1st. ed., O’Reilly, 2002.
