Application Provisioning

Transkript

1 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

2 Inhaltsverzeichnis 1 Einleitung in das Application Provisioning Grundlagen des Application Provisioning von MIDlets Java Micro Edition als Zielplattform von MIDlets Konfigurationen und Profile in der Java Micro Edition Application Management Software Kommunikation und Identifikation eines mobilen Gerätes Java Enterprise Edition als Plattform für Provisioning Server Darstellung des Application Provisionings von MIDlets und eines Provisioning Frameworks Application Provisioning von MIDlets Begriffsbestimmung und Arten des Application Provisionings Der Over-The-Air User-Initiated Provisioning Prozess Funktionsumfang von Provisioning Systemen Java Enterprise Edition Client Provisioning Framework Überblick Stocking und Repository Discovery Delivery Darstellung eines Provisioning Systems am Beispiel der Sun Client Provisioning Reference Implementation Zusammenfassung und Ausblick A Zusammenstellung einiger JAD-Datei Attribute nach MIDP 2.0 Spezifikation B Beispiel eines Provisioning Descriptors C Beispiel einer Device Capability Datei D Beispiel einer Matchers Datei E Beispiel einer Adapters Datei Literaturverzeichnis II

3 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 ], in [Sch07, S. 4] oder [JME01] zu finden. 1

4 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 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 ]. 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

5 Kapitel 2: Grundlagen des Application Provisioning von MIDlets [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 ]. 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 ; 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] 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. zu finden. Für weitere Einzelheiten zum MIDP 2.0 sei hier direkt auf die Spezifikation des MIDP 2.0 unter [JSR118] verwiesen. 3

6 Kapitel 2: Grundlagen des Application Provisioning von MIDlets 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 ; 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 ; 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 ] zu finden. 4

7 Kapitel 2: Grundlagen des Application Provisioning von MIDlets 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 ]. 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 , 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 ]: 5 GET 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 und die Authentication Spezifikation (RFC 2617) unter erreichbar. 5

8 Kapitel 2: Grundlagen des Application Provisioning von MIDlets 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 Client Machine JSP Pages, Servlets Enterprise Beans Web Tier Business Tier Java EE Server Database Enterprise Information System Tier 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 ]. 6 Auf der Java EE und insbesondere auf JSP und Servlets basiert die J2EE Client Provisioning Specification Version 1.0 (JSR-124) [JSR124a, S ]. 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

9 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

10 Kapitel 3: Darstellung des Application Provisionings von MIDlets und eines Provisioning Frameworks 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 Mobile Operational Management Over-The-Air 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

11 Kapitel 3: Darstellung des Application Provisionings von MIDlets und eines Provisioning Frameworks 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 (O- TA) 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 ; 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 ] 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 Final Release 1.0 der JSR-232 ist von Oktober 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 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

12 Kapitel 3: Darstellung des Application Provisionings von MIDlets und eines Provisioning Frameworks Stocking «uses» MIDlet Developer Discovery «uses» «uses» Repository Management Delivery Provisioning System Developer 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 JAD-Server JAR-Server Notification-Server Discovery GET /midlet.jad 200 OK Delivery GET /midlet.jar 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

13 Kapitel 3: Darstellung des Application Provisionings von MIDlets und eines Provisioning Frameworks 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 ]. 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 (MIDlet- Install-Notify). In der MIDP 2.0 Spezifikation wird außerdem die jederzeitige Abbruchmö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 ]. 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 Push registration failure 912 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 ]. In der Client Provisioning Specification wird dies als Delivery bezeichnet [JSR124a, S ]. 11

14 Kapitel 3: Darstellung des Application Provisionings von MIDlets und eines Provisioning Frameworks 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 ] 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

15 Kapitel 3: Darstellung des Application Provisionings von MIDlets und eines Provisioning Frameworks Hinzu kommen u. a. Komfort-, Sicherheits- und Abrechnungsüberlegungen, falls einige MIDlets kommerziell genutzt werden sollen [Or02; La03; JSR124a, S ]. 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 ]. 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 bzw ) Ü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 ]. 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. Clients Adapter 3 (andere) Adapter 2 (JNLP) Adapter 1 (HTTP) Provisioning Adapter Client Provisioning API Provisioning Framework Provisioning System Provisioning Applikation Java EE Applikations Server Erweitertes Provisioning System Sonstige Services Repository Abbildung 9: Aufbau eines Provisioning Systems nach der Client Provisioning Spec. [JSR124a, S. 10] 13

16 Kapitel 3: Darstellung des Application Provisionings von MIDlets und eines Provisioning Frameworks 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) adapters.xml: HTTP Java SE 1.4 JNLP, HTTP PAR-Datei (MIDP 1.0) adapters.xml: HTTP adapters.xml: HTTP adapters.xml: 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

17 Kapitel 3: Darstellung des Application Provisionings von MIDlets und eines Provisioning Frameworks 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 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 Re- 15

18 Kapitel 3: Darstellung des Application Provisionings von MIDlets und eines Provisioning Frameworks 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 gehö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 ]. 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) 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 JNLP- Adapter 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

19 Kapitel 3: Darstellung des Application Provisionings von MIDlets und eines Provisioning Frameworks 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 erreichbar. 17

20 Kapitel 3: Darstellung des Application Provisionings von MIDlets und eines Provisioning Frameworks 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