Installation von Java MIDlets auf dem Handy via OTA-Technik

Over The Air

Michael Jentsch

Im Java Magazin sind schon mehrere Artikel erschienen, die sich mit der Entwicklung von MIDlets beschäftigt haben. Diese MIDlets müssen auch den Weg vom Emulator zum Mobiltelefon finden. Wie so oft gibt es viele Wege zum Ziel. In diesem Artikel wird eine herstellerunabhängige Technik vorgestellt, die es dem Anwender ermöglicht MIDlets auf dem Handy zu installieren. Und das ganz ohne externe Hardware, Datenkabel und PC.

Die ersten javafähigen Handys verwendeten netzwerkabhängige Techniken, um Software auf dem Handy zu installieren. Alle Verfahren waren völlig unterschiedlich. Mit der aufkommenden 3G-Technologie sollte dann eine einheitliche Basis geschaffen werden (In Tabelle 1 werden die gängigsten Abkürzungen erläutert). Zu diesem Zweck hat die MIDP-Experten-Gruppe ein best practice-Dokument veröffentlicht. Es beschreibt einen Weg, MIDlets auf dem Handy zu installieren ohne dass der Benutzer externe Hardware benötigt. Damit hat er die Möglichkeit überall und zu jeder Zeit neue MIDlets zu probieren und auch zu kaufen. Fast alle javafähigen Handys unterstützen OTA. Während die Flagschiffe der Mobiltelefon-Hersteller (z.B. Siemens SL45i und Nokia 7650) zusätzlich auf Datenkabel mit PC-Unterstützung setzen, werden die neueren Geräte für den Massenmarkt wie z.B. das Siemens M50 oder das Nokia 3410 ausschließlich mit OTA-Unterstützung angeboten.
Die Vorteile von OTA liegen klar auf der Hand. Es ist gelungen einen herstellerübergreifenden Standard zu etablieren, der unabhängig vom Mobilfunk-Provider und der verwendeten Netzwerk-Technologie ist.
Ein weiterer Vorteil sind die Online-Gebühren pro Download, die dazu beitragen, dem einen oder anderen Mobilfunk-Provider das Überleben zu sichern. Aus Sicht des Kunden ist das natürlich eher ein Manko, dass er jeden Download bezahlen muss. Aber dazu später mehr.

Ein weiterer, nicht so gravierender Nachteil ist, dass der OTA-Download auf die beiden Dateien der Applikation beschränkt ist: Den Java Applikation Descriptor (JAD-Datei) und das Java Archiv (JAR-Datei). Es gibt aber auch MIDlets die zusätzlich noch eine Datenbank benötigen, die nicht im Java Archiv gespeichert werden kann. Das kann z.B. bei Highscore-Listen der Fall sein. Das Problem hierbei ist, dass OTA keine Möglichkeit anbietet, Dateien für das Record Management System des Handys zu installieren. Eine einheitliche Lösung für dieses Problem existiert bisher noch nicht, sodass es dem MIDlet-Entwickler überlassen ist, eine individuelle Lösung zu finden.

Begriff Erläuterung
MIDP 1.0 Das Mobile Information Device Profile 1.0 ist ein Profil der Java 2 Micro Edition. Es definiert im wesentlichen die Schnittstelle zwischen dem MIDlet und dem Handy. Hierzu gehört ein spezielles API für die Java-Programme und gewisse Mindestanforderungen an die Handys (Devices).
MIDlet Eine Java-Anwendung, die MIDP kompatibel ist.
WAP Wireless Application Protocol. Ein Übertragungsverfahren für WML Content.
Record Management System Das Mobile Information Device Profile enthält eine Sammlung von Klassen, die es ermöglicht, Daten persistent zu speichern um sie später wieder abrufen zu können. Ausführlich beschrieben im Artikel Persistente Datenspeicherung in der J2ME im Java Magazin 12.2001
3G Third generation wireless technologies.

Während in Japan primär i-Mode im Einsatz ist, gibt es im europäischen GSM-Netz bisher nur WAP-fähige Handys, die Java MIDlets ausführen können. Daraus folgt, dass hier zulande die MIDlets im Moment untrennbar mit WAP verbunden sind. Hinzu kommt, dass ein MIDlet in zwei Schritten übertragen wird. Erst die Übertragung des Java Application Descriptor per WAP und dann per HTTP das Java Archiv. Daraus folgt, dass in vielen Fällen mehr als nur eine einfache WAP-Konfiguration nötig ist, um die ersehnte MIDlet Suite auf dem Handy zu installieren. Hat man diesen Schritt aber einmal getan, ist der Download von MIDlets ein Kinderspiel. Sollte der i-Mode Boom nach Europa überschwappen, ist das Problem mit der WAP-Konfiguration endgültig gelöst, da i-Mode Content nur die HTTP-Übertragstechnik verwendet. In diesem Fall würden dann der Java Application Descriptor und das Java Archiv mit dem gleichen Protokoll übertragen. Doch bis dahin sind in der Regel zwei Konfigurationen nötig. Eine Konfiguration für WAP und eine für HTTP.

Abb. 1: Infrastruktur für OTA

In einem Punkt sind sich alle Mobilfunk-Provider einig: Die Kosten für WAP sind von T-D1 bis Quam 19 Cent pro Minute. Zudem lassen einige dieser Einwahl-Gateways keine HTTP-Verbindung zwischen Handy und Internet zu. Das disqualifiziert sie für den Download der JAR-Datei.

Doch mobil im Internet surfen kann auch preiswerter sein. Am Wochenende sind Gespräche in das deutsche Festnetz schon für 6 – 8 Cent pro Minute möglich. Bei Genion in der Homezone sogar nur 3 Cent pro Minute. Da die Mobilfunk Provider nicht zwischen Sprach- und Datenverbindung unterscheiden, sind Verbindungen zum Internet auf der Rechnung genauso ausgewiesen, wie Sprachverbindung. Die Konditionen sind daher die gleichen, wenn statt der voreingestellten WAP-Konfiguration eine Telefonnummer aus dem deutschen Festnetz angewählt wird. Solche Einwahlpunkte gibt es deutschlandweit. Eine Liste steht unter www.teltarif.de/internet/einwahl.html zur Verfügung.

Diese Einwahlpunkte eignen sich hervorragend dazu, die JAR-Datei herunterzuladen, da hierfür nur eine HTTP-Verbindung nötig ist. Für die JAD-Datei ist ein WAP-Gateway nötig. Diese Gateways werden normalerweise von den Mobilfunk-Providern zur Verfügung gestellt, lassen sich dann aber ausschließlich über die WAP-Einwahlnummer des Anbieters aufrufen. Um einen öffentlichen Einwahlpunkt im deutschen Festnetz für WAP verwenden zu können ist ein freies WAP-Gateway nötig. Ein solches Gateway wird von M-Software unter 217.160.134.45 betrieben.

JAD-Anpassungen

Der Java Application Descriptor dient unter anderem dazu, dem Handy mitzuteilen, wo sich die zugehörige JAR-Datei befindet. Im Emulator reicht normalerweise die Angabe des Dateinamens. Um die MIDlet Suite per OTA installieren zu können, muss der URL angegeben werden unter dem sich die JAR-Datei befindet. Der Standard-Zeichensatz für JAD-Dateien ist UTF-8. Es kann aber möglich sein, dass vom Handy ein anderer Zeichensatz benötigt wird. In diesem Fall steht er im Attribut Accept-Charset des Requests. In Tabelle 2 und 3 sind die Attribute für den Java Application Descriptor sowie für OTA angegeben.

MIDlet-Install-Notify Das Attribut MIDlet-Install-Notify sollte im Java Application Descriptor angegeben werden. Die angegebene URL wird vom Handy aus aufgerufen und übermittelt den Status der Installation.
MIDlet-Delete-Confirm Beim Löschen der MIDlet Suite vom Handy, sollte vom Handy die vorgegebene URL aufgerufen werden, wenn dieses Attribut vorhanden ist.

Die Anpassung in der Zeile MIDlet-JAR-URL des Java Application Descriptors ist ausreichend, um den OTA-Download durchzuführen. OTA kann aber noch mehr. Nach der erfolgten Installation sendet das Handy einen Status an den Server, um ihn darüber zu informieren, wie die Installation verlaufen ist. Eine Liste der Status Codes ist in Tabelle 4 dargestellt. Im besten Fall übermittelt das Handy den Status 900. Es kann aber während der Installation sehr viel passieren. Um die Probleme identifizieren und eliminieren zu können, gibt es die weiteren Statuswerte. Der URL, an den der Status gesendet wird, kann mit dem Attribut MIDlet-Install-Notify festgelegt werden. Fehlt der Parameter, wird auch kein Status übertragen.

Status 900 Installation erfolgreich abgeschlossen
Status 901 Speicherplatz des Handys nicht ausreichend
Status 902 Abbruch durch Benutzer
Status 903 Unerwartetes Übertragungsende
Status 904 Fehlerhafte Größe der JAR-Datei
Status 905 Falsche oder fehlende Attribute
Status 906 Ungültiger Java Application Descriptor
Status 907 Ungültige JAR-Datei
Status 908 Inkompatibilitäten bei der Konfiguration oder dem Profil
Status 909 Ungültige Anmeldung bei der Anwendung
Status 910 Ungenügende Rechte für die Anwendung
Status 911 Push Registrierung fehlgeschlagen
Status 912 Bestätigung über die Löschung des MIDlets

Ein weiteres wichtiges Attribut ist MIDlet-Delete-Confirm. Die Idee dahinter ist, den Server auch über das Löschen des MIDlets zu benachrichtigen. Löscht ein Anwender das MIDlet, versucht das Handy eine Verbindung mit dem URL aus MIDlet-Delete-Confirm aufzubauen. Natürlich kann der Anwender diese Verbindung abbrechen, sodass man sich darauf nicht verlassen kann. Das bezieht sich natürlich auch auf den Aufruf der MIDlet-Install-Notify URL. Sun Microsystems empfiehlt in diesem Fall eine erfolgreiche Installation anzunehmen.

Bei der Installation per OTA wird zwischen zwei Verfahren unterschieden, die OTA Push und OTA Pull heißen.

OTA Pull

Beim OTA Pull-Installationsprozess navigiert der Anwender durch ein mobiles Onlineangebot, um einen Link zu der JAD-Datei des MIDlets aufzurufen. Die JAD-Datei wird auf das Handy geladen und dort die Attribute in einem Parser extrahiert. Ist die Datei gültig, wird die JAR-Datei heruntergeladen und nach einer Prüfung installiert. Während dieses Prozesses kann der Anwender, je nachdem welches Handy er verwendet, unterschiedliche Entscheidungen treffen. Nach dem Download der JAD-Datei werden Name und Größe des MIDlets angezeigt. Hier muss dann entschieden werden, ob der Download der JAR-Datei erfolgen soll. Wurde das MIDlet erfolgreich heruntergeladen, kann ein Zielverzeichnis gewählt werden.

Abb. 2: Ablaufdiagramm

Es kann vorkommen, dass der Benutzer versucht ein MIDlet zu installieren, das sich bereits im Speicher des Handys befindet. In diesem Fall sollte das Handy den Anwender darüber informieren. Es ist also nicht möglich, ein MIDlet mehrfach zu installieren, ohne das der Anwender dies bemerkt. Was vor allem in Anbetracht der begrenzten Ressourcen sehr sinnvoll ist. Weiterhin muss ein MIDP-kompatibles Handy Basic Authentication (entsprechend RFC2617) unterstützen. Dieser Zugriffsschutz ist bereits von HTTP-Servern bekannt. Hierbei sendet der Server einen Status an den Browser, der dann den Benutzer dazu veranlasst, sich mit Username und Passwort anzumelden.

Während des gesamten Prozesses kann der Download vom Benutzer abgebrochen werden, ohne dass sich hierdurch eine Beeinträchtigung der anderen MIDlets oder anderer Funktionen des Mobiltelefons ergibt.
Es ist oft der Fall, dass zwei unterschiedliche Verbindungen verwendet werden. Dann kommt es vor, dass sich die IP-Adresse des Handys beim JAD-Download von der IP-Adresse während des JAR-Downloads unterscheidet. Um das Handy eindeutig identifizieren zu können, muss also eine Konstante gefunden werden, die sich während des kompletten Downloads nicht mehr ändert. In der OTA-Spezifikation sind hierfür Cookies vorgesehen. Im Response Header der JAD-Datei wird der Cookie vom Download Server gesetzt, der dann beim Download der JAR-Datei wieder an den Server zurückgesendet wird. Hierdurch lässt sich das Handy leicht identifizieren, auch wenn sich die IP-Adresse während des Installationsprozesses ändert. Ausführliche Informationen zum Status Management-Mechanismus per Cookie sind in RFC2109 dokumentiert.

OTA Push

Auch wenn der Name OTA Push annehmen lässt, dass es sich hierbei um eine Push Technik handelt, muss klar gesagt werden, das der Download des MIDlets wie auch bei OTA Pull abläuft. Der Unterschied ist, dass im Falle von OTA Push kein Link einer WML-Seite oder ein Bookmark ausgewählt wird, sondern der URL der JAD-Datei in einer SMS ausgewählt wird. Da SMS eine Push-Technologie ist, wird dieses Verfahren OTA Push genannt, obwohl sich der eigentliche Download nicht vom OTA Pull-Download unterscheidet.

Für eine OTA Push SMS ist folgendes zu beachten. Das Handy sucht in der SMS nach folgenden Schlüsselworten: http:, Http:, www., WWW., wap., Wap.
Findet das Handy einen Link in der SMS, wird er optisch hervorgehoben. Drückt der Anwender dann die Senden-Taste, wird der URL vom WAP Browser aufgerufen.

Abb. 3: Nach dem Download des Java Application Descriptors

Bei der Kommunikation zwischen Handy und Server werden neben den Nutzdaten auch eine Menge organisatorische Zusatzdaten übertragen. Einige dieser Informationen können sehr hilfreich sein, wenn man individuell auf die Handy-Typen eingehen möchte oder ein Micro Payment System verwendet.
Anhand eines Auszugs aus dem Apache Logfile des OTA-Servers werden die Informationen hier kurz erläutert.

Download des Promille-Rechners M-Promi mit einem Samsung S100:

193.254.160.83 - - [25/Sep/2002:15:40:01 +0200] "GET /msf/jad.cgi/msf.jad HTTP/1.1" 200 194 www.gtma.de:80 "-" "MOT-T720/05.05.21R MIB/2.0 Profile/MIDP-1.0 Configuration/CLDC-1.0 UP.Link/5.1.0.2" "172.17.255.236"
193.254.160.83 - - [25/Sep/2002:15:40:05 +0200] "GET /msf/jar.cgi/msf.jar HTTP/1.1" 200 32316 www.gtma.de:80 "-" "MOT-T720/05.05.21R MIB/2.0 Profile/MIDP-1.0 Configuration/CLDC-1.0 UP.Link/5.1.0.2" "172.17.255.236"

Diese Zeilen aus dem Apache Logfile eines OTA-Download Servers zeigen, wie die Handys ein MIDlet herunterladen. In der ersten Zeile erkennt man gleich die IP-Adresse des T-Online WAP-Gateways, das im Auftrag eines SHG S100 Handys den Java Application Descriptor des Promille-Rechners ermittelt. Dieser Download dauert nur wenige Sekunden, trotzdem dauert es 36 Sekunden bis das Java Archiv heruntergeladen wird. Beim Siemens M50 verstreichen sogar 51 Sekunden zwischen den beiden Downloads. Das ist genau die Zeit in der das Handy die WAP-Verbindung trennt und sich dann mit dem Java Profil wieder einwählt, um dann eine direkte HTTP-Verbindung zum Server aufzubauen. Einzig das T720 hat einen Zeitversatz von nur 4 Sekunden zwischen den Downloads. Es baut ganz offensichtlich keine neue Verbindung auf, was den Download merklich beschleunigt.

Ein weiterer Unterschied liegt in den Informationen, die von den Handys übertragen werden. Das S100 sendet nur sehr rudimentäre Informationen und der JAR-Download erfolgt sogar völlig ohne Angabe irgendwelcher Informationen. Siemens identifiziert sich mit der Handy Bezeichnung und der Browser Version. Zusätzlich wird beim JAR File Download sogar noch die Konfiguration und das Profil übertragen. Ähnlich verhält es sich auch beim T720. Es werden Handy-Bezeichnung, Browser-Version, Konfiguration und Profil übertragen. Wobei der Browser des T720 nicht zwischen JAD- und JAR-Download unterscheidet. Diese Informationen können vom Server für diverse Zwecke verwendet werden. Gleichzeitig wird aber auch das übertragene Datenvolumen mit jeder zusätzlichen Information aufgebläht. Gerade GPRS-Nutzer wundern sich dann schon mal über ihre Rechnung, da GPRS abhängig vom Volumen abgerechnet wird.

HTTP/1.1 200 OK
Date: Thu, 26 Sep 2002 16:15:15 GMT
Server: Apache/1.3.20 (Linux/SuSE) PHP/4.0.6
Connection: close
Content-Type: text/vnd.wap.wml

Das Attribut Server wird nicht wirklich benötigt und kann eigentlich ganz entfallen, ohne dass dadurch irgendwelche Nachteile entstehen. Die Konfiguration des Apache Servers bietet leider keine Möglichkeit die Zeile komplett zu entfernen. Man kann aber mit einfachen Mitteln das Datenvolumen reduzieren, sollte man vor einem Patch des Servers zurückschrecken. Mit dem Eintrag ServerTokens Minimal kann die Zeile auf ein Minimum reduziert werden. Weitere Möglichkeiten für ServerTokens sind ProductOnly, OS und Full.

Um die Zeile völlig zu entfernen muss leider der Sourcecode geändert und der Server neu übersetzt werden. Man muss seine Kunden zwar schon sehr lieben, um so weit zu gehen, aber ich möchte gerade deshalb hier eine kurze Anleitung präsentieren. Natürlich sind diese Angaben mit den jeweiligen Bestimmungen der Apache Software Foundation abzugleichen.

1565 #ifdef CHARSET_EBCDIC
1566     PUSH_EBCDIC_OUTPUTCONVERSION_STATE_r(r, 1);
1567 #endif /*CHARSET_EBCDIC*/
1568
1569     /* output the HTTP/1.x Status-Line */
1570     ap_rvputs(r, protocol, " ", r->status_line, CRLF, NULL);
1571
1572     /* output the date header */
1573     ap_send_header_field(r, "Date", ap_gm_timestr_822(r->pool, r->request_time));
1574
1575     /* keep the set-by-proxy server header, otherwise
1576      * generate a new server header */
1577 /* ##################### */
1578     /* "Server: Apache...." wird nicht ausgegeben
1579     if (r->proxyreq) {
1580         const char *server = ap_table_get(r->headers_out, "Server");
1581         if (server) {
1582             ap_send_header_field(r, "Server", server);
1583        }
1584     }
1585     else {
1586         ap_send_header_field(r, "Server", ap_get_server_version());
1587     }
1588     */
1589 /* ##################### */
1590     /* unset so we don't send them again */
1591     ap_table_unset(r->headers_out, "Date");        /* Avoid bogosity */
1592     ap_table_unset(r->headers_out, "Server");
1593 #ifdef CHARSET_EBCDIC
1594     POP_EBCDIC_OUTPUTCONVERSION_STATE_r(r);

Dann noch make ausführen und fertig ist der anonyme Webserver. Hier kann der Apache sseine Vorteile gegenüber dem IIS von Microsoft klar ausspielen, der nicht so einfach angepasst werden kann. Ein weiterer Webserver, der verwendet werden kann, ist der Tomcat. Gerade wenn ein OTA-Server mit Java Server Pages oder Servlets realisiert werden soll. Auch der Tomcat überträgt einen HTTP Header, der sehr viel Overhead enthält. Ein typischer Header einer WML-Datei ist in Listing 2 dargestellt.

HTTP/1.0 200 OK
Date: Thu, 26 Sep 2002 16:08:11 GMT
Servlet-Engine: Tomcat Web Server/3.2.1 
 (JSP 1.1; Servlet 2.2; Java 1.2.2; Linux 2.4.4 i386; 
 java.vendor=Sun Microsystems Inc.)
Content-Type: text/vnd.wap.wml
Age: 0
X-Cache: MISS from dtm2-t6-1.mcbone.net
Connection: close

Die Zeile Servlet-Engine ist in diesem Fall 127 Zeichen lang. Daraus ergibt sich ein Overhead von einem Kilobyte bei nur 8 WML-Seiten. Dieser Misstand kann durch ein Patch des Tomcat leicht aufgehoben werden. Die Änderungen müssen in verschiedenen Dateien durchgeführt werden (Listing 3).

org/apache/tomcat/service/http/HttpResponseAdapter.java:	    
	// setHeader("Servlet-Engine", request.getContext().getEngineHeader());

org/apache/tomcat/service/connector/Ajp13ConnectorResponse.java:	    	
	// setHeader("Servlet-Engine", request.getContext().getEngineHeader());

org/apache/tomcat/service/connector/Ajp12ConnectionHandler.java:	    
	// setHeader("Servlet-Engine", request.getContext().getEngineHeader());

org/apache/tomcat/service/connector/JNIConnectionHandler.java:	    
	// setHeader("Servlet-Engine", request.getContext().getEngineHeader());

org/apache/tomcat/adapter/HttpAdapter.java:	    
	// headAppend( "Servlet-Engine: ");

Der Tomcat ist mehr als nur ein Webserver. Er kann per HTTP aufgerufen werden oder über einen anderen Connector die Daten übertragen. Aus diesem Grund muss ein und dieselbe Zeile in unterschiedlichen Dateien geändert werden. Natürlich ist es auch möglich nur einen speziellen Connector anzupassen, was dazu führen würde, dass sich der Tomcat abhängig von diesen Änderungen unterschiedlich verhalten würde.

Volle Kostenkontrolle

Mit OTA steht eine sehr mächtige und einfach zu verwendende Technologie zur Verfügung, die aller Wahrscheinlichkeit nach in dem MIDP 2.0-Standard aufgenommen wird und die Installation von Anwendungen und Spielen auf den Handys unterschiedlichster Hersteller vereinheitlicht. Bleibt nur abzuwarten bis alle Handys OTA unterstützen und der Markt für mobile Software profitabel wird.

Michael Jentsch ist Gründer der Mobile-Software Organisation zur Entwicklung und Verbreitung mobiler Software Lösungen. Information unter www.m-software.org.

Geschrieben von
Michael Jentsch
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.