Ausarbeitung - Department of Information Systems

Transcription

Westfälische Wilhelms-Universität Münster
Ausarbeitung
Application Provisioning
im Rahmen des Seminars Mobile Java
Steffen Müller
Themensteller: Prof. Dr. Herbert Kuchen
Betreuer: Christian Hermanns
Institut für Wirtschaftsinformatik
Praktische Informatik in der Wirtschaft
Inhaltsverzeichnis
1
Einleitung in das Application Provisioning ............................................................. 1
2
Grundlagen des Application Provisioning von MIDlets.......................................... 2
2.1
Java Micro Edition als Zielplattform von MIDlets......................................... 2
2.1.1 Konfigurationen und Profile in der Java Micro Edition ........................ 2
2.1.2 Application Management Software ....................................................... 3
2.1.3 Kommunikation und Identifikation eines mobilen Gerätes................... 5
2.2
3
Java Enterprise Edition als Plattform für Provisioning Server ....................... 6
Darstellung des Application Provisionings von MIDlets und eines Provisioning
Frameworks ............................................................................................................. 7
3.1
Application Provisioning von MIDlets........................................................... 7
3.1.1 Begriffsbestimmung und Arten des Application Provisionings ............ 8
3.1.2 Der Over-The-Air User-Initiated Provisioning Prozess ........................ 9
3.1.3 Funktionsumfang von Provisioning Systemen .................................... 12
3.2
Java Enterprise Edition Client Provisioning Framework ............................. 13
3.2.1 Überblick ............................................................................................. 13
3.2.2 Stocking und Repository...................................................................... 15
3.2.3 Discovery ............................................................................................. 15
3.2.4 Delivery ............................................................................................... 16
3.3
Darstellung eines Provisioning Systems am Beispiel der Sun Client
Provisioning Reference Implementation ...................................................... 17
4
Zusammenfassung und Ausblick ........................................................................... 20
A
Zusammenstellung einiger JAD-Datei Attribute nach MIDP 2.0 Spezifikation ... 21
B
Beispiel eines Provisioning Descriptors ................................................................ 22
C
Beispiel einer Device Capability Datei.................................................................. 23
D
Beispiel einer Matchers Datei................................................................................ 24
E
Beispiel einer Adapters Datei ................................................................................ 25
Literaturverzeichnis ........................................................................................................ 26
II
Kapitel 1: Einleitung in das Application Provisioning
1 Einleitung in das Application Provisioning
Mobile Geräte – z. B. Handys – sollen klein, leicht und mobil sein. Deshalb sind sie
bestimmten Einschränkungen unterworfen, was bspw. die Rechenleistung und Speicherausstattung angeht. Auf den Geräten können nicht alle Programme, die sich ein Benutzer wünscht, vorinstalliert werden. Die Einschränkungen der mobilen Geräte führen
aber dazu, dass keine vollständige Laufzeitumgebung wie die Java Virtual Machine
(JVM) der Java Standard Edition (Java SE) Platz findet.1 Deshalb wurde die Java Micro Edition (Java ME) für mobile Geräte entwickelt. Diese ist ein angepasstes und abgespecktes Java auf Basis von Spezifikationen und Technologien, welche bestimmte Konfigurationen und Profile für verschiedene Geräte bereitstellt. Konfigurationen umfassen
dabei eine JVM mit Sätzen von Bibliotheken und Profile notwendige fehlende Application Programming Interfaces (API). Aufgrund von unterschiedlichen Konfigurationen
und Profilen müssen Java Programme für mobile Geräte (MIDlets bzw. MIDlet-Suiten –
Im Folgenden nur MIDlets) zu diesen passen. Eine Überprüfung auf Kompatibilität
wird beim Application Provisioning von MIDlets durchgeführt.
Application Provisioning – kurz Provisioning – beschreibt die Aktivitäten von Provisioning Systemen, „Services“ anzubieten, sowie den Prozess, diese „Services“ an die verschiedenen Client Geräte auszuliefern [JSR124a, S. 7]. Ziel im Zusammenhang mit
MIDlets ist die sichere und korrekte Installation der „Services“ auf den mobilen Geräten. Dabei soll das Provisioning aus Nutzersicht so einfach wie möglich vonstatten gehen. Provisioning Systeme werden hier häufig mit Getränkeautomaten verglichen, und
ihre Bedienung soll dem Kauf einer Getränkedose ähneln [JSR124a, S. 11].
Ziel dieser Ausarbeitung ist die Darstellung von Techniken für das Application Provisioning von MIDlets. Hierzu wird zuerst auf erforderliche Grundlagen der Java ME als
Zielplattform eingegangen (Kapitel 2.1). Anschließend werden Grundkonzepte der Java
Enterprise Edition (Java EE) für Provisioning Systeme erläutert (Kapitel 2.2). Im
Hauptteil werden zuerst generelle Aspekte des Application Provisionings von MIDlets
behandelt (Kapitel 3.1) – z. B. der Provisioning Prozess. Es folgt die Darstellung eines
Provisioning Frameworks auf Basis der Java EE (Kapitel 3.2). Abschließend wird das
Provisioning an der Sun Referenz Implementierung verdeutlicht (Kapitel 3.3).
1
Eine Beschreibung, welche Gründe für und gegen Java als Programmiersprache auf mobilen
Geräten spricht, ist z. B. in [BrMo06, S. 17-18], in [Sch07, S. 4] oder [JME01] zu finden.
1
Kapitel 2: Grundlagen des Application Provisioning von MIDlets
2 Grundlagen des Application Provisioning von MIDlets
Nachfolgend soll kurz beleuchtet werden, welche Voraussetzungen ein mobiles Gerät
mit Java ME bietet, welche Kommunikationsmöglichkeiten es bereitstellt (Kapitel 2.1)
und auf welche Technologien bei der Implementierung eines Provisioning Systems zurückgegriffen werden kann (Kapitel 2.2) (vgl. dazu Abbildung 1).
Kommunikation
Mobiles Gerät
Provisioning System
Abbildung 1: Kommunikation zwischen einem mobilen Gerät und einem Provisioning System
2.1 Java Micro Edition als Zielplattform von MIDlets
In diesem Kapitel werden kurz Grundkonzepte der Java ME erläutert, die für das Application Provisioning von MIDlets auf Java ME Geräten von Bedeutung sind. Hierzu wird
auf Konfigurationen und Profile der Java ME (Kapitel 2.1.1), auf die Application Management Software als Laufzeitumgebung für MIDlets (Kapitel 2.1.2) und auf die
Kommunikation und Identifikation von mobilen Geräten mit Java ME gegenüber Servern (Kapitel 2.1.3) eingegangen.
2.1.1 Konfigurationen und Profile in der Java Micro Edition
In der Java ME werden zwei verschiedene Konfigurationen für Endgerätetypen bzw.
Technologien unterschieden. Zum einen gibt es die Connected Device Configuration
(CDC), welche bspw. für High-End PDAs oder TV Set-top-Boxen mit leistungsfähiger
Hardware vorgesehen ist. Zum anderen gibt es die Connected Limited Device Configuration (CLDC), welche speziell auf die Einschränkungen mobiler Endgeräte abgestimmt
ist – wie z. B. Handys. Dabei umfassen die Konfigurationen – wie weiter oben erwähnt – eine JVM und Sätze von Bibliotheken, die aufgrund der Ressourceneinschränkungen angepasst sind und eine Untermenge der Java SE API bieten [BrMo06, S. 1920]. Beide Konfigurationen liegen in der neusten Fassung als Version 1.1 vor.
Im Folgenden wird insbesondere auf Geräte mit der CLDC näher eingegangen, da ein
Großteil der mobilen Geräte diese Konfiguration unterstützt und bei der CDC nur geringfügige Unterschiede zum Programmieren mit der Java SE zu beachten sind
2
[BrMo06, S. 38]. Jedoch ist zu erwähnen, dass mit steigender Hardware-Ausstattung in
Zukunft voraussichtlich auch immer mehr mobile Geräte die CDC erfüllen können.2
Auf den Konfigurationen der Geräte setzen die sog. Profile auf. Sie ergänzen – wie weiter oben erwähnt – die API der Konfigurationen mit notwendigen fehlenden API. Im
Zusammenhang mit der CLDC wird hauptsächlich das Mobile Information Device Profile (MIDP) verwendet, welches aktuell in der Version 2.0 vorliegt. Mit dem MIDP wird
das Ziel verfolgt, einen einheitlichen Standard für die Erstellung von mobilen Anwendungen zu schaffen und die Entwicklung dieser zu erleichtern. Das MIDP 2.0 enthält
u. a. API für die grafische Benutzerschnittstelle, Spiele, Persistenz von Daten, Kommunikation mit dem Internet und Multimedia [We06, S. 54-55]. Es legt dabei zusätzlich
zur Konfiguration z. B. die minimalen Hardwareanforderungen für Bildschirme, die
Sicherheit für MIDlets und eine Spezifikation für das Laden und Installieren von MIDlets über die Luftschnittstelle (Over-The-Air) fest [BrMo06, S. 38-40; JSR118].3 Auf
den Profilen können zusätzlich noch optionale Pakete aufbauen. Abbildung 2 veranschaulicht den Aufbau einer Java ME Implementierung in einem Mobiltelefon.
Optionale Pakete (z. B. Multimedia)
Profil (z. B. MIDP 2.0)
Konfiguration (z. B. CLDC 1.1)
Betriebssystem (z. B. Symbian)
Abbildung 2: Aufbau einer Java ME Implementierung in einem Mobiltelefon [We06, S. 54]
2.1.2 Application Management Software
Die Bezeichnung MIDlets für mobile Java Programme macht hierbei die Konformität
zu einem MIDP deutlich. MIDlets, die bspw. für das MIDP 2.0 geschrieben wurden,
lassen sich in den seltensten Fällen auf einem mobilen Gerät mit einer älteren MIDP
Version ausführen. Dies muss bei der Installation auf einem mobilen Gerät sichergestellt werden. Das MIDP sieht zur Kompatibilitätsprüfung u. a. den Java Application
Descriptor (JAD-Datei) vor, welcher Details über das zu installierende MIDlet in Form
2
3
Weitere Details zu den Einschränkungen der CLDC 1.1 sind in der Spezifikation der CLDC
unter [JSR139a] zu finden. Der Umfang der API der CLDC 1.1 ist in der CLDC API Documentation [CLDC03] beschrieben. Für nähere Informationen zur CDC 1.1 sei hier direkt auf die Spezifikationen der CDC unter [CDC06], [CDC06a] und [JSR218] verwiesen.
Auf die Spezifikation für das Laden und Installieren von MIDlets wird in Kapitel 3.1 näher eingegangen. Weitere Informationen zu alternativen Konfigurationen und Profilen sind bspw. in
[BrMo06], [Sch07] oder auf den Seiten der Java ME der Sun Microsystems Inc.
http://java.sun.com/javame/reference/index.jsp zu finden. Für weitere Einzelheiten zum MIDP
2.0 sei hier direkt auf die Spezifikation des MIDP 2.0 unter [JSR118] verwiesen.
3
von Attributen enthält. Diese Attribute, wie z. B. das Attribut MIDlet-Jar-Size für
die Größe des MIDlets oder das Attribut MicroEdition-Profile für die vom MIDlet benötigte MIDP Version, werden im Rahmen der Installation analysiert. Hierbei
wird überprüft, ob das MIDlet auf dem mobilen Gerät lauffähig ist und installiert werden kann.4 Die Überprüfung auf Kompatibilität wird dabei geräteseitig durch die sog.
Application Management Software (AMS) durchgeführt [KrHa03, S. 53-57; JSR118].
Alternativ zur JAD-Datei kann die AMS auch die Manifest-Datei der JAR-Datei überprüfen, welche die gleichen Attribute wie die JAD-Datei enthalten muss.
Die AMS – oft auch Application Management System oder Java Application Manager
genannt (JAM) – bezeichnet die Laufzeitumgebung für MIDlets. Sie ist eine essenzielle
Komponente in jedem MIDP-kompatiblen Gerät und steuert den Download sowie den
Application-Life-Cycle von MIDlets auf dem mobilen Gerät [Sch07, S. 28; JSR118,
S. 20, S. 433]. Die AMS ist Teil des Betriebssystems und ermöglicht die Installation,
die Auswahl, die Ausführung, das Updaten und die Entfernung von MIDlets sowie Interaktion mit dem Benutzer und Behandlung von Fehlern [JSR118, S. 433-436;
BrMo06, S. 41; KrHa03, S. 54]. Das MIDP 2.0 spezifiziert im Rahmen des Ladens von
Software über die Luftschnittstelle noch weitere Anforderungen an den Funktionsumfang der AMS. Hierunter fallen u. a. die Suche nach MIDlets, die Authentifizierung und
der JAD- und JAR-Datei Transfer auf das mobile Gerät [JSR118, S. 20]. In Abbildung 3
ist ein Beispiel einer AMS dargestellt, auf der ein MIDlet installiert und die entsprechende JAD-Datei angezeigt wird.
Abbildung 3: Installation eines MIDlets und Anzeige einer JAD-Datei in einer AMS
4
Eine Zusammenstellung von notwendigen und optionalen Attribute im MIDP 2.0 ist in Anhang
A dargestellt. Weitere Details sind in der Spezifikation des MIDP 2.0 [JSR118, S. 427-433] zu
finden.
4
2.1.3 Kommunikation und Identifikation eines mobilen Gerätes
Mobile Geräte können über verschiedene Techniken kommunizieren. Hier ist z. B. die
Kommunikation über serielles Kabel, Bluetooth, Global System for Mobile Communications (GSM) oder Universal Mobile Telecommunications System (UMTS) zu nennen.
Entsprechend können MIDlets über diese Techniken auf das mobile Gerät übertragen
werden. Während die drei erstgenannten Techniken i. d. R. keine Kommunikation mit
dem Internet ermöglichen, können mobile Geräte über die letztgenannten Techniken
bspw. per Hypertext Transfer Protokoll (HTTP bzw. HTTPS) oder per Wireless Application Protokoll (WAP) mit Servern und Webseiten Kontakt aufnehmen und Dateien –
z. B. JAD- oder JAR-Dateien – vom Server laden. Dabei wird HTTP im MIDP 2.0 als
Protokoll auf jeden Fall vorgeschrieben, da über HTTP u. a. JAD- und JAR-Dateien von
einem Server geladen werden [JSR118, S. 20]. WAP wird optional unterstützt [JSR118,
S. 26-29].
Hierbei ist in der MIDP 2.0 Spezifikation z. B. für HTTP die Unterstützung eines Großteils der HTTP 1.1 Spezifikation (RFC 2616) sowie die HTTP Basic und Digest Access
Authentifizierung (RFC 2617) gefordert [JSR118, S. 16-17, S. 20]. So sollen sich MIDP
2.0 kompatible Geräte bspw. einem Server gegenüber mit einem HTTP Request-Header
identifizieren können. Dies geschieht über den Header User-Agent. Weitere vorgesehene HTTP Request-Header sind der Accept-Language Header – für die auf dem
Gerät benutzte Sprache – und der Accept Header – für die Art des nachgefragten Content. Ein beispielhafter HTTP Request von einem MIDP-Gerät (CoolPhone/1.4), was
eine JAD-Datei (text/vnd.sun.j2me.app-descriptor) bei einem Server nachfragt, sieht folgendermaßen aus [JSR118, S. 25-29]:5
GET http://host.foo.bar/app-dir/game.jad HTTP/1.1
Host: host.foo.bar
Accept: text/vnd.sun.j2me.app-descriptor
User-Agent:CoolPhone/1.4 Profile/MIDP-2.0 Configuration/CLDC-1.0
Accept-Language: en-US, fi, fr
Accept-Charset: utf-8
Als weiteren wichtigen Bestandteil der HTTP-Kommunikation sieht das MIDP 2.0 GET
und POST Requests vor. Hierauf wird im späteren Kapiteln näher eingegangen (vgl.
Kapitel 3.1.2).
5
Für weitergehende Informationen sei auf die MIDP 2.0 Spezifikation verwiesen [JSR118]. Die
HTTP 1.1 Spezifikation (RFC 2616) ist unter http://www.ietf.org/rfc/rfc2616.txt und die Authentication Spezifikation (RFC 2617) unter http://www.ietf.org/rfc/rfc2617.txt erreichbar.
5
2.2 Java Enterprise Edition als Plattform für Provisioning Server
Die MIDP 2.0 Spezifikation fordert, wie oben erwähnt, dass konforme Geräte HTTP
und eventuell WAP unterstützen. Außerdem bieten mobile Geräte mittlerweile in den
meisten Fällen einen Browser zur Suche nach passenden MIDlets. Aus diesem Grund
liegt es nahe, für Provisioning Systeme Web-basierte Technologien zu benutzen.
Die Java EE bietet eine „Plattform für unternehmensweite und übergreifende Anwendungen“ [KoFW06, S. 1]. Hierbei sieht das Java EE Konzept eine strikte Trennung von
Präsentation (Client), Geschäftslogik (Business/Web Tier) und Datenebene (Enterprise
Information Systems Tier) in einer sog. Multi-Tier Architektur vor. Zusätzlich wird die
Trennung der organisatorischen Aufgaben und der Verwaltung der Komponenten propagiert. Die Java EE ist – wie die Java ME – plattformunabhängig [KoFW06, S. 7-9;
JEE06, S. 3]. Abbildung 4 veranschaulicht die Multi-Tier Web Architektur der Java EE.
Dyn. HTML
Pages
Client Tier
JSP Pages, Servlets
Web Tier
Enterprise Beans
Business Tier
Database
Enterprise
Information
System Tier
Client Machine
Java EE Server
Database Server
Abbildung 4: Java EE Multi-Tier Web Architektur [JEE06, S. 3]
Mit Java Server Pages (JSP) und Servlets bietet die Java EE auch eine Technologie zur
dynamischen, serverseitigen, Web-basierten Präsentation von Java-Applikationen. JSP
ermöglicht es dabei, statischen HTML-Seiten kleine Java Code-Stücke hinzuzufügen
und so dynamischen Inhalt zu generieren. Servlets hingegen sind Java-Klassen, die –
ähnlich CGI-Skripten – Eingabeparamter in der Geschäftslogik, welche durch sog. Enterprise Beans verwirklicht wird, verarbeiten und dynamisch erzeugte HTML-Seiten
ausgeben können [KoFW06, S. 11-13].6
Auf der Java EE und insbesondere auf JSP und Servlets basiert die J2EE Client Provisioning Specification Version 1.0 (JSR-124) [JSR124a, S. 21-24]. Die Spezifikation,
welche in Form der Sun Client Provisioning Reference Implementation ein Provisioning
von MIDlets erlaubt, wird im Folgenden näher dargestellt [JCPRI10].
6
Für weiterführende Details sei bezüglich Java EE z. B. auf [JEE06] bzw. für Servlets z. B. auf
[HuCr01] verwiesen.
6
Kapitel 3: Darstellung des Application Provisionings von MIDlets und eines
Provisioning Frameworks
3 Darstellung des Application Provisionings von MIDlets
und eines Provisioning Frameworks
In den bisherigen Ausführungen wurden die Voraussetzungen und Möglichkeiten von
mobilen Geräten auf Basis der Java ME sowie deren Kommunikationsmöglichkeiten
mit Provisioning Systemen beschrieben, die bspw. auf der Java EE Plattform aufbauen
(vgl. Abbildung 5, welche Abbildung 1 verfeinert). Die Installation von MIDlets auf
mobilen Geräten ist – wie beschrieben – mit Besonderheiten verbunden: Es müssen u. a.
die Einschränkungen der mobilen Geräte bei der Kompatibilität von MIDlets berücksichtigt werden. Der Benutzer sollte deshalb beim Provisioning von MIDlets unterstützt
werden, damit überflüssige Downloads von nicht installierbaren MIDlets und so auch
Verbindungskosten im GSM- oder UMTS-Netz vermieden werden.
HTTP-Kommunikation
bspw. über
GSM oder UMTS
MIDP 2.0-Gerät
Provisioning System auf Java EE
Plattform (z. B. Sun Reference
Implementation)
Abbildung 5: Kommunikation zwischen einem MIDP-Gerät und einem Provisioning System
Im Folgenden wird näher auf das Application Provisioning von MIDlets eingegangen.
Dazu werden zuerst generelle Aspekte, wie z. B. der der Prozess des Application Provisionings von MIDlets, erläutert (Kapitel 3.1). Anschließend wird auf die Client Provisioning Specification (Kapitel 3.2), einem Framework, welches den Aufbau eines Provisioning Systems ermöglicht und u. a. den Nutzer bei der Suche nach passenden MIDlets
unterstützen kann. Anhand einer Reference Implementation von Sun wird die Client
Provisioning Specification dann in der Praxis vorgestellt (Kapitel 3.3).
3.1 Application Provisioning von MIDlets
In diesem Kapitel werden generelle Aspekte des Application Provisionings von MIDlets
beschrieben. Dazu werden zuerst der Begriff des Application Provisionings näher bestimmt und die verschiedenen Arten des Application Provisionings dargestellt. Anschließend wird ein konkreter Provisioning Prozess erläutert und danach der benötigte
Funktionsumfang eines Provisioning Systems zusammengefasst.
7
3.1.1 Begriffsbestimmung und Arten des Application Provisionings
Application Provisioning beschreibt die Aktivitäten von Provisioning Systemen, „Services“ anzubieten, sowie den Prozess, diese „Services“ an die verschiedenen Client Geräte auszuliefern (vgl. Kapitel 1). Als „Services“ werden Applikationen (Applications)
bzw. „Bundles“ und im Rahmen dieser Ausarbeitung MIDlets – d. h. JAR- und
JAD-Dateien – verstanden [JSR124a, S. 7]. Diese allgemeine Umschreibung des Provisionings wird häufig durch die Aufzählung von Provisioning Teilprozessen verdeutlicht.
Zu diesen Teilprozessen zählt zuerst das Anbieten von MIDlets auf einem Provisioning
System, welches durchsucht werden kann. Als nächstes können passende MIDlets ausgewählt, transferiert und letztendlich installiert werden [Ma03]. Zur Veranschaulichung
des Provisionings und der Funktionen eines Provisioning Systems wird häufig ein Getränkeautomat als Vorbild herangezogen (vgl. Kapitel 1): Die Befüllung sowie das Anbieten von verschiedenen Getränken, die Möglichkeit der Getränkeauswahl, die Ausgabe des Getränks und das Trinken des Getränks vom Käufer. Sowohl bei einem Provisioning System als auch bei einem Getränkeautomaten kann zusätzlich ein Bezahlungsvorgang mit eventuell vorheriger Authentifizierung vonnöten sein [JSR124a, S. 11].
Das Provisioning im Rahmen der Java ME lässt sich in verschiedene Arten unterteilen.
Einen Überblick bietet die in Abbildung 6 dargestellte Strukturierung. Als erstes Kriterium kann z. B. die Initiierung des Provisionings herangezogen werden. Die Initiierung
des Provisionings kann durch den Netzbetreiber, eine Software Komponente, die weitere zu ladende Komponenten benötigt, oder durch gemeinsame Bibliotheken initiiert
werden [JSR232a]. Diese Art des Provisionings ist unter dem Oberbegriff Mobile Operational Management (JSR-232) zusammengefasst [JSR232]. Eine andere Initiierungsart ist das User-initiated Provisioning. Hier sucht ein Benutzer aktiv mit einer sog. Discovery Application – wie z. B. einem Browser – nach MIDlets.
Application Provisioning
User-initiated
Over-The-Air
Mobile Operational Management
Andere Übertragungswege
(z.B. per Software)
Abbildung 6: Strukturierung des Application Provisionings
Das Mobile Operational Management ist eine wichtige Spezifikation bspw. für Handyhersteller und Netzbetreiber zum Management von Handyfirmware, Betriebssystem,
Frameworks usw. – kurz von Services und Applikationen [Hai05]. Da die Spezifikation
8
sehr jung ist, ist diese Initiierungsart noch nicht auf vielen Geräten verbreitet.7 Das Mobile Operational Management bietet die Möglichkeit, ein automatisches Provisioning
durchzuführen. So kann z. B. bei fehlerhaften API oder Applikation ein Update on demand verbreitet werden. Hierzu benötigt das Mobile Operational Management jedoch
Interaktions- und Zugriffsmöglichkeiten zwischen bzw. auf Pakete [JSR232a]. Dies ist
aber in der CLDC 1.1 und im MIDP 2.0 nicht vorgesehen, sondern ist lediglich im Rahmen der CDC möglich [JSR232a; Hai05]. Aus diesem Grund wird das Mobile Operational Management in dieser Ausarbeitung nicht weiter vertieft (vgl. auch Kapitel 2.1.1).
Im Folgenden wird näher auf das User-initiated Provisioning eingegangen. Als zweites
Strukturierungskriterium dient hier der Übertragungsweg der Software zum mobilen
Gerät. Hier wird u. a. die Luftschnittstelle – oder wie oben erwähnt Over-The-Air (OTA) – von anderen Übertragungswegen – wie z. B. per Herstellersoftware über serielles
Kabel oder Bluetooth – unterschieden. Zur Übertragung per Herstellersoftware wird ein
passendes MIDlet auf einen PC geladen und danach eine Software (z. B. Nokia PC Suite) verwendet, die die Installation des MIDlets über serielles Kabel oder Bluetooth auf
dem mobilen Gerät vornimmt. Diese Art der Übertragung wird herstellerabhängig implementiert und ist nicht Teil einer Spezifikation [BrMo06, S. 30-31; JSR118, S. 20].
Nachfolgend wird das OTA User-initiated Provisioning näher beleuchtet, welches als
Standard in der MIDP 2.0 Spezifikation festgelegt ist [JSR118, S. 19-26].8
3.1.2 Der Over-The-Air User-Initiated Provisioning Prozess
Der Provisioning Prozess kann in drei Teilprozesse unterteilt werden: Stocking, Discovery und Delivery. Alle Teilprozesse nutzen das Repository – ein Verzeichnis, welches
die zum Provisioning angebotenen Dateien enthält – und werden zwecks Dekomposition der Aufgaben von verschiedenen Rollen ausgeführt. Stocking bezeichnet hierbei das
Managen des Repository, Discovery das Durchsuchen des Repository nach passenden
MIDlets und Delivery das Laden und Installieren der MIDlets [La03]. Einen vereinfachten Überblick über den Provisioning Prozess und dessen Teilprozesse bietet Abbildung
7.
7
8
Final Release 1.0 der JSR-232 ist von Oktober 2006. Jedoch wurde die Entwicklung der Spezifikation unter Leitung der Open Service Gateway Initiative (OSGi) schon vor geraumer Zeit vollendet und im Jahr 2003 als JSR vorgeschlagen. Nähere Details sind unter [JSR232] bzw.
[JSR232a] oder unter http://www.osgi.org/ zu erhalten.
Das OTA User-initiated Provisioning war im MIDP 1.0 lediglich als Recommended Practice
formuliert, wurde aber zur Vereinheitlichung in die MIDP 2.0 Spezifikation aufgenommen.
9
Stocking
«uses»
«uses»
Repository
Management
Discovery
MIDlet Developer
«uses»
Provisioning System Developer
Delivery
Client User
Abbildung 7: Vereinfachtes Anwendungsfall-Diagramm des Provisioning Prozesses
Der OTA User-Initiated Provisioning Prozess – wie er in der MIDP 2.0 Spezifikation
beschrieben ist – umfasst dabei lediglich die Teilprozesse Discovery und Delivery aus
Sicht eines Benutzers. Beim OTA User-initiated Provisioning Prozess wird davon ausgegangen, dass das Repository als Teil eines Provisioning Systems bereitsteht und entsprechende Dateien zum Download vorhanden sind. Als Provisioning Systeme können
bspw. leicht angepasste Webserver benutzt werden, die JAR-Dateien und eventuell vorhandene JAD-Dateien zum Download anbieten [Or02].9 Ein angepasster Webserver
bietet jedoch beim Stocking und Repository Management weniger Komfort als ein spezielles Provisioning System (vgl. Kapitel 3.1.3). Auf den Prozess des Stocking und auf
das Repository sowie auf die Implementierung des Discovery bzw. Delivery Prozesses
aus Sicht eines Provisioning Systems wird später näher eingegangen (vgl. Kapitel 3.2).
Abbildung 8 verdeutlicht den Ablauf eines erfolgreichen OTA User-initiated Provisioning Prozesses, der im Anschluss näher erläutert wird.
AMS
Discovery
JAD-Server
JAR-Server
Notification-Server
GET /midlet.jad
200 OK
GET /midlet.jar
Delivery
200 OK
POST /install-notify: 900 Success
200 OK
Abbildung 8: Sequenzdiagramm eines erfolgreichen OTA Provisioning Prozesses [Sch07, S. 29]
Discovery bezeichnet, wie oben erwähnt, das Durchsuchen eines Repository nach passenden MIDlets. Diese Suche wird durch eine „Discovery Application“ (DA) – wie z. B.
einen Browser oder einer speziell von der AMS bereitgestellten Anwendung – ermög-
9
Die Anpassung umfasst lediglich eine Änderung des MIME-Headers (vgl. hierzu [Or02]).
10
licht. Die DA greift dabei per WAP oder HTTP auf das Provisioning System zu und
zeigt die installierbaren MIDlets meist in Form einer Liste an. Die Mindestanforderung
des MIDP 2.0 sieht vor, dass der Benutzer den Discovery bzw. Delivery Prozess durch
die Eingabe eines Links zu einer JAD- bzw. zu einer JAR-Datei in der DA oder AMS
erreicht [JSR118, S. 20-21]. Jedoch kann dieser Link bei vielen Geräten auch per SMS
o. ä. übertragen werden (Push Dienste). Sobald der Benutzer den Link anwählt, soll das
mobile Gerät – wie weiter oben beschrieben – einen Request mit entsprechendem Request-Header versenden, und das Provisioning System muss darauf den Datentyp der
Datei per MIME-Header in der Antwort bekannt geben. Falls es sich bei der angeforderten Datei um eine JAR-Datei handelt, startet der Delivery Prozess.10 Wenn es sich
um eine JAD-Datei handelt, soll diese heruntergeladen werden und inklusive Download-Link der JAR-Datei an die AMS übergeben werden. Die AMS führt gegebenenfalls
Konvertierungsmaßnahmen in den vom Gerät verwendeten Zeichensatz aus und überprüft die Attribute der JAD-Datei auf Kompatibilität. Sollte die Installation nicht möglich sein, soll die AMS der Spezifikation zufolge über den Grund des Scheiterns informieren und einen sog. Status Code per POST Request (vgl. Tabelle 1) an einen Notification-Server übertragen, der in der JAD-Datei angegeben werden kann (MIDletInstall-Notify). In der MIDP 2.0 Spezifikation wird außerdem die jederzeitige Ab-
bruchmöglichkeit durch den Benutzer gefordert. Wenn die Installation möglich ist, sollen die Attribute – wie z. B. die Lizenzvereinbarungen – und ein Bestätigungsbutton für
die weitere Installation in der AMS angeboten werden [JSR118, S. 20-21].
Status Code
Status Message
900
Success
901
Insufficient Memory
902
User Cancelled
903
Loss of Service
904
JAR size mismatch
905
Attribute Mismatch
906
Invalid Descriptor
907
Invalid JAR
908
Incompatible Configuration or Profile
909
Application authentication failure
910
Application authorization failure
911
912
Push registration failure
Deletion Notification
Tabelle 1: POST Request Status Codes beim Discovery und Delivery Prozess [JSR118, S. 24]
10
Die MIDP Spezifikation teilt diese Prozesse in Installation und Update auf [JSR118, S. 21-24].
In der Client Provisioning Specification wird dies als Delivery bezeichnet [JSR124a, S. 45-48].
11
Der Delivery Prozess beginnt mit der Übergabe des Download-Links der JAR-Datei
bzw. dem Download der JAR-Datei selbst. Hier sei erwähnt, dass die JAD- und die
JAR-Datei nicht unbedingt auf dem gleichen Servern liegen müssen (vgl. auch
Abbildung 8). Wenn die JAD- und die JAR-Datei auf unterschiedlichen Servern liegen,
muss der Download-Link der JAR-Datei als Attribut MIDlet-Jar-URL in der
JAD-Datei definiert sein und mit an die AMS übergeben werden. Die JAR-Datei wird
über HTTP heruntergeladen, wobei das Provisioning System eine Authentifizierung
verlangen kann (vgl. erwähnte Authentifizierung in Kapitel 2.1.3). Wenn die JAR-Datei
geladen ist, wird sie von der AMS erneut überprüft, der Benutzer bei Fehlern gegebenenfalls alarmiert, das MIDlet installiert und ein Status Code an das Provisioning System versandt (vgl. Tabelle 1). Falls es sich bei dem heruntergeladenen MIDlet um ein
Update handelt – d. h. sich dieses MIDlet in gleicher oder ähnlicher Version schon auf
dem mobilen Gerät befindet – wird das alte MIDlet ersetzt und die persistenten Daten
zugreifbar gemacht. Hierbei müssen jedoch die Signaturen der MIDlets größtenteils
übereinstimmen [JSR118, S. 21-23].
3.1.3 Funktionsumfang von Provisioning Systemen
Bisher wurde bereits deutlich, dass ein Provisioning System eine zentrale Rolle im Provisioning Prozess einnimmt. Provisioning Systeme bieten eine zentrale Anlaufstelle für
Nutzer an, die sich von diesen MIDlets laden können. Dabei werden Funktionen für die
Teilprozesse Stocking, Discovery und Delivery sowie für das Repository Management
benötigt. Wie weiter oben beschrieben, kann diese Funktionen auch ein modifizierter
Webserver realisieren, Provisioning Systeme bieten allerdings mehr [Or02].
Provisioning Systeme müssen i. d. R. eine sehr große Anzahl von Dateien managen
können. Dabei ist es, wie oben erwähnt, sinnvoll, für Aufgaben Rollen zu vergeben
(vgl. Abbildung 7). Diese verschiedenen Rollen können durch ein spezielles Provisioning System besser unterstützt werden. Ein Benutzer kann durch ein spezielles Provisioning System z. B. während des Discovery Prozesses unterstützt werden, indem die
Menge an Dateien kategorisiert und durch Suchfunktionen eine bessere Qualität der
Treffer erreicht wird. Dies wird umso wichtiger, je größer die Anzahl der verwalteten
Dateien wird. Das betrifft sowohl Benutzer als auch MIDlet-Entwickler, die ihre bereitgestellten MIDlets managen müssen, als auch Provisioning System Entwickler, die das
gesamte Provisioning System managen müssen (vgl. zu den Rollen auch Abbildung 7).
12
Hinzu kommen u. a. Komfort-, Sicherheits- und Abrechnungsüberlegungen, falls einige
MIDlets kommerziell genutzt werden sollen [Or02; La03; JSR124a, S. 17-20].
3.2 Java Enterprise Edition Client Provisioning Framework
Die J2EE Client Provisioning Specification Version 1.0 stellt ein Framework zur Erstellung von Provisioning Systemen dar und ermöglicht, den Aufbau von Provisioning Systemen. Dabei ist das Framework nicht nur auf das Provisioning von MIDlets beschränkt, sondern kann auch andere Clients bzw. Protokolle – z. B. Java Network Launching Protokol (JNLP) – beim Provisioning durch sog. Provisioning Adapter bedienen
[JSR124a, S. 49-60]. Im Folgenden wird das Framework und dessen Unterstützung
beim OTA User-initiated Provisioning Prozess erläutert. Dazu wird zuerst ein Überblick
über die Client Provisioning Specification gegeben (Kapitel 3.2.1) und anschließend die
Unterstützung der Provisioning Teilprozesse durch das Framework erklärt. Hierzu zählen das Stocking und das Repository (Kapitel 3.2.2) sowie die serverseitige Implementierung der Discovery und Delivery Prozesse (Kapitel 3.2.3 bzw. 3.2.4).
3.2.1 Überblick
Das Ziel der Client Provisioning Specification ist die Unterstützung der Implementierung von „großen“ Provisioning Systemen (vgl. Kapitel 3.1.3) – in der Client Provisioning Specification „Advanced Portals“ genannt [JSR124a, S. 17-20]. Dabei sollen diese
Systeme, einmal implementiert, auch für andere Provisioning Adapter verwendet werden können und diese durch wenige Anpassungen unterstützen. Eine Grundüberlegung
dafür ist der modularisierte Aufbau des Frameworks [JSR124a, S. 8-11]. Den wesentlichen Aufbau eines Provisioning Systems nach der Client Provisioning Specification
verdeutlicht Abbildung 9.
Provisioning Framework
Java EE Applikations Server
Sonstige
Services
Erweitertes
Provisioning System
Repository
Adapter 1
(HTTP)
Provisioning Applikation
Adapter 2
(JNLP)
Provisioning
Adapter
Adapter 3
(andere)
Client Provisioning
API
Provisioning System
Clients
Abbildung 9: Aufbau eines Provisioning Systems nach der Client Provisioning Spec. [JSR124a, S. 10]
13
Vereinfacht beschrieben, stellt das Client Provisioning Framework die Kommunikation
zwischen Clients, die eine Anfrage nach MIDlets an das Provisioning System richten,
der Provisioning Applikation, die auf das Repository und auf sonstige Services zugreifen kann, und dem Repository, in dem die angebotenen MIDlets gespeichert sind, her
und vermittelt zwischen ihnen. Dazu kapselt das Framework die Clients durch Provisioning Adapter (≈ verschiedene Protokolle) vom Repository ab, was der Nutzer jedoch
während der Kommunikation mit dem Provisioning System i. d. R. nicht wahrnimmt.
Das Provisioning System agiert dabei – übertragen auf die Multi-Tier Web Architektur
der Java EE in Abbildung 4 – als Geschäftslogik (Provisioning Application und Provisioning API) und Präsentation (z. B. Adapter 1 mit HTTP), welche auf die Datenebene
(Repository und sonstige Services) zugreifen. Die sonstigen Services und das Repository können dabei auch von anderen verbundenen Provisioning Systemen oder Servern
angeboten werden und werden deshalb hier zusammen mit dem Provisioning System als
erweitertes Provisioning System bezeichnet (vgl. auch Abbildung 8). Unter sonstigen
Services sind bspw. Abrechnungsdienste zur kommerziellen Nutzung von MIDlets oder
LDAP-Verzeichnisse für die Nutzerverwaltung zusammengefasst. Die Funktionsweise
der Client Provisioning Specification ist in Abbildung 10 dargestellt. Diese wird in den
nächsten Kapiteln näher beschrieben.
Server (Stocking/Repository)
Kommunikation (Delivery)
Client (Discovery)
provisioning.xml
matchers.xml
device.xml
adapters.xml:
JNLP
PAR-Datei
(Java SE 1.3)
PAR-Datei
(MIDP 1.0)
adapters.xml:
HTTP
adapters.xml:
HTTP
adapters.xml:
HTTP
adapters.xml:
HTTP
Java SE 1.4
JNLP, HTTP
Java SE 1.3
HTTP
Java ME (MIDP 2.0)
HTTP, WAP
PAR-Datei
(MIDP 2.0)
Java ME (MIDP 1.0)
HTTP, WAP
Abbildung 10: Überblick über die Funktionsweise der Client Provisioning Specification
14
3.2.2 Stocking und Repository
Stocking bezeichnet, wie weiter oben erwähnt, das Managen des Repository. Das bedeutet, dass MIDlets im Repository verfügbar gemacht, verwaltet und gelöscht werden
müssen (vgl. hierzu auch den Application-Lifecycle in Kapitel 2.1.2) [JSR124a, S. 44].
Das Repository als Verzeichnis der bereitgestellten Dateien muss die MIDlets aufnehmen und entsprechend der Anfragen der Clients darstellen und ausliefern (Discovery
und Delivery) [La03]. Hierzu werden die MIDlets in spezielle Provisioning Archive
(PAR-Dateien) gepackt. Diese PAR-Dateien enthalten mindestens eine JAD-Datei und
eine
XML-Datei –
den
sog.
Provisioning
Descriptor
(/META-
INF/provisioning.xml). Hinzu kommen noch weitere optionale Dateien wie z. B.
ein Icon oder eine Lizenzvereinbarung. Die JAR-Datei muss nicht in der PAR-Datei
enthalten sein, muss aber über zumindest das Attribut MIDlet-Jar-URL in der
JAD-Datei erreichbar sein. Eine PAR-Datei kann z. B. folgenden Aufbau haben:
/META-INF/provisioning.xml
/Demo3D.jad
/Demo3D.jar
/Demo3D.agree.txt
Damit das Repository MIDlets auf die Suchanfragen der Benutzer darstellen kann, benötigt es Werte anhand derer es die Suchergebnisse bewerten kann (Matching). Diese
Werte werden zu jeder PAR-Datei im Provisioning Descriptor festgelegt. Darunter fallen u. a. Angaben zum MIDlet selbst (<tool-descriptions> bzw. <clientbundle>), zum Autor (<vendor-info>), zur MIDlet-Kategorie – ob es sich bspw. um
ein Spiel, einen Bildschirmschoner o. ä. handelt – und zu den Anforderungen
(<device-requirement>) – d. h. Konfiguration und Profil. Ein beispielhafter Provisioning Descriptor ist in Anhang A dargestellt. Eine Matching-Möglichkeit des Repository ist das Requirement/Capability Matching, welches die Anforderungen eines MIDlets (provisioning.xml) mit den Fähigkeiten eines Gerätes automatisch matcht, welche in einer weiteren XML-Datei (device.xml) festgehalten sind. Dieses Matching
wird im Rahmen des Discovery Prozesses anhand der Request-Header durchgeführt.
3.2.3 Discovery
Im Rahmen des Discovery Prozesses wird einem Benutzer anhand einer Suchanfrage
eine Trefferliste von MIDlets bzw. Links präsentiert. Hierbei kann ein Benutzer freie
Suchparameter verwenden oder bspw. – wie oben beschrieben –mit Hilfe des Re15
quest-Headers des mobilen Gerätes die Anforderungen eines MIDlets mit den Fähigkeiten matchen (Requirement/Capability Matching). Die Datei device.xml beinhaltet
eine Auflistung von Geräten und ihrer Fähigkeiten. Ein Teil einer device.xml-Beispieldatei ist in Anhang C abgebildet. Zu den angegebenen Schlüsseln ge-
hören u. a. die Identifikation des Gerätes (<identifier>), der sog. Adaptername
(<adapter-name>), mit dem bei einer Anfrage eines entsprechenden Gerätes der Delivery Prozess ausgeführt wird, und die Gerätefähigkeiten (<capability>) [JSR124a,
S. 21-33].
Die Matching-Konfigurationsdatei (matchers.xml) definiert dabei die Matching-Regeln
bzw.
-Algorithmen.
Im
JSR-124
ist
eine
Konfiguration
der
matchers.xml mit einem Default-Algorithmus angegeben, der in den meisten Fällen
ausreichen dürfte [La03]. Ein Teil der Default matchers.xml ist in Anhang D abgebildet. Dabei wird zuerst die Konfiguration (SoftwarePlatform.JavaPackage)
geprüft, da der <param-value> gesetzt ist. Als nächster Wert werden die durch den
Client
unterstützten
Kommunikationsprotokolle
für
Java
geprüft
(SoftwarePlatform.JavaProtocol).
3.2.4 Delivery
Der Delivery Prozess überträgt die per Link ausgewählten Dateien über ein Provisioning Adapter an einen Client. Der Adapter ist eine Software Komponente, welche die
auszuliefernden Dateien auf ein sog. Provisioning Model anpasst. Das Provisioning
Model bezeichnet dabei ein Netzwerkprotokoll – wie z. B. HTTP oder JNLP –, was für
den Delivery Prozess der MIDlets verwendet wird [JSR124, S. 49].
Ein Provisioning System kann über diese Adapter mehrere Provisioning Models anbieten. So kann ein Provisioning System neben einem MIDP-Adapter auch einen JNLPAdapter und einen HTTP-Adapter implementieren. Konfiguriert wird ein Adapter über
eine entsprechende Konfigurationsdatei (adpaters.xml). Einen Ausschnitt aus einer
Konfigurationsdatei ist in Anhang E abgebildet.
In der adapters.xml sind u. a. der Adaptername (<adapter-name>), auf den auch
der Discovery Prozess zurückgreift, und Angaben zum Descriptor (<descriptorfile>) zu machen.
16
3.3 Darstellung eines Provisioning Systems am Beispiel der Sun
Client Provisioning Reference Implementation
Die Sun Client Provisioning Reference Implementation setzt die Konzepte der J2EE
Client Provisioning Specification in eine lauffähige Java EE Anwendung um. Sie dient
dabei auch als Vorbild für weitere Implementierungen wie z. B. JVending.11
Von der Startseite (vgl. Abbildung 11) sind die Seiten für den Stocking und Discovery
erreichbar („Add/remove PAR files to/from the repository“ bzw. bspw. „browse available MIDlet suites“).
Abbildung 11: Startseite der J2EE Client Provisioning Reference Implementation
Das Stocking wird durch die Möglichkeit, PAR-Dateien auf das Provisioning System zu
laden, unterstützt (vgl. Abbildung 12). Die PAR-Dateien werden beim Hochladen im
Rahmen einer Pre-verification auf Vollständigkeit überprüft (vgl. hierzu [JSR124,
11
JVending ist unter http://jvending.sourceforge.net/ erreichbar.
17
S. 63]). Wenn wichtige Elemente in der PAR-Datei nicht enthalten sind, wird die Aufnahme der Datei in das Repository mit einer entsprechenden Fehlermeldung verweigert.
Abbildung 12: Stocking der J2EE Client Provisioning Reference Implementation
Der Discovery Prozess mobiler Endgeräte wird von der Reference Implementation
durch den Link /ri-test/jam/ unterstützt. Wird dieser Link in einer AMS aufgerufen, werden die installierbaren MIDlets in einer Liste angezeigt (vgl. Abbildung 13).
Dabei bietet die Reference Implementation die Möglichkeit, auch über andere Provisioning Adapter auf diese Liste zuzugreifen (vgl. Abbildung 14).
18
Abbildung 13: Discovery Prozess der Reference Implementation in der AMS
Der Delivery Prozess wird standardmäßig durch die Adapter MIDP, JNLP und generic – d. h. HTTP – unterstützt.
Abbildung 14: Discovery Prozess der Reference Implemtation in einem Browser
19
Kapitel 4: Zusammenfassung und Ausblick
4 Zusammenfassung und Ausblick
Im Rahmen dieser Ausarbeitung wurde kurz aufgezeigt, wie ein konkreter Provisioning
Prozess von MIDlets aussieht, welche Vorteile und welchen Funktionsumfang ein Provisioning Server bietet sowie eine Spezifikation für ein Framework zur Erstellung von
Provisioning Systemen vorgestellt.
Die Client Provisioning Specification bietet ein solides Framework für ein Provisioning
System. Für vereinzelte MIDlets ist der Aufwand zur Erstellung und Pflege eines solchen Systems mit dem Framework sicherlich zu groß. Wer aber große Systeme unterhält, ist mit der Umsetzung eines Servers mit diesem Framework besser bedient als mit
einem modifizierten Webserver [La03].
Aufgrund der Tatsache, dass das Framework auf Java EE aufbaut, sind die Sicherheit
und die Stabilität auch für kommerzielle Anwendungen ausreichend. Die Authentifizierung und die Übermittlung des Status Codes währende des Provisioning Prozesses erlauben dabei interessante Geschäftsmodelle. Hier sei z. B. auf die nutzungsabhängige
Abrechnung von MIDlets verwiesen.
Interessant wird voraussichtlich die Entwicklung des Mobile Operational Managements
im Rahmen der Java ME. Diese Initiierungsart des Provisionings bietet viele Vorteile,
die im momentanen Umfeld von mobilen Geräten (CLDC) noch nicht nutzbar sind. Angesprochen wurde jedoch, dass in Zukunft wahrscheinlich mehr mobile Geräte die CDC
unterstützen werden und somit Mobile Operational Management nutzen können.
Das Client Provisioning Framework bietet mit seinem modularen Aufbau und vielfältigen Erweiterungsmöglichkeiten generell eine gute Basis für das Provisioning. Ein leicht
fader Beigeschmack bleibt bei der Nutzung der Sun Reference Implementation dadurch
hängen, dass diese Implementierung lediglich mit dem Java 2 SDK 1.4.2 und dem Java
2 SDK Enterprise Edition 1.3.1 als Plattform laufen will.
20
Anhang A: Zusammenstellung einiger JAD-Datei Attribute nach MIDP 2.0
Spezifikation
A Zusammenstellung einiger JAD-Datei Attribute nach
MIDP 2.0 Spezifikation
Attribute Name
MIDlet-Name
MUST
Yes
MIDlet-Version
Yes
MIDlet-Vendor
Yes
MIDlet-Icon
MIDlet-Description
No
MIDlet-Info-URL
No
MIDlet-Jar-URL
Yes
MIDlet-Jar-Size
Yes
MicroEdition-Profile
Yes
MicroEditionConfiguration
MIDlet-Install-Notify
MIDlet-Delete-Notify
MIDlet-Delete-Confirm
No
No
No
Yes
Attribute Description
The name of the MIDlet suite that identifies the MIDlets to the user.
The version number of the MIDlet suite. Version numbers are formatted so they
can be used by the application management software for install and upgrade uses,
as well as communication with the user.
The organization that provides the MIDlet suite.
The case-sensitive absolute name of a PNG file within the JAR used to represent
the MIDlet suite. It SHOULD be used when the Application Management Software
displays an icon to identify the suite.
The description of the MIDlet suite.
A URL for information further describing the MIDlet suite. The syntax and meaning
MUST conform to RFC2396 and RFCs that define each scheme.
The URL from which the JAR file can be loaded. The syntax
and meaning MUST conform to RFC2396 and RFCs that
define each scheme. Both absolute and relative URLs MUST
be supported. The context for a relative URL is the URL from
which this application descriptor was loaded.
The number of bytes in the JAR file.
The J2ME profiles required, using the same format and value as the System property microedition.profiles(for example "MIDP-2.0"). The device must implement all
of the profiles listed. If any of the profiles are not implemented the installation
MUST fail. Multiple profiles are separated with a blank (Unicode U+0020).
The J2ME Configuration required using the same format and value as the System
property microedition.configuration(for example"CLDC-1.0").
Refer to the OTA Specification for details.
21
Anhang B: Beispiel eines Provisioning Descriptors
B Beispiel eines Provisioning Descriptors
<?xml version="1.0" encoding="UTF-8"?>
<provisioning-archive xmlns:j2ee-cp="http://java.sun.com/xml/ns/j2eecp" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee-cp
Provisioning_1_0.xsd ">
<tool-descriptions>
<description locale="">description</description>
<display-name locale="">Demo3D</display-name>
</tool-descriptions>
<client-bundle>
<content-id>1</content-id>
<version>1.0</version>
<bundle-type>RINGTONE</bundle-type>
<descriptor-file mime-type="">Demo3D.jad</descriptor-file>
<tool-descriptions>
</tool-descriptions>
<user-descriptions>
</user-descriptions>
<vendor-info>
<vendor-name locale="">Horst</vendor-name>
<vendor-description locale="">vendor-description</vendordescription>
</vendor-info>
<copyright locale="" uri="">copyright</copyright>
<device-requirement>
<requirement-name>MIDP-2.0</requirement-name>
</device-requirement>
</client-bundle>
</provisioning-archive>
22
Anhang C: Beispiel einer Device Capability Datei
C Beispiel einer Device Capability Datei
<devices xmlns="http://java.sun.com/xml/ns/j2ee-cp"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
Devices_1_0.xsd">

<device>
<identifier>
Mozilla
</identifier>
<adapter-name>
jnlp
</adapter-name>
<adapter-name>
midp
</adapter-name>
<adapter-name>
generic
</adapter-name>
<capability>
<capability-name>
SoftwarePlatform.JavaPlatform
</capability-name>
<capability-value>
J2SE/1.4
</capability-value>
</capability>
</device>

<device>
<identifier>
MIDP-2.0
</identifier>
<adapter-name>
midp
</adapter-name>
<capability>
<capability-name>
SoftwarePlatform.JavaPlatform
</capability-name>
<capability-value>
MIDP/2.0
</capability-value>
</capability>
<capability>
<capability-name>
HardwarePlatform.ScreenSize
</capability-name>
<capability-value>
96x128
</capability-value>
</capability>
<capability>
<capability-name>
HardwarePlatform.BitsPerPixel
</capability-name>
<capability-value>
2
</capability-value>
</capability>
</device>
…
</devices>
23
Anhang D: Beispiel einer Matchers Datei
D Beispiel einer Matchers Datei
<matchers xmlns="http://java.sun.com/xml/ns/j2ee-cp"
Matchers_1_0.xsd">
<matcher>
<attribute-name>SoftwarePlatform.JavaPlatform</attribute-name>
<matcher-class>javax.provisioning.matcher.VersionMatcher</matcherclass>
<init-param>
<param-name>allMustMatch</param-name>
<param-value>false</param-value>
</init-param>
</matcher>
<matcher>
<attribute-name>SoftwarePlatform.JavaPackage</attribute-name>
<init-param>
<param-value>true</param-value>
</init-param>
</matcher>
<matcher>
<attribute-name>SoftwarePlatform.JavaProtocol</attribute-name>
<init-param>
</init-param>
</matcher>
…
</matchers>
24
Anhang E: Beispiel einer Adapters Datei
E Beispiel einer Adapters Datei
<adapters xmlns="http://java.sun.com/xml/ns/j2ee-cp"
Adapters_1_0.xsd">
<adapter>
<!-This is the MIDP OTA adapter.
-->
<adapter-name>midp</adapter-name>
<adapterclass>com.sun.provisioning.adapters.midp.AdapterMIDP</adapter-class>
<base-uri>/delivery/midp</base-uri>
<descriptor-file>
<extension>jad</extension>
<mime-type>text/vnd.sun.j2me.app-descriptor</mime-type>
</descriptor-file>
<fulfillment-duration>0</fulfillment-duration>
<init-param>
<param-name>install-notify</param-name>
</init-param>
<init-param>
<param-name>delete-notify</param-name>
</init-param>
</adapter>
…
</adapters>
25
Literaturverzeichnis
[BrMo06] Ulrich Breymann, Heiko Mosemann: Java ME – Anwendungsentwicklung
für Handys, PDA und Co, Hanser Fachbuchverlag, 2006.
[CDC06]
Sun Microsystems Inc.: Java Plattform, Micro Edition Connected Device
Configuration Data Sheet, http://java.sun.com/j2me/docs/j2me_cdc.pdf,
2006, Abrufdatum: 2006-11-09.
[CDC06a] Sun Microsystems Inc.: CDC API Comparision,
http://java.sun.com/products/cdc/reference/cdc_packages.pdf, 2006, Abrufdatum: 2006-11-11.
[CLDC03] Sun Microsystems Inc.: CLDC API Documentation,
http://java.sun.com/j2me/docs/pdf/cldc11api.pdf, 2003, Abrufdatum: 200611-11.
[CLDC04] Sun Microsystems Inc.: Datasheet Connected Limited Device Configuration
HotSpot Implementation,
http://java.sun.com/j2me/docs/pdf/CLDC_HI112.pdf, 2004, Abrufdatum:
2006-11-11.
[Hai05]
Sven Haiges: Mobil-Machung – Mobile Operational Management mit OSGi, Javaspektrum 2/2005, S. 21-23, SIGS-DATACOM Verlag, 2005
[HuCr01] Jason Hunter, William Crawford: Java Servlet Programming, 2nd Edition,
O’Reilly, 2001.
[JCPRI10] Sun Microsystems Inc.: J2EE Client Provisioning 1.0 Reference Implementation, http://java.sun.com/j2ee/provisioning/download.html, 2003, Abrufdatum: 2006-11-30.
[JEE06]
Jennifer Ball, Debbie Carson, Ian Evans, Scott Fordin, Kim Haase, Eric
Jendrock: The Java EE 5 Tutorial – For Sun Java System Application Server
Plattform Edition 9,
http://java.sun.com/javaee/5/docs/tutorial/doc/JavaEETutorial.pdf, 2006,
Abrufdatum: 2006-11-29.
[JME01]
Sun Microsystems Inc.: Building Compelling Services for the Wireless
Market Using Java Technology,
http://developers.sun.com/techtopics/mobility/getstart/articles/whyjava/,
2001, Abrufdatum: 2006-11-08.
[JSR118] Java Community Process: Mobile Information Device Profile for Java 2
Micro Edition Version 2.1,
http://jcp.org/aboutJava/communityprocess/mrel/jsr118/index.html, 2006,
[JSR124] Java Community Process: J2EE Client Provisioning Specification,
http://jcp.org/en/jsr/detail?id=124, 2003, Abrufdatum: 2006-11-11
[JSR124a] Java Community Process: J2EE Client Provisioning Specification Final Release Version 1.0,
http://jcp.org/aboutJava/communityprocess/final/jsr124/index.html, 2003,
[JSR139] Java Community Process: Connected Limited Device Configuration 1.1,
http://www.jcp.org/en/jsr/detail?id=139, 2003, Abrufdatum: 2006-11-11.
[JSR139a] Java Community Process: J2ME Connected Limited Device Configuration
(CLDC) Specification 1.1 Final Release,
http://jcp.org/aboutJava/communityprocess/final/jsr139/index.html, 2003,
[JSR218] Java Community Process: Connected Device Configuration (CDC) 1.1,
http://jcp.org/en/jsr/detail?id=218, 2006, Abrufdatum: 2006-11-09.
[JSR232] Java Community Process: JSR-232 Mobile Operational Management,
http://www.jcp.org/en/jsr/detail?id=232, 2006, Abrufdatum: 2006-12-01.
[JSR232a] Java Community Process: JSR-232 Mobile Operational Management for
Java 2 Plattform – Micro Edition Version 1.0 Final Specification Package.pdf, http://jcp.org/aboutJava/communityprocess/final/jsr232/index.html ,
2006, Abrufdatum: 2006-12-01.
[KoFW06] Arne Koschel, Stefan Fischer, Gerhard Wagner: J2EE/Java EE kompakt –
Enterprise Java: Konzepte und Umfeld, 2. Aufl., Elsevier Verlag, 2006
[KrHa03] Michael Kroll, Stefan Haustein: J2ME Developer´s Guide – JavaAnwendungen für mobile Geräte, Markt + Technik Verlag, 2003.
[La03]
Eric Larson: An Overview of JSR 124: J2EE Client Provisioning,
http://developers.sun.com/techtopics/mobility/midp/articles/provisioning/,
2003, Abrufdatum: 2006-12-02.
[Ma03]
Quasay Mahmoud: Getting started with the J2EE Client Provisioning Reference Implementation,
http://developers.sun.com/techtopics/mobility/midp/articles/provisioningget
start/, 2003, Abrufdatum: 2006-12-02.
[Or02]
Enrique Ortiz: Introduction to OTA Application Provisioning,
http://developers.sun.com/techtopics/mobility/midp/articles/ota/index.html,
2002, Abrufdatum: 2006-10-26.
[Sch07]
Klaus-Dieter Schmatz: Java Micro Edition – Entwicklung mobiler JavaMEAnwendungen mit CLDC und MIDP, 2. Aufl., Dpunkt.verlag, 2007.
[We06]
Matthias Weßendorf: Web Services & mobile Clients – SOAP, WSDL,
UDDI, J2ME, MIDlets, WAP & JSF, 2. Aufl., W3L Verlag, 2006.

Ausarbeitung - Department of Information Systems

Transcription

Similar documents

InCD 5 -

Anleitung OpenCms 8 Der Onlineshop