Fachhochschule Karlsruhe Hochschule für Technik Fachbereich Informatik. Diplomarbeit. Untersuchung zur Portierung von Java-Swing- Anwendungen auf PDAs

Transkript

1 Fachhochschule Karlsruhe Hochschule für Technik Fachbereich Informatik Diplomarbeit Untersuchung zur Portierung von Java-Swing- Anwendungen auf PDAs STZ-IDA Sven Falk Referent: Prof. Gremminger Moltkestr. 30 Neuwindeckstr. 5 Koreferent: Prof. Herbstreith Karlsruhe Lauf Betreuer: MS-CS Andreas Junghans falk_sven@web.de Beginn: Matrikelnummer: Ende:

2 Zusammenfassung Diese Arbeit untersucht Strategien, mit welchen vorhandene Java-Applikationen auf mobile Plattformen portiert werden können. Einführend erfolgt ein Überblick über die möglichen Plattform- Alternativen. Dabei wird auf die Prozessor-/Betriebssystemarchitekturen eingegangen. Insbesondere bei den Betriebssystemen findet eine detailiertere Untersuchung bezüglich der Eignung als Entwicklungsplattform statt. Betrachtet werden Microsoft PocketPC 2002 und Familiar Linux Bewertet wird der Installationsaufwand, das Look-And-Feel, das Vorhandensein und die Bedienbarkeit wichtiger Entwicklungstools sowie aufgetretene Probleme. Anschließend werden die Java-Technologien Personal Java, Java 2 Micro Edition und Java 2 Standard Edition bezüglich des Einsatzes auf mobilen Plattformen untersucht. Während dieser Evaluierung wird J2ME detaillierter betrachtet, weil diese Technologie noch relativ jung ist. Soweit möglich findet gleichzeitig eine Evaluierung von J2ME-Laufzeitumgebungen verschiedener Hersteller statt. Im weiteren Verlauf werden dann auf J2SE basierende Java-Umgebungen untersucht. Aufgrund des großen Bekanntheitsgrades von J2SE wird dabei verstärkt auf die verfügbaren Laufzeitumgebungen eingegangen und Einzelheiten von J2SE nicht näher erläutert. Aufgedeckte Probleme werden an den entsprechenden Stellen näher beschrieben. Lediglich RMI-Aspekte sind separat dargestellt, weil diese für die später durchgeführte Test-Portierung von größerer Bedeutung sind. Nach diesen Voruntersuchungen findet eine Portierung einer JDK 1.3 konformen Anwendung statt, um die Durchführbarkeit durch praktische Fakten zu belegen. Dabei werden die gefundenen Lösungen für spezielle Anforderungen der mobilen Plattformen dargestellt. Diese reichen von einer veränderten Systemarchitektur über Bedienerkonzepte bis hin zu speziellen grafischen Benuzteroberflächen. Natürlich werden auch die aufgetretenen Problemstellungen und deren Lösungs- bzw. Umgehungsalternativen aufgezeigt. Probleme waren besonders im Bereich der grafischen Benutzeroberfläche und der verteilten Kommunikation anzutreffen. Abschließend werden die gefundenen Lösungen nochmals betrachtet und eventuelle Alternativen bzw. Verbesserungsvorschläge dargestellt. Ausserdem wird erläutert, in wie fern die aus dieser Arbeit gewonnenen Erkenntnisse in ein zukünftiges Projekt einfließen.

3 Inhaltsverzeichnis Abbildungsverzeichnis ii Tabellenverzeichnis iii Eidesstattliche Erklärung iv 1 Einleitung Motivation Das STZ-IDA Anmerkung zu den Abbildungen Betriebssystem-Aspekte Installation der Betriebssysteme Betriebssystem-Architektur MS PocketPC Familiar Linux Zusammenfassung BS-Aspekte Mobile Java Runtimes PersonalJava J2ME Konzepte der J2ME J2ME Implementierungen JDK vs. J2ME-Profiles i

4 3.2.4 Zusammenfassung J2ME Vollwertige JVMs Kaffe for PocketPC Blackdown for Linux Zusammenfassung RMI-Kompatibilität J2ME und RMI Vollwertige JVM und RMI Zusammenfassung RMI-Kompatibilität Zusammenfassung Mobile VMs Portierung Anwendungsbeschreibung Die Bestandskorrektur Anforderungen Aufgaben Entwurfsaspekte Architekturaspekte Bedienerkonzept Benutzeroberfläche Gesamtkonzept Implementierung Vorgehensweise Werkzeuge Performancetests Spezielle Entwicklungen Offene Problemstellungen Zusätzliche Entwicklungen ii

5 4.4.1 Motivation Verwendete Entwurfs-Muster Beispiel Ergebnisse 69 6 Ausblick 74 A Glossar 76 B Literaturverzeichnis 80 iii

6 Abbildungsverzeichnis 3.1 J2ME-Architektur Einsatz von Java auf diversen Geräten Titelleistenüberdeckung durch Menüleiste des OS Blockierter Zeichnungskontext der sh-konsole Zeichnungsfehler in Swing Systemarchitektur des Warenwirtschaftssystems FILIS Erweiterte Systemarchitektur der Bestandskorrektur Client-Architektur der Bestandskorrektur Kommunikation zwischen den Objekten am Beispiel eines Login Konzept für Scroll-Texte Klassendiagramm des GUI-Frameworks Mit dem GUI-Framework erzeugte SWT-Oberfläche Mit dem GUI-Framework erzeugte Swing-Oberfläche AWT-Implementierung der Login-GUI AWT-Implementierung der Bestandskorrektur-GUI SWT-Implementierung der Login-GUI SWT-Implementierung der Bestandskorrektur-GUI Swing-Implementierung der Login-GUI Swing-Implementierung der Bestandskorrektur-GUI iv

7 Tabellenverzeichnis 3.1 PersonalJava vs. JDK CDC - Packages CLDC - Packages Foundation Profile - Packages Personal Basis Profile - Packages Personal Profile - Packages Mobile Information Device Profile - Packages Systemanforderungen NSIcom CrEme v4.0 beta Evaluation NSIcom CrEme Preisgestaltung JDK vs. J2ME-Profiles Kaffe Registry-Einträge Optionale Kaffe Registry-Einträge J2ME - RMI-Kompatibitlität RMI-Kompatibitlität der vollwertigen JVMs FILIS-Performance-Messung RMI-Performance-Messung Kommunikationsserver-Performance-Messung v

8 Eidesstattliche Erklärung Hiermit erkläre ich an Eides statt, dass ich die vorliegende Arbeit selbständig und ohne fremde Hilfe verfasst habe und keine anderen als die angegebenen Hilfsmittel verwendet habe. Die Arbeit wurde in gleicher oder ähnlicher Form keiner anderen Prüfungsbehörde zur Erlangung eines akademischen Grades vorgelegt. Karlsruhe, den Sven Falk vi

9 Kapitel 1 Einleitung 1

10 1.1. MOTIVATION KAPITEL 1. EINLEITUNG 1.1 Motivation Mobile Computing gewinnt im Bereich der betriebswirtschaftlichen Anwendungen immer mehr an Bedeutung. Die stetig steigende Leistungsfähigkeit und innovative Neuentwicklungen im Bereich mobiler Datenverarbeitungsgeräte, bilden die Grundlage für Überlegungen, vorhandene Anwendungen auf sogenannte Handhelds zu portieren. Vor allem Applikationen, die auf Basis plattformunabhängiger Technologien wie z.b. Java entwickelt wurden, sind für die Portierung auf mobile Clients geeignet. Java entstand auf der Basis von Suns Entwicklungsarbeiten für OAK. OAK sollte, basierend auf den Erkenntnissen der C++-Programmierung, eine bessere, sicherere und leichter zu handhabende Programmiersprache speziell für mobile Datenverarbeitungsgeräte darstellen. Leider wurde OAK und der damit verbundene erste Personal Digital Assistant (PDA) Star 7 nach relativ kurzer Zeit eingestellt. Die aus OAK resultierende Programmiersprache Java zielt in den beiden Versionen Java 2 Standard Edition (J2SE) und Java 2 Enterprise Edition (J2EE) auf den Bereich der leistungsfähigen Desktop- bzw. Serversysteme. Speziell für den mobilen Bereich sind zum einen Personal Java, welches bereits eingestellt wurde, und zum anderen die Java 2 Micro Edition (J2ME), eine relativ junge Technologie, verfügbar. Viele der im Moment im Einsatz befindlichen Java-Anwendungen basieren noch auf den Versionen von Suns Java Development Kit 1.3.x (JDK) und somit auf J2SE bzw. J2EE. In dieser Ausarbeitung wird deshalb untersucht, welche Strategien in Bezug auf verwendbare Plattformen und Java- Technologien für die Portierung einer solchen Anwendung auf einen modernen Handheld sinnvoll sind. Dabei werden die beiden Prozessorarchitekturen Intel XSCALE und Intel StrongARM, die Betriebssysteme Microsoft PocketPC 2002 und Familiar Linux sowie die in Frage kommenden Java Technologien Personal Java, Java 2 Standard Edition und Java 2 Micro Edition näher betrachtet. Ziel dieser Ausarbeitung ist es, eine Aussage über sinnvolle Kombinationen von Prozessorarchitektur, Betriebssystem und Java-Technologie treffen zu können. Ausserdem soll Aufschluss darüber gegeben werden, welcher Aufwand hinsichtlich Entwicklungs- und Portierungsarbeit bei den entsprechenden Kombinationen zu erwarten ist. Um eine konkrete Aussage zu diesen Aspekten geben zu können, wird die Portierung einer JDK 1.3 konformen Anwendung durchgeführt. Bei dieser Anwendung handelt es sich um eine Teilapplikation des Warenwirtschaftssystems FILIS der Drogeriemarktkette dm. FILIS wurde von der Firma Filiadata GmbH entwickelt, mit der während dieser Ausarbeitung auch eng zusammengearbeitet wurde. Die Portierung wurde erfolgreich durchgeführt und bildet nun die Basis für eine weitere Zusammenarbeit des STZ-IDA mit der Filiadata GmbH. c 2003, Sven Falk Seite 2

11 1.2. DAS STZ-IDA KAPITEL 1. EINLEITUNG 1.2 Das Steinbeis Transferzentrum für Industrielle Datenverarbeitung und Automation Angesiedelt im Gebäudekomplex der Pädagogischen Hochschule Karlsruhe, in direkter Nachbarschaft zur Fachhochschule Karlsruhe, stellt das Steinbeis Transferzentrum für Industrielle Datenverarbeitung und Automation (STZ-IDA) eines der vielen, weltweit agierenden Transferzentren der Steinbeis-Stiftung dar. Die 1972 gegründete Steinbeis-Stiftung setzt sich weltweit für den Technologieund Wissenstransfer ein. Diesem Moto folgend hat es sich das 1984 gegründete STZ-IDA zur Aufgabe gemacht, den Wissenstransfer der Fachhochschule Karlsruhe zu den Partnerunternehmen zu ermöglichen. Umgekehrt ist das STZ-IDA in der Lage, Anliegen und Trends in der Wirtschaft zu erkennen und diese in den Hochschulunterricht einfließen zu lassen. Diese bilaterale Beziehung wird durch die Einbindung von studentischen Hilfskräften, Diplomanden, Bachelor- und Master-Anwärtern sowie Absolventen des Fachbereiches Informatik in Projekte mit Partnerunternehmen ermöglicht. Diese Diplomarbeit ist ein typisches Beispiel für die oben beschriebene Beziehung des STZ-IDA zur Fachhochschule Karlsruhe und den Partnerunternehmen. Sie bildet die Vorstudie für ein Projekt, das die Firma Filiadata GmbH in Zusammenarbeit mit dem STZ-IDA durchführen möchte. Geleitet wird das STZ-IDA von Prof. Dipl. Inf. Klaus Gremminger. Unter seiner Führung arbeiten im Moment 7 Mitarbeiter, 2 Diplomanden und 1 Master-Student im STZ-IDA. Weiterführende Information zum STZ-IDA finden Sie unter [1]. 1.3 Anmerkung zu den Abbildungen Die Abbildungen 4.3, 4.4 und 4.6 wurden mit Microsoft Visio 2002 erstellt. Aufgrund einer fehlerhaften Export-Funktion von Visio, sind in den Grafiken diverse Zeichenfehler vorhanden. Weil dies erst kurz vor dem Abgabetermin aufgefallen ist, konnten keine neuen Grafiken mehr erstellt werden. c 2003, Sven Falk Seite 3

12 Kapitel 2 Betriebssystem-Aspekte 4

13 2.1. INSTALLATION DER BETRIEBSSYSTEME KAPITEL 2. BETRIEBSSYSTEM-ASPEKTE 2.1 Installation der Betriebssysteme In dieser Ausarbeitung sind zwei Betriebssysteme zum Einsatz gekommen: 1. Microsoft PocketPC Familiar Linux Betriebssystem Architektur Wie bei herkömmlichen PC-Betriebssystemen ist auch bei den mobilen Betriebssystemen eine zweischichtige Betriebssystem-Architektur anzutreffen. Auf unterster Ebene befindet sich der sogenannte Bootloader, welcher die rudimentären Aufgaben beim Systemstart übernimmt. Vergleichbar ist dieser Teil des Betriebssystems mit dem Basic Input Output System (BIOS) der PC Systeme. Eine seiner Hauptaufgaben nach der Initialisierung der Hardware ist das Kopieren des Betriebssystems aus dem nicht-flüchtigen (Flash-ROM) in den flüchtigen (DRAM) Speicherbereich des Gerätes. Ist dies geschehen, übergibt der Bootloader die Kontrolle an das Betriebssystem. Zusätzlich zu diesen Aufgaben kann mit Hilfe des Bootloaders das installierte Betriebssystem aktualisiert bzw. ein neues Betriebssystem installiert werden. Um den Einsatz von verschiedenen Betriebssystemen auf dem PDA (Compaq ipaq) zu ermöglichen, ist es also notwendig, einen Bootloader zu installieren, der verschiedene Betriebssysteme booten kann. Während dieser Ausarbeitung wurde hierfür der ARM Bootloader in der Version verwendet. Dieser ist frei verfügbar und kann unter [6] heruntergeladen werden. Mit dem ARM Bootloader können Betriebssysteme auf zwei Arten installiert werden: 1. Übertragung des Betriebssystem-Image vom PC über die serielle Schnittstelle unter Verwendung einer Terminal-Anwendung an den PDA. 2. Mit Hilfe einer Compact-Flash-Karte, auf der sich das Betriebssystem-Image befindet Beim Einsatz des o.g. Bootloaders tritt bei Verwendung von Microsoft PocketPC 2002 sporadisch und in Verbindung mit Familiar Linux immer das Problem auf, dass sich das Gerät nicht mehr aus dem Standby-Modus wecken lässt und somit ein Reset durchgeführt werden muss. c 2003, Sven Falk Seite 5

14 2.1. INSTALLATION DER BETRIEBSSYSTEME KAPITEL 2. BETRIEBSSYSTEM-ASPEKTE Installationsprobleme Der Installationsvorgang beider oben genannten Varianten ist sehr ausführlich auf [6] beschrieben, und wird deshalb hier nicht näher erläutert. Die Installation verläuft aber nicht unbedingt unproblematisch, weshalb hier kurz Problemlösungen für eventuelle Schwierigkeiten erläutert werden. Bei der Installation via CF-Karte kann es vorkommen, dass das angegebene Image-File nicht gefunden wird. In diesem Fall sind folgende Befehle auszuführen: sleeve insert pcmcia insert vfat mount 0 Anschließend kann mit der normalen Installationsprozedur fortgefahren werden Microsoft PocketPC 2002 Das auf dem Compaq ipaq standardmäßig installierte Microsoft PocketPC 2002 ist ein Microsoft Windows CE 3.0 Ableger und gleicht in seinem Aussehen den üblichen Microsoft Betriebssystemen. Installation des Betriebssystems Es ist keine Software zur Installation von PocketPC 2002 erhältlich. Deshalb sollte, bevor ein neues Betriebssystem installiert wird, unbedingt eine Sicherungskopie der PocketPC-Installation angefertigt werden. Ist dies einmal geschehen, kann das ursprüngliche System mit Hilfe dieses Images und des Bootloaders problemlos wiederhergestellt werden. Verfügbare Anwendungen PocketPC 2002 bringt eine Reihe wichtiger Anwendungen mit. So sind diverse, personelle Anwendungen wie z.b. Kalender, Adressbuch sowie Office-, Multimedia- und Spiele-Anwendungen standardmäßig auf dem Gerät installiert. Leider sind wichtige Anwendungen schlecht umgesetzt bzw. nicht vorhanden. Hierzu zählen z.b. der Dateimanager Explorer, die Textverarbeitung Pocket Word und die fehlende Systemkonsole. Vor allem der Explorer lässt einige Wünsche offen. So werden Systemdateien standardmäßig ausgeblendet und sind, soweit in dieser Ausarbeitung ermittelt werden konnte, auch nicht einblendbar. Für Installationsprozesse bzw. Wartungsarbeiten an der Software ist dies natürlich gänzlich ungeeignet. Word ist nicht in der Lage Dateien zu öffnen, deren Dateierweiterung ihm nicht bekannt sind. Ausserdem ist ein wahlfreies öffnen von Dateien nicht möglich, da lediglich die laut Word auf dem System befindlichen Dateien im Öffnen-Dialog angezeigt werden. Hinzu kommt, dass unter PocketPC 2002 keine Systemkonsole vorhanden ist. Vor allem zu Entwicklungszwecken ist eine solche aber unbedingt erforderlich. c 2003, Sven Falk Seite 6

15 2.1. INSTALLATION DER BETRIEBSSYSTEME KAPITEL 2. BETRIEBSSYSTEM-ASPEKTE Diese unglücklichen Umstände trüben den ansprechenden Gesamteindruck von PocketPC Alle erforderlichen Tools müssen aus dem Internet zusammengesucht, eventuell gekauft und nachinstalliert werden. Installation von Anwendungen Zur Installation von Anwendungen existieren oft Setup-Applikationen, welche unter Verwendung von Microsoft ActiveSync die benötigten Dateien auf das Zielsystem übertragen. Microsoft ActiveSync ist vorwiegend dazu gedacht, Anwendungsdaten des mobilen Gerätes mit stationären Systemen zu synchronisieren. Hierbei kann die Bluetooth-, USB- oder die serielle Schnittstelle des ipaq verwendet werden. Verbindungsprobleme Bei der Verwendung von ActiveSync bzw. des Explorers in Verbindung mit der USB-Schnittstelle sind häufig Fehler aufgetreten. Das heißt, dass z.b. beim Kopieren von Dateien auf das mobile Gerät Daten verfälscht wurden, dies aber nicht zu erkennen war. Erst als alternativ ein Datenaustausch über die CF-Karte (IBM-Microdrive) durchgeführt wurde, stellte sich heraus, dass die zuvor über die USB- Verbindung übertragenen Daten fehlerhaft waren. Dieses Problem ist auf einen Hardware-Fehler in der USB-Schnittstelle zurückzuführen. Es handelt sich hierbei um einen systematischen Fehler d.h., dass nicht nur das für diese Diplomarbeit eingesetzte Gerät diesen Fehler besitzt, sondern alle Geräte die diesen Chipsatz verwenden Familiar Linux Familiar Linux stellt mittlerweile eine ernstzunehmende Konkurrenz zu MS PocketPC 2002 dar. Familiar Linux unterscheidet sich von Desktop-Linux-Distributionen nur insofern, dass der Umfang der verfügbaren Anwendungen eingeschränkter ist und die Anwendungen an sich oft nicht über die gesamte Funktionalität der entsprechenden Versionen der Desktop-Distributionen verfügen. Bereits der erste Eindruck der verfügbaren grafischen Oberflächen GNU Palmtop Environment (GPE) als auch Open Palmtop Integrated Environment (OPIE) wirken überzeugend und durchdacht. Während GPE dem gewohnten Look-And-Feel eines grafischen Desktop-Systems folgt (Mauszeiger etc.), ähnelt OPIE eher dem Look-And-Feel von PocketPC Beide GUIs unterscheiden sich bezüglich der grafischen Gestaltung der Oberflächen sowohl untereinander als auch im Vergleich zu PocketPC GPE basiert auf dem Gnome Tool Kit mit X als Basis während OPIE mit QT auf Framebuffer- Basis realisiert wurde. Da die in dieser Ausarbeitung verwendeten VMs für OPIE aber keine QT- Unterstützung für AWT mitbringen, muss diese nachträglich installiert werden. Nach bisherigem Erkenntnisstand ist nur für die Kaffe VM eine freie AWT-QT-Implementierung erhältlich. Leider hatten bisherige Versuche, diese in eine Kaffe VM einzubinden, keinen Erfolg. Daher scheidet OPIE vorerst als alternatives GUI zu GPE aus. c 2003, Sven Falk Seite 7

16 2.1. INSTALLATION DER BETRIEBSSYSTEME KAPITEL 2. BETRIEBSSYSTEM-ASPEKTE Installation des Betriebssystems Familiar Linux ist in verschiedenen Versionen verfügbar und steht unter [6] zum Download bereit. Für diese Ausarbeitung wurde die Version verwendet. Die heruntergeladenen Images können, wie in Kapitel dargestellt, über den Bootloader installiert werden. Für das Linux OS bietet sich an, Teile des Betriebssystems auf die CF-Karte auszulagern, um zusätzlichen Speicher freizugeben. Dabei kann folgendermaßen vorgegangen werden: 1. Partitionierung der CF-Karte. Um die CF-Karte sowohl als Auslagerungs-Speicher für Betriebssystemdaten als auch für Installationszwecke nutzen zu können, wurden eine VFAT- und eine EXT2-Partition eingerichtet. Die VFAT-Partition ist notwendig, damit der Bootloader die Image-Files von der CF-Karte lesen kann. Die Partitionen können z.b. auf dem Handheld unter Linux mit folgenden Tools eingerichtet werden: fdisk package fdisk benötigt mkfs package e2fsprogs und mkfs benötigt 2. Installation der ext2 bzw. ext3-packages. 3. Erstellen der Mountpunkte für die neuen Partitionen. 4. /etc/pcmcia/ide.opts modifizieren, sodass beide Partitionen gemountet werden (Anleitung im Header der Datei). 5. /etc/init.d/pcmcia vor dem Ende der Start-Anweisungen (ca. Zeile 104) sleep 5 eintragen. Dieser Eintrag ist notwendig, damit die CF-Karte, in diesem Fall ein Microdrive, genügend Zeit zur Initialisierung hat und somit das Mounten der Partitionen nicht fehlschlägt. 6. Bei Verwendung von GPE folgendes durchführen: /etc/rc2.d/s10pcmcia nach /etc/rcs.d/s11pcmcia verschieben/umbenennen /etc/rcs.d/s11bootsplash nach /etc/rcs.d/s12bootsplash umbenennen Bei Verwendung von OPIE folgendes durchführen: /etc/rc2.d/s10pcmcia nach /etc/rc2.d/s15pcmcia umbenennen 7. Neubooten und überprüfen, ob die Partitionen richtig gemountet wurden. 8. Verschieben der Daten und Anlegen von entsprechenden Links. Zum Auslagern eignen sich z.b. die Ordner /usr/lib, /usr/x11r6 oder /opt... Falls GPE installiert wurde, so sollten noch die Schriftarten AndaleMO.ttf, Verdana.ttf, Verdanab.ttf, Verdanai.ttf, Verdanaz.ttf nach /usr/x11r6/lib/x11/fonts/ttf kopiert werden. Wird dies nicht durchgeführt, ist diese GUI kaum benutzbar, da die Standardschriftarten zu klein sind und überdies fehlerhaft gezeichnet werden. c 2003, Sven Falk Seite 8

17 2.1. INSTALLATION DER BETRIEBSSYSTEME KAPITEL 2. BETRIEBSSYSTEM-ASPEKTE Verfügbare Anwendungen Familiar Linux bringt die Linux-typischen Applikationen wie z.b. den vi mit. Die beiden GUIs GPE und OPIE erweitern diese Funktionalität um weitere Standardanwendungen wie z.b. Browser, Terminkalender, File-Manager etc.. Als Vorteil gegenüber PocketPC 2002 kann hier die integrierte Konsolen-Anwendung, Multiuser- Fähigkeiten sowie eine breite Unterstützung von Netzwerkdiensten und -servern wie z.b. SSH, SMB oder NFS genannt werden. Diese müssen in der Regel nachinstalliert werden, erleichtern die Nutzung des Handheld aber erheblich. Installation von Anwendungen Die Installation von Anwendungen ist unter Familiar Linux recht unkompliziert. Es existieren sogenannte Packages (*.ipk), welche über die Anwendung ipkg installiert, entfernt oder aufgelistet werden können. Die Liste der verfügbaren Anwendungen lässt sich über das Internet aktualisieren. Packages die nicht explizit als Parameter in Form des Dateinamens angegeben werden, werden aus dem Internet heruntergeladen. Einziger Nachteil dieser Methodik ist, dass es bei großen Packages vorkommen kann, dass nicht mehr ausreichend Speicherplatz für die Installation zur Verfügung steht. Probleme Kleinere Probleme sind bei Familiar Linux in Verbindung mit den grafischen Oberflächen GPE bzw. OPIE aufgetreten. Vor allem bei GPE muss nach der Installation noch manuell nachgebessert werden, um das System benutzbar zu machen. Dabei handelt es sich im Allgemeinen um die Installation von diversen Schriftarten. Als größeres Problem stellte sich der Standby-Modus des ipaq heraus. Nach bisherigem Erkenntnisstand ist der ipaq nur durch einen Reset aus dem Standby-Modus zu wecken. Dies sollte jedoch wie unter Pocket-PC 2002 auch über die Ein-Aus-Taste möglich sein. Wahrscheinlich ist dieses Problem aber auf die zuvor beschriebene Schwäche des Bootloaders zurückzuführen. Tipps Netzwerkeinstellungen können in der Datei /etc/pcmcia/network.opts vorgenommen werden. Wird der Internetzugang durch einen Proxy ermöglicht, so sollte die Variable http_proxy gesetzt werden (z.b. in /etc/profile). c 2003, Sven Falk Seite 9

18 2.2. ZUSAMMENFASSUNG BS-ASPEKTE KAPITEL 2. BETRIEBSSYSTEM-ASPEKTE 2.2 Zusammenfassung Betriebssystem-Aspekte In diesem Kapitel wurde die Architektur und Installation der beiden Betriebssysteme Microsoft Pocket- PC 2002 und Familiar Linux dargestellt. Die Architektur beider Betriebssysteme ist in zwei Schichten (Bootloaderschicht, Betriebssystemschicht) aufgeteilt. Der Bootloader übernimmt dabei verschiedene Initialisierungsaufgaben und übergibt nach Abschluß derselbigen die Kontrolle an das Betriebssystem. Um überhaupt den Einsatz von unterschiedlichen Betriebssystemen auf dem PDA zu ermöglichen, musste der bestehende Bootloader durch einen anderen ersetzt werden. Hierbei kam der ARM Bootloader zum Einsatz. Mit diesem konnten die diversen Betriebssysteme installiert und ausgeführt werden. Leider tritt bei diesem Bootloader das Problem auf, dass das Gerät nicht immer aus dem Standby-Modus geweckt werden kann und somit ein Reset durchgeführt werden muss. Microsoft PocketPC 2002, das auf Microsoft Windows CE 3.0 basiert, überzeugt vor allem durch seine ansprechende und intuitive Benutzer-Oberfläche. Ausserdem stellt das umfangreiche Anwendungsangebot einen weiteren Pluspunkt dar. Negativ aufgefallen sind allerdings Standardanwendungen wie der Explorer oder Pocket Word. Beim Einsatz in Verbindung mit Software-Entwicklungsarbeiten vermisst man schnell Standardanwendungen wie z.b. SSH-Server oder Systemkonsole. Die Installation von Anwendungen ist in Verbindung mit Microsoft ActiveSync leicht zu bewerkstelligen. Familiar Linux ist während dieser Ausarbeitung sehr positiv aufgefallen. Vor allem zu Entwicklungszwecken eignet sich dieses Betriebssystem besser als Microsoft PocketPC Die beiden verfügbaren grafischen Benutzeroberflächen GPE und OPIE wirken ansprechend und durchaus alltagstauglich. Das Anwendungsangebot für Familiar Linux ist sehr umfangreich und enthält viele Applikationen, die bereits von Desktop-Linux-Distributionen bekannt sind. Lediglich der Funktionsumfang dieser Anwendungen ist im Vergleich zu den Desktop-Versionen eingeschränkt. Negativ aufgefallen sind kleinere Fehler in den Benutzeroberflächen von GPE als auch OPIE. Die Installation von Anwendungen gestaltet sich auch hier einfach. c 2003, Sven Falk Seite 10

19 Kapitel 3 Mobile Java Runtimes 11

20 KAPITEL 3. MOBILE JAVA RUNTIMES Wie bereits zuvor erwähnt, soll diese Ausarbeitung klären, mit welcher Strategie vorhandene Java Applikationen auf mobile Plattformen portiert werden können. Dafür ist es notwendig, verschiedene Java Technologien zu untersuchen, die für dieses Vorhaben in Frage kommen. Nachfolgend werden Personal Java, Java 2 Micro Edition und Java 2 Standard Edition evaluiert um Aussagen treffen zu können, welche dieser Technologien für Portierungen geeignet bzw. ungeeignet sind. Gleichzeitig werden, falls sinnvoll, konkrete virtuelle Maschinen zu der jeweiligen Technologie näher betrachtet. Der dafür gewählte Detailierungsgrad scheint auf den ersten Blick zu hoch. Die dargestellten Erkenntnisse bzgl. Bedienbarkeit, Installation, Ressourcenaufwand, Kombatibilität und Inkompatibilität sind aber für Entscheidungen hinsichltich wählbarer Strategien sehr wichtig und sollten nicht vernachlässigt werden. c 2003, Sven Falk Seite 12

21 3.1. PERSONALJAVA KAPITEL 3. MOBILE JAVA RUNTIMES 3.1 PersonalJava PersonalJava wurde für Geräte mit bis zu 2 MB ROM und mindestens 1 MB RAM für die Laufzeitumgebung entwickelt. PersonalJava basiert auf dem JDK und erweitert diesen um einige anwendungsspezifische APIs. Es beinhaltet eine voll ausgestattete JVM und verwendet den gesamten Umfang der Java-Sprache in der Version der Java Language Specification First Edition. Tabelle 3.1 zeigt die Unterschiede bzw. Erweiterungen von PersonalJava im Vergleich zum JDK Package Name Status java.awt modifiziert, d.h. keine volle AWT- Unterstützung java.awt.peer modifiziert java.io modifiziert, File-Zugriff optional java.lang modifiziert, bis auf einige Umstellungen auf JDK gleich wie JDK java.lang.reflect modifiziert, bis auf einige Umstellungen auf JDK gleich wie JDK java.math optional java.net modifiziert, bis auf einige Umstellungen auf JDK gleich wie JDK java.rmi optional java.rmi.dgc optional java.rmi.registry optional java.rmi.server optional java.rmi.security modifiziert, bis auf einige Umstellungen auf JDK gleich wie JDK java.security.acl nicht unterstützt java.security.cert teilweise unterstützt java.security.interfaces teilweise unterstützt, teilweise optional java.security.spec teilweise unterstützt, teilweise optional java.sql optional java.text unterstützt, aber teilweise Einschränkungen durch plattform-spezifische Encodings java.text.resources modifiziert java.util modifiziert, bis auf einige Umstellungen auf JDK gleich wie JDK java.util.jar teilweise unterstützt, teilweise optional java.util.zip modifiziert, bis auf einige Umstellungen auf JDK gleich wie JDK Tabelle 3.1: PersonalJava vs. JDK Da PersonalJava von Sun nicht weiter unterstützt wird, empfiehlt sich die Migration nach J2ME CDC in Verbindung mit dem Personal Profile und dem RMI Profile. c 2003, Sven Falk Seite 13

22 3.2. J2ME KAPITEL 3. MOBILE JAVA RUNTIMES 3.2 Java 2 Micro Edition Abbildung 3.1: J2ME-Architektur (Quelle: [2]) Konzepte der Java 2 Micro Edition Die Zielsysteme der J2ME decken ein breites Spektrum von mobilen Geräten ab. Angefangen von Java-fähigen Mobiltelefonen bis hin zu High-End-PDAs ist der Einsatz einer Vielzahl von Geräten in Verbindung mit J2ME denkbar (siehe Abbildung 3.2). Um diesen möglichst flexibel gestalten zu können, ist J2ME, wie in Abbildung 3.1 dargestellt, in Schichten aufgeteilt. Mit dieser Architektur kann auf folgende Anforderungen im Bereich des Mobile Computing angemessen reagiert werden: Viele unterschiedliche Gerätetypen mit unterschiedlichen Konfigurationen Rasche Entwicklungszyklen neuer Technologien Viele Anwendungen mit unterschiedlichen Funktionen Skalierbarkeit der Anwendungen In J2ME sind ein Gerät und eine JVM- /Konfigurations-Implementierung sehr stark aneinander gekoppelt. Sie sind so entworfen, dass sie zusammen die grundlegenden Fähigkeiten einer Kategorie von Geräten nutzen. Die weitere Unterscheidung (Spezialisierung) in Geräte-Familien wird durch zusätzliche APIs in der Profil-Schicht gewährleistet. Profile können ausserdem mit zusätzlichen Java- Bibliotheken parametrisiert werden. Sun konzentriert sich zum Zeitpunkt dieser Ausarbeitung auf die Spezifizierung von Konfigurationen und Profilen und stellt lediglich Referenz-Implementierungen für die jeweiligen Spezifikationen zur Verfügung. Diese sind meist auf eine bestimmte System-Architektur in Verbindung mit einem bestimmten Betriebssystem beschränkt. Die Entwicklung von J2ME-VMs wird also OEM- bzw. Third- Party-Entwicklern überlassen. Zu Test- bzw. Emulations-Zwecken kann jedoch der J2ME-Wireless- Toolkit verwendet werden. c 2003, Sven Falk Seite 14

23 3.2. J2ME KAPITEL 3. MOBILE JAVA RUNTIMES Abbildung 3.2: Einsatz von Java auf diversen Geräten (Quelle: [2]) JVM-Schicht: In der JVM-Schicht befindet sich die Implementierung einer JVM für eine spezielle OS-Plattform. Eine J2ME-JVM ist immer an eine spezielle Konfiguration gebunden. Konfigurations-Schicht Eine Konfiguration ist eine Spezifikation für eine Klasse von Geräten. Die Klassifizierung von Geräten basiert auf den charakteristischen Eigenschaften, auf welche die Konfiguration aufbaut. Hierzu zählen z.b.: Speicherkapazitäten und -technologien Prozessorarchitektur und -leistung Netzwerkfähigkeiten des Gerätes c 2003, Sven Falk Seite 15

24 3.2. J2ME KAPITEL 3. MOBILE JAVA RUNTIMES Jede Konfiguration besteht aus einer JVM und einer Ansammlung von Kern-Klassen-Bibliotheken, welche auf der Java 2 Plattform basieren. Grundsätzlich weist eine Konfiguration folgende Eigenschaften auf: Sie definiert die kleinste Schnittmenge von verfügbaren Funktionen und Bibliotheken, die ein Entwickler auf Geräten einer Klasse erwarten kann Sie spezifiziert also die unterstützten Fähigkeiten der Java Programmiersprache Fähigkeiten der JVM Basis-Java-Bibliotheken und -APIs Bisher sind 2 Konfigurationen durch den Java Community Process (JCP) spezifiziert worden. Connected Device Configuration (CDC) Connected Limited Device Configuration (CLDC) Eine größere Anzahl von Konfigurationen ist aufgrund der daraus resultierenden Fragmentierung nicht erwünscht. Connected Device Configuration CDC umschließt eine Teilmenge von J2SE und erweitert diese um zusätzliche neue Klassen. Sie: Verwendet eine klassische JVM, d.h. eine voll ausgestatte VM, welche die gesamte Funktionalität einer VM eines Desktop-Systems unterstützt Ist vorgesehen für Geräte mit meheren MBs Arbeitsspeicher Ist gedacht für OEM-Entwickler Enthält folgende Packages: - java.lang JVM Systemklassen - java.util verwendbare Java-Werkzeuge - java.net Unterstützung für Universal Datagram Protocol Ein- / Ausgabe - java.io Java-Dateieingabe und -ausgabe - java.text minimale Unterstüzung für Internationalization (I18N) - java.security minimale Sicherheit und Verschlüsselung für Objektserialisierung Tabelle 3.2 gibt genaueren Aufschluss über die Zusammenstellung der enthaltenen Packages. c 2003, Sven Falk Seite 16

25 3.2. J2ME KAPITEL 3. MOBILE JAVA RUNTIMES Package Name Description java.io Standard Ein- und Ausgabeklassen und Schnittstellen java.lang VM-Klassen java.lang.ref Referenz-Klassen java.lang.reflect Reflection-Klassen und -Schnittstellen java.math Mathematikpaket java.net Netzwerkklassen und -schnittstellen java.security Sicherheitsklassen und -schnittstellen java.security.cert Sicherheitszertifikatklassen java.text Text-Paket java.util Standard-Werkzeugklassen java.util.jar Java Archive (JAR) Werkzeugklassen java.util.zip ZIP Werkzeugklassen javax.microedition.io CDC allgemeine Verbindungsklassen und -schnittstellen Tabelle 3.2: Connected Device Configuration - Packages Connected Limited Device Configuration CLDC ist laut Sun unabhängig von CDC, obwohl es eine Untermenge von CDC darstellt. CLDC besitzt folgende Eigenschaften: Es unterstützt Wireless-Geräte und andere Systeme mit beschränkten Speicher- und Rechenkapazitäten Es ist gedacht für Geräte mit Speichervolumen von 160kB bis 512kB Es benötigt Systeme mit 16 bzw. 32-Bit Prozessoren Es ist zusammengestellt aus der KVM und Kern-Klassen-Bibliotheken Es richtet sich an Third-Party-Entwickler Es bietet keine Unterstützung für folgende Java-Language-Features: Fließkommaberechnungen Objekt-Beendigung (Finalization) java.lang.error Klassen-Hierarchie Es besitzt keine Unterstützung für folgende VM-Funktionen: Java Native Interface (JNI) Benutzerdefinierte Classloader Reflection Thread groups und thread daemons Finalization (keine Object.finalize() Methode in den CLDC-Klassen) Schwache Bindungen errors (eine kleine Untermenge der J2SE errors wird unterstützt) c 2003, Sven Falk Seite 17

26 3.2. J2ME KAPITEL 3. MOBILE JAVA RUNTIMES Class-File-Prüfung die Referenz-Implementierung beinhaltet die Kilobyte Virtual Machine (KVM) Tabelle 3.3 gibt genaueren Aufschluss über die Zusammenstellung der enthaltenen Packages. Package Name Description java.io Standard Java Ein- / Ausgabeklassen und -pakete; Untermenge des J2SE Package java.lang VM-Klassen und -Schnittstellen; Untermenge des J2SE Package java.util Standardwerkzeugklassen und -schnittstellen; Untermenge des J2SE Package javax.microedition.io CLDC allgemeine Verbindungsklassen und -schnittstellen Tabelle 3.3: Connected Limited Device Configuration - Packages Profil-Schicht Wie bereits zuvor erwähnt bauen Profile auf speziellen Konfigurationen auf. Profile erweitern also die von der zugrundeliegenden Konfiguration vorhandene API und erlauben somit eine vertikale Spezialisierung (Konfiguration horizontale Spezialisierung). Ein Profil kann auch ein anderes Profil erweitern. Nachfolgend sind die wichtigsten Eigenschaften von J2ME-Profilen aufgelistet. Ein Profil Definiert die minimale Menge an APIs, welche auf einer bestimmten Familie von Geräten eines vertikalen Marktsegmentes verfügbar sind Baut auf einer bestimmten Konfiguration oder anderen Profilen auf Kann sehr gerätespezifisch, aber auch allgemein gehalten sein Kann zusammen mit mehreren anderen Profilen von einem Gerät unterstützt werden Die unten aufgeführten Profile wurden bereits vom JCP spezifiziert: Foundation Profile (FP) Personal Basis Profile(PBP) Personal Profile (PP) Remote Method Invocation Profile (RMI) Mobile Information Device Profile(MIDP) c 2003, Sven Falk Seite 18

27 3.2. J2ME KAPITEL 3. MOBILE JAVA RUNTIMES Foundation Profile Das Foundation Profile baut auf CDC auf und beinhaltet fast die gesamte Kern-Funktionalität der Java 2 Version 1.3 Klassen-Bibliotheken. Es soll die Basis für weitere CDC-basierte Profile darstellen. Tabelle 3.4 zeigt eine genauere Auflistung der enthaltenen Packages. Package Name Beschreibung java.awt Framework zur Erstellung von grafischen Benutzeroberflächen java.io Vervollständigt java.io.* J2SE Package Unterstützung für die Java language java.lang Vervollständigt java.lang.* J2SE package Unterstützung für die Java language java.lang.ref Enthält reference-object classes, die eine begrenzte Interaktion mit dem garbage collector erlaubt java.lang.reflect Enthält Klassen und Interfaces um auf reflective Informationen von Klassen und Objekten zuzugreifen java.math Klassen für mathematische Operationen java.net Bietet TCP/IP Socket und HTTP Unterstützung java.security Enthält Code signing und Zertifikat-Funktionalität java.security.acl Klassen und Interfaces dieses Packages wurden durch die Klassen des java.security Package ersetzt java.security.cert Klassen und Interfaces um Zertifikate zu verwalten java.security.interfaces Klassen und Interfaces um RSA zu generieren (Rivest, Shamir and Adleman Asymmetric- Cipher algorithm) java.security.spec Klassen und Interfaces um Key und Algorithmus Parameter zu spezifizieren java.text Vervollständigt java.text.* J2SE Package Unterstützung für Internationalization (I18N) java.text.resources Unterstützt für Internationalization (I18N) java.util Bietet ZIP-Unterstützung und weitere J2SE utilities java.util.jar Klassen zum Lesen und Schreiben von JAR (Java ARchive) Dateien java.util.zip Klassen zum Lesen und Schreiben von standard ZIP and GZIP Dateien javax.microedition.io Spezielle Ein- und Ausgabeklassen Tabelle 3.4: Foundation Profile - Packages c 2003, Sven Falk Seite 19

28 3.2. J2ME KAPITEL 3. MOBILE JAVA RUNTIMES Personal Basis Profile / Personal Profile Das Personal Basis Profile (PBP) baut auf dem vorher erläuterten Foundation Profile auf und erweitert dieses um grundlegende Benutzeroberflächen-Funktionalität. Das PBP unterstützt Geräte, welche einfache GUI-Anforderungen erfüllen (z.b. max. ein aktives Fenster) und verwendet ausschließlich lightweight Komponenten. Geräte, die anspruchsvollere GUI-Fähigkeiten besitzen, können mit Hilfe des Personal Profile (PP) komplexere GUIs darstellen. PP bietet volle AWT-Unterstützung inklusive heavyweight Komponenten und stellt somit einen Migrationspfad für Personal Java Applikationen dar. Tabelle 3.5 zeigt eine genauere Auflistung der im Personal Basis Profile enthaltenen Packages. Package Name Beschreibung java.awt AWT-Unterstützung java.awt.color Unterstützung für Farbräume java.awt.event Bietet Klassen und Interfaces für das AWT-Event-Modell java.awt.image Bietet Klassen und Interfaces für Image-Unterstützung java.beans Enthält Klassen für Runtime Java Beans Unterstützung java.rmi Enthält Klassen für RMI java.rmi.registry APIs für RMI-Registry javax.microedition.xlet Schnittstellen, die von Applikationen und dem Applikations-Manager zu Kommunikationszwecken genutzt werden javax.microedition.xlet.ixc Enthält APIs für inter-xlet Communication (IXC) Tabelle 3.5: Personal Basis Profile - Packages Tabelle 3.6 zeigt eine genauere Auflistung der im Personal Profile enthaltenen Packages. Package Name java.applet java.awt java.awt.color java.awt.datatransfer java.awt.event java.awt.image java.beans java.math java.rmi Beschreibung Applet-Unterstützung AWT-Unterstützung Bietet Unterstützung von Farbräumen Datentransferunterstützung innerhalb und zwischen Anwendungen Unterstützung des AWT-Event- Handling Unterstützung für Image-Funktionalität JAVA-Beans-Unterstützung Klassen, um präzise Integer Arithmetik (BigInteger) und präzise Dezimal- Arithmetik (BigDecimal) durchzuführen Bietet RMI-Unterstützung c 2003, Sven Falk Seite 20

29 3.2. J2ME KAPITEL 3. MOBILE JAVA RUNTIMES Package Name Beschreibung java.rmi.registry Enthält APIs für RMI Registry Unterstützung javax.microedition.xlet Schnittstellen, die von Applikationen und dem Applikations-Manager zu Kommunikationszwecken genutzt werden javax.microedition.xlet.ixc Enthält APIs für inter-xlet Communication (IXC) Tabelle 3.6: Personal Profile - Packages Remote Method Invocation Profile Das Remote Method Invocation Profile erweitert das Foundation Profile um die Remote Method Invocation Bibliotheken, wobei nur die Client-seitige API unterstützt wird. Folgende Packages wurden aufgrund von Beschränkungen nicht integriert: java.rmi.server.disablehttp java.rmi.activation.port java.rmi.loader.packageprefix java.rmi.registry.packageprefix java.rmi.server.packageprefix Mobile Information Device Profile Mobile Information Device Profile basiert auf CLDC und erweitert diese um folgende Funktionalität: Netzwerk-Bibliotheken Benutzeroberflächen-Bibliotheken Lokale Datenhaltungs-Bibliotheken Da CLDC hauptsächlich für ressourcenschwache, mobile Geräte gedacht ist, sind nur einfache, grundlegende Funktionen in den oben aufgelisteten Bibliotheken enthalten. Die minimalen Anforderungen an ein unterstütztes Gerät sind: Display-Größe von mindestens 96*54 Pixel Farbtiefe von mindestens 1 Tastatur bzw. Touchscreen 128 KB nichtflüchtiger Speicher für die MIDP-Komponenten 8 KB nichtflüchtiger Speicher für Anwendungsdaten c 2003, Sven Falk Seite 21

30 3.2. J2ME KAPITEL 3. MOBILE JAVA RUNTIMES 32 KB flüchtiger Speicher für den Java-Heap bidirektionale drahtlose Schnittstelle Eine MIDP-basierte Anwendung wird auch als MIDlet bezeichnet. Tabelle 3.7 zeigt eine genauere Auflistung der im MIDP enthaltenen Packages. Package Name javax.microedition.lcdui javax.microedition.rms javax.microedition.midlet javax.microedition.io java.io java.lang java.util Beschreibung User Interface Klassen und Schnittstellen Record Management System (RMS) unterstützt persistente Datenhaltung MIDP Klassentypen für Anwendungsdefinitions-Unterstützung MIDP allgemeine Verbindungsklassen und -schnittstellen Standard Java Ein- / Ausgabeklassen und -schnittstellen VM Klassen und Schnittstellen Standard Utility Klassen und Schnittstellen Tabelle 3.7: Mobile Information Device Profile - Packages Personal Digital Assistant Profile Dieses Profil soll den speziellen Anforderungen moderner PDAs gerecht werden. Da MIDP die Ressourcen von High-End-PDAs wie z.b. die Compaq ipaq 38xx Serie nicht voll ausnutzt, sollte zusätzlich ein Profil speziell für diese Geräteklasse entwickelt werden. Zum Zeitpunkt dieser Ausarbeitung ist jedoch unklar, ob dieses Profil fertiggestellt wird, da offensichtlich große Gemeinsamkeiten mit MIDP bestehen und PDAs bald in der Lage sein werden, CDC voll zu unterstützen J2ME Implementierungen Wie bereits zuvor erwähnt, werden von Sun nur Referenzimplementierungen zur Verfügung gestellt, welche auf einer bestimmten Kombination von Prozessorarchitektur und Betriebssystem basieren. Es sind jedoch diverse kommerzielle J2ME JVMs erhältlich. Im folgenden sollen verschiedene Implementierungen bezüglich des Installationsaufwandes, der Bedienbarkeit der Runtime sowie eventueller Stärken bzw. Schwächen untersucht werden. Für diese Ausarbeitung wurden in Betracht gezogen: NSICOM CrEme IBM Websphere Micro Environment Sun Microsystems Wireless Toolkit 2.0 (Emulator) Gegen Ende der Diplomarbeit wurde von Seiten Filiadatas eine weitere Alternative zu den oben genannten VMs vorgeschlagen. Hierbei handelt es sich um die J2ME VM Jeode, welche aber aus Zeitgründen nicht mehr näher untersucht werden konnte. Weiterführende Informationen zu Jeode sind unter [17] zu finden. c 2003, Sven Falk Seite 22

31 3.2. J2ME KAPITEL 3. MOBILE JAVA RUNTIMES NSICOM CrEme v4.0 beta Evaluation Allgemeines CrEme stellt eine von Sun Microsystems zertifizierte VM dar, welche folgende J2ME Eigenschaften unterstützt: CDC-Unterstützung Foundation Profile-Unterstützung außer java.lang.ref package Swing Unterstützung Die implementierten Bibliotheken basieren auf Suns JDK Personal Profile-Unterstützung mit folgenden Einschränkungen: java.awt.frame.getframes() nicht implementiert Die Klasse java.awt.graphicsenvironment ist nicht vorhanden Ausserdem sind folgende Punkte nicht vollständig umgesetzt: Die Klasse java.awt.graphicsconfigurarion Transparente Farben NSIcom CrEme ist leider nur für diverse Windows-Betriebssysteme verfügbar. Installation Die Installation von CrEme kann auf zwei Arten durchgeführt werden: 1. Installation aus dem CAB-File 2. Installation über ActiveSync-Verbindung unter Verwendung des mitgelieferten Installers Beide Installationsarten sind mit Hilfe der enthaltenen HTML-Hilfe einfach und problemlos durchzuführen. Der Installationsprozess an sich wird hier deshalb nicht näher erläutert. CrEme hat folgende Systemanforderungen: Kombination aus Prozessorarchitektur und Betriebssystem nach Tabelle ca. 2,8 MB nichtflüchtiger Speicher für die Programmdateien und -bibliotheken (incl. Swing- Bibliothek ca. 5 MB) ca. 13,5 MB flüchtiger Speicher für die Laufzeitumgebung (bei einer einfachen Swing-Anwendung) 1 enthalten, nicht verfügbar c 2003, Sven Falk Seite 23

32 3.2. J2ME KAPITEL 3. MOBILE JAVA RUNTIMES ARM MIPS X86 SH3 PowerPC PocketPC HPC CE 3.0 HPC CE.net Tabelle 3.8: Systemanforderungen NSIcom CrEme v4.0 beta Evaluation Bedienung der Laufzeitumgebung Die CrEme-Laufzeitumgebung lässt sich auf drei Arten starten: 1. Start des CrEme-Executables aus einer separaten Konsolenanwendung CrEme kann wie Suns Java-Runtime über eine gewöhnliche Konsole gestartet werden. Parameter wie z.b. die Einstiegsklasse bzw. zusätzliche Optionen werden einfach als Übergabeparamter an das Executable übergeben. 2. Start von CrEme über das Startmenü Wird das CrEme-Executable über das Startmenü ausgeführt, startet eine interne Konsole von CrEme und wartet auf zusätzliche Übergabeparameter wie z.b. Einstiegsklasse, zusätzliche Klassenpfade etc.. 3. Start von CrEme über Jrun Jrun ist ein grafisches Tool von CrEme, das dessen Start ohne Verwendung einer Konsole ermöglicht. Nachdem Jrun gestartet wurde, wird ein Dialog eingeblendet, über welchen der Benutzer zur Eingabe von Parametern aufgefordert wird (z.b. Einstiegsklasse, zusätzliche Klassenpfade etc.). Preisgestaltung In Tabelle 3.9 ist die preisliche Gestaltung beim Erwerb von NSIcom CrEme Lizenzen aufgezeigt. Hierbei sollte beachtet werden, dass es ein Minimal-Packet gibt, welches erworben werden muss, um CrEme nutzen zu dürfen. Dieses Minimal-Packet kostet 1000 $ und enthält folgende Leistungen: Entwicklungslizenz Garantie- und & Unterstützungs-Hotline für 90 Tage 40 Runtime-Lizenzen Für interne Verwendung, Demos, Bundling mit Hard-/Software Menge Lizenzpreis $ Tabelle 3.9: NSIcom CrEme Preisgestaltung c 2003, Sven Falk Seite 24

33 3.2. J2ME KAPITEL 3. MOBILE JAVA RUNTIMES Stärken und Schwächen + Einfache Installation und Ausführung der Runtime-Umgebung + CrEme enthält einen Emulator, welcher es erlaubt, Anwendungen auf einem PC zu testen + Java-Applet-Plugin für Internet-Explorer bzw. Standalone-Applet-Viewer + Just-In-Time Compiler + JNI-Unterstützung - Kommerzielle Lizenz - Relativ lange Startup-Zeiten (ca. 40 sec für eine einfache Swing-Anwendung) - Sporadische Leistungseinbrüche in Verbindung mit Swing c 2003, Sven Falk Seite 25

34 3.2. J2ME KAPITEL 3. MOBILE JAVA RUNTIMES IBM Websphere Micro Environment Allgemeines IBM Websphere Micro Environment (J9) stellt ebenso wie CrEme eine von Sun Microsystems zertifizierte J2ME VM dar. Im Gegensatz zu CrEme ist in J9 jedoch auch eine CLDC/MIDP Implementierung integriert. Folgende J2ME Eigenschaften werden unterstützt: CDC CLDC Foundation Profile Personal Profile MIDP J9 ist für diverse Betriebssysteme verfügbar. Leider ist zum Zeitpunkt dieser Ausarbeitung keine Version für Familiar Linux erhältlich. Laut IBM existiert allerdings eine Linux/StrongARM-Version, welche aber nicht offiziell erhältlich ist. Installation Die J9 VM ist für eine Reihe von Betriebssystem/Prozessorarchitektur-Kombinationen verfügbar. Hierzu zählen z.b.: PocketPC (ARM) Linux (ARM) QNX (SH4, PowerPC, MIPS, ARM, x86) Da die Installation der J9 Runtime-Umgebung trotz des vorhandenen Hilfe-Systems nicht trivial ist, wird hier eine detailiertere Erläuterung des Installationsvorganges aufgezeigt. J9 erwartet eine Pfad-Struktur, welche z.b. für ein PocketPC /ARM-System folgendermaßen aussehen muss: \j9\pocketpc\arm\bin \j9\pocketpc\arm\lib In diese beiden Verzeichnisse werden die Betriebssystem/Prozessor-spezifischen Dateien kopiert, welche sich im Installationspfad des Websphere Developer Studios unter...\wsdd5.0\ive\runtimes\ os \ architecture in den entsprechenden Unterverzeichnissen befinden. c 2003, Sven Falk Seite 26

35 3.2. J2ME KAPITEL 3. MOBILE JAVA RUNTIMES Im bin-verzeichnis müssen folgende Dateien abgelegt werden: j9.exe bzw. j9w.exe für VM ohne eigene Konsole j9dbg20.dll j9dyn20.dll j9foun20.dll j9hook20.dll j9prt20.dll j9thr20.dll j9vm20.dll j9zlib20.dll swt-win dll Im lib-verzeichnis werden die Bibliotheken für die gewünschten Profile hinterlegt. Will man z.b. das Personal Profile nutzen, so müssen die Verzeichnisse jclfoundation und jclppro aus dem Websphere Developer Studio-Installationsverzeichnis in das bin-verzeichnis kopiert werden. Zusätzliche Bibliotheken wie z.b. JAR-Archive können beliebig auf dem Zielgerät abgelegt, müssen jedoch beim Aufruf der Runtime-Umgebung als Übergabeparameter absolut referenziert werden. Bedienung der Laufzeitumgebung Die J9-Laufzeitumgebung wird aus einer Konsolen-Anwendung heraus gestartet. Dabei muss das J9-Executable sowie Klassenpfade und zusätzliche Bibliotheken absolut referenziert werden. Ein typischer J9-Aufruf sieht folgendermaßen aus: \j9\pocketpc\arm\bin\j9 -jcl:foun -cp \j9\pocketpc\arm\lib\jclppro\ppro-ui-win.zip;. HelloWorld Die in diesem Aufruf verwendeten Optionen erklären sich folgendermaßen: -jcl:foun - definiert das zu verwendende Profil (hier Foundation, obwohl Personal Profile verwendet werden soll) -cp - definiert, dass zusätzliche Klassen im angegebenen Archiv/Pfad zu finden sind (hier Klassen des Personal Profile) J9 startet nach diesem Aufruf eine eigene Konsole, falls j9.exe gestartet wurde, welche als Standardaus- bzw. -eingabe verwendet wird. Beim Start von J9 über die Datei j9w.exe wird keine separate Konsole eingeblendet. c 2003, Sven Falk Seite 27

36 3.2. J2ME KAPITEL 3. MOBILE JAVA RUNTIMES Preisgestaltung IBM Websphere Micro Environment ist über Zweit- und Drittanbieter zu beziehen und variiert dementsprechend im Lizenzpreis. 6 $ je Lizenz können jedoch als Richtlinie für den Bezug von Kleinmengen angesehen werden. Stärken und Schwächen + IBM Websphere Micro Environment ist in Verbindung mit IBM Websphere Developer Studio verwendbar. Dieses stellt eine komplette IDE auf Eclipse Basis, mit integriertem Emulator dar. + Just In Time Compiler (JIT) + Ahead Of Time Compiler (AOT) + SWT-Unterstützung (schnell) + schnelle AWT-Umsetzung - Swing-Unterstützung aufgrund unvollständiger AWT-Umsetzung nicht möglich - Kommerzielle Lizenz Sun Microsystems Wireless Toolkit 2.0 Sun Microsystems Wireless Toolkit 2.0 (WTK) ist eine Referenzimplementierung der CLDC mit MIDP. Sie stellt eine Testumgebung für Windows/x86 Systeme dar. Neben dieser Version sind auch Versionen für Solaris und Linux verfügbar, welche auf der Sun Website jedoch als unsupported aufgeführt sind. c 2003, Sven Falk Seite 28

37 3.2. J2ME KAPITEL 3. MOBILE JAVA RUNTIMES JDK vs. J2ME-Profiles Tabelle zeigt die Unterschiede bzw. Erweiterungen der in J2ME enthaltenen Klassenbibliotheken im Vergleich zu Suns JDK Package Name PP PBP FP CDC java.applet java.awt java.awt.color java.awt.datatransfer java.awt.dnd java.awt.event java.awt.font???? java.awt.geom java.awt.im java.awt.im.spi java.awt.image java.awt.image.rederable java.awt.print java.beans java.beans.beancontext java.io java.lang java.lang.ref java.lang.reflect java.math java.net java.rmi java.rmi.activation java.rmi.dgc java.rmi.registry java.rmi.server java.security java.security.acl java.security.cert java.security.interfaces java.security.spec java.sql java.text java.util java.util.jar java.util.zip javax.accessibility javax.naming javax.naming.directory javax.naming.event javax.naming.ldap 2 enthalten, von anderen Profilen geerbt, optional, nicht verfügbar c 2003, Sven Falk Seite 29

38 3.2. J2ME KAPITEL 3. MOBILE JAVA RUNTIMES Package Name PP PBP FP CDC javax.naming.spi javax.rmi javax.rmi.corba javax.sound.midi javax.sound.midi.spi javax.sound.sampled javax.sound.sampled.spi javax.swing javax.swing.border javax.swing.colorchooser javax.swing.event javax.swing.filechooser javax.swing.plaf javax.swing.plaf.basic javax.swing.plaf.metal javax.swing.plaf.multi javax.swing.table javax.swing.text javax.swing.text.html javax.swing.text.html.parser javax.swing.text.rtf javax.swing.tree javax.swing.undo javax.transaction org.omg.corba org.omg.corba_2_3 org.omg.corba_2_3.portable org.omg.corba.dynanypackage org.omg.corba.orbpackage org.omg.corba.portable org.omg.corba.typecodepackage org.omg.cosnaming org.omg.cosnaming.namingcontextpackage org.omg.sendingcontext org.omg.stub.java.rmi Tabelle 3.10: JDK vs. J2ME-Profiles c 2003, Sven Falk Seite 30

39 3.2. J2ME KAPITEL 3. MOBILE JAVA RUNTIMES Zusammenfassung J2ME Mit der J2ME will Sun eine Java-Umgebung realisieren, welche auf die sich dynamisch ändernden Anforderungen des Mobile Computing adäquat reagieren kann. Sun selbst beschränkt sich dabei auf die Entwicklung der Spezifikationen und überlässt die Implementierung OEM- bzw. Third-Party-Entwicklern. Die J2ME-Architektur ist in drei Schichten aufgeteilt, die Java-Virtual-Machine-, Konfigurationsund Profil-Schicht. JVM- und Konfigurations-Schicht sind dabei stark aneinander gekoppelt. Eine Konfiguration spezifiziert die Fähigkeiten der Java Programmiersprache, der JVM sowie die Basis- Java-Bibliotheken und -APIs. Bisher sind zwei Konfigurationen durch den JCP spezifiert: die CDC und die CLDC. CDC verwendet eine klassische VM und ist vorgesehen für leistungstarke, mobile Geräte. CLDC dagegen besitzt eine eigene VM: die KVM. CLDC soll vorrangig auf mobilen Geräten mit eingeschränkten Fähigkeiten zum Einsatz kommen. Oberhalb der Konfigurationsschicht befindet sich die Profilschicht. Profile spezialisieren die durch die Konfigurationschicht bereitgestellte Basisfunktionalität durch zusätzliche APIs und Klassenbibliotheken. Ein Profil baut immer auf einer bestimmten Konfiguration oder einem anderen Profil auf. Für CDC sind das Foundation, Personal Basis, Personal und RMI Profil bereits durch den JCP spezifiziert. Für CLDC existiert bisher nur ein Profil: das MIDP. In dieser Ausarbeitung wurden zwei Implementierungen der J2ME-Spezifikation betrachtet NSICom CrEme v4.0 beta und IBM Websphere Microenvironment. CrEme bietet in der vorliegenden Version Unterstützung für CDC in Verbindung mit dem Foundation, Personal Basis und Personal Profile. Zusätzlich zu erwähnen wäre hier die Swing-Unterstützung, welche während dieser Ausarbeitung auch getestet wurde. Die Installation der VM ist unkompliziert. CrEme kann nach der Installation über eine Konsolenanwendung, das Startmenü oder einem separaten Tool gestartet werden. Positiv aufgefallen sind der mitgelieferte Emulator, der JIT, die JNI- Unterstützung und das Applet-Plugin für den Internet Explorer. Negativ zu erwähnen sind die kommerzielle Lizenz, relativ lange Startupzeiten und sporadische Leistungseinbrüche in Verbindung mit Swing. Als weitere J2ME-Implementierung wurde die IBM Websphere Micro Environment getestet. Diese VM unterstützt CDC in Verbindung mit Foundation, Personal Basis und Personal Profile sowie CLDC in Verbindung mit MIDP. Sie ist ausserdem für eine Reihe von Betriebssystem / Prozessorarchitektur Kombinationen verfügbar. Die Installation gestaltet sich aufgrund des fehlenden Installers nicht so einfach wie bei CrEme. Ausserdem ist die lückenhafte Dokumentation negativ aufgefallen. Die konsolenlose Version der IBM Websphere Microenvironment benötigt zum Start eine Konsolenanwendung bzw. ein ausführbares Startskript. Bei der Version mit der integrierten Konsole können die erforderlichen Parameter nach dem Start eingegeben werden. Positiv zu erwähnen ist, dass eine komplette IDE verfügbar ist, welche auch einen integrierten Emulator besitzt. Weiterhin vorteilhaft sind der JIT, AOT und die SWT-Unterstützung. Negativ zu bewerten ist hier die kommerzielle Lizenz sowie die fehlerhafte AWT-Implementierung. Abschliessend bleibt hier zu erwähnen, dass die IBM Websphere Microenvironment der NSICom CrEme aufgrund der günstigeren Lizenzbedingungen und dem umfangreicheren Funktionsumfang zu bevorzugen ist. c 2003, Sven Falk Seite 31

40 3.3. VOLLWERTIGE JVMS KAPITEL 3. MOBILE JAVA RUNTIMES 3.3 Vollwertige Java Virtual Machines Neben den J2ME-VMs gibt es Alternativen für den Einsatz von Java auf mobilen Geräten, welche auf voll ausgestatteten Virtuellen Maschinen basieren. In dieser Ausarbeitung sollen zwei dieser VMs näher betrachtet werden Kaffe for PocketPC Allgemeines Kaffe ist eine clean room-implementierung von Suns Spezifikation für die Java Virtual Machine. Kaffe ist völlig unabhängig von jeglichem Sun Source Code und bringt seine eigenen Klassenbibliotheken für die Java Runtime Umgebung mit. Die Lizenzierung von Kaffe erfolgt durch eine GNU Public License, was bedeuted, dass Kaffes Source Code frei verfügbar, modifizierbar und einsetzbar ist. Kaffe befindet sich noch im Entwicklungsstadium und bietet noch nicht alle Funktionen, welche eine vollwertige JVM (wie z.b. Suns JDK) zur Verfügung stellt. Die aktuelle Version von Kaffe (1.0.7) enthält eine Reihe von Java-Standardbibliotheken, welche unter anderem auch AWT und Beans unterstützen. Für weiterführende Informationen sei hier auch auf die offizielle Website [10] von Kaffe verwiesen. Die Kaffe Portierung für PocketPC Ein Paradigma von Kaffe ist, dass es leicht auf diverse Plattformen portierbar sein soll. Deshalb kann auf der Kaffe-Website [10] auch eine Richtlinie heruntergeladen werden, welche die nötigen Schritte des Portierungs-Vorgangs näher erläutert. Rainer Keuchelt hat eine Portierung der Kaffe Virtual Machine auf WindowsCE/ARM-Systeme vorgenommen. Diese Portierung ist unter [11] zu finden. Allerdings weist diese Kaffe-Version noch einige Schwächen auf, welche nachfolgend betrachtet werden. Installation Kaffe benötigt keine bestimmte Ordnerstruktur. Lediglich die unten aufgeführte Datei celib.dll muss sich im \windows-verzeichnis befinden. Zusätzlich müssen diverse Registry-Einträge vorgenommen werden, damit das Kaffe-Executable die benötigten Programmbibliotheken findet. c 2003, Sven Falk Seite 32

41 3.3. VOLLWERTIGE JVMS KAPITEL 3. MOBILE JAVA RUNTIMES Folgende Dateien werden für die Installation benötigt: celib.dll (Version 3.0 oder höher) kaff.exe kvm.dll libawt.dll libio.dll libnative.dll libnet.dll Diese Dateien bilden das Grundgerüst der Kaffe VM und benötigen auf dem Zielgerät ca. 2 MB nichtflüchtigen Speicher. Für die Laufzeitumgebung werden zusätzlich noch folgende Java-Archive benötigt: Klasses.jar KJC.jar, falls auf dem Zielgerät kompiliert werden soll swingall.jar, falls Swing-Unterstützung erwünscht ist Hierzu werden zusätzlich mindestens ca. 900 kb bzw. 3 MB, wenn Swing- und Kompilier-Unterstützung gefordert sind, benötigt. Die minimale Kaffe-Laufzeitumgebung benötigt also mindestens ca. 3MB nichtflüchtigen Speicher. Damit das Kaffe-Executable seine Programm- und Klassenbibliotheken findet, müssen die in Tabelle 3.11 aufgelisteten Registry-Einträge erstellt werden. Key Type Name Value HKLM\Environment String KAFFELIBRARYPATH Pfad zu DLLs ausser celib.dll HKLM\Environment String KAFFECLASSPATH Pfad zu Java Resources HKLM\Environment String CLASSPATH Pfad zu zusätzl. Java Ressourcen Tabelle 3.11: Kaffe Registry-Einträge c 2003, Sven Falk Seite 33

42 3.3. VOLLWERTIGE JVMS KAPITEL 3. MOBILE JAVA RUNTIMES Bedienung der Laufzeitumgebung Es gibt zwei Arten Kaffe zu starten: 1. Start aus einer Konsolen-Anwendung 2. Binden von.class-dateien an das Kaffe-Executable durch Registry-Einträge dadurch werden.class-dateien doppelklickbar. Soll 2. zur Anwendung kommen, müssen die in Tabelle 3.12 aufgeführten Registry-Einträge erstellt werden. Key Type Name Value HKCR\.class String DEFAULT javaclass HKCR\javaclass String DEFAULT Java Class HKCR\javaclass\Shell\Open\ String DEFAULT Pfad zum Command Kaffe- Executable %%1 Tabelle 3.12: Optionale Kaffe Registry-Einträge Ausserdem muss sichergestellt sein, dass alle benötigten Ressourcen über die HKLM\Environment\KAFFECLASSPATH- bzw. HKLM\Environment\CLASSPATH-Variable referenziert werden. Kaffe nutzt eine sh-ähnliche Konsole als Standardein- bzw. -ausgabe, welche in der celib.dll enthalten ist. Zusätzlich werden Ein- und Ausgaben in den Dateien \kaff-stderr.txt, \kaff-stdin.txt und \kaff-stdout.txt protokolliert. Probleme der Kaffe PocketPC Portierung Wie bereits vorher erwähnt, bestehen noch kleine Probleme in der von Rainer Keuchel durchgeführten Portierung. Die bisher aufgedeckten Schwächen werden nachfolgend näher erläutert. Zeichnungsprobleme in AWT Die AWT-Umsetzung der Portierung zeigt Schwächen in folgender Hinsicht: 1. Unter PocketPC2002 wird die Titelleiste der erzeugten Frames von der Menüleiste des OS überdeckt (siehe Bild 3.3). Eine Modifizierung der Native-Zeichen-Methoden bzgl. der Verschiebung des Zeichnungsursprunges um die Höhe der Menüleiste behebt dieses Problem. Allerdings verliert man durch diesen Workaround Darstellungsfläche. 2. Die Frame-Widgets zur Minimierung und Maximierung sind nur zum Zeitpunkt der Aktivierung sichtbar und verschwinden anschliessend wieder. Da eine Minimierung und Maximierung ohnehin nicht erwünscht ist, kann diese Funktion ebenfalls in der Native-Zeichen-Methode deaktiviert werden. c 2003, Sven Falk Seite 34

43 3.3. VOLLWERTIGE JVMS KAPITEL 3. MOBILE JAVA RUNTIMES Abbildung 3.3: Titelleistenüberdeckung durch Menüleiste des OS 3. Der Zeichnungskontext der sh-konsole ist nach dem Start der AWT-Anwendung blockiert (siehe Bild 3.4). 4. Frames sind verschieb- und größenmodifizierbar, was im Umfeld mobiler Geräte aufgrund der Displaygröße ebenfalls unerwünscht ist. Die Punkte 1, 2 und 4 der oben dargestellten Aufzählung konnten durch diverse Modifikationen der nativen Zeichenoperationen gelöst werden. Bei Versuchen mit den so gepatchten AWT-Bibliotheken in Verbindung mit Swing zeigten sich ebenfalls Probleme: 1. Swings Zeichenoperationen funktionierten nicht korrekt (siehe Abbildung 3.5). Der Fehler hierbei ist die Verwendung ungeeigneter Zeichenoperationen zum Zeichnen von Linien. Dieser Fehler wurde durch Modifikation der Native-Zeichnungs-Methoden behoben. 2. Fehlerhaftes Verhalten im Bereich des Look-And-Feel diverser Komponenten (z.b. Buttons zum Scrollen im javax.swing.jscrollpane klemmen ) Leider ist zu diesem Zeitpunkt der Ausarbeitung keine genauere Untersuchung der Swing-Inkompatibilitäten möglich. Es ist aber anzunehmen, dass weitere, kleinere Probleme existieren. Diese werden sich allerdings erst beim konkreten Einsatz von Swing, z.b. im Rahmen einer Java-Applikation, aufdecken lassen. c 2003, Sven Falk Seite 35

44 3.3. VOLLWERTIGE JVMS KAPITEL 3. MOBILE JAVA RUNTIMES Abbildung 3.4: Blockierter Zeichnungskontext der sh-konsole Abbildung 3.5: Zeichnungsfehler in Swing c 2003, Sven Falk Seite 36

45 3.3. VOLLWERTIGE JVMS KAPITEL 3. MOBILE JAVA RUNTIMES Blackdown for Linux Blackdown stellt in seinen verschiedenen Versionen eine Linux-Portierung der Sun JDKs dar. Er basiert auf Java-Sourcen, welche von Sun lizenziert sind. Für gewöhnliche Desktop-Systeme sind viele JDK 1.x kompatible Versionen verfügbar. Für die Familiar Linux Distribution ist bisher nur die JDK kompatible Blackdown Version erhältlich. Weiterführende Informationen sind unter [12] zu finden. Installation Die Installation von Blackdown erfolgt über das ipkg-tool, das zur Installation von Paketen verwendet wird. Dieses Tool übernimmt die Installations- und Konfigurationsaufgaben, sodass keine manuellen Nacharbeiten vorgenommen werden müssen. Das Blackdown-Packet benötigt ca. 18 MB nichtflüchtigen Speicher, welcher sinnvoller Weise durch eine CF-Karte bereitgestellt werden sollte. Bedienung der Laufzeitumgebung Die Anwendungen im Blackdown-Packet entsprechen in Sachen Namensgebung und Funktionalität den Sun JDK-Pondons. Probleme mit Blackdown Probleme traten mit Blackdown nur beim Einsatz von RMI auf (siehe Kapitel 3.4). c 2003, Sven Falk Seite 37

46 3.3. VOLLWERTIGE JVMS KAPITEL 3. MOBILE JAVA RUNTIMES Zusammenfassung In diesem Kapitel wurden die beiden vollwertigen VMs Kaffe und Blackdown for Linux näher betrachtet. Dabei stellte sich heraus, dass für Microsoft PocketPC 2002 keine einsatzbereite VM verfügbar ist. Die bestehende Portierung von Kaffe ist unvollständig und weist noch einige Schwachstellen auf. Die Installation von Kaffe umfasst das Kopieren der benötigten Dateien sowie das Anlegen von diversen Registry-Keys. Für zweiteres muss für Microsoft PocketPC 2002 zusätzliche Software installiert werden. Da der direkte Start von.class-files nicht reibungslos funktioniert, sollte auf die Alternative, dem Start aus einer Konsolenanwendung, ausgewichen werden. Im Rahmen dieser Ausarbeitung wurden diverse Zeichenprobleme der nativen AWT-Implementierung festgestellt und teilweise behoben. Um Kaffe einsatzfähig zu machen, ist jedoch weitere Entwicklungsarbeit notwendig. Die fehlende RMI-Unterstützung schränkt das Einsatzgebiet von Kaffe zusätzlich ein. Als vollwertige Java-VM für Familiar Linux wurde Blackdown getestet. Blackdown entsprach zum Zeitpunkt dieser Ausarbeitung dem Funktionsumfang von Suns JDK Natürlich sind aber auch Blackdown-Versionen auf dem Stand älterer JDKs erhältlich. Die Installation unter Familiar Linux gestaltet sich durch die Verwendung des ipkg-tools einfach. Die Bedienung der VM entspricht der von Sun gewohnten Syntax und Semantik. Probleme traten mit Blackdown nur in Verbindung mit RMI auf. c 2003, Sven Falk Seite 38

47 3.4. RMI-KOMPATIBILITÄT KAPITEL 3. MOBILE JAVA RUNTIMES 3.4 Remote Method Invocation - Kompatibilität Um Java-Applikationen sinnvoll auf einem mobilen Gerät einsetzen zu können, bietet sich an, rechenaufwendige bzw. ressourcenhungrige Applikationsteile auf Anwendungs-Server auszulagern. Um auf diesen so entstandenen Serverteil der Anwendung zuzugreifen, kann z.b. Remote Method Invocation (RMI) verwendet werden J2ME und RMI RMI wird in J2ME durch das RMI-Profile bereitgestellt und ist auch im Personal Basis und Personal Profile enthalten. Wie in Kapitel bereits aufgezeigt wurde, werden diese Profile von NSIcom CrEme und IBM Websphere Microenvironment unterstützt. Tabelle 3.13 gibt Aufschluss über den Funktionsumfang und die Einsatzfähigkeit dieser beiden Implementierungen. Server Client Fehlerart Unter Verwendung der java.rmi.naming-klasse Sun JDK (PC) NSIcom CrEme keine Fehler Sun JDK (PC) IBM J9 keine Fehler NSIcom CrEme NSICom CrEme keine Fehler NSIcom CrEme IBM J9 java.rmi.server.skeletonmismatchexception NSIcom CrEme Sun JDK (PC) java.rmi.notboundexception IBM J9 NSIcom CrEme java.io.streamcorruptedexception IBM J9 IBM J9 keine Fehler, aber träge IBM J9 Sun JDK (PC) java.io.streamcorruptedexception Unter Verwendung der java.rmi.registry-klasse Sun JDK (PC) NSIcom CrEme keine Fehler Sun JDK (PC) IBM J9 keine Fehler NSIcom CrEme NSICom CrEme keine Fehler NSIcom CrEme IBM J9 java.rmi.server.skeletonmismatchexception NSIcom CrEme Sun JDK (PC) keine Fehler IBM J9 NSIcom CrEme java.io.streamcorruptedexception IBM J9 IBM J9 keine Fehler IBM J9 Sun JDK (PC) java.rmi.unmarshalexception Tabelle 3.13: J2ME - RMI-Kompatibitlität Vollwertige Java-Virutal-Machines und RMI Die vollständig ausgestatten VMs dürften eigentlich keine Probleme beim Einsatz von RMI haben. Es hat sich jedoch herausgestellt, dass nicht in allen JVMs die RMI-Funktionalität integriert ist. Ein Versuch, diese Funktionalität in Form eines Packages nachzurüsten, ist bisher nicht gelungen, da in bestimmten Klassen auf Native-Funktionalität zugegriffen wird, welche diesbezüglich noch implementiert werden müsste. c 2003, Sven Falk Seite 39

48 3.4. RMI-KOMPATIBILITÄT KAPITEL 3. MOBILE JAVA RUNTIMES Von den hier eingesetzten virtuellen Maschinen Kaffe und Blackdown, konnte Erstere deshalb nicht auf RMI-Funktionalität überprüft werden. Aber es stellte sich heraus, dass auch Blackdown bezüglich RMI noch Schwächen aufweist. Tabelle 3.14 zeigt die Kompatibilität von Kaffe und Blackdown zu RMI. Server Client Fehlerart Unter Verwendung der java.rmi.naming-klasse Sun JDK (PC) Blackdown java.rmi.connectexception Sun JDK (PC) Kaffe nicht implementiert Kaffe Blackdown nicht implementiert Kaffe Sun JDK (PC) nicht implementiert Blackdown Kaffe nicht implementiert Blackdown Sun JDK (PC) keine Fehler Unter Verwendung der java.rmi.registry-klasse Sun JDK (PC) Blackdown keine Fehler Sun JDK (PC) Kaffe nicht implementiert Kaffe Blackdown nicht implementiert Kaffe Sun JDK (PC) nicht implementiert Blackdown Kaffe nicht implementiert Blackdown Sun JDK (PC) keine Fehler Tabelle 3.14: RMI-Kompatibitlität der vollwertigen JVMs Zusammenfassung RMI-Kompatibilität Beim Einsatz von J2ME-VMs und den vollwertigen JVMs stellten sich Inkompatibilitäten in Bezug auf RMI heraus. Bei J2ME traten die meisten Probleme beim Einsatz der VMs als RMI-Server auf. Dies ist darauf zurückzuführen, dass der Einsatz von J2ME-VMs als RMI-Server nicht spezifiziert ist. Verwunderlich ist aber dennoch, dass fast die gesamte RMI-Funktionalität der CrEme VM deprecated ist. Beim Einsatz von Suns JDK als RMI-Server konnten die besten Ergebnisse erzielt werden. Obwohl von einer vollwertigen JVM eigentlich erwartet werden kann, dass RMI vollständig unterstützt wird, zeigte sich während dieser Ausarbeitung, dass hier noch Defizite bestehen. So unterstützt die portierte Kaffe Version überhaupt keine RMI-Funktionalität und Blackdown liefert in speziellen Fällen ebenfalls Fehlermeldungen zurück. c 2003, Sven Falk Seite 40

49 3.5. ZUSAMMENFASSUNG MOBILE VMS KAPITEL 3. MOBILE JAVA RUNTIMES 3.5 Zusammenfassung Mobile Java Runtimes In diesem Kapitel wurden Alternativen und Problemstellungen untersucht, welche beim Einsatz von Java auf mobilen Geräten berücksichtigt werden sollten. Grundsätzlich stellt sich die Frage, welche Technologie für die Portierung einer JDK 1.3 konformen Applikation verwendet werden soll. Einerseits garantiert der Einsatz einer vollwertigen JVM einen geringen Portierungsaufwand andererseits enthält dieser Ansatz einen relativ großen Overhead an Funktionalität und einen erheblichen Ressourcenaufwand. Leistungsschwächere Geräte könnten somit keine Anwendungen auf dieser Basis ausführen. Wählt man J2ME, kann die JVM auf die durch das Gerät vorgegebenen Einschränkungen angepasst werden. Ausserdem wird die vorhandene Funktionalität auf das benötigte Maß reduziert was zusätzlich Ressourcen schont. Bei diesem Ansatz muss allerdings berücksichtigt werden, dass mit einem größeren Portierungsaufwand zu rechnen ist. Tests mit verfügbaren J2ME JVMs haben ergeben, dass sich besonders in Verbindung mit CDC und den entsprechenden Profilen der Portierungsaufwand in Grenzen hält. Der gewonnene Vorteil durch die ressourcenschonende Architektur fällt deshalb stärker ins Gewicht. Das bedeutet, dass J2ME-VMs, wenn technisch realisierbar, den vollwertigen JVMs trotz höheren Portierungsaufwandes zu bevorzugen sind. Bestehende Inkompatibilitäten bzw. fehlende Funktionalität sind mitunter auf das relativ junge Stadium der J2ME-Technologie zurückzuführen. Als mögliche Kandidaten für den Einsatz wurden die IBM Websphere Microenvironment und die NSI- Com CrEme v4.0 beta näher betrachtet. Beide VMs sind in der Lage modifizierte JDK 1.3 konforme Java-Anwendungen auszuführen. In manchen Fällen, wie z.b. beim Einsatz von Swing, trifft man natürlich an die Grenzen der Leistungsfähigkeit des mobilen Gerätes. Hier bleibt abzuwarten, was die Optimierungen der Betriebssysteme auf die neue XSCALE-Prozessorarchitektur an Leistungspotential enthalten. Ist das Leistungspotential des mobilen Gerätes nicht sonderlich eingeschränkt, wie z.b. bei Tablet- PCs oder Sub-Notebooks, so empfiehlt sich jedoch der Einsatz der vollwertigen JVMs. Als Kandidaten hierfür wurden Kaffe und Blackdown for Linux untersucht. Kaffe ist sowohl für Microsoft PocketPC 2002 als auch für Familiar Linux erhältlich. Die Microsoft PocketPC 2002 Version von Kaffe enthält noch Entwicklungspotential. Besonders in Bezug auf AWT bzw. Swing und RMI müsste für den realen Einsatz noch Nacharbeit geleistet werden. Teilweise wurden während dieser Ausarbeitung bereits Lösungen für bestimmte GUI-Probleme entwickelt. Blackdown stellt im Gegensatz zu Kaffe eine fast vollständige Umsetzung einer JVM für mobile Geräte dar. Nur in Bezug auf RMI traten während dieser Ausarbeitung in speziellen Fällen Probleme auf. Blackdown ist, wie im vollen Namen offensichtlich, im Moment nur für Familiar Linux erhältlich. Die RMI-Kompatibilität wurde in diesem Kapitel gesondert betrachtet, weil es sich bei der im weiteren Verlauf dieser Ausarbeitung portierten Anwendung um eine verteilte Client/Server-Applikation handelt, welche RMI verwendet. Wie zuvor bereits erwähnt, bestehen sowohl bei den untersuchten J2ME-VMs als auch bei den vollwertigen JVMs gewisse Defizite in diesem Bereich. Allerdings sind diese nicht so gravierend, sodass die Verwendung von RMI grundsätzlich möglich ist. c 2003, Sven Falk Seite 41

50 Kapitel 4 Portierung einer JDK 1.3 konformen Anwendung 42

51 4.1. ANWENDUNGSBESCHREIBUNG KAPITEL 4. PORTIERUNG Um die im bisherigen Verlauf gewonnenen theoretischen Erkenntnisse auch mit praktischen Fakten zu belegen bzw. zu widerlegen, wurde eine Portierung einer JDK 1.3 konformen Anwendung durchgeführt. Dabei handelt es sich um eine Teilapplikation des Warenwirtschaftssystems FILIS, das sich bei der Drogeriemarktkette dm im Einsatz befindet und von der Firma Filiadata GmbH entwickelt wurde. Im weiteren Verlauf dieser Ausarbeitung wird diese Teilapplikation als Bestandskorrektur bezeichnet. 4.1 Anwendungsbeschreibung Das Gesamtsystem FILIS ist eine 3-Tier-Client-Server-Applikation bestehend aus Anwendungsclient, Applikations- und Datenbankserver (siehe Abbildung 4.1). Für den Datenaustausch zwischen Anwendungsclient und Applikationsserver wird ein Kommunikationsserver eines Drittanbieters verwendet. Dieser bietet die Möglichkeit, falls Anwendungsclient und Anwendungsserver auf der gleichen Maschine ausgeführt werden, Aufrufe des Anwendungsclients mittels Reflection an den Applikationsserver weiterzuleiten. Bei der verteilten Nutzung des Systems werden diese Aufrufe über RMI an den Server übermittelt. Als Datenbasis wird eine IBM DB2 Instanz verwendet. Diese ist über Java Database Connectivity (JDBC) an den Applikationsserver angebunden. Ein DB-Generic Framework übernimmt die Umsetzung der relationalen Daten der Datenbasis in Objektdaten und umgekehrt. Da nicht alle Anwendungsteile von FILIS für die Ausführung auf einem mobilen Client geeignet sind, wurde für den Portierungstest eine Teilfunktion, die Bestandskorrektur, aus dem Gesamtsystem herausgelöst und portiert Die Bestandskorrektur Bei der Bestandskorrektur handelt es sich um eine einfache transaktionsbasierte Funktion der FILIS- Anwendung. Die Transaktionssteuerung geschieht dabei serverseitig. Die Bestandskorrektur wird dazu verwendet, Zu- oder Abgänge von den im Warenwirtschaftssystem FILIS gepflegten Artikel-Datenbeständen zu erfassen. Dabei hat der Bediener die Möglichkeit, Artikel mit Hilfe von DANs 1 oder EANs zu identifizieren. Über ein Auswahlmenü kann der Buchungsgrund angegeben werden. Das Erscheinungsbild der Applikation ist mitunter von dieser Auswahl abhängig, da bestimmte Buchungsvorgänge zusätzliche Information wie z.b. ein Datum benötigen. Um den Gesamtvorgang abzuschließen, muss noch die Anzahl der zu erfassenden Artikel angegeben und die Buchung gestartet werden. Dieser Teil der FILIS-Anwendung soll zur Evaluation der Portierbarkeit dienen. Falls sich herausstellt, dass Portierungen mit einem rechtfertigbaren Aufwand durchzuführen sind, strebt die Filiadata GmbH an, weitere Teile des Systems auf mobile Clients auszulagern. Diese Ausarbeitung kann deshalb als Machbarkeitsstudie für zukünftige Portierungen angesehen werden. 1 DAN ist die Bezeichnung für die internen Artikelnummern der Drogeriemarktkette dm. c 2003, Sven Falk Seite 43

52 4.1. ANWENDUNGSBESCHREIBUNG KAPITEL 4. PORTIERUNG Abbildung 4.1: Systemarchitektur des Warenwirtschaftssystems FILIS c 2003, Sven Falk Seite 44

53 4.1. ANWENDUNGSBESCHREIBUNG KAPITEL 4. PORTIERUNG Anforderungen Folgende Anforderungen mussten bei der Portierung der Bestandskorrektur berücksichtigt werden: 1. Es soll möglichst viel vom vorhandenen Framework der FILIS-Anwendung verwendet werden. Besonders im Hinblick auf J2ME ergeben sich hieraus diverse Fragestellungen. So war zunächst unklar, in wie weit die bestehende RMI-Unterstützung ausreichend ist. Ausserdem musste geklärt werden, ob der in FILIS integrierte Kommunikationsserver spezielle APIs verwendet, die in J2ME nicht vorhanden sind. Sollten Inkompatibilitäten in dieser Hinsicht auftreten, so galt es entsprechende Lösungen bzw. Workarounds zu erarbeiten. 2. Die Anwendung sollte unabhängig von der Benutzeroberfläche gestaltet werden. Ausschlaggebend hierfür ist hauptsächlich, dass noch nicht feststeht welche Technologie bei der Entwicklung der GUI zum Einsatz kommt. Mögliche Kandidaten hierfür sind AWT, SWT und Swing. Für AWT und SWT spricht eindeutig die Nähe zur nativen GUI des entsprechenden Betriebssystems. Die daraus resultierenden Geschwindigkeitsvorteile haben gerade im Umfeld der ohnehin leistungsbeschränkten, mobilen Geräte eine besondere Bedeutung. Erste Versuche mit Swing haben schon im Vorfeld gezeigt, dass selbst moderne PDAs hier an ihre Leistungsgrenzen stoßen. Swing könnte allerdings hinsichtlich der Wiederverwendbarkeit der vorhandenen GUI-Klassen des FILIS-Framework einen Vorteil bieten. 3. Implementierung der Benutzeroberfläche in verschiedenen Technologien. 4. Die Bedienung der GUI sollte möglichst ohne Verwendung des Touchscreens möglich sein. Diese Anforderung resultiert aus dem Einsatzszenario der Bestandskorrektur, welche hauptsächlich zu Inventarisierungszwecken verwendet werden soll. Hierfür wurden von der Filiadata GmbH bereits Informationen zu speziellen PDAs mit integriertem Scanner und Tasten- Bedienfeld gesammelt. Zur Inventarisierung muss der Bediener lediglich den gewünschten Artikel mit dem Scanner erfassen, die gewünschte Buchungsart und Buchungsmenge eingeben, und anschließend die Buchung durchführen. Um diesen Vorgang effizient zu gestalten, ist ein Wechsel des Eingabegerätes möglichst zu vermeiden. Die umständliche Bedienung eines Touchscreens mit Zeigestift bzw. Finger ist hierfür also ungeeignet. 5. Die Antwortzeiten der Anwendung müssen besonderen Anforderungen entsprechen (Dauer von Vorgängen < 1s). Dies ist ebenfalls auf das zuvor erläuterte Anwendungsszenario der Bestandskorrektur zurückzuführen. 6. Die Eingabefelder der Benutzeroberfläche müssen mit entsprechenden Formatierern ausgestattet werden, um Fehleingaben sofort zu erkennen. Der Applikationsserver der FILIS-Anwendung reagiert sehr sensibel auf unerwartete Datentypen. Deshalb muss clientseitig gewährleistet werden, dass dieser Fall nicht eintritt. 7. Entwicklung einer Dummy-Version, um die Präsentation und Tests der GUI auch ohne Server- Zugriffe durchführen zu können. c 2003, Sven Falk Seite 45

54 4.2. ENTWURFSASPEKTE KAPITEL 4. PORTIERUNG Aufgaben Aus den vorher beschriebenen Anforderungen ergaben sich folgende Aufgaben: Einarbeitung in die Architektur von FILIS. Da diese gut strukturiert und im Quellcode ausreichend mit Kommentaren versehen ist, konnte diese Einarbeitungphase recht zügig durchlaufen werden. Einarbeitung in die Funktionsweise des Kommunikationsservers. Dies gestaltete sich etwas schwieriger, da hierfür keine Sourcen vorhanden waren. Deshalb wurden die vorhandenen Binaries dekompiliert, um so Einblick in die Funktionsweise zu erhalten und eventuelle Inkompatibilitäten beim Einsatz auf mobilen Java-Plattformen aufzudecken. Entwurf der Systemarchitektur für die Portierung. Entwurf eines vorläufigen Bedienerkonzeptes. Um ein endgültiges Bedienerkonzept auszuarbeiten, war der zeitliche Rahmen dieser Diplomarbeit zu beschränkt. Entwurf der Benutzeroberfläche und Anpassung an die verschiedenen Technologien AWT, SWT und Swing. Implementierung der ausgearbeiteten Entwürfe. Test der Implementierungen. 4.2 Entwurfsaspekte Architekturaspekte der Portierung Um einen besseren Überblick über die Architektur der Bestandskorrektur zu geben, wird hier die Gesamtsystemarchitektur separat von der Clientsystemarchitektur betrachtet. Diese Vorgehensweise soll sowohl einen abstrakteren Gesamtüberblick über das System geben, als auch einen detaillierten Einblick in die clientseitige Architektur ermöglichen. Gesamtarchitektur Die Architektur der Portierung sollte sich nur bezüglich der Gestaltung der Benutzeroberfläche vom Original in FILIS unterscheiden. D.h., dass möglichst viele Klassen des bestehenden Framework wiederverwendet werden sollten. Die Architektur der Portierung ist deshalb stark an die von FILIS angelehnt (siehe Abbildung 4.1). Lediglich der Client-Teil dieser Architektur wurde entsprechend verringert, um nicht unnötigen Overhead zu erzeugen. Hierzu konnte ein bereits bestehender Batch- Client, der zur Ausführung von Batches in den Client-Teil von FILIS integriert ist, modifiziert werden. Im weiteren Verlauf dieser Ausarbeitung wird der neu entwickelte Client-Teil als Thin-Client bezeichnet. Bei den ersten Tests zeigte sich jedoch, dass diese Architektur auf dem mobilen Gerät zu nicht vertretbaren Verzögerungen im Anwendungsablauf führten (siehe Kapitel 4.3.3). Deshalb wurde nachträglich ein alternativer Architekturvorschlag erarbeitet und implementiert. Diese neue Architektur wird im weiteren Verlauf dieser Ausarbeitung als RMI-Architektur bezeichnet. c 2003, Sven Falk Seite 46

55 4.2. ENTWURFSASPEKTE KAPITEL 4. PORTIERUNG Die RMI-Architektur sieht vor den in FILIS vorhandenen Kommunikationsserver zu umgehen und pure RMI-Zugriffe auf den Applikationsserver zu tätigen. Leider waren die benötigten Server-Sourcen für diese Modifikationen nicht zugänglich. Deshalb wurde die Architektur der Anwendung dahingehend verändert, dass der bereits vorhandene Thin-Client auf einem gewöhnlichen Desktop-System zur Ausführung kommt. Eine Serveranwendung (RMI Client Provider), welche diese Thin-Client- Instanzen verwaltet, ermöglicht den Zugriff auf diese via RMI (siehe Abbildung 4.2). Durch diese Vorgehensweise übernimmt der mobile Client nur noch Darstellungs- und Interaktions-Aufgaben. Die eigentliche Funktionalität der Anwendung wird auf ein Desktop-System ausgelagert. Diese unkonventionelle Lösung kann natürlich nur zu Evaluationszwecken dienen. Für einen Rollout müsste die RMI-Serveranwendung direkt auf dem Applicationserver-Teil von FILIS aufbauen. Die Vorteile der beiden aufgezeigten Alternativen liegen auf der Hand. Die änderungsfreie Übernahme der FILIS-Architektur gewährleistet: Einen geringen Portierungsaufwand. Vorhandene Klassen können eins zu eins übernommen werden. Die Integrierung zusätzlicher Funktionalität gestaltet sich somit sehr einfach. Einen geringen Entwicklungsaufwand. Zukünftige Entwicklungen müssen nicht zweigleisig gefahren werden. Einen geringen Änderungsaufwand. Änderungen finden nur an einer Stelle statt und pflanzen sich nicht im System fort. Diese offensichtlichen Vorteile fordern an anderer Stelle natürlich ihren Tribut, indem sie die Bedienbarkeit des Systems aufgrund längerer Laufzeiten verschlechtern. Die RMI-Architektur bietet folgende Vorteile: Schnelle Antwortzeiten des Systems. Da die Bestandskorrektur besonderen Antwortzeitanforderungen genügen muss, kommt diesem Punkt eine hohe Bedeutung zu. Schonung der Systemressourcen. Durch die Auslagerung der eigentlichen Anwendungsfunktionalität kann der Umfang der benötigten Klassen entsprechend verringert werden. Allerdings bringt dieser Ansatz auch gewisse Nachteile mit sich: Höherer Portierungsaufwand. Sämtliche Funktionaltiät, die auf dem mobilen Client verfügbar sein soll, muss durch entsprechende Interfaces zugänglich gemacht werden. Höherer Entwicklungsaufwand. Neu entwickelte Funktionalität muss zusätzlich durch die Interfaces veröffentlicht werden. Hoher Änderungsaufwand. Änderungen pflanzen sich im System fort. Es muss also entschieden werden, wo die höheren Prioritäten anzusiedeln sind. Ein Ausweg aus diesem Dilemma wäre natürlich die Entkopplung des mobilen Clients von den Schnittstellen des Anwendungsservers. Bestrebungen in diese Richtung würden allerdings in einem ähnlichen System resultieren wie der bereits vorhandene Kommunikationsserver, der in FILIS zum Einsatz kommt. Folglich ist anzunehmen, dass man in dieselben Performanceprobleme läuft, die bereits bei der eins zu eins -Portierung der FILIS-Anwendung bestehen. c 2003, Sven Falk Seite 47

56 4.2. ENTWURFSASPEKTE KAPITEL 4. PORTIERUNG Abbildung 4.2: Erweiterte Systemarchitektur der Bestandskorrektur c 2003, Sven Falk Seite 48

57 4.2. ENTWURFSASPEKTE KAPITEL 4. PORTIERUNG Client-Architektur Wie bereits zuvor erwähnt wurde beim Entwurf der Systemarchitektur darauf geachtet, dass die Benutzeroberfläche lose an die Anwendung gekoppelt ist. D.h., dass der Austausch der Benutzeroberfläche leicht zu bewerkstelligen sein soll. Um dies zu ermöglichen, wurde für die Architektur der Clientseite der Anwendung das Observer-Pattern verwendet. Dabei kommen zwei zentrale Instanzen zum Einsatz: 1. Ein User-Interface-Manager 2. Ein Application-Manager In Abblidung 4.3 ist diese Architektur grafisch dargestellt. Der UIManager soll dabei Aufgaben, welche die Benutzeroberfläche betreffen, übernehmen. Der ApplicationManager übernimmt Aufgaben, welche die Business-Logic der Anwendung betreffen. Er kennt auch den UIManager, um die Benutzeroberfläche von Änderungen der Darstellung zu informieren. Die GUIKomponenten registrieren sich beim UIManager, um über Events informiert zu werden. Damit dies funktioniert, müssen die GUIKomponenten das Interface UIEventListener implementieren. Umgekehrt ist der ApplicationManager als Listener an den GUIKomponenten registriert. Drückt der Benutzer z.b. einen Button, so wird der ApplicationManager mittels eines Events über diese Aktion informiert. Damit dies möglich ist, muss der ApplicationManager das Interface ApplicationEventListener implementieren. Die so entstandene lose Kopplung vermeidet die direkte Bindung der GUI an Methoden der Business- Logic. Soll die Benutzeroberfläche ausgetauscht werden, so muss: diese das UIEventListener-Interface implementieren, sich am UIManager registrieren und auf Events adäquat reagieren. der ApplicationManager an die neue Benutzeroberfläche gebunden werden. Beides funktioniert in der Regel ohne Änderungen am Grundgerüst der Anwendung. Lediglich die neue Benutzeroberfläche, welche ohnehin neu entwickelt wird, muss an die gegebenen Rahmenbedingungen angepasst werden. c 2003, Sven Falk Seite 49

58 4.2. ENTWURFSASPEKTE KAPITEL 4. PORTIERUNG Abbildung 4.3: Client-Architektur der Bestandskorrektur c 2003, Sven Falk Seite 50

59 4.2. ENTWURFSASPEKTE KAPITEL 4. PORTIERUNG Abbildung 4.4 zeigt am Beispiel eines Login, wie die Kommunikation zwischen den einzelnen Klassen abläuft. Zuerst werden Instanzen der beiden Steuerungsklassen ApplicationManager und UIManager erzeugt. Bei der Erzeugung des ApplicationManagers wird gleichzeitig der UIManager übergeben, um diesen dem ApplicationManager bekannt zu machen. Sind diese Instanzen erzeugt, werden die beiden Haupt-GUIs instanziiert. Dabei handelt es sich um eine Instanz des LoginUI und eine des AccountUI. Das LoginUI stellt eine Login-Maske dar, die zu Authentifizierungszwecken dient. Das AccountUI repräsentiert die eigentliche GUI der Anwendung. Nach der Erzeugung der GUI-Instanzen müssen diese als UIEventListener an der UIManager-Instanz registriert werden. Umgekehrt muss sich die ApplicationManager- Instanz an den GUI-Komponenten registrieren, um über Benutzer-Interaktionen informiert zu werden. Hierzu wird die ApplicationManager-Instanz als ApplicationEventListener an der LoginUI-Instanz und der AccountUI-Instanz registriert. Drückt der Benutzer, wie in diesem Beispiel angedeutet, den Login-Button, so werden die an der LoginUI-Instanz registrierten Listener über dieses Ereignis mittels eines ApplicationEvents informiert (Methode notifylisteners()), hier also die ApplicationManager-Instanz. In diesem Event sind Detail-Informationen über die auszuführende Aktion enthalten, in diesem Fall, dass ein Login ausgeführt werden soll. Die ApplicationManager-Instanz führt nun die für den Login notwendigen Aktionen durch. Um den Benutzer über Erfolg/Misserfolg dieser Aktion zu informieren, löst die ApplicationManager- Instanz über die UIManager-Instanz entsprechende UIEvents aus. Die an der UIManager registrierten GUI-Komponenten werden über diese Events informiert und können demensprechend Rückmeldungen an den Benutzer liefern. In diesem Beispiel ist der Login erfolgreich. Die ApplicationManager-Instanz löst zwei UIEvents aus. Einen um die LoginUI-Instanz auszublenden und einen weiteren um die AccountUI-Instanz einzublenden. c 2003, Sven Falk Seite 51

60 4.2. ENTWURFSASPEKTE KAPITEL 4. PORTIERUNG Abbildung 4.4: Kommunikation zwischen den Objekten am Beispiel eines Login c 2003, Sven Falk Seite 52

61 4.2. ENTWURFSASPEKTE KAPITEL 4. PORTIERUNG Bedienerkonzept Um eine effiziente Bedienung der Bestandskorrektur auf einem mobilen Client (PDA) zu gewährleisten, mussten grundsätzliche Überlegungen bzgl. der Ergonomie angestellt werden. Das hier erarbeitete Bedienerkonzept soll jedoch lediglich eine vorläufige Lösung dieser Porblemstellung repräsentieren. Ein vollständiges Bedienerkonzept müsste in enger Zusammenarbeit mit den späteren Benutzern der Anwendung ausgearbeitet werden. Leider reichte dafür der gegebene Zeitrahmen dieser Diplomarbeit nicht aus. Nachfolgend sind die wichtigsten Aspekte aufgelistet: 1. Verwendung eines speziellen PDAs mit Tastenfeld und Barcode-Scanner. 2. Einbindung des Scanners in die Anwendung z.b. für die Eingabe von Artikelinformationen oder Verwendung einer Code-Tabelle für häufig verwendete Befehle Einbindung des Tastenfelds keine Verwendung des Touchscreens notwendig. 4. Keine größen- und positionsveränderbare Fenster möglichst Reiterkarten verwenden Modale Dialoge Darstellung von Detailinformationen in Scrollfeldern. 7. Formatierer, die automatische Vervollständigung, z.b. bei der Datumseingabe, unterstützen. 8. Validierer, die Falscheingaben erkennen und somit nicht zulassen. 9. Bestätigungs-Widgets (Buttons) so skalieren, dass diese notfalls auch mit dem Finger bedienbar sind Benutzeroberfläche Die Gestaltung der Benutzeroberfläche war grundsätzlich durch die bestehende GUI der Bestandskorrektur innerhalb der FILIS-Anwendung vorgegeben. Diese Vorgaben wurden lediglich auf die Bedürfnisse des mobilen Gerätes angepasst und eventuell mit den Ideen des Bedienerkonzeptes in Einklang gebracht. Die Benutzeroberfläche wurde soweit möglich einheitlich in den verschiedenen Technologien AWT, SWT und Swing implementiert. Lediglich in der SWT-Version wurde das Reiterkartenprinzip umgesetzt, um diese Idee praktisch zu veranschaulichen. Um einen einfachen und reibungslosen Wechsel der GUI-Technologie zu ermöglichen, wurde gegen Ende der Diplomarbeit damit begonnen, einen sogenannten GUI-Framework zu entwickeln (siehe Kapitel 4.4). Dieser sollte dazu dienen, eine einheitliche Schnittstelle bei der Benutzeroberflächenprogrammierung bereitzustellen. Berücksichtigt wurden dabei vorerst nur Swing und SWT. Diese Entscheidung beruht darauf, dass hauptsächlich Swing und SWT für die Implementierung der Benutzeroberfläche vorgesehen waren. Die erheblichen Performanceprobleme bei der Verwendung von Spezielle Funktionen der Anwendung werden durch eine bestimmte Zeichenfolge eines Barcode repräsentiert. Das Einscannen dieses Barcodes bewirkt die Ausführung der Funktion. Die beschränkte Darstellungsfläche des PDA kann bei der Größen- bzw. Positionsveränderung des Anwendungsfensters zu Problemen führen. Es könnten z.b Fenster aus dem sichtbaren Bereich hinausgeschoben werden und somit nicht mehr zugänglich sein. Um zu verhindern, dass ein Dialog-Fenster in den Hintergrund gerät und die Anwendung blockiert. c 2003, Sven Falk Seite 53

62 4.3. IMPLEMENTIERUNG KAPITEL 4. PORTIERUNG Swing könnten allerdings dazu führen, dass AWT trotzdem zum Einsatz kommt. Die Erweiterung des GUI-Frameworks um diese Funktionalität sollte aber keine größeren Schwierigkeiten bereiten Gesamtkonzept Zusammenfassend ergab sich folgendes Gesamtkonzept der Portierung: Gesamtsystemarchitektur gemäß Abbildung 4.1 als auch gemäß Abbildung 4.2 Clientsystemarchitektur gemäß Abbildung 4.3 Benutzeroberflächen in AWT, SWT und Swing gemäß Kapitel Implementierung Vorgehensweise Bei der Umsetzung der zuvor erläuterten Konzepte konnte aufgrund der nicht abschätzbaren Probleme nicht nach üblichen Softwareentwicklungsmodellen wie z.b. dem V-Modell vorgegangen werden. Vielmehr wurde teilweise Bottom-Up und teilweise Top-Down entwickelt. Das heißt, dass wie in Kapitel 4.2 dargestellt, Grundsätzliches vor der Implementierung konzeptioniert wurde. Implementierungen fanden aber schon in der Entwurfsphase statt, um die Durchführbarkeit der Konzepte zu belegen. Diese Bottom-Up Entwicklungen wurden dann widerum unter dem Dach der vorher entwickelten Konzepte gesammelt. Die Erstellung eines Projektplanes war, aufgrund des Forschungscharakters dieser Arbeit, nicht sinnvoll. Traten Problemstellungen auf, wurden diese ausführlich untersucht, falls möglich gelöst oder anderenfalls durch Workarounds umgangen. Im weiteren Verlauf dieser Ausarbeitung werden nennenswerte Problemlösungen bzw. Workarounds dargestellt. Die folgende Auflistung zeigt die grobe Reihenfolge der abgearbeiteten Aufgaben: Implementierung des Thin-Clients und erste Tests der Login- und Logout-Funktion. Erstellen der Benutzeroberfläche in AWT und Swing Implementierung der restlichen Funktionalität der Bestandskorrektur. Anpassung der Benutzeroberfläche an das erarbeitete Bedienerkonzept. Implementierung einer Dummy -Version zu Testzwecken. Implementierung der Benutzeroberfläche mit SWT Test der Anwendung. Integrierung des Scanners in die Anwendung Abschließende Tests. c 2003, Sven Falk Seite 54

63 4.3. IMPLEMENTIERUNG KAPITEL 4. PORTIERUNG Dieses schrittweise Vorgehen war auch teilweise dadurch bedingt, dass einige Ressourcen, wie z.b. der Spezial-PDA mit integrierter Tastatur und Scanner, erst gegen Ende der Diplomarbeit zur Verfügung standen. Ein anderer Grund war, dass manche Entscheidungen, wie z.b. der Einsatz von SWT, erst spät getroffen wurden Verwendete Werkzeuge Während der Implementierungs- und Testphase wurden diverse Entwicklungswerkzeuge eingesetzt. Nachfolgend werden diese nach Kategorien gruppiert erläutert. Integrated Development Environments Für die Entwicklung von Softwarekomponenten wurden zwei Integrated Development Environments (IDE) verwendet. Im Bereich Java wurde eclipse 2.1 [13] verwendet. Vor allem zu Einarbeitungszwecken konnten die Vorteile einer IDE, wie z.b. Übersicht über Klassenmethoden, Sprung zu Methodendeklarationen usw., genutzt werden. Die Kompillierungs- und Ausführungsfunktion dieser IDE wurde allerdings nur für die Entwicklung der Dummy-Bestandskorrektur verwendet. Für die vollständige Version der Bestandskorrektur wurde Ant als Build-Tool verwendet. Ant bietet den Vorteil, dass auch Deploymentaufgaben, wie das Kopieren von Dateien oder das Erstellen von JAR-Files, unterstützt wird. Für Entwicklungen im Bereich von C bzw. C++ wurden die Microsoft embedded Visual Tools (EVT) und speziell davon Microsoft embedded Visual C / 4.0 und cygwin verwendet. Diese kamen hauptsächlich für Optimierungen bzw. Fehlerbehebungen in der Kaffe VM zum Einsatz (siehe Kapitel 3.3.1). Cygwin wurde parallel zu EVT für Crosscompiling benutzt. Build- und Compile-Tools Als Build-Tool wurde Apache Ant eingesetzt. Ant ist mit Hilfe eines Build-Skripts in der Lage, verschiedenste Aufgaben auszuführen. Diese reichen von der Kompillierung über Kopieraufgaben bis hin zur Erstellung bzw. dem Update von Java-Archives. Weiterführende Information zu Ant findet sich unter [14]. Um den Kompillierungsvorgang zu beschleunigen, wurde in manchen Fällen IBM Jikes 1.18 verwendet. Leider hat dieser Compiler die Angewohnheit, sämtliche vorgefundenen Klassen eines Verzeichnisses, anstatt nur jene durch das Build-Skript von Ant vorgegebene Klassen, zu kompillieren. Deshalb wurde Jikes nicht immer eingesetzt. Der Geschwindigkeitsvorteil von Jikes gegenüber Suns Compiler ist jedoch erheblich. Weiterführende Informationen zu Jikes findet sich unter [15]. c 2003, Sven Falk Seite 55

64 4.3. IMPLEMENTIERUNG KAPITEL 4. PORTIERUNG Java-Runtime-Umgebungen Die entstandenen Softwarekomponenten sowie das fertige Programm wurden unter verschiedenen Java-Runtime-Umgebungen getestet. Hierzu zählen: Suns JDK IBMs Websphere Micro Environment (J9) NSIComs CrEme v4.0 beta Diese VMs sind sowohl für Microsoft PocketPC 2002 als auch für Microsoft Windows 2000 erhältlich. Deshalb wurden Tests zuerst auf einem Desktop-System und anschließend auf dem PDA durchgeführt. Dabei traten Unterschiede sowohl zwischen den verschiedenen VMs als auch bei gleichen VMs auf den verschiedenen Betriebssystemen auf. Eine genauere Betrachtung der oben aufgeführten VMs fand bereits unter Kapitel statt. Test-Tools Wie bereits an anderer Stelle erwähnt, traten bei der Kommunikation unter den verteilten Anwendungsteilen nicht vertretbare Verzögerungen auf. Diese Kommunikation wurde mit einem Sniffing- Tool abgehört, um so Rückschlüsse auf die Ursachen dieser Zeitverluste ziehen zu können. Hierzu wurde Ethereal verwendet. Weiterführende Informationen zu Ethereal findet sich unter [16] Performancetests Benutzeroberfläche Bei genauerer Untersuchung der beiden Technologien AWT und SWT ergaben sich, wie erwartet, keine Performanceprobleme. Bezüglich Swing sieht die Situation jedoch anders aus. Dies wurde im Rahmen einer kleinen Testanwendung festgestellt. Diese verfügte über häufig verwendete GUI- Komponenten wie z.b. Textfelder, Trees, Buttons, Schieberegler etc.. Bei der Ausführung der Anwendung unter Verwendung der CrEme VM stellte sich heraus, dass die Swing-Komponenten zwar richig gezeichnet wurden, jedoch im Verhalten sehr träge wirkten. Hinzu kam, dass die Anwendung mitunter ins Stocken geriet und kurzzeitig nicht bedienbar war. Leider konnten keine Versuche mit anderen VMs durchgeführt werden, da diese Swing noch nicht unterstützen. Es ist aber anzunehmen, dass die Performance-Probleme auch dort anzutreffen sind. Aufgrund dieser Erkenntnisse schied Swing vorerst als Alternativ-Technologie für die Entwicklung der Benutzeroberfläche aus. Eine Untersuchung ob die neuen XSCALE-PDAs in Verbindung mit XSCALE-optimierten Betriebssystemen hier eine Verbesserung bringen, konnte aufgrund von fehlender Hard- und Software nicht durchgeführt werden. Diversen Testberichten im Internet zufolge kann aber davon ausgegangen werden, dass die Beschleunigung von Swing durch XSCALE eher gering ausfallen wird. c 2003, Sven Falk Seite 56

65 4.3. IMPLEMENTIERUNG KAPITEL 4. PORTIERUNG Verteilte Kommunikation Nach der Fertigstellung der ersten Prototypen zeigte sich schnell, dass beim Zugriff auf entfernte Ressourcen erhebliche Zeitverluste zustande kamen. So benötigte ein entfernter Aufruf über die Desktop-Emulatoren deutlich weniger als eine halbe Sekunde, während auf dem PDA für die gleiche Aktion mitunter fast zwei Sekunden benötigt wurden (siehe Tabelle 4.1). Erste Vermutungen ließen darauf schließen, dass diese Verzögerungen durch RMI zustande kamen. Deshalb wurde eine genauere Untersuchung der RMI-Kommunikation unternommen. Aufruf Desktop Desktop PDA Desktop startup ca. 30s login ca. 1,6s ca. 15s search ca. 0,3s 1,5s bis 2s Tabelle 4.1: FILIS-Performance-Messung Zur Messung der Zeitverzögerungen wurde ein RMI-Testprogramm entwickelt, bei dem ein einfacher Methodenaufruf durchgeführt wird. Dieser liefert die Systemzeit des RMI-Servers zurück. Zwei Arten von Messungen wurden durchgeführt: 1. Messung der Verzögerungen zwischen zwei Desktop-Systemen 2. Messung der Verzögerungen zwischen einem PDA und einem Desktop-System Tabelle 4.2 zeigt die daraus resultierenden Messergebnisse. Aufruf-Nr. Desktop Desktop PDA Desktop 1 ca. 500ms 1000ms bis 2000ms n ca. 25ms 60ms bis 70ms Tabelle 4.2: RMI-Performance-Messung Diese Messergebnisse zeigten, dass die Unterschiede in RMI zwischen Desktop-System und PDA nicht allzu gravierend sind. Der Grund für die Verzögerungen war also an anderer Stelle zu suchen. Als nächste Verlustquelle kam der in FILIS eingesetzte Kommunikationsserver in Frage. Wie bereits an anderer Stelle erwähnt waren für diesen keine Sourcen vorhanden, weshalb die vorliegenden Binaries dekompiliert wurden. Die anschließende Untersuchung dieser so erzeugten Sourcen zeigte Problemstellen auf, die sich auf einem Desktopsystem kaum bemerkbar machen, auf einem leistungsbeschränkten Gerät, wie einem PDA, aber durchaus Probleme bereiten können. Als erste vermutete Verzögerungsquelle wurde die Art der Anfrage-Bearbeitung des Kommunikationsservers identifiziert. Bei dieser Anfrage-Bearbeitung werden ankommende Anfragen in Request- Objekte verpackt. Diese werden in Spezialfällen ebenfalls wieder in Requests eingebettet. So entstehen verschachtelte Requests, die an den Kommunikationsserver auf dem Middle-Tier weitergeleitet werden. c 2003, Sven Falk Seite 57

66 4.3. IMPLEMENTIERUNG KAPITEL 4. PORTIERUNG Es können zwei Arten von Requests generiert werden: 1. Einzelanfragen 5 2. Sammelanfragen 6 Um die Vermutungen zu bestätigen bzw. zu widerlegen wurde widerum eine einfache Testapplikation entwickelt, welche zum einen 100 Einzelrequests und zum anderen 100 gekapselte Requests an den Kommunikationsserver absetzt. Dabei wurden die in Tabelle 4.3 dargestellten Verzögerungen gemessen. Aufruf Desktop Desktop PDA Desktop start ca. 0,4s ca. 6,5s 100 einzel ca. 1s ca. 20s 100 gekapselt ca. 1,3s ca. 1,7s Tabelle 4.3: Kommunikationsserver-Performance-Messung Die zuvor getroffene Vermutung wurde durch diese Messergebnisse bestätigt. Die verschachtelte Erzeugung der Einzelrequests summiert sich auf dem PDA zu nicht vertretbaren Verzögerungen auf. Eine Kapselung der Aufrufe ist aber aufgrund der mitunter benötigten Zwischenergebnisse nicht möglich. Bei der oben aufgezeigten Untersuchung wurde noch eine weitere Quelle von Verzögerungen im Kommunikationsserver aufgedeckt. Die zuvor beschriebenen Requests werden an einen sogenannten ServiceDispatcher gestellt. Dieser befindet sich auf dem Middle-Tier und wird vor jedem Request erneut über RMI angefordert. Dies ist dann sinnvoll, wenn sich meherer Middle-Tier-Server im Einsatz befinden und aus Skalierungsgründen eventuell zwischen diesen hin und her geschaltet wird. Ist aber nur ein Middle-Tier-Server im Einsatz, dann erzeugt dies einen nicht unerheblichen Overhead an Kommunikation. Dieser ist auf einem Desktop-System aufgrund der geringen Verzögerungszeiten vernachlässigbar, macht sich aber auf einem PDA durchaus bemerkbar. Lösbar ist dieses Problem durch eine temporäre Zwischenspeicherung der ServiceDispatcher-Instanz. Ändern sich Anfrageparameter wie z.b. die Serveradresse, muss diese Kopie natürlich aktualisiert werden. Diese Optimierung wurde durch Modifikation der dekompilierten Kommunikationsserver-Klassen implementiert und erfolgreich getestet. Leider kann diese Optimierung nicht real eingesetzt werden, weil dadurch Lizenzrechte verletzt würden. Die Verzögerungen in der Kommunikation zwischen den verteilten Komponenten konnten also durch die zuvor beschriebenen Tests aufgeklärt werden. Durch den Einsatz, der entwickelten RMI-Architektur, können diese Probleme beseitigt werden. Allerdings bringt dies auch einen größeren Entwicklungsaufwand mit sich. Die extrem lange Startup-Zeit kann so aber nicht begründet werden. Weitere Tests zeigten, dass die Verzögerung beim Startup der Anwendung hauptsächlich durch das Laden der Resource-Bundles 7 erzeugt wurden. Leider konnte diese Themenstellung aus Zeitgründen nicht mehr näher untersucht werden Diese Methodik kommt bei FILIS zum Einsatz. Mehrere Anfragen werden in einem Vector gekapselt und als Anfragenbündel übertragen. Resource-Bundles werden dazu verwendet Ressourcen wie z.b. Label-Beschriftungen zentral abzulegen und somit eine Hart-Kodierung im Quellcode zu vermeiden. Natürlich werden Aspekte wie z.b. Internationalisierung durch Resource-Bundles ebenfalls vereinfacht. c 2003, Sven Falk Seite 58

67 4.3. IMPLEMENTIERUNG KAPITEL 4. PORTIERUNG Abbildung 4.5: Konzept für Scroll-Texte Spezielle Entwicklungen Bei vielen der während dieser Ausarbeitung entwickelten Softwarekomponenten handelt es sich um Standard-Implementierungen, die nicht näher betrachtet werden müssen. Spezielle Entwicklungen, die sich aus den besonderen Anforderungen der Bestandskorrektur ergaben, werden hier jedoch kurz erläutert. Scrolltexte Wie in den Anforderungen unter Kapitel 4.2 beschrieben, sollten Detail-Informationen zu den Artikeln möglichst effizient dargestellt werden. Hierzu eignet sich besonders das Konzept von Scrolltexten. Da es in den GUI-Technologien AWT, SWT und Swing keine Komponenten gibt, die das Scrollen automatisch durchführen, wurde in jeder Technologie eine entsprechende Komponente entwickelt. Allen diesen Scroll-Komponenten liegt dasselbe Konzept zugrunde. Alle zur Verfügung stehenden GUI-Technologien stellen eine scrollbare Komponente bereit, welche dazu benutzt wird, die zu scrollende Komponente aufzunehmen. Um Ungleichheiten von Seitenrändern oder ungerader Anzahl von Wörtern bzw. Buchstaben auszugleichen, ist die Text-Komponente zwei mal vorhanden (siehe Abbildung 4.5). Diese beiden Text-Komponenten werden in einen Container eingebettet, der die zu scrollende Komponente darstellt. Gescrollt wird dann jeweils bis zur Hälfte dieses Containers. Damit ist die erste Text-Komponente komplett aus dem Sichtbarkeitsbereich verschwunden und die zweite Text-Komponente befindet sich genau dort, wo sich die erste Text-Komponente beim Scroll-Beginn befand. Ist dieser Punkt erreicht, wird der Container in den Ursprung zurückgesetzt. Damit befindet sich die Scroll-Komponente wieder im Anfangszustand und der Scroll-Vorgang beginnt von vorne. Um den Zeichenkontext der Anwendung nicht zu blockieren, wird ein separater Thread gestartet, welcher die eigentliche Aufgabe, das Scrollen, durchführt. Dies geschieht durch die zuvor beschriebene kontinuierliche Positionsänderung des Containers. IBMs AWT-Implementierung verwendet für das Scrollable ein anderes Modell als Sun. Eine scrollbare Komponente besitzt normalerweise Scrollbars, mit denen die Position der zu scrollenden Komponente verändert werden kann. Bei einem Scroll-Text sollten diese Scrollbars aber nicht sichtbar c 2003, Sven Falk Seite 59

68 4.3. IMPLEMENTIERUNG KAPITEL 4. PORTIERUNG sein. Während dies bei AWT und Swing unter Verwendung von CrEme bzw. Suns VM kein Problem darstellt, treten bei Verwendung von AWT mit IBMs Websphere Microenvironment Probleme auf. In dieser AWT-Implementierung ist es nicht vorgesehen, dass ein Scrollable gescrollt werden kann, wenn keine Scrollbars sichtbar sind. Genauer betrachtet ist der Vorgang des Scrollens vom Vorhandensein der Scrollbars abhängig. Werden diese aber in der entsprechenden AWT-Komponente unsichtbar gemacht, werden die Scrollbars nicht erzeugt bzw. gelöscht. Folglich ist auch der Vorgang des Scrollens nicht mehr durchführbar. Um einen Scroll-Text auch unter der IBM Websphere Microenvironment verwenden zu können, war es also notwendig, deren AWT-Implementierung dahingehend zu ändern, dass Scrollbars immer vorhanden sind, aber nicht immer angezeigt werden. Hierzu wurde die Klasse java.awt.scrollpane entsprechend modifiziert. Nach der Durchführung dieser Modifikation war auch unter IBMs Websphere Microenvironment das Scrollen von Texten möglich. Dummy-Version Für Präsentations- und Testzwecke war es sinnvoll, eine Dummy-Version der Bestandskorrektur zu entwickeln, welche unabhängig von einem Applikationsserver ausführbar ist. Daten, die normalerweise vom Applikationsserver gelierfert werden, sind bei dieser Version in Dateien abgelegt. Dem Bediener der Anwendung wird also eine bestehende Server-Verbindung vorgetäuscht. Alle anderen Funktionen der Bestandskorrektur bleiben von dieser Änderung jedoch unbeeinflusst. Einbindung des Scanners Gegen Ende der Diplomarbeit war der Spezial-PDA mit integriertem Barcode-Scanner verfügbar. Dieser Scanner kann beliebige Barcode-Folgen identifizieren und löst nach der Validierung des Codes für die einzelnen Zeichen Keyboard-Events aus. Über die Konfigurationssoftware kann der Scanner so konfiguriert werden, dass er ein Pre- 8 und ein Postfix 9 sendet. Die Werte des Pre- oder Postfix sind in der Konfigurationssoftware definierbar. Sie dürfen bis zu zwanzig Zeichen lang sein. Für jedes Zeichen wird ein Keyboard-Event ausgelöst. Da die vom Scanner ausgelösten Keyboard-Events nicht von denen der Tastatur unterscheidbar sind, kann die Zeichenfolge des Pre- und des Postfix dazu verwendet werden, den Anfang und das Ende der eingescannten Zeichenfolge zu erkennen. Ein gut gewähltes Muster für das Pre- und das Postfix verhindert, dass der Bediener durch Eingabe der erwarteten Zeichenfolge einen Scannvorgang unbeabsichtig simuliert. Um die Scann-Events noch mehr von den Tastatur-Events abzugrenzen, kann zusätzlich mit einem Timeout gearbeitet werden. Der Barcode-Scanner löst die Keyboard-Events in der Regel schneller aus, als dies über die Tastatur möglich ist. Wird nun das Muster des Prefix durch die Software erkannt, startet ein Timer. Erkennt die Software vor Ablauf dieses Timers das Muster des Postfix, wird angenommen, dass die ausgelösten Events vom Scanner stammten und eine spezielle Routine zur Bearbeitung des Scann-Events wird gestartet. Läuft der Timer ab, bevor das Postfix-Muster erkannt wurde, ist entweder der Scannvorgang fehlgeschlagen oder das Prefix-Muster wurde unbeabsichtigt über die Tastatur eingegeben. In beiden Fällen wird angenommen, dass kein Scann-Vorgang stattfand und die Eingabe wird normal behandelt bzw. verworfen. Solange man über die Möglichkeit verfügt, Keyboard-Events zentral abzufangen und zu bearbeiten, kann nach der zuvor beschriebenen Strategie vorgegangen werden. AWT bietet für die zentrale Abarbeitung von Events die Klasse java.awt.eventqueue. Eine selbst entworfene Klasse, die von 8 9 Das Prefix wird vor der eingescannten Zeichenfolge gesendet. Das Postfix wird nach der eingescannten Zeichenfolge gesendet. c 2003, Sven Falk Seite 60

69 4.3. IMPLEMENTIERUNG KAPITEL 4. PORTIERUNG EventQueue erbt, kann somit den zentralen Event-Verarbeitungsmechanismus überladen, um die oben beschriebenen Spezialfälle abzufangen. Die im java.awt.toolkit vorhandene Standard-EventQueue muss durch die abgeleitete Klasse ersetzt werden. Damit ist gewährleistet, dass Keyboard-Events, die vom Scanner stammen, speziell behandelt werden und nicht zur Anwendung durchdringen. Das Problem, das besteht, wenn man keine zentrale Stelle hat, in der die Keyboard-Events des Scanners abgefangen werden können, wird nachfolgend beschrieben: 1. Jede GUI-Komponente, die in der Lage ist, Keyboard-Events zu verarbeiten, erhält automatisch einen Listener, der auf diese Events reagiert Der Scanner scannt einen gültigen Barcode ein und löst dementsprechend die Prefix-Keyboard- Events, die Keyboard-Events der eingelesenen Zeichenfolge und die Postfix-Keyboard-Events aus. 3. Da diese Events nicht zentral ausgefiltert werden, gelangen sie an jene GUI-Komponente die gerade den Focus besitzt. 11 Suns AWT-Implementierung ermöglicht die zentrale Behandlung von Events. Wie dies geschieht, wurde zuvor bereits beschrieben. IBMs AWT-Implementierung basiert jedoch auf dem Event-Modell von SWT, und SWT basiert widerum auf dem nativen Event-Modell. In diesen Modellen ist eine zentrale Behandlung von Events nicht vorgesehen, obwohl IBM die Klasse EventQueue, die für die zentrale Event-Behandlung vorgesehen ist, zur Verfügung stellt. In SWT besteht also das vorher beschriebene Problem bei der Auswertung von Pre- bzw. Postfixes. Leider konnte IBM diesbezüglich während dieser Ausarbeitung nicht mehr kontaktiert werden. Es ist aber möglich, dass die ohnehin unvollständige AWT-Implementierung in dieser Hinsicht noch korrigiert wird. Eine Alternative zur zentralen Behandlung von Keyboard-Events bestünde darin, an allen Komponenten, welche Keyboard-Events behandeln, spezielle Listener zu registrieren, welche die spezielle Behandlung beim Auftreten des Pre- bzw. Postfix übernehmen. Diese verteilten Listener sind aber eher unpraktikabel, da sie einen erheblichen Programmieraufwand darstellen und immer darauf geachtet werden muss, dass keine Komponente vergessen wurde. Eine bessere Lösung wäre eine native Anwendung, die sich in die native Event-Behandlung einhängt und die speziellen Scanner-Keyboard- Events abfängt, bevor diese zur VM durchdringen. Die Bestandskorrektur müsste dann natürlich mit dieser Anwendung kommunizieren, um von erfolgreichen Scann-Vorgängen informiert zu werden Es ist zwar möglich, weitere Listener hinzuzufügen, das Entfernen von Listenern ist aber nur möglich, wenn der entsprechende Listener bekannt ist. Der automatisch hinzugefügte Listener ist jedoch unbekannt. Ist dies z.b. ein Textfeld, so wird die empfangene Zeichenfolge als Text angezeigt. In diesem Fall wären das das Prefix, die eingescannte Zeichenfolge und das Postfix. Um das zu verhindern sollte eine native Komponente entwickelt werden, welche das Pre- und das Postfix erkennt, diese Events ausfiltert und gesondert behandelt. c 2003, Sven Falk Seite 61

70 4.3. IMPLEMENTIERUNG KAPITEL 4. PORTIERUNG Offene Problemstellungen Zusammenfassend werden hier offene Problemstellungen aufgezeigt: Aspekte in Verbindung mit IBM Websphere Microenvironment Fehlerhafte AWT-Implentierung Fehlerhaftes Verhalten beim Schließen von AWT-Dialogen 12 Fehlerhafte Umsetzung des AWT-Event-Handling Ungeignetes Verhalten des SWT-Event-Handling Entwicklung eines Workaround 13 Ausarbeitung von Optimierungen bzgl. verteilter Kommunikation Ausarbeitung einer allgemeinen Lösung für das Scanner-Problem Verfeinerung des Bedienerkonzeptes Minimierung des Konfigurationsaufwandes der mobilen Clients. 14 Untersuchung der Performanceverbesserungen bei Verwendung von Intel XSCALE Prozessoren und den entsprechend optimierten Betriebssystemen. Untersuchung der Jeode VM [17] als Alternative zu IBM WME und NSICom CrEme Wird ein AWT-Dialog geschlossen, so wird nicht sein Vater-Fenster, sondern genau das Fenster hinter dem Vaterfenster in den Vordergrund gebracht. Dieses Verhalten lässt auf eine fehlerhafte Implementierung von AWT schließen und muss somit von IBM behoben werden. Problem der dezentralen Behandlung von Events. Z.B. Entwicklung einer Methodik, mit welcher der Client-Teil der Anwendung in der Lage ist, einen Applikatoins- Server automatisch aufzufinden. c 2003, Sven Falk Seite 62

71 4.4. ZUSÄTZLICHE ENTWICKLUNGEN KAPITEL 4. PORTIERUNG 4.4 Zusätzliche Entwicklungen Motivation Während der Entwicklung der verschiedenen Benutzeroberflächen kam die Idee auf, ein Framwork zu entwickeln, das eine einheitliche Schnittstelle zur Erstellung von Benutzeroberflächen bietet. Die beiden konkurrierenden Technologien, SWT und Swing sollten in dieses Framework integriert werden. Es ist aber möglich, weitere Technologien, wie z.b. AWT, in den Framework einzubeziehen. In Abbildung 4.6 ist das Klassendiagramm auf abstrakter Ebene grafisch dargestellt Verwendete Entwurfs-Muster Es wurden drei Entwurfs-Muster verwendet: 1. Brücke 2. Kompositum 3. Abstrakte Fabrik Das Brücken-Muster wird an verschiedenen Stellen eingesetzt. Zum einen beim Interface ComponentInterface, und zum anderen beim TextComponentInterface. Es dient zur Abstrahierung gemeinsamer Methoden von unterschiedlichen Implementierungen. Dies gewährleistet, dass eine einheitliche API für die Generierung der Benutzeroberfläche vorhanden ist, unabhängig davon, welche Technologie für die konkreten Komponenten verwendet wird. Das Kompositum-Muster kommt bei der Container-Klasse zum Einsatz. Die Unterscheidung zwischen SimpleComponent und Container besteht wegen den unterschiedlichen Konzepten in Swing und SWT. In Swing erbt nahezu jede UI-Komponente von der Klasse java.awt.container und kann somit weitere Komponenten aufnehmen. In SWT wird zwischen Kontainern und flachen Komponenten unterschieden. Um zu beiden Technologien kompatibel zu sein, mussten also beide Ansätze berücksichtigt werden. Das Muster Abstrakte Fabrik wurde eingesetzt, um nicht direkt mit der API, welche die GUI-Komponenten erzeugt, arbeiten zu müssen. Für die verschiedenen Technologien werden konkrete Fabriken entwickelt, welche für die Erzeugung der GUI-Komponenten verantwortlich sind. Dadurch wird erreicht, dass durch die Umschaltung eines Parameters, die gesamte Oberfläche mit einer anderen Technologie erzeugt wird. c 2003, Sven Falk Seite 63

72 4.4. ZUSÄTZLICHE ENTWICKLUNGEN KAPITEL 4. PORTIERUNG Abbildung 4.6: Klassendiagramm des GUI-Frameworks c 2003, Sven Falk Seite 64

73 4.4. ZUSÄTZLICHE ENTWICKLUNGEN KAPITEL 4. PORTIERUNG Beispiel Folgendes Code-Listing zeigt eine einfache GUI unter Verwendung des vorläufigen Frameworks. public class SWTTest { public static long millis; public SWTTest() { super(); } public static void main(string[] args) { millis = System.currentTimeMillis(); //GFSwingFactory factory = new GFSwingFactory(); // konkrete Fabrik GFSWTFactory factory = new GFSWTFactory(); // konkrete Fabrik Frame frame = factory.createframe(); // dargestellter Frame Container filemenu; //File-Menue Container helpmenu; //Help-Menue ComponentInterface logoutitem; // logout-item des File-Menue ComponentInterface exititem; // exit-item des File-Menue GridLayout layout = factory.creategridlayout(); // Layout des Frames ContainerInterface contentcontainer = factory.createcontainer(); // Wurzel-Container des Frames final TextComponentInterface textfield = factory.createtextfield(); // linkes Textfeld final TextComponentInterface textfield2 = factory.createtextfield();// rechtes Textfeld ComponentInterface abutton = factory.createpushbutton(); // doit-button layout.setnumberofcolumns(2); contentcontainer.setlayout(layout);//todo contentcontainer.addcomponent(textfield); contentcontainer.addcomponent(textfield2); contentcontainer.addcomponent(abutton); abutton.setname("modify"); abutton.getlayoutdata().sethorizontalspan(2); abutton.getlayoutdata().setverticalspan(1); abutton.getlayoutdata().sethorizontalalignment(gridlayoutdata.center); abutton.getlayoutdata().setwidthhint(100); abutton.getlayoutdata().setheighthint(20); abutton.getlayoutdata().sethorizontalfill(gridlayoutdata.horizontal); textfield.getlayoutdata().sethorizontalalignment(gridlayoutdata.west); textfield.getlayoutdata().setwidthhint(60); textfield.getlayoutdata().setheighthint(20); textfield.getlayoutdata().sethorizontalspan(1); c 2003, Sven Falk Seite 65

74 4.4. ZUSÄTZLICHE ENTWICKLUNGEN KAPITEL 4. PORTIERUNG textfield.getlayoutdata().setverticalspan(1); textfield2.getlayoutdata().sethorizontalspan(1); textfield2.getlayoutdata().setverticalspan(1); textfield2.getlayoutdata().setwidthhint(60); textfield2.getlayoutdata().sethorizontalalignment(gridlayoutdata.west); textfield2.getlayoutdata().setheighthint(20); filemenu = frame.addmenutomenubar("file"); helpmenu = frame.addmenutomenubar("?"); logoutitem = frame.addmenuitemtomenu("logout", filemenu); logoutitem.addselectionlistener(factory.createselectionlistener( new Customizable(){ public Object execute(object obj){ Object result = null; System.out.println("logout1"); return result; } } )); logoutitem.addselectionlistener(factory.createselectionlistener( new Customizable(){ public Object execute(object obj){ Object result = null; System.out.println("logout2"); return result; } } )); exititem = frame.addmenuitemtomenu("exit", filemenu); exititem.addselectionlistener(factory.createselectionlistener( new Customizable(){ public Object execute(object obj){ Object result = null; System.exit(0); return result; } } )); abutton.addselectionlistener(factory.createselectionlistener( new Customizable(){ public Object execute(object obj){ Object result = null; textfield2.settext(textfield.gettext()); return result; } } )); } } frame.setsize(240, 320); //frame.setshellstyle(frame.no_trim); frame.setcontentcontainer(contentcontainer); frame.createmenubar(); frame.createcomponent(); frame.showcomponent(); frame.disposecomponent(); c 2003, Sven Falk Seite 66

75 4.4. ZUSÄTZLICHE ENTWICKLUNGEN KAPITEL 4. PORTIERUNG Abbildung 4.7: Mit dem GUI-Framework erzeugte SWT-Oberfläche Diese Klasse erzeugt eine SWT-GUI, wie sie in Abbildung 4.7 dargestellt ist. Wird die dritte Zeile der main-methode einkommentiert und die vierte Zeile auskommentiert, wird eine Swing-GUI, wie sie Abbildung 4.8 zeigt, dargestellt. Die Änderung einer Zeile im Code bewirkt also die komplette Umschaltung von SWT auf Swing. Die unterschiedliche vertikale Anordnung der Komponenten basiert auf unterschiedlichem Default -Verhalten von SWT und Swing. Defaultmäßig zentriert Swing die Komponenten vertikal, während SWT die Komponenten vertikal unverändert lässt. Hier zeigt sich auch das unvollständige Stadium dieses Frameworks. Ausserdem müssen gewisse Einschränkungen bezüglich des Funktionalitätsumfanges der GUI in Kauf genommen werden. So können nur Features im GUI-Framework enthalten sein, die in jeder Technologie, die unterstützt werden soll, vorhanden sind. Spezial-Funktionen, die nur in einer Technologie vorkommen, können also nicht genutzt werden. Für normale Anwendungen dürfte dies aber kein Problem darstellen, da SWT und Swing viele Gemeinsamkeiten aufweisen. c 2003, Sven Falk Seite 67

76 4.4. ZUSÄTZLICHE ENTWICKLUNGEN KAPITEL 4. PORTIERUNG Abbildung 4.8: Mit dem GUI-Framework erzeugte Swing-Oberfläche c 2003, Sven Falk Seite 68

77 Kapitel 5 Ergebnisse 69

78 KAPITEL 5. ERGEBNISSE Das primäre Ziel, die Ausarbeitung einer Portierungsstrategie, wurde erreicht. In der Ausarbeitung wurde dargestellt, welche Alternativen hierzu bestehen und woraus sich Vor- bzw. Nachteile ergeben. Prinzipiell sind zwei grundsätzliche Alternativen möglich: 1. Die Portierung nach J2ME in Verbindung mit den entsprechenden Aufwänden. 2. Den Einsatz von vollwertigen Java Virtual Machines mit eventuellen Leistungseinbußen. Beide Alternativen sind unter verschiedenen Betriebssystemen realisierbar. Zukünftige Weiterentwicklungen, wie z.b. neue Prozessorarchitekturen und die daraus resultierende Leistungssteigerung der mobilen Geräte, müssen natürlich im Entscheidungsprozess berücksichtigt werden. Um die Durchführbarkeit der Portierungsstrategien auch praktisch zu belegen, wurde die Bestandskorrektur portiert. Im Bereich der Benutzeroberfläche sowie der Anbindung des Barcode-Scanners ist noch Entwicklungspotential vorhanden. Dabei steht der Austausch von Quick and Dirty -Lösungen, wie bereits in Kapitel beschrieben, im Vordergrund. Die Bestandskorrektur im jetzigen Stadium wird vorraussichtlich nur zu Test- und Evaluationszwecken verwendet. Für den Rollout wird ein Redesign plus Integration neuer Funktionalität angestrebt. Die gestellten Aufgaben konnten teilweise umgesetzt werden. Die Einarbeitung in FILIS und den darin enthaltenen Kommunikationsserver ging reibungslos vonstatten. Die ausgearbeiteten Systemarchitekturen werden so nicht zum Einsatz kommen, da hier die Anforderungen der Filiadata GmbH miteinfließen müssen. Sie stellen jedoch die Grundlage für das Redesign der Anwendung dar. Das erarbeitete Bedienerkonzept muss noch verfeinert werden. Die Erstellung eines endgültigen Bedienerkonzeptes war im gegebenen Zeitrahmen nicht möglich. Die Benutzeroberflächen wurden in AWT (siehe Abbildung 5.1 und 5.2), SWT (siehe Abbildung 5.3 und 5.4) und zu Testzwecken auch in Swing (siehe Abbildung 5.5 und 5.6) umgesetzt. Mit Ausnahme der nativen Scanner-Anbindung wurden sämtliche ausgearbeiteten Konzepte implementiert und getestet. Zusätzlich zu den gegebenen Aufgabenstellungen wurde mit der Entwicklung eines Frameworks (siehe Kapitel 4.4) begonnen, welcher es erlaubt, Benutzeroberflächen unabhängig von der darunterliegenden Technologie zu entwickeln. Teilfunktionen davon konnten noch während der Diplomarbeit getestet werden. Allerdings besteht bis zur Fertigstellung noch erheblicher Entwicklungsaufwand. Die Tests während dieser Ausarbeitung konzentrierten sich hauptsächlich auf entwickelte Teilkomponenten. So wurde die Scrolltext-Komponente, die RMI-Funktionalität, die Barcode-Scanner-Anbindung und, obwohl nicht fertig entwickelt, der GUI-Framework ausführlicher getestet. Ein detailierter Test der Bestandskorrektur fand nicht statt. Es war von vornherein klar, dass keine Rollout-Version der Bestandskorrektur entwickelt werden sollte. Sie diente lediglich dazu, die gewonnenen theoretischen Erkenntnisse zu belegen. c 2003, Sven Falk Seite 70

79 KAPITEL 5. ERGEBNISSE Abbildung 5.1: AWT-Implementierung der Login-GUI Abbildung 5.2: AWT-Implementierung der Bestandskorrektur-GUI c 2003, Sven Falk Seite 71

80 KAPITEL 5. ERGEBNISSE Abbildung 5.3: SWT-Implementierung der Login-GUI Abbildung 5.4: SWT-Implementierung der Bestandskorrektur-GUI c 2003, Sven Falk Seite 72

81 KAPITEL 5. ERGEBNISSE Abbildung 5.5: Swing-Implementierung der Login-GUI Abbildung 5.6: Swing-Implementierung der Bestandskorrektur-GUI c 2003, Sven Falk Seite 73