Design und Implementierung einer mobilen, Workflow

Fachhochschule Wiesbaden
Fachbereich Design Informatik Medien
Studiengang Allgemeine Informatik
Diplomarbeit
zur Erlangung des akademischen Grades
Diplom-Informatiker/in (FH)
Design und Implementierung einer mobilen,
Workflow-orientierten BlackBerry-Anwendung für
den Zugriff auf ein SAP-System
vorgelegt von Alexander Opatz
am 28. Februar 2007
Referent: Prof. Dr. R. Kröger
Korreferent: Dipl.-Ing. Dipl.-Kfm. T. Schneider
II
Erklärung
Ich versichere, dass ich die Diplomarbeit selbstständig verfasst und keine anderen als die
angegebenen Hilfsmittel benutzt habe.
Wiesbaden, 28.02.2007
Alexander Opatz
Hiermit erkläre ich mein Einverständnis mit den im Folgenden aufgeführten Verbreitungsformen dieser Diplomarbeit:
Verbreitungsform
Einstellung der Arbeit in die
Bibliothek der FHW
Veröffentlichung des Titels der
Arbeit im Internet
Veröffentlichung der Arbeit im
Internet
Wiesbaden, 28.02.2007
ja
nein
√
√
√
Alexander Opatz
III
IV
Inhaltsverzeichnis
1
Einleitung
1
2
Grundlagen
5
2.1
Die BlackBerry-Architektur . . . . . . . . . . . . . . . . . . . . . . . .
5
2.1.1
BES - BlackBerry Enterprise Server . . . . . . . . . . . . . . . .
6
2.1.2
BB-MDS-Studio . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.1.3
BB-Handheld . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.1.4
RIM Push-Technologie . . . . . . . . . . . . . . . . . . . . . . .
11
Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.2.1
WSDL - Web Services Description Language . . . . . . . . . . .
12
2.2.2
SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
SAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.3.1
SAP-CRM 4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
2.3.2
SAP-XI - eXchange Infrastructure . . . . . . . . . . . . . . . . .
20
J2ME - Java 2 Platform Micro Edition . . . . . . . . . . . . . . . . . . .
23
2.4.1
Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
2.4.2
Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
2.4.2.1
MIDlet Suite . . . . . . . . . . . . . . . . . . . . . . .
24
2.4.2.2
OTA Provisioning . . . . . . . . . . . . . . . . . . . .
26
Programmierung . . . . . . . . . . . . . . . . . . . . . . . . . .
26
2.4.3.1
Lebenszyklus . . . . . . . . . . . . . . . . . . . . . .
26
2.4.3.2
PushRegistry . . . . . . . . . . . . . . . . . . . . . . .
28
2.4.3.3
Graphische Benutzerschnittstelle . . . . . . . . . . . .
28
2.4.3.4
RMS - Persistente Speicherung . . . . . . . . . . . . .
31
2.4.3.5
kSOAP Web-Service-Bibliothek . . . . . . . . . . . .
33
2.4.3.6
Optimierungen für mobile Anwendungen . . . . . . . .
35
Sicherheitskonzept . . . . . . . . . . . . . . . . . . . . . . . . .
37
2.2
2.3
2.4
2.4.3
2.4.4
V
3
Analyse
39
3.1
Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
3.1.1
Rahmenbedingungen . . . . . . . . . . . . . . . . . . . . . . . .
39
3.1.2
Anwendungsfälle . . . . . . . . . . . . . . . . . . . . . . . . . .
41
3.1.2.1
Server-initiiert . . . . . . . . . . . . . . . . . . . . . .
41
3.1.2.2
Client-initiiert . . . . . . . . . . . . . . . . . . . . . .
42
Problembereiche . . . . . . . . . . . . . . . . . . . . . . . . . .
43
Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
3.2.1
SAP-CRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
3.2.2
Datenmodellierung . . . . . . . . . . . . . . . . . . . . . . . . .
44
3.2.3
Web Service zum SAP-CRM-System . . . . . . . . . . . . . . .
45
3.3
Mobile Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
3.4
Mobile Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
3.4.1
Kommunikation mit dem Web Service . . . . . . . . . . . . . . .
49
3.4.1.1
JSR 172 - Web-Service-API für J2ME . . . . . . . . .
50
3.4.1.2
REST-Web-Services . . . . . . . . . . . . . . . . . . .
51
3.4.1.3
Voranalysen . . . . . . . . . . . . . . . . . . . . . . .
52
3.4.1.4
Evaluierung . . . . . . . . . . . . . . . . . . . . . . .
54
3.4.2
Synchronisation und Offline-Modus . . . . . . . . . . . . . . . .
55
3.4.3
Usability der mobilen Anwendung . . . . . . . . . . . . . . . . .
61
3.4.4
Logging und Unit-Tests . . . . . . . . . . . . . . . . . . . . . .
63
3.1.3
3.2
4
Design
65
4.1
Architekturüberblick . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
4.2
mobileCRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
4.2.1
Allgemeine Design-Prinzipien . . . . . . . . . . . . . . . . . . .
67
4.2.2
Benutzerschnittstelle . . . . . . . . . . . . . . . . . . . . . . . .
68
4.2.3
Model und Backend-Zugriffe . . . . . . . . . . . . . . . . . . . .
72
4.2.4
Abbildung der Anwendungsfälle . . . . . . . . . . . . . . . . . .
75
4.2.4.1
Server-initiiert . . . . . . . . . . . . . . . . . . . . . .
75
4.2.4.2
Client-initiiert . . . . . . . . . . . . . . . . . . . . . .
76
Integrationsszenarien in SAP-XI . . . . . . . . . . . . . . . . . . . . . .
83
4.3
VI
5
Implementierung
89
5.1
Entwicklungswerkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . .
89
5.2
SOAP-Parsing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
5.3
RMS-Schnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
92
5.4
Multi-Threading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
94
5.4.1
Worker-Thread . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
5.4.2
Push-Thread . . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
5.5
Logging und Internationalisierung . . . . . . . . . . . . . . . . . . . . .
98
5.6
Workarounds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.7
5.6.1
javax.microedition.midlet.MIDlet . . . . . . . . . . . . . . . . . 100
5.6.2
javax.microedition.lcdui.Gauge . . . . . . . . . . . . . . . . . . 101
5.6.3
Statische PushRegistry-Verbindungen im JAD . . . . . . . . . . . 102
5.6.4
Initialisierung von statischen Attributen . . . . . . . . . . . . . . 102
Qualitätssicherung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.7.1
Styleguide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.7.2
Software-Metriken . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.7.3
Automatisierte Tests . . . . . . . . . . . . . . . . . . . . . . . . 104
5.8
Implementierungsaufwand . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.9
Performance-Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . 108
5.9.1
Messreihe 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
5.9.2
Messreihe 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
5.9.3
Messreihe 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
5.9.4
Messreihe 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
5.9.5
Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
6
Zusammenfassung
117
7
Literaturverzeichnis
121
A Abkürzungen
123
VII
VIII
Abbildungsverzeichnis
2.1
Aufbau der BlackBerry-Architektur . . . . . . . . . . . . . . . . . . . .
6
2.2
Komponenten des BES aus [RIM06a] . . . . . . . . . . . . . . . . . . .
7
2.3
Verschlüsselung zwischen BB-Endgerät und BES . . . . . . . . . . . . .
8
2.4
Aufbau einer Beschreibung eines Web Service mit WSDL nach [HL04] .
13
2.5
Aufbau einer SOAP-Nachricht (HTTP als Transportprotokoll) . . . . . .
15
2.6
Überblick der SAP-Module . . . . . . . . . . . . . . . . . . . . . . . . .
18
2.7
Aktivitätsmanagement im GUI-Client von SAP . . . . . . . . . . . . . .
20
2.8
SAP-XI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
2.9
Aufbau der J2ME-Komponenten . . . . . . . . . . . . . . . . . . . . . .
24
2.10 Lebenszyklus eines MIDlets, angelehnt an [Sch04] . . . . . . . . . . . .
27
2.11 Zusammenhang der Klassen des LCDUI, adaptiert aus [Sch04] . . . . . .
30
2.12 MIDlet-Suite übergreifende Zugriffe auf RecordStores . . . . . . . . . .
31
3.1
Grobe Systemarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . .
40
3.2
Server-initiierte Anwendungsfälle . . . . . . . . . . . . . . . . . . . . .
41
3.3
Client-initiierte Anwendungsfälle . . . . . . . . . . . . . . . . . . . . .
42
3.4
Zusammenhang der Komponenten von JSR 172 . . . . . . . . . . . . . .
51
3.5
Beispiel für ein Lost-Update bei der Synchronisation . . . . . . . . . . .
56
3.6
Synchronisationslösung 1 für Client-initiiertes Aktivitätsupdate . . . . . .
58
3.7
Push-Update, Bestandteil der Synchronisationslösungen 1 und 2 . . . . .
59
3.8
Synchronisationslösung 2 für Client-initiiertes Aktivitätsupdate . . . . . .
60
3.9
Mögliches Lost-Update in Synchronisationslösung 2 . . . . . . . . . . .
61
4.1
Verfeinerter Aufbau der Systemarchitektur . . . . . . . . . . . . . . . . .
66
4.2
Klassen der Benutzerschnittstelle (View) . . . . . . . . . . . . . . . . . .
69
4.3
Übersicht und Zusammenhang der Screens . . . . . . . . . . . . . . . . .
71
IX
4.4
Business Objects in mobileCRM . . . . . . . . . . . . . . . . . . . . . .
73
4.5
Komponenten zur Kommunikation mit den Backend-Systemen . . . . . .
74
4.6
Sequenzdiagramm zum Anwendungsfall Daten synchronisieren . . . . .
76
4.7
Sequenzdiagramm zum Anwendungsfall Aktivitäten auflisten . . . . . . .
77
4.8
Sequenzdiagramm zum Anwendungsfall Aktivität anlegen . . . . . . . .
78
4.9
Sequenzdiagramm zum Anwendungsfall Aktivität löschen . . . . . . . . .
80
4.10 Sequenzdiagramm zum Anwendungsfall Aktivität anzeigen . . . . . . . .
81
4.11 Sequenzdiagramm zum Anwendungsfall Aktivitätenliste anfordern . . . .
82
4.12 Sequenzdiagramm zum Anwendungsfall Daten synchronisieren . . . . .
83
4.13 Aufbau eines synchronen Integrationsszenarios im SAP-XI . . . . . . . .
84
5.1
Aufbau der verschiedenen Nachrichtentypen . . . . . . . . . . . . . . . .
92
5.2
Klassen für Internationalisierung und Logging . . . . . . . . . . . . . . .
99
5.3
Kiviat-Graph der Metriken von mobileCRM . . . . . . . . . . . . . . . . 104
5.4
Messaufbau und Bezeichnung der Messwerte . . . . . . . . . . . . . . . 108
5.5
Zeit zum Serialisieren der Anfrage in SOAP-XML-Markup . . . . . . . . 109
5.6
Messreihe 1: Eine Aktivität als Payload . . . . . . . . . . . . . . . . . . 110
5.7
Messreihe 2: 14 Aktivitäten als Payload . . . . . . . . . . . . . . . . . . 111
5.8
Messreihe 3: Zehn Aktivitäten als Payload . . . . . . . . . . . . . . . . . 112
X
Tabellenverzeichnis
2.1
kSOAP Mappings für primitive Datentypen . . . . . . . . . . . . . . . .
34
3.1
Übersicht der Attribute einer Aktivität in mobileCRM . . . . . . . . . . .
46
4.1
Übersicht der Komponenten von mobileCRM . . . . . . . . . . . . . . .
67
4.2
Übersicht der Integrationsszenarien . . . . . . . . . . . . . . . . . . . .
85
4.3
Integrationsszenario ActionPush . . . . . . . . . . . . . . . . . . . . . .
86
4.4
Integrationsszenario ChangeActivity . . . . . . . . . . . . . . . . . . . .
87
4.5
Integrationsszenario GetActivityList . . . . . . . . . . . . . . . . . . . .
88
5.1
LOC des Package com.csc.bb.mobileCRM . . . . . . . . . . . . . . 105
5.2
LOC des Package com.csc.bb.mobileCRM.gui . . . . . . . . . . 106
5.3
LOC des Package com.csc.bb.mobileCRM.model . . . . . . . . . 106
5.4
LOC des Package com.csc.bb.mobileCRM.model.backend.rms106
5.5
LOC des Package com.csc.bb.mobileCRM.model.backend.sap106
5.6
LOC des Package com.csc.bb.mobileCRM.util . . . . . . . . . . 107
5.7
LOC des Package com.csc.bb.mobileCRM.tests . . . . . . . . . 107
5.8
LOC von mobileCRM und mobileCRMtestsuite . . . . . . . . . . . . . . 107
5.9
Statistische Kenngrößen zu Messreihe 1 (Einheit [ms]) . . . . . . . . . . 110
5.10 Statistische Kenngrößen zu Messreihe 2 (Einheit [ms]) . . . . . . . . . . 112
5.11 Statistische Kenngrößen zu Messreihe 3 (Einheit [ms]) . . . . . . . . . . 112
5.12 Daten aus Messreihe 4 (Einheit [ms]) . . . . . . . . . . . . . . . . . . . 113
XI
XII
Verzeichnis der Quellcodes
2.1
Aufbau einer RIM-Push HTTP-Anfrage . . . . . . . . . . . . . . . . . .
11
2.2
Beschreibung eines Web Service aus [W3C01] . . . . . . . . . . . . . .
14
2.3
Beispiel einer SOAP-Nachricht (Anfrage) . . . . . . . . . . . . . . . . .
16
2.4
Beispiel einer SOAP-Nachricht (Antwort) . . . . . . . . . . . . . . . . .
16
2.5
Beispiel eines Java Application Descriptors . . . . . . . . . . . . . . . .
25
2.6
Beispiel zur Serialisierung in einen Byte-Strom . . . . . . . . . . . . . .
33
2.7
KvmSerializable-Schnittstelle von kSOAP . . . . . . . . . . . . . .
35
3.1
JAD der Push-Test-Anwendung . . . . . . . . . . . . . . . . . . . . . .
52
4.1
Interface zur Umsetzung des Command Pattern . . . . . . . . . . . . . .
72
5.1
build.xml: Target makecod . . . . . . . . . . . . . . . . . . . . . . . .
90
5.2
Parameter für den Obfuscator ProGuard . . . . . . . . . . . . . . . . .
90
5.3
SAPmanager.java: Methode receivePush . . . . . . . . . . . . . . .
93
5.4
RMSmanager.java: Methode saveActivityEntry . . . . . . . . . .
94
5.5
ModelController.java: Methode getActivity . . . . . . . . . . . . .
95
5.6
ModelController.java: Methode handleGetActivity . . . . . . . . .
96
5.7
ModelController.java: Methode stop . . . . . . . . . . . . . . . . . . .
96
5.8
PushReceiver.java: Methode run . . . . . . . . . . . . . . . . . . . . . .
97
5.9
PushReceiver.java: Methode stop . . . . . . . . . . . . . . . . . . . . .
98
5.10 Bug in Klasse MIDlet . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.11 Log-Ausgabe der Testanwendung MIDlet_Destroy_Bug . . . . . . . . . 101
5.12 Bug in Klasse Gauge . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
XIII
XIV
Kapitel 1
Einleitung
Die Verbreitung von mobilen Endgeräten wie Smartphones, PDAs und Handys nimmt
weltweit rasant zu. Im September 2006 wurde global die Marke von 2.5 Milliarden Handys erreicht. In Westeuropa betrug im Jahr 2004 der Verbreitungsgrad 74 - 110 Prozent,
d.h. in manchen Ländern ist pro Kopf bereits mehr als ein Handy vorhanden (siehe Studie
[Gei05]). Man liest in diesem Zusammenhang auch häufig von pervasive oder ubiquitous
computing, womit die Durchdringung und Allgegenwärtigkeit von mobilen oder eingebetteten Endgeräten in allen Lebensbereichen gemeint ist. Dies schafft ein großes Potential
für mobile Anwendungen und darauf basierende Geschäftsmodelle. Zur Unterstützung
von Geschäftsprozessen können mobile Anwendungen auch in Unternehmen eingesetzt
werden.
Unter Mobile Business versteht man die Abwicklung von Geschäftsprozessen durch elektronische Kommunikationstechniken mit mobilen Endgeräten. Die besonderen Merkmale
des Mobile Business sind örtliche Unabhängigkeit, Erreichbarkeit zu jeder Zeit, einfache Handhabung sowie Identifizierungs- und Telemetriefunktionen. Dadurch lassen sich
Prozesse in verschiedenen Geschäftsbereichen effizienter gestalten. Mit dem Einsatz von
mobilen Endgeräten innerhalb logistischer Ketten können beispielsweise Daten in Echtzeit erfasst werden. Dies ermöglicht ein besseres Supply Chain Management (SCM) Engpässe können so früh erkannt werden, und Entscheidungen basieren auf aktuellen
Daten. Außendienstmitarbeiter sind zu jeder Zeit in der Lage, ihre Daten des Personal Information Management (PIM) - also z.B. Aufgaben, Termine und Kontakte - und E-Mails
abzurufen. Diese Funktionalität nennt sich auch Mobile Office und ist auf Kommunikation
und Zusammenarbeit ausgerichtet. Anwendungen für den sogenannten Mobile Workforce
Support dienen der Unterstützung von Geschäftsprozessen und ermöglichen den mobilen
Zugriff auf firmeninterne Backend-Systeme. Beispielsweise können Daten des Customer
1
Kapitel 1. Einleitung
Relationship Management (CRM) somit zu jeder Zeit an einem beliebigen Ort verfügbar
sein, und der Kunde kann ohne Zeitverzögerung Informationen oder spezifische Angebote
von seinem Ansprechpartner erhalten. Auch für Konsumenten als Nutzer bringen mobile Anwendungen Zeitersparnis oder eine Verbesserung der Lebensqualität. Entertainment
in Form von Spielen und Musik hat sich bereits auf Handys etabliert und gehört schon
zum Alltag. Navigations- und Bezahlsysteme steigern die Effizienz im Alltag. Ebenso
ist vorstellbar, dass weitergehende standortbezogene Dienste - auch Location Based Services (LBS) genannt - durch erweiterte Funktionen an Attraktivität gewinnen. Im Bereich
öffentlicher und sozialer Einrichtungen wie Notfalldienste, Polizei und Militär führt eine schnelle und auch interdisziplinäre Kommunikation durch mobilen Datenaustausch zu
effizienterem Agieren und kann dadurch entscheidend oder sogar lebensrettend sein.
Zur Verwaltung und Optimierung von Geschäftsprozessen wie beispielsweise dem bereits
angesprochenen CRM und SCM haben sich Softwaresysteme etabliert. Die SAP AG ist
als Hersteller auf diesem Gebiet führend und ihre Software ist bei großen und mittelständischen Unternehmen weit verbreitet. Die aktuelle Produktlinie setzt mit ihrer Serviceorientierten Architektur (SOA) auf hohe Integration der SAP-Teilkomponenten und auch
der eingebundenen Fremdsysteme. Dadurch sollen die Geschäftsprozesse schneller abgewickelt werden, und unmittelbare Anpassungen der Prozesse an die aktuellen Bedürfnisse
der Marktlage sind leichter durchführbar. An dieser Stelle kann Mobile Business zu weiteren Optimierungen beitragen.
Bei der Arbeit mit sensiblen Daten, seien es Betriebsgeheimnisse oder Abwicklungen von
Geschäften mit hohen Transaktionssummen, ist die Gewährleistung der Sicherheit unabdingbar. Neben der verschlüsselten Kommunikation muss garantiert sein, dass die Endgeräte selbst auch sicher sind, da sie Daten lokal speichern können und Zugriff zum Unternehmensnetzwerk haben. Diese Möglichkeiten bietet z.B. die mobile Plattform BlackBerry (BB) des Herstellers Research in Motion (RIM). Die mobilen Endgeräte sind dabei
über einen zentralen Server in das Unternehmen eingebunden und jegliche Kommunikation ist verschlüsselt. Auf dem Endgerät selbst können Daten kodiert gespeichert und via
Passwort zugriffsgeschützt werden. Über den Server ist es außerdem möglich, die Daten
von Geräten über die drahtlose Verbindung zu löschen und IT-Richtlinien anzuwenden.
Mit 5,5 Millionen Nutzern weltweit zeigt sich bereits eine gewisse Verbreitung dieser
Architektur.
Diese Diplomarbeit entstand extern in Kooperation mit der CSC Deutschland Solutions
GmbH in Wiesbaden. Sie zielt darauf ab, die vielfach bereits in Unternehmen vorhandene SAP-Infrastruktur in die BlackBerry-Plattform zu integrieren, um so sicheres Mobile
Business zu ermöglichen. Ein Workflow in einem SAP-CRM-System wird dabei proto-
2
Kapitel 1. Einleitung
typisch durch eine mobile Anwendung auf einem BlackBerry-Endgerät abgebildet. Um
dabei möglichst plattformunabhängig und generisch vorzugehen, erfolgt die Integration
durch Web Services. Durch die damit verbundene Kommunikation in Form von XMLbasierten Nachrichten bleibt die Kopplung zwischen den zu integrierenden Systemen so
gering wie möglich, und die Interoperabilität mit anderen Plattformen ist gewahrt. Der
Schwerpunkt dieser Arbeit liegt auf dem Entwurf von Konzepten für die Integration, die
anhand einer prototypische mobilen Anwendung realisiert werden soll. Die Implementierung des zu entwerfenden Web Service auf SAP-Seite wird durch den Betreuer (Herrn
Thomas Schneider) von Seiten der Firma CSC vorgenommen.
Der Aufbau dieser Arbeit gliedert sich wie folgt: Im Kapitel Grundlagen werden die technologischen Voraussetzungen BlackBerry, SAP, Web Services und J2ME erläutert, die bei
der Bearbeitung des Themas eingesetzt wurden.
Daran schließt sich die Analyse an, in der zunächst die Rahmenbedingungen und Anwendungsfälle der Anwendung beschrieben werden, um dann die einzelnen Systembestandteile dieser Arbeit und mögliche Alternativen zu untersuchen. Im Abschnitt Design wird
die Realisierung dieser Ausführungen softwaretechnisch entworfen, basierend auf den
Entscheidungen in der Analyse und mit der mobilen Anwendung auf dem BB-Endgerät
als Schwerpunkt. Darauffolgend werden die wesentlichen und interessanten Teile der Implementierung dargelegt. Das abschließende Kapitel Fazit fasst die gesamte Abhandlung
zusammen und gibt einen Ausblick für weitere Entwicklungen in diesem Themenbereich.
3
Kapitel 1. Einleitung
4
Kapitel 2
Grundlagen
Dieses Kapitel dient dazu, den Leser mit Architekturen und Technologien vertraut
zu machen, die für das Verständnis dieser Arbeit benötigt werden. Zunächst wird
die BlackBerry-Architektur erläutert und darauf folgend ein Überblick über die SAPArchitektur gegeben und im Speziellen auf die Module zur Kundenverwaltung (CRM)
und der Integration mit anderen Unternehmensanwendungen (XI) eingegangen. Zum besseren Verständnis der SAP-Integration folgt ein Unterkapitel über Technologien für Web
Services. Für die Realisierung dieser Arbeit ist die Java-Plattform für mobile Endgeräte
(J2ME) maßgebend und wird darauffolgend vorgestellt.
2.1
Die BlackBerry-Architektur
Der kanadische Hersteller RIM bezeichnet mit BB Produkte, die im Zusammenhang mit
dieser mobilen Plattform stehen. Einen Überblick darüber gibt Abbildung 2.1. Über mobile Endgeräte ist man in die firmeninternen E-Mail- und Messaging-Systeme integriert.
Das PIM wird ebenso drahtlos abgeglichen. Weiterhin besteht die Möglichkeit, an die
Kommunikationsplattform weitere Unternehmensanwendungen anzubinden, um Daten
und Funktionen zugänglich zu machen.
Einen Überblick der Architektur und des Zusammenspiels der Komponenten liefert
[RIM06a]. Die Plattform besteht hauptsächlich aus einem BB-Handheld als Client, der
über einen BB-fähigen Mobilfunkanbieter mit einem BlackBerry Enterprise Server (BES)
verbunden ist.
Die BB-Infrastruktur besteht aus globalen Rechenzentren des Herstellers RIM. Diese nehmen für das Endgerät verschlüsselte Nachrichten von BES-Servern und über eine durch
5
2.1. Die BlackBerry-Architektur
Kapitel 2. Grundlagen
Abbildung 2.1: Aufbau der BlackBerry-Architektur
das SRP-Protokoll (SRP steht für Secure Remote Password) authentifizierte Verbindung
an. Die Nachricht wird an den entsprechenden Mobilfunkanbieter weitergeleitet, bei dem
das BB-Endgerät eingebucht ist, welches die Nachricht empfangen soll. Für diesen Vorgang ist die von RIM bereitgestellte BB-Infrastruktur notwendig, da ein BB-Client sonst
nur mit einem Mobilfunkanbieter funktionieren würde. Über GPRS oder UMTS übermittelt der Mobilfunkanbieter die Nachricht zum Endgerät, wo sie entschlüsselt werden kann.
Übertragungen in umgekehrter Richtung arbeiten analog, hierbei kodiert jedoch das mobile Endgerät und der BES nimmt die entschlüsselnde Rolle ein. Eine Dekodierung durch
die BB-Infrastruktur findet nicht statt.
Eine weitere Möglichkeit, das Endgerät mit dem BES zu verbinden, ist mittels USBKabelverbindung zur einer Workstation, auf der die BB-Desktop-Software läuft, von der
die Daten über das LAN an den BES gesendet werden.
2.1.1
BES - BlackBerry Enterprise Server
Das Herzstück der Architektur ist der BES, über den die gesamte Kommunikation stattfindet. Diese Serversoftware besteht aus mehreren Komponenten, die in Abbildung 2.2
dargestellt sind. Die wesentlichen Komponenten werden in den folgenden Abschnitten
besprochen.
Über den BES werden standardmäßig bereits das firmeninterne E-Mail-System (unterstützt werden Microsoft Exchange und IBM Lotus Domino) und einige Instant-
6
Kapitel 2. Grundlagen
2.1. Die BlackBerry-Architektur
Abbildung 2.2: Komponenten des BES aus [RIM06a]
Messaging-Systeme durch entsprechende Clientsoftware in die BB-Endgeräte integriert.
Ein besonderes Merkmal ist dabei die sogenannte Push-Technologie, mit der eingehende Nachrichten vom BES aus auf das entsprechende Endgerät gesendet werden können.
Dadurch ist es möglich, die Rechen- und die Latenzzeit des E-Mail-Empfangs zu verringern, und das aufkommende Datenvolumen im Vergleich zu benutzerinitiierten MailAbfragen (Polling) zu reduzieren. Über die Desktop-Software kann das Verhalten des EMail-Systems benutzerspezifisch eingestellt werden. So können beispielsweise Filter angelegt werden, um zu bestimmen, welche E-Mails auf das BB-Gerät gepusht werden sollen. Vom Handheld aus gesendete E-Mails werden bei Bedarf mit der Desktop-Software
synchronisiert. E-Mail-Anhänge werden vom BES in ein spezielles Binärformat konvertiert, das die BB-Gerätesoftware standardmäßig anzeigen kann, ohne dass spezifische Clientsoftware nötig ist. Dies funktioniert allerdings nur für Formate, die vom Anhangdienst
im BES unterstützt werden und die dieser entsprechend konvertieren kann. Ebenso werden Daten des PIM drahtlos über den BES synchronisiert, so dass die Desktop-Clients
und das BB-Endgerät mit den gleichen Daten arbeiten.
Verbindungen zwischen dem BES und BB-Handhelds sind immer mit einem symmetrischen Verschlüsselungsverfahren gesichert (vgl. Abbildung 2.1), aktuell durch AES mit
7
2.1. Die BlackBerry-Architektur
Kapitel 2. Grundlagen
Abbildung 2.3: Verschlüsselung zwischen BB-Endgerät und BES
einem Schlüssel der Länge 256 Bit. Eine Aufgabe des BES ist also die serverseitige Verund Entschlüsselung, die durch den Dispatcher-Service (siehe Abbildung 2.2) stattfindet.
Dazu gehört auch die Verwaltung der geheimen Schlüssel der Endgeräte.
Ein Hauptkodierungsschlüssel wird mit einem Handheld generiert, der entweder mit der
BB-Desktop-Software oder über die Funkverbindung mit dem BES verbunden ist. Dieser
Schlüssel wird an drei Stellen hinterlegt: im BES, im Endgerät und auf dem Mailsystem.
Mit dem Hauptkodierungsschlüssel wird der sogenannte Nachrichtenschlüssel chiffriert,
mit dem die eigentliche Nachricht verschlüsselt ist (siehe Abbildung 2.3).
Die verschlüsselte Nachricht und der zugehörige kodierte Nachrichtenschlüssel werden
an den BES gesendet. Durch den dort hinterlegten Hauptschlüssel des Endgeräts kann
der Nachrichtenschlüssel dekodiert werden und im nächsten Schritt somit auch die Nachricht. Der Hauptschlüssel des Geräts wird üblicherweise alle 30 Tage automatisch geändert. Eine manuelle Änderung ist jederzeit möglich und kann server- oder clientseitig
initiiert sein, Der Nachrichtenschlüssel ändert sich bei jedem Datenpaket (maximal 2kB)
8
Kapitel 2. Grundlagen
2.1. Die BlackBerry-Architektur
und wird basierend auf Zufallsdaten generiert. Optional kann auch ein Schlüssel zum Inhaltsschutz des Handhelds auf der Grundlage des Geräte-Kennworts generiert werden.
Mit Hilfe dieses Schlüssels werden gespeicherte Daten und der Hauptkodierungsschlüssel chiffriert. Detailliertere Informationen zu den Verschlüsselungsmechanismen finden
sich im im Kapitel „BlackBerry-Codierungsschlüssel“ in [RIM06b].
Die Sicherheitseinstellungen der BB-Endgeräte lassen sich über IT-Richtlinien zentral
vom BES aus drahtlos konfigurieren. Die zuständige Komponente dafür ist der PolicyService. So kann z.B. unterbunden werden, dass die Benutzer der Endgeräte Anwendungen installieren können, oder es können die Aktivierung des Inhaltsschutzes und sichere
Passwörter erzwungen werden. Änderungen an den Richtlinien können für alle oder manuell ausgewählte Endgeräte vorgenommen werden.
Der BES stellt mit der Komponente namens Mobile Data System (MDS) Verbindungen
zwischen den mobilen Endgeräten und Anwendungen des Unternehmens oder dem Internet her. Die Kommunikation zwischen Endgerät und dem BES ist dabei auf bekannte
Weise verschlüsselt, für eine sichere Verbindung zwischen MDS und der Unternehmensanwendung kann SSL verwendet werden.
Neben der Verschlüsselung stellt die Dispatcher-Komponente auch einen Dienst zur Optimierung des Datenverkehrs für BB-Endgeräte bereit. Die Optimierung umfasst Datenverkehr von E-Mail-Kommunikation, MDS-Studio-Applikationen (erstellt mit BBspezifischer IDE), J2ME-Anwendungen und dem BB-Browser (falls diese über das MDSSystem übertragen werden). Je nach Anwendungsfall werden die Daten komprimiert oder
auch in ein anderes Format konvertiert, welches das BB-Gerät darstellen kann.
Eine weitere Funktion des MDS ist der Provisioning-Service, mit dem MDS-StudioAnwendungen zentralisiert an die Endgeräte verteilt werden können. Für die Anbindung
unternehmensspezifischer Anwendungen an BB-Endgeräte bieten sich Applikationen auf
Basis von J2ME (siehe Kapitel 2.4) und MDS-Studio-Anwendungen an, welche im nächsten Abschnitt erläutert werden.
2.1.2
BB-MDS-Studio
Die Software BB-MDS-Studio ist eine Entwicklungsumgebung von RIM (siehe Dokumentation [RIM06c]), mit der relativ schnell und leicht graphische Client-Anwendungen
erstellt werden können, die auf Web Services zugreifen. Als Ausgangsbasis dient dabei
die Beschreibung des Web Service in Form eines WSDL-Dokuments, auf dessen Aufbau
später eingegangen wird. Die IDE erstellt aus einem WSDL-Dokument bereits Dialog-
9
2.1. Die BlackBerry-Architektur
Kapitel 2. Grundlagen
felder, die an den Ein- und Ausgabemöglichkeiten des Web Service orientiert sind. Über
einen graphischen Assistenten können die Dialoge manuell angepasst werden. Auf Basis
der Dialoge kann mittels JavaScript weitere Logik implementiert werden. Die Anwendung wird als XML-Struktur repräsentiert und zusammen mit einer separaten Datei für
das JavaScript sowie optionalen Resourcen in ein Java Archive (JAR) verpackt. Der BES
stellt eine Datenbank zur Verfügung, in der MDS-Studio-Anwendungen verwaltet werden und von BB-Clients zur Installation drahtlos abgerufen werden können. Vom MDSRuntime-System im BB-Endgerät wird die Anwendung in native Java-Aufrufe umgesetzt
und die Web-Service-Bibliothek bereitgestellt.
2.1.3
BB-Handheld
Aktuelle BB-Endgeräte laufen mit einem eigenen Betriebssystem von RIM und unterstützen J2ME- und MDS-Studio-Anwendungen. Standardmäßig sind auf den Geräten bereits
ein E-Mail-Client und ein Web-Browser installiert. Für den Browser gibt es drei verschiedene Profile:
1. Den WAP-Browser, wobei die Verbindung über das WAP-Gateway des Mobilfunkanbieters aufgebaut wird.
2. Den BlackBerry-Browser, der Verbindungen über das MDS des BES herstellt.
3. Internet-Browser, der Verbindungen über die RIM-Infrastructure (nicht über den
BES) schafft.
Unter dem Namen BB-Connect bietet RIM Module an, mit denen einige Endgeräte von
Drittanbietern, basierend auf den Betriebssystemen Symbian OS und Windows Mobile,
einen Großteil an Funktionalitäten der BlackBerry-Enterprise-Lösung nutzen können.
Die ausführbaren Anwendungen für BlackBerry-Geräte bzw. die BlackBerry-JVM werden in einem proprietären Format mit der Datei-Extension .cod gespeichert. Die Entwicklungsumgebung von RIM, das Java Development Environment (JDE), bringt einige Entwicklungswerkzeuge mit, die sich auch außerhalb der IDE nutzen lassen. Unverzichtbar ist dabei rapc.exe, ein Compiler, der reguläre J2ME-Anwendungen in das
BlackBerry-Format übersetzt. Mit der BlackBerry-Desktop-Software lassen sich die installierten Anwendungen auf einem Endgerät verwalten.
10
Kapitel 2. Grundlagen
2.1.4
2.1. Die BlackBerry-Architektur
RIM Push-Technologie
Der BES stellt eine externe Schnittstelle für Anwendungen des Unternehmens bereit, über
die Push-Nachrichten angenommen werden und an das entsprechende BB-Endgerät weitergeschickt werden. Die genaue Funktionsweise wird im BlackBerry Application Developer Guide Volume 1 [RIM05] in Kapitel 10 erläutert. Voraussetzung ist, dass die externe
Anwendung das HTTP-Protokoll beherrscht und mit der POST-Methode die Nachricht
an den BES übermitteln kann. Eine Nachricht wird entweder im RIM-Push-Protokoll
(Aufbau siehe Codeausschnitt 2.1) oder Push Access Protocol (PAP, Teil der WAP 2.0
Spezifikation) verpackt.
1 POST /push?DESTINATION=<Gerät>&PORT=<Port>&REQUESTURI=<URI> HTTP/1.1
<HTTP-Header>
3 <RIM-spezifische HTTP-Header>
5 <Nachrichteninhalt>
Quellcode 2.1: Aufbau einer RIM-Push HTTP-Anfrage
Die notwendigen Informationen und Optionen für die Nachrichtenzustellung werden über
den URI der HTTP-Anfrage und spezifische HTTP Header übermittelt. Das Zielgerät wird
mit Hilfe eines eindeutigen Identifikationsstrings des Geräts, in der Dokumentation des
Herstellers PIN genannt, oder der E-Mail-Adresse des Benutzers identifiziert. Der angegebene Port spezifiziert den Port auf dem Endgerät, auf dem die Anwendung auf eingehende
Verbindungen wartet. Dort wird der Inhalt der Nachricht in Form eines Byte-Datenstroms
entgegen genommen. Den Parameter REQUESTURI gibt der BES über HTTP an das Endgerät weiter. Über optionale, herstellerspezifische HTTP Header kann beispielsweise die
Priorität angegeben werden oder ein URI, den der BES aufruft, um eine Rückmeldung
über die Nachrichtenzustellung zu geben. Die Informationen der Rückmeldung werden
dabei ebenfalls über HTTP Header transportiert. Es ist auch möglich, Push-Nachrichten
eine Lebensdauer zuzuweisen, so daß die Nachricht nicht mehr ausgeliefert wird, falls
dies nicht innerhalb des im BES definierten Zeitraums erfolgt ist.
Im Gegensatz zum RIM-Push-Protokoll werden beim PAP die protokollspezifischen Informationen in einer XML-Struktur transportiert. Daher wird die Nachricht in Form einer
MIME-Multipart-Nachricht versendet, um diese Informationen von dem Nachrichteninhalt zu trennen.
11
2.2. Web Services
2.2
Kapitel 2. Grundlagen
Web Services
Unter einem Web Service versteht man eine Software-Komponente, die über XMLbasierten Nachrichtenaustausch mit anderen Applikationen Daten und Funktionen anbieten und entgegennehmen bzw. ausführen kann. Web Services dienen also der Kommunikation zwischen Anwendungskomponenten. Der Unterschied zu anderen Kommunikationsverfahren ist, dass die Grundlage der Nachrichtenformate XML ist, und Nachrichten
über das HTTP-Protokoll übertragen werden können. Dadurch ergibt sich eine große Interoperabilität zwischen verschiedenen Plattformen und Programmiersprachen und die Integration in bestehende Firewall-geschützte Netzwerke fällt leichter. Für die Bereitstellung
und Nutzung von Web Services haben sich einige Protokolle etabliert, die in den folgenden Unterkapiteln beschrieben werden. Als Grundlage dient dabei das Buch [HL04].
2.2.1
WSDL - Web Services Description Language
Mit der Web Services Description Language (WSDL) lassen sich Web Services in Form
von XML-Dokumenten beschreiben. Die aktuelle Version 2.0 des WSDL-Standards liegt
beim World Wide Web Consortium (W3C) als sogenannte Candidate Recommendation
vor [W3C06]. Die zuvor in Entwicklung befindliche Version 1.2 wurde aufgrund größerer Änderungen in 2.0 umbenannt. Der neue Standard unterteilt sich in die Teile Core
Language, Message Patterns und Bindings. Einige Elemente wurden umbenannt oder um
Attribute erweitert, und das aktuelle SOAP-Binding nutzt nun die Version 1.2 statt 1.1
in der vorherigen Version. Viele Implementierungen nutzen jedoch noch nicht die neuen
Standards. Im Folgenden wird WSDL in der Version 1.1 beschrieben (für die Spezifikation siehe [W3C01]), da SAP die neueste Version noch nicht unterstützt.
Eine Beschreibung für die Schnittstelle eines Web Service ist notwendig, um die bereitgestellten Operationen sowie erwartete und zurückgegebene Daten unabhängig von
der Web-Service-Implementierung zu dokumentieren. Mittlerweile bieten viele Entwicklungswerkzeuge Unterstützung beim Umgang mit WSDL. Ausgehend von einem WSDLDokument kann beispielsweise ein Client-Skelett in einer spezifischen Programmiersprache generiert werden, um mit dem Web Service zu kommunizieren. Umgekehrt gibt es
Tools, die zu einer Web-Service-Implementierung ein entsprechendes WSDL-Dokument
erzeugen. Außerdem gibt es noch graphische Design-Werkzeuge, mit denen man ein
WSDL-Dokument entwerfen kann. Die Beschreibung einer Schnittstelle gliedert sich in
fünf Teile, die in Abbildung 2.4 dargestellt sind.
12
Kapitel 2. Grundlagen
2.2. Web Services
Abbildung 2.4: Aufbau einer Beschreibung eines Web Service mit WSDL nach [HL04]
Das Wurzelelement einer Beschreibung ist das definitions-Element, das alle notwendigen XML-Namensräume einbindet. Innerhalb der darauf folgenden Sektion types
können eigene Datentypen definiert werden, falls die XML-Schema-Datentypen nicht
ausreichend sind - üblicherweise werden damit komplexere Datentypen als XML-Schema
realisiert. Eine WSDL-Beschreibung muss mindestens ein message-Element enthalten,
das mit Namen und Typ den Aufbau einer Nachricht beschreibt, die der Web Service
senden oder empfangen kann. Diese Nachrichtentypen werden in der darauffolgenden
portType-Sektion verwendet, in der sie Operationen als Ein- oder Ausgabe-Typ zugeordnet werden. Durch die Reihenfolge und das Vorhandensein der Unterelemente input
und output wird festgelegt, welcher Endpunkt die Kommunikation initiiert und ob eine
Reaktion von der anderen Seite erwartet wird.
Die Struktur unterhalb des Elements binding ist ähnlich wie portType aufgebaut,
allerdings werden dort die Operationen mit einem Transportprotokoll (z.B. SOAP oder
HTTP) verknüpft. Eine abstrakte Definition einer Operation kann mehrere Bindungen haben. Der letzte Abschnitt service enthält port-Unterelemente, in denen jeweils einem
Binding ein URL zugeordnet wird, auf der diese Operation abzurufen ist. Eine beispielhafte Beschreibung eines Web Service durch WSDL findet sich in Quellcode-Listing 2.2.
2.2.2
SOAP
Ursprünglich bedeutete SOAP Simple Object Access Protocol, wird aber mittlerweile nur
noch als Eigenname verwendet, da eine Objektorientierung nicht gegeben ist. SOAP ist
eine Spezifikation zum plattformunabhängigen Austausch von XML-Nachrichten. Initiiert wurde SOAP von Microsoft, basierend auf der Entwicklung von XML-RPC (Spezifikation siehe [Win99]) durch Dave Winer bei UserLand-Software. Die Version 1.1,
an der sich auch IBM beteiligte, wurde dem W3C zur Standardisierung vorgelegt. Vielen
13
2.2. Web Services
Kapitel 2. Grundlagen
1 <definitions name="StockQuote"
targetNamespace="http://example.com/stockquote.wsdl"
3
xmlns:tns="http://example.com/stockquote.wsdl"
xmlns:xsd1="http://example.com/stockquote.xsd"
5
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
7
<types>
9
<schema targetNamespace="http://example.com/stockquote.xsd"
xmlns="http://www.w3.org/2000/10/XMLSchema">
11
<element name="TradePriceRequest">
<complexType>
13
<all>
<element name="tickerSymbol" type="string" />
15
</all>
</complexType>
17
</element>
<element name="TradePrice">
19
<complexType>
<all>
21
<element name="price" type="float" />
</all>
23
</complexType>
</element>
25
</schema>
</types>
27
<message name="GetLastTradePriceInput">
29
<part name="body" element="xsd1:TradePriceRequest" />
</message>
31
<message name="GetLastTradePriceOutput">
33
<part name="body" element="xsd1:TradePrice" />
</message>
35
<portType name="StockQuotePortType">
37
<operation name="GetLastTradePrice">
<input message="tns:GetLastTradePriceInput" />
39
<output message="tns:GetLastTradePriceOutput" />
</operation>
41
</portType>
43
45
47
49
51
53
55
57
59
61
<binding name="StockQuoteSoapBinding"
type="tns:StockQuotePortType">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" />
<operation name="GetLastTradePrice">
<soap:operation soapAction="http://example.com/GetLastTradePrice" />
<input>
<soap:body use="literal" />
</input>
<output>
<soap:body use="literal" />
</output>
</operation>
</binding>
<service name="StockQuoteService">
<documentation>My first service</documentation>
<port name="StockQuotePort" binding="tns:StockQuoteBinding">
<soap:address location="http://example.com/stockquote" />
</port>
</service>
63
</definitions>
Quellcode 2.2: Beschreibung eines Web Service aus [W3C01]
14
Kapitel 2. Grundlagen
2.2. Web Services
Abbildung 2.5: Aufbau einer SOAP-Nachricht (HTTP als Transportprotokoll)
SOAP-Implementierungen liegt diese Version zugrunde, die jedoch nur ein Working Draft
des W3C ist. Sie wurde bereits abgelöst in Form einer endgültigen Empfehlung des W3C
durch die Version 1.2, an der auch Sun Microsystems und Canon erstmalig mitgewirkt
haben. In der Version 1.2 besteht die Spezifikation nun aus drei Teilen statt einem. Die
Namensräume für Envelope und Encoding haben sich geändert, und statt einer Bindung
an HTTP ist die Spezifikation in der Version 1.2 nun allgemeiner gefasst und erlaubt andere Protokolle. Im Folgenden wird auf die Version 1.1 eingegangen (für die Spezifikation
siehe [W3C00]), da diese Version in Kombination mit WSDL 1.1 noch bei SAP eingesetzt
wird.
Im Gegensatz zu XML-RPC muss die Kommunikation über SOAP nicht synchron ablaufen. Eine Nachricht kann jedoch einen Informationsfluss in Gegenrichtung auslösen,
ebenso wie eine Nachricht an mehrere Empfänger addressiert werden kann. In der Praxis
wird SOAP hauptsächlich mit den sogenannten Message Exchange Pattern (MEP) in der
Form Anfrage-Antwort (XML-RPC) und Einzelnachrichten verwendet. Zwischen Sender
und Empfänger sieht die Spezifikation noch SOAP intermediaries vor, die die Mitteilung
weiterleiten. Üblicherweise wird die Information jedoch direkt vom Sender zum Empfänger geschickt. Als Transportprotokoll für SOAP-Nachrichten wird oft HTTP verwendet,
deren gemeinsames Binding im Standard fest integriert wurde. Dabei werden auch die
Statuscodes und der Header von HTTP eingesetzt. Es lassen sich aber auch andere Protokolle wie FTP und SMTP für SOAP nutzen.
Abbildung 2.5 verdeutlicht den Aufbau einer SOAP-Nachricht, die aus einem Envelope-XML-Element als Wurzel besteht, das als Kind-Elemente Header und Body hat,
wobei der Header optional ist. Vor den SOAP-spezifischen Elementen kann gff. noch
eine XML-Deklaration stehen, sowie meistens noch der HTTP Header, falls HTTP als
Transportprotokoll verwendet wird.
Während im SOAP-Envelope verschiedene XML-Schema-Namensräume bekannt gemacht werden, ist der Header relativ offen spezifiziert und bietet so Möglichkeiten,
15
2.2. Web Services
Kapitel 2. Grundlagen
dort optionale Funktionalität einzufügen wie beispielsweise Aspekte der Sicherheit oder
Transaktionssteuerungsinformationen.
Innerhalb des Body-Tags werden die eigentlichen Nutzdaten in Form von XMLDokumenten übertragen. Dieses Element und auch Unterelemente davon können im Attribut encodingStyle Angaben darüber machen, welche Regeln für die Deserialisierung von XML in entsprechende Datentypen verwendet werden können. Die SOAPSpezifikation stellt ein Regelwerk zur Verfügung, das auf den Datentypen von XMLSchema basiert und mit dem Namensraum http://schemas.xmlsoap.org/soap/encoding/ assoziiert ist. Im Falle eines Fehlers zwischen den Kommunikationspartnern wird dies durch ein Element namens Fault als Unterelement von Body signalisiert.
Dieses Element enthält weitere Unterelemente für eine genaue Fehlerrückmeldung. Ein
vollständiges Beispiel einer SOAP-Nachricht mit Anfrage und Antwort befindet sich im
Quellcode-Listing 2.3 und 2.4.
<?xml version=’1.0’ encoding=’utf-8’?>
2 <soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
4
xmlns:tns="http://axisversion.sample/xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
6
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Body>
8
<tns:getVersion>
</tns:getVersion>
10
</soap:Body>
</soap:Envelope>
Quellcode 2.3: Beispiel einer SOAP-Nachricht (Anfrage)
1 <?xml version=’1.0’ encoding=’utf-8’?>
<soapenv:Envelope
3 xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header />
5
<soapenv:Body>
<ns:getVersionResponse xmlns:ns="http://axisversion.sample/xsd">
7
<return>
Hello I am Axis2 version service , My version is 1.0 May 05, 2006 (12:30:54 IST)
9
</return>
</ns:getVersionResponse>
11
</soapenv:Body>
</soapenv:Envelope>
Quellcode 2.4: Beispiel einer SOAP-Nachricht (Antwort)
16
Kapitel 2. Grundlagen
2.3
2.3. SAP
SAP
Dieses Unterkapitel bietet einen Überblick der SAP-Softwarelösungen und geht danach
auf die für diese Arbeit interessanten Module CRM und XI ein. Die Basis dieses Abschnitts sind die SAP-Schulungsunterlagen [SA03].
Die SAP AG ist ein weltweit agierendes Unternehmen und führender Anbieter von Unternehmenssoftware. Die Service-orientierte Architektur der Software ist darauf ausgelegt, Geschäfte in Echtzeit abzuwickeln, auf veränderte Marktbedingungen schnell reagieren zu können und die Zusammenarbeit der Mitarbeiter zu verbessern. Erreicht werden soll dies durch die Komponente NetWeaver, die dafür zuständig ist, die einzelnen
SAP-Module und auch Fremdanwendungen untereinander zu vernetzen und zu integrieren. Ebenso stellt diese Komponente einen Application-Server zur Verfügung, auf dem
die weiteren Module aufsetzen. Das Kern-Modul ist mySAP ERP, es ist der Nachfolger des SAP R/3 Systems, das weiterhin verfügbar ist, jedoch nicht auf der NetWeaverTechnologie basiert. ERP ist ein Begriff aus den Wirtschaftswissenschaften und bedeutet
Enterprise Resource Planning. Damit werden die Basisfunktionalitäten für ein Unternehmen bereitgestellt. Dieser Kern kann um Zusatzkomponenten ergänzt werden, um weitere Geschäftsprozesse abbilden zu können. Einen Überblick dazu gibt die Abbildung 2.6.
Das SRM (Supplier Relationship Management) umfasst die Planung und Steuerung von
Beziehungen des Unternehmens zu seinen Lieferanten. Das SCM (Supply Chain Management) dient der Optimierung von innerbetrieblichen Logistikketten. Das PLM (Product
Lifecycle Management) gestattet allen an der Produktentwicklung beteiligten Einheiten
und Partnern Zugriff auf die Daten der Produktentwicklung. Dies kann zur Verkürzung
der Produktzyklen beitragen, erlaubt Qualitätsverbesserungen und wird dem Sachverhalt
gerecht, dass Unternehmen mit immer mehr Geschäftspartnern kooperieren. Mit Hilfe
des CRM lassen sich Kundenbeziehungen verwalten, so dass Mitarbeiter alle nötigen Informationen zu Kunden abrufen können. Auf die Funktionalität dieses Moduls wird im
Folgenden näher eingegangen.
2.3.1
SAP-CRM 4.0
Als inhaltliche Quelle zu diesem Abschnitt dient [BEZ04]. Unter CRM versteht man allgemein Strategien und Verfahren, um Beziehungen von Unternehmen zu Kunden individualisiert verwalten zu können. Die wesentlichen Faktoren für den wirtschaftlichen Erfolg
eines Unternehmens - marktgerechte Produkte, profitabler Betrieb und zufriedene Kunden
- können durch CRM optimiert werden. Die Zielsetzung ist dabei, die Kunden kontinu-
17
2.3. SAP
Kapitel 2. Grundlagen
Abbildung 2.6: Überblick der SAP-Module
ierlich und effizient zu betreuen und die Leistungen den jeweiligen Kundenbedürfnissen
anzupassen. Dazu werden alle interessanten Kundendaten wie Kontaktmöglichenkeiten,
eine Historie von bisherigen Geschäftsabwicklungen oder auch die Liquidität des Kunden
festgehalten. Jeder beteiligte Mitarbeiter hat somit Zugriff auf die Daten und kann den
Kunden individuell bedienen. Die Informationen sind also nicht in Köpfen von bestimmten Mitarbeitern oder auf Notizen verteilt, sondern gehören dem Unternehmen und sind
für alle am Geschäftsprozess Beteiligten verfügbar. Durch eine Auswertung der CRMDaten kann auch genau festgestellt werden, welche Kunden am meisten Profit einbringen und welche möglicherweise Verluste verursachen. So können die Kundenbetreuung
aufgrund dieses Aspektes entsprechend gestaltet und Prioritäten festgelegt werden. Ebenso kann eine wirtschaftliche Geschäftsfokussierung stattfinden. Durch weitere Analysen
können Änderungen im Kundenverhalten und des gesamten Marktgeschehens erkannt
und die Ressourcen und Geschäftsprozesse entsprechend adaptiert werden.
Die CRM-Software von SAP ist in drei Kategorien unterteilt:
• Operatives CRM
Das operative CRM unterstützt Geschäftsabläufe, die unmittelbar am Kunden ausgerichtet sind. Darunter fällt der Vertrieb eines Unternehmens, der mit Kaufinteressenten und Kunden bis zur Vertragsabwicklung agiert. Im Service werden Kundenbeschwerden entgegen genommen, mit Unterstützung von Lösungsdatenbanken
18
Kapitel 2. Grundlagen
2.3. SAP
bearbeitet, und Serviceverträge erfüllt. Auch der Bereich Marketing hat direkten
Kontakt zu den Kunden.
• Analytisches CRM
Das Ziel von CRM-Analysen ist die Auswertung von Kundenzufriedenheit und
Kundenverhalten, deren Ergebnisse wiederum die Entscheidungsgrundlage für Vertrieb und Marketing sind.
• Kollaboratives CRM
Das kollaborative oder auch unternehmensübergreifende CRM dient der Zusammenarbeit des Unternehmens mit Geschäftspartnern.
Um den Einsatzbereich eines CRM-Systems weiter zu optimieren, müssen auch beispielsweise die ERP- und SCM-Module zugreifbar sein. So können Bestellungsänderungen
oder andere Wünsche des Kunden direkt vom CRM aus abgewickelt werden. Das CRM ist
quasi die Schnittstelle des Kunden zum Unternehmen, und somit müssen alle relevanten
Geschäftsprozesse im Backend des Unternehmens und auch unternehmensübergreifend
bei Lieferanten und Partnern zugreifbar sein. Bei CRM-Lösungen findet sich auch eine
Spezialisierung nach Branchen, um konkret den unterschiedlichen Bedürfnissen gerecht
zu werden.
Für den technischen Zugriff auf ein CRM-System gibt es BAPIs (Business Application Programming Interface) und Funktionen, die remote-fähig sind, sogenannte RFCBausteine. RFC steht für Remote Function Call und ist ein von SAP definiertes Protokoll für entfernte Funktionsaufrufe. Dabei übernimmt das Protokoll die Kommunikationssteuerung, Parameterübergabe und die Fehlerbehandlung. Ein BAPI ist ein RFC-fähiger
Funktionsbaustein, der einen fest definierten Funktionsumfang hat, meist zusammenfassend für einen bestimmten Geschäftsvorfall. Weiterhin soll eine BAPI-Schnittstelle über
Versionswechsel der Software hinaus konstant bleiben und abstrahiert somit mehr als ein
RFC-Interface.
Eine Funktion des CRM, auf die in diesem Rahmen näher eingegangen wird, ist das Aktivitätsmanagement, das die Mitarbeiter bei der Organisation der täglichen Arbeit unterstützen soll. Eine Aktivität ist vergleichbar mit einem Eintrag in einem Terminkalender,
der um zusätzliche Funktionen erweitert ist. Sie dienen der Dokumentation von Interaktionen mit Kunden. Wie sich eine Aktivität im graphischen SAP-Frontend darstellt, ist in
Abbildung 2.7 zu sehen. Neben den beteiligten Ansprechpartnern auf Unternehmens- und
Kundenseite wird auch der Ort und der Zeitraum festgehalten. Es kann ein Text für den
Grund und das Ziel der Aktivität hinterlegt werden, ebenso wie ein Erledigungsstatus,
19
2.3. SAP
Kapitel 2. Grundlagen
Abbildung 2.7: Aktivitätsmanagement im GUI-Client von SAP
eine Priorität und ein Ergebnis. Als Anlage können weitere Dokumente und Belege verknüpft sein, beispielsweise Marketingbroschüren oder Briefe, die an den Kunden adressiert wurden. Dabei werden noch die speziellen Möglichkeiten vom System angeboten,
einen Aktivitätsbericht zu erstellen oder einen Fragebogen zu entwerfen und Aktivitäten
zuzuordnen. In einem Aktivitätsbericht kann der Produktbezug einer Aktivität festgehalten werden oder auch Feedback des Kunden. Mit Hilfe eines Fragebogens können z.B. die
Verkaufschancen (Opportunity-Bewertung) in einer Geschäftsbeziehung berechnet werden.
2.3.2
SAP-XI - eXchange Infrastructure
Die SAP Exchange Infrastructure (XI) (siehe [SO04]) ist ein Bestandteil von NetWeaver
und dient der Integration von SAP- und Fremdanwendungen inner- oder außerhalb des
Unternehmens. Hervorgehoben sei an dieser Stelle, dass auch einige SAP-Module wie
beispielsweise SRM und CRM über XI angebunden sind. Dies unterstreicht das Serviceorientierte Paradigma der SAP-Architektur. Die an Geschäftsprozessen orientierte Inte-
20
Kapitel 2. Grundlagen
2.3. SAP
Abbildung 2.8: SAP-XI
gration von Applikationen in heterogene Anwendungssysteme nennt sich auch Enterprise
Application Integration (EAI). Ein weiteres Ziel, das mit XI verfolgt wurde, ist das Abspeichern von integrationsspezifischem Wissen an zentraler Stelle. So wird vermieden,
dass die Unternehmensanwendungen direkt miteinander verknüpft werden und dadurch
eine komplexe Struktur mit möglicherweise unterschiedlichen verwendeten Technologien
entsteht. Stattdessen kommuniziert jede Applikation mit der XI, die Daten intern durch
XML-basierte Nachrichten repräsentiert und an die entsprechende Ziel-Anwendung weiterleitet. Dadurch ist die Kopplung der Anwendungen an den Kommunikationsendpunkten gering. Das interne XI-Protokoll basiert auf SOAP und verwendet Header Extensions
und weitere Payload in MIME Multiparts. Der Datenaustausch mit XI kann synchron
und asynchron erfolgen. Eine solche Plattform, die Nachrichten zwischen voneinander
unabhängigen Systemen vermittelt, nennt man in diesem Zusammenhang auch Messageorientied Middleware (MOM).
In Abbildung 2.8 sind die wesentlichen Teile von XI dargestellt. Die Adapter-Engine setzt
Nachrichten der zu integrierenden Systeme in das XI-Message-Format um und umgekehrt. Statt Formatumsetzungen für alle Kombinationen miteinander kommunizierender
Systeme muss lediglich eine Umsetzung für die entsprechenden Protokolle in beide Richtungen stattfinden, beispielsweise SOAP-Nachrichten in RFC- oder BAPI-Aufrufe umsetzen und umgekehrt. Anstatt die Adapter-Engine zu verwenden, kann mit einer Java- oder
ABAP-Anwendung innerhalb des Applikation Servers auch direkt mit der IntegrationEngine kommuniziert werden. Die Integration-Engine übernimmt das Routing der konvertierten Nachrichten, und ggf. werden sogenannte Mappings durchgeführt. Mit Hilfe
von Mappings können Datenkonvertierungen in XI umgesetzt werden, um die Doku-
21
2.3. SAP
Kapitel 2. Grundlagen
mentstruktur der Nachricht eines Senders an den Empfänger anzupassen. Die BusinessProcess-Engine setzt auf der Integration-Engine auf und übernimmt die zustandsbehaftete
Nachrichtenübermittlung auf Geschäftsprozessebene.
Die nötigen Informationen, um Nachrichten zwischen Systemen zu vermitteln, werden
in Integration-Repository, Integration-Directory und System-Landscape-Directory (SLD)
gespeichert, deren Inhalt im Folgenden erläutert wird:
• System-Landscape-Directory
Das SLD enthält einen Katalog mit Beschreibungen über installierbare Softwareprodukte und deren Komponenten in der Systemlandschaft. Mit Komponenten sind
in diesem Fall einzeln installierbare Einheiten gemeint, die jedoch nicht zwangsweise ohne das Hauptprodukt ausführbar sind. Die Beschreibungen enthalten auch
jeweils die Version des Produkts oder der Komponente. In einem weiteren Katalog
werden die konkreten Systeme erfasst, unterteilt in technische Systeme und weiter abstrahierend in Business-Systeme. Abgespeichert werden diese Daten mit dem
Standard Common Information Model (CIM) [DMT06]. Für SAP-Produkte werden
bereits entsprechende Beschreibungen mit ausgeliefert.
• Integration-Repository
Im Integration-Repository werden die Schnittstellen der beteiligten Systeme in
Form von WSDL- und XML-Schema-Dokumenten hinterlegt. Die Definition von
Prozessen kann mittels der Business Process Execution Language (BPEL) [BPE]
stattfinden. Für die bereits erwähnten Mappings werden XSLT-Dokumente verwendet.
• Integration-Directory
Durch das Integration-Directory werden Schnittstellen aus dem Integration-Repository konkrete Systeme aus dem SLD zugeordnet. Dadurch werden letztendlich die
Systeme festgelegt, die untereinander Nachrichten austauschen.
Mit der Browser-basierten Anwendung Integration Builder, die auf der Technologie Java
Web Start (JWS) basiert, kann das Design im Integration-Repository entworfen und die
Konfiguration im Integration-Directory vorgenommen werden. Das SLD kann über eine
Web-Anwendung konfiguriert werden.
22
Kapitel 2. Grundlagen
2.4
2.4. J2ME - Java 2 Platform Micro Edition
J2ME - Java 2 Platform Micro Edition
Dieses Unterkapitel vermittelt das nötige Wissen, um standardisierte Java-Anwendungen
für mobile Endgeräte zu entwickeln. Die Basis dieses Abschnitts sind die Lehr-Bücher
[Sch04] und [Yua06].
2.4.1
Überblick
Die Micro Edition ist eine Spezifikation der Java-Laufzeitumgebung für mobile Endgeräte wie beispielsweise PDAs und Mobiltelefone. Aufgrund der unterschiedlichen Ausprägungen und Einschränkungen solcher Geräte ist J2ME komponentenbasiert aufgebaut
und dadurch flexibler als die Java 2 Standard Edition (J2SE). Die Spezifikationen sind im
offenen Java Community Process (JCP) unter Federführung großer Hersteller wie Nokia
und RIM durch sogenannte Java Specification Requests (JSR) entstanden.
Die unterste von drei Schichten in J2ME (siehe Grafik 2.9) bilden sogenannte Konfigurationen. Sie legen fest, welche Hardwareanforderungen ein Gerät erfüllen muss, und
definieren zu den Anforderungen passende Standardbibliotheken und eine Java Virtual
Machine (JVM). Auf diesen Konfigurationen bauen diverse Profile auf, die weitere fundamentale, gerätespezifische Bibliotheken zur Verfügung stellen. In der letzten Schicht,
die auf ein Profil aufsetzt, gibt es optionale Zusatzpakete, beispielsweise eine 3D-API
oder XML-Parser.
Die Connected Limited Device Configuration (CLDC) zielt auf in der Hardware eingeschränkte Geräte ab. Die Mindestanforderungen sind 160kB nichtflüchtiger Speicher für
die VM und Bibliotheken und 32kB flüchtiger Speicher für den Ablauf der VM. Aufgrund dieser Restriktionen ist nur eine Untermenge der J2SE-API vorgesehen und an die
Endgeräte angepasst implementiert.
Ebenso ist eine auf das Wesentliche reduzierte Kilo Virtual Machine (KVM) verfügbar,
die beispielsweise nicht die Java-Reflection-API unterstützt. Die CLDC ist größtenteils
auf Mobiltelefonen wiederzufinden und wird im JSR 139 in der Version 1.1 definiert.
Details können der zugehörigen Spezifikation [Tai03] entnommen werden.
Die Connected Device Configuration (CDC) hingegen hat höhere Hardwareanforderungen, stellt mehr Funktionalität der J2SE-API zur Verfügung und kommt beispielsweise
auf High-End PDAs, TV Set-Top-Boxen oder Navigationssystemen zum Einsatz. Im Gegensatz zur CLDC bietet sie eine vollständige J2SE JVM. Für diese Diplomarbeit ist nur
die Konfiguration CLDC relevant.
23
2.4. J2ME - Java 2 Platform Micro Edition
Kapitel 2. Grundlagen
Abbildung 2.9: Aufbau der J2ME-Komponenten
Auf der CLDC setzt das Mobile Information Device Profile (MIDP) auf. Es stellt eine
API für die wesentlichen Merkmale eines Mobiltelefons zur Verfügung (vgl. [MW06]):
• Lebenszyklus, Deployment und Signieren von Anwendungen
• Graphische Benutzerschnittstelle (Ein- und Ausgabe)
• Persistente Speicherung für Anwendungsdaten und Einstellungen
• Netzwerkverbindungen und HTTP/HTTPS
• Media API (nur für Audio)
Dementsprechend formuliert die Spezifikation weitere Hardware-Anforderungen, zusätzlich zu denen der CLDC, um die Funktionalität des MIDP realisieren zu können. Im Wesentlichen sind dies weiterer Speicher von mind. 256kB für die MIDP-Implementierung
und 8kB für persistente Daten, eine minimale Auflösung des Displays mit 96x96 Pixeln
und 1 Bit Farbtiefe, sowie eine Tastatur oder einen Touchscreen.
2.4.2
Deployment
In den folgenden Abschnitten erfolgt eine Beschreibung des Packaging und der Installation von J2ME-Anwendungen auf Basis des MIDP (siehe Kapitel 2 der Spezifikation
[MW06]).
2.4.2.1
MIDlet Suite
Die Installation und das Starten einer Anwendung geschehen über die Application Management Software (AMS), die auf dem Endgerät vom Hersteller implementiert ist. Eine
24
Kapitel 2. Grundlagen
2.4. J2ME - Java 2 Platform Micro Edition
Deinstallation wird ebenso von der AMS durchgeführt. Eine installierbare Anwendung
nennt sich MIDlet Suite und besteht aus einem JAR und einem optionalen Java Application Descriptor (JAD). Ein Beispiel eines JAD findet sich im Quellcode-Listing 2.5. Das
JAR enthält die kompilierten Klassen der Anwendung, eine Manifest-Datei, sowie optionale Ressourcen wie Text- und Bilddateien, die von der Anwendung benötigt werden.
Der Kompiliervorgang wird mit einem J2SE-Standardcompiler vollzogen. Da die CLDC,
wie in Abschnitt 2.4.1 erwähnt, nicht den vollen J2SE-VM-Umfang implementiert, muss
der generierte Bytecode anschließend noch mit einem sogenannten Preverifier bearbeitet werden. Ein solches Werkzeug wird beispielsweise innerhalb des Wireless Toolkit
(WTK)1 von Sun bereitgestellt, und formt den Bytecode zu einem Äquivalent um, das
auf einer KVM lauffähig ist.
MIDlet-1: MIDletName, /path/to/midlet/icon.png, com.example.MIDletClassName
2 MIDlet-Jar-URL: midletsuite.jar
MIDlet-Name: Midlet Suite Name
4 MIDlet-Vendor: CSC
MIDlet-Version: 1.0.11
6 MicroEdition-Configuration: CLDC-1.1
MicroEdition-Profile: MIDP-2.0
8 CustomAttribute: value
Quellcode 2.5: Beispiel eines Java Application Descriptors
Die Manifest-Datei besteht aus Key:Value-Paaren und beinhaltet notwendige Informationen für das AMS zur Installation. Optional können einige solcher Attribute auch durch
einen externen JAD zur Verfügung gestellt werden, so dass die Anwendung an den Benutzer oder das Endgerät angepasst werden kann, ohne das JAR modifizieren zu müssen.
Außerdem können eigene anwendungsspezifische Attribute angelegt werden, die jedoch
nicht mit „MIDlet“ oder „MicroEdition“ beginnen dürfen. Weitere Details und eine Übersicht zu verpflichtenden Attributen hält die Spezifikation [MW06] auf S. 435 bereit. Mit
der Methode getAppProperty() der Klasse MIDlet lassen sich alle im JAD angegebenen Attribute der Suite zur Laufzeit abfragen. Die Ressourcen kann ein MIDlet über
die Methode java.lang.Class.getResourceAsStream(String name) als
Datenstrom auslesen. Das Wurzelverzeichnis ist dabei das JAR des MIDlets.
1
http://java.sun.com/products/sjwtoolkit/download-2_5.html
25
2.4. J2ME - Java 2 Platform Micro Edition
2.4.2.2
Kapitel 2. Grundlagen
OTA Provisioning
Der Installationsvorgang wird nach dem Over The Air (OTA) Provisioning Verfahren abgewickelt, das in [MW06] Kapitel 2 genauer spezifiziert ist. Die MIDlet Suite liegt dabei
auf einem entfernten Web Server vor und wird in mehreren Schritten über die Funkverbindung auf das Endgerät übertragen:
1. Der Benutzer wählt im Endgerät die zu installierende Anwendung in der sogenannten Discovery Application (DA) aus - üblicherweise geschieht dies im WAPBrowser. Durch eine HTTP-GET-Anfrage wird der entsprechenden JAD vom Server auf das Endgerät transferiert und von der AMS ausgewertet.
2. Falls alle im JAD enthaltenen Voraussetzungen zur Installation erfüllt sind, wird
durch die AMS das JAR der Anwendung (die URL befindet sich im JAD) ebenfalls
via HTTP auf das Gerät geladen und installiert.
3. Falls entsprechende Attribute im JAD vorhanden sind, erzeugt das AMS per HTTPPOST eine Rückmeldung an einen angegebenen Server, in der ein Statuscode der
Installation übermittelt wird.
Zu beachten ist dabei, dass der Web Server die entsprechenden MIME-Typen für den JAD
(text/vnd.sun.j2me.app-descriptor) und das JAR (application/java-archive) im HTTP
Header angeben sollte.
2.4.3
Programmierung
In den folgenden Abschnitten wird auf die Entwicklung von J2ME-Anwendungen eingegangen, basierend auf der Konfiguration CLDC 1.1 und dem Profil MIDP 2.0.
2.4.3.1
Lebenszyklus
Wenn der Benutzer eine Anwendung zum Starten ausgewählt hat, wird von der AMS
das entsprechende MIDlet geladen. Der Einstiegspunkt einer solchen Anwendung, analog zur Funktion main() in J2SE oder anderen Programmiersprachen, ist in der abstrakten Klasse javax.microedition.midlet.MIDlet definiert. Eine Applikation muss dementsprechend mindestens eine Klasse beinhalten, die MIDlet erweitert und
die Handler-Methoden startApp(), pauseApp() und destroyApp(boolean
unconditional) überschreibt.
26
Kapitel 2. Grundlagen
2.4. J2ME - Java 2 Platform Micro Edition
Abbildung 2.10: Lebenszyklus eines MIDlets, angelehnt an [Sch04]
Ein MIDlet kennt die drei Zustände paused, active und destroyed. Der Zustand eines MIDlets kann sowohl von der AMS als auch vom MIDlet selbst in einen anderen überführt werden (siehe Abbildung 2.10). Wenn ein Zustandsübergang von der
AMS ausgelöst wird, ruft diese zunächst die entsprechende Handler-Methode des MIDlets auf. Wird der Zustand vom MIDlet selbst geändert, durch den Aufruf einer der
Methoden notifyPaused() oder notifyDestroyed(), so werden die HandlerMethoden nicht aufgerufen, dafür muss das MIDlet ggf. selbst sorgen. Mittels notifyDestroyed() im MIDlet (nicht überschreibbar, da final) wird eine Anwendung regulär beendet, System.exit() verursacht im Kontext mit MIDP spezifikationsgemäß
eine SecurityException.
Bei Aufruf einer Anwendung wird von der AMS zunächst der Konstruktor des MIDlets aufgerufen, und der Zustand ist paused. Im Konstruktor können nicht-zeitaufwändige
Initialisierungen erfolgen. Weitere Ressourcenanforderungen und das Erfüllen der eigentlichen Aufgabe der Applikation erfolgen in startApp() bzw. von dort aus delegiert in
anderen Klassen. Die Methode startApp() wird ebenfalls von der AMS aufgerufen,
und der Zustand ändert sich zu active. Wenn das Display von einer anderen Anwendung,
z.B. einem eingehenden Telefonanruf, benötigt wird, pausiert die AMS das MIDlet. In
der Handler-Methode pauseApp() sollte das MIDlet dabei zuvor angeforderte Ressourcen freigeben. Falls das MIDlet Hintergrund-Threads gestartet hat, so laufen diese
weiter, auch wenn das MIDlet pausiert. Daher sollten solche Threads nicht viele Ressourcen wie CPU-Zeit, Speicher und Bandbreite benötigen oder anderenfalls gestoppt werden. Soll das MIDlet durch die AMS beendet werden, so wird destroyApp(boolean
unconditional) aufgerufen, wobei der Parameter angibt, ob das MIDlet den Befehl
zur Beendigung mit einer MIDletStateChangeException verweigern kann oder
nicht. Weiterhin werden in dieser Methode üblicherweise Ressourcen freigegeben - bei-
27
2.4. J2ME - Java 2 Platform Micro Edition
Kapitel 2. Grundlagen
spielsweise Deskriptoren freigeben oder Threads beenden - und ggf. Anwendungsdaten
persistent gespeichert.
2.4.3.2
PushRegistry
Für Anwendungen, die auf bestimmte Ereignisse warten, stellt die AMS eine sogenannte PushRegistry zur Verfügung. Bei dieser Komponente können sich Anwendungen dynamisch via javax.microedition.io.PushRegistry oder statisch über einen
Eintrag im JAD registrieren und werden dann von der AMS gestartet, wenn ein entsprechendes Ereignis eintritt. Dadurch ist es für eine Applikation möglich, auf eingehende
TCP- und UDP-Verbindungen an einem registrierten Port oder auf eine SMS von einer
bestimmten Rufnummer zu reagieren. Darüberhinaus bietet die PushRegistry noch die
Möglichkeit, einen Timer zu setzen, so dass die Anwendung regelmäßig gestartet wird.
Der Vorteil der PushRegistry ist, dass die Anwendung erst gestartet wird, wenn das Ereignis eintritt und nicht selbst aktiv wartet. Somit können Ressourcen gespart werden.
Die AMS wartet auf eingehende Verbindungen an registrierten Ports und startet das zugehörige MIDlet, das die Verbindung über javax.microedition.io.Connector
mit der Methode open() öffnen kann. Das MIDlet ist, wenn es gestartet ist, selbst für
eingehende Verbindungen und darauf empfangene Daten verantwortlich. Die AMS überwacht dies erst wieder, nachdem das MIDlet beendet wurde. Zu beachten ist dabei, dass
im JAD das Attribut MIDlet-Permissions entsprechend die vollqualifizierten Klassennamen der PushRegistry und der verwendeten Netzwerkklassen enthält.
2.4.3.3
Graphische Benutzerschnittstelle
Das Lowest Common Denominator User Interface (LCDUI) im Package javax.microedition.lcdui ist ein Framework der J2ME für grafische Benutzerschnittstellen und untergliedert sich in eine High- und Low-Level-API. Letzteres ermöglicht
pixelgenaues Zeichnen auf dem Display, das Nutzen von gerätespezifischen Hardwarefunktionalitäten wie beispielsweise Auflösung, Farbtiefe und das Abfragen von Tasten.
Die Low-Level-API kommt z.B. bei Spielen zum Tragen und wird hier nicht näher betrachtet.
Im Gegensatz dazu ist die High-Level-API eine abstrahierende Schicht über den gerätespezifischen Grafik-Elementen, den sogenannten Widgets. Dies hat zur Folge, dass Anwendungen, die diese API nutzen, nicht auf jedem Gerät das gleiche Look and Feel - also
Erscheinungsbild und Bedienung der Widgets - haben. Auf der anderen Seite integriert
28
Kapitel 2. Grundlagen
2.4. J2ME - Java 2 Platform Micro Edition
sich die Anwendung so automatisch, und der Benutzer hat das vom Endgerät gewohnte
Look and Feel.
Ein Überblick der Klassenhierarchie der LCDUI wird in Abbildung 2.11 gegeben. Gemeinsam ist beiden APIs, dass sie eine dem MIDlet zugeordnete Instanz der Klasse
Display verwenden, die das physikalische Display repräsentiert und mit der statischen Methode Display.getDisplay(MIDlet m) abgefragt werden kann. Zu einem Zeitpunkt kann auf dem Display ein einziges Objekt dargestellt werden, das die
abstrakte Klasse Displayable erweitert. Darin werden bereits die Funktionalitäten für
einen Fenster-Titel, -Laufschrift und Hinzufügen von Bedienelementen zur Interaktion
mit dem Benutzer zur Verfügung gestellt. Um die Benutzereingaben zu bearbeiten, kann
man einem Displayable-Objekt auch CommandListener übergeben, die häufig als
anonyme Klasse implementiert werden. Das Framework ruft dessen Callback-Methode
commandAction(Command c, Displayable d) bei entsprechenden Events seriell auf, d.h. weitere Callbacks werden erst aufgerufen, wenn der vorherige beendet wurde. Aus diesem Sachverhalt heraus ergibt sich die Empfehlung, in Callback-Methoden
keine zeitaufwändigen Operationen einzubetten.
Welches Objekt auf dem Bildschirm sichtbar sein soll, kann mit der Methode Display.setCurrent(Displayable nextDisplayable) gesetzt werden. Diese Methode darf jedoch nicht im Konstruktor des MIDlets sondern erst in startApp() aufgerufen werden. Über Display lassen sich außerdem Informationen zum Display abfragen
sowie die Hintergrundbeleuchtung und der Vibrationsalarm steuern.
Von Displayable erbt die Klasse Canvas, an der die Low-Level-API ansetzt. Das
Pendant für die Highlevel API ist Screen, von dem sich die Benutzerelemente List,
Alert, TextBox und Form ableiten. Dabei ist Form ein flexibles Element, das man
mit Items bestücken kann, die eigene ItemCommandListener haben können. Es
gibt vorgefertigte Unterklassen von Item, die häufig benötigte Funktionalitäten zur Verfügung stellen, beispielsweise eine Auswahl mittels ChoiceGroup, die vereinfachte
Eingabe eines Datums durch DateField und Fortschrittsbalken (Klasse Gauge).
Die Aktualisierung auf dem Display gestaltet sich einfach: Modifiziert man Elemente,
führt das LCDUI Framework automatisch eine Aktualisierung durch, eine TextBox
kümmert sich z.B., wenn nötig, eigenständig um einen Scrollbalken.
Ein wichtiger Aspekt bei der Programmierung von graphischen Benutzerschnittstellen
ist die Verwendung von Threads. Die Logik einer Anwendung sollte in einem separaten
Thread laufen, damit der Ausführungsstrang der LCDUI jederzeit Aktualisierungen in der
graphischen Repräsentation vornehmen kann.
29
2.4. J2ME - Java 2 Platform Micro Edition
Kapitel 2. Grundlagen
Abbildung 2.11: Zusammenhang der Klassen des LCDUI, adaptiert aus [Sch04]
30
Kapitel 2. Grundlagen
2.4. J2ME - Java 2 Platform Micro Edition
Abbildung 2.12: MIDlet-Suite übergreifende Zugriffe auf RecordStores
2.4.3.4
RMS - Persistente Speicherung
Um Daten auf mobilen Endgeräten persistent speichern zu können, definiert das MIDP
eine abstrakte, herstellerunabhängige Schnittstelle - das sogenannte Record Management
System (RMS). Details können der Spezifikation [MW06] in Kapitel 14 entnommen werden.
Das RMS im Package javax.microedition.rms bietet den Klassen einer MIDlet Suite die Funktionalität, RecordStores anzulegen, die dann wiederum eine Sammlung
von Records enthalten. Ein Record ist ein Datensatz in Form eines Java Byte-Arrays von
beliebigem Inhalt und Länge, dem vom RMS ein Primärschlüssel als Identifikator zugeordnet wird. Der Datentyp des Primärschlüssels ist int, und die Vergabe beginnt mit 1,
jeder weitere Record erhält n+1. Schlüssel von gelöschten Datensätzen werden nicht neu
vergeben. Ein RecordStore ist durch einen innerhalb der MIDlet Suite eindeutigen Namen
bezeichnet, der 1 bis 32 Unicode-Zeichen umfassen kann, wobei Groß- und Kleinschreibung beachtet wird. Seit MIDP 2.0 kann ein RecordStore über ein Attribut auch für andere
MIDlet Suites zugänglich gemacht werden. Der Zugriff erfolgt dabei über die Bezeichner des MIDlet-Suite-Herstellers, der MIDlet Suite selbst (beides Attribute im JAD, siehe
auch 2.4.2) und den Namen des RecordStores. Dies ist in Abbildung 2.12 veranschaulicht.
Wenn eine MIDlet Suite deinstalliert wird, schreibt die Spezifikation vor, dass alle zugehörigen RecordStores mit gelöscht werden. Für das Öffnen und Anlegen von RecordStores stellt die Klasse RecordStore die statische Methode openStore in verschie-
31
2.4. J2ME - Java 2 Platform Micro Edition
Kapitel 2. Grundlagen
denen Ausprägungen (Überladung) zur Verfügung. Ebenso kann man statisch RecordStores löschen und sich alle zu der MIDlet Suite gehörenden RecordStores auflisten lassen. Nachdem ein RecordStore geöffnet wurde, wird er durch eine Instanz der Klasse
RecordStore repräsentiert, über die alle weiteren Operationen erreichbar sind. Im Wesentlichen sind dies die Methoden addRecord(), setRecord zum Modifizieren eines vorhandenen Datensatzes und deleteRecord. Bei jedem Aufruf dieser Methoden
wird die Version des RecordStores inkrementiert sowie der Zeitpunkt der letzten Änderung festgehalten. Diese Attribute können auch über die API abgerufen werden.
Eine Implementierung des RMS muss zusichern, dass diese Operationen immer atomar
nacheinander ablaufen - Transaktionen werden jedoch nicht unterstützt. Bei der Verwendung von Threads muss daher beachtet werden, dass bei zusammengehörenden, aufeinander folgenden Operationen für das zugehörige RecordStore-Objekt mittels eines
synchronized-Block in Java der exklusive Zugriff sichergestellt ist.
Um nun das Datenmodell einer Anwendung mittels RMS zu speichern, müssen die Objekte zu Byte-Arrays serialisiert werden (siehe Codebeispiel 2.6). Dafür bietet es sich
an, die Klasse java.io.DataOutputStream zu verwenden, die für alle primitiven
Datentypen inkl. String eine Methode zum Schreiben in einen Ausgabestrom besitzt.
Dahinter wird ein weiterer Ausgabestrom vom Typ ByteArrayOutputStream geschaltet, der die serialisierten Daten des DataOutputStreams erhält und eine Methode
toByteArray() zur Verfügung stellt. Zu beachten gilt es dabei, dass String-Objekte,
die den Wert null referenzieren, nicht serialisiert werden können. Statt dessen kann ein
leerer String verwendet werden. Außerdem sollte der äußere Ausgabestrom nach der Benutzung mittels close() geschlossen werden. Analog dazu funktioniert die Deserialisierung aus dem RMS mit den Klassen ByteArrayInputStream und DataInputStream.
Für das Suchen von Datensätzen bietet ein RecordStore(-Objekt) die Methode enumerateRecords(RecordFilter a, RecordComparator b, boolean ke
epUpdated). Optional kann man spezifische Implementierungen von RecordFilter
und RecordComparator übergeben, so dass die Enumeration auf Basis des Inhalts
eines Records gefiltert und die Reihenfolge der Records innerhalb der Enumeration beeinflusst werden kann. Für den Fall, dass für die beiden ersten Parameter null übergeben wird, enthält die Enumeration alle Records des RecordStores und die Reihenfolge ist beliebig. Das Resultat von enumerateRecords() implementiert das Interface
RecordEnumeration, über das man durch die Ergebnismenge der Records iterieren kann und deren Primärschlüssel oder den Inhalt abrufen kann. Der dritte Parameter
keepUpdated gibt an, ob die Datensatzrepräsentation sich mit ändern soll, falls am
32
Kapitel 2. Grundlagen
2.4. J2ME - Java 2 Platform Micro Edition
private String s = "string";
2 private boolean b = true;
private int i = 42;
4
public byte[] serialize() throws IOException {
6
ByteArrayOutputStream byteStream = new ByteArrayOutputStream();
DataOutputStream dataStream = new DataOutputStream(byteStream);
8
dataStream.writeUTF(s);
10
dataStream.writeBoolean(b);
dataStream.writeInt(i);
12
dataStream.close();
14
return byteStream.toByteArray();
}
Quellcode 2.6: Beispiel zur Serialisierung in einen Byte-Strom
RecordStore Änderungen vorgenommen werden. Mit statischen Enumerationen können
Probleme beim Iterieren auftreten, wenn gleichzeitig der RecordStore manipuliert wird.
In diesem Fall bieten sich dynamische Enumerationen an, die jedoch auch mehr Systemressourcen benötigen.
2.4.3.5
kSOAP Web-Service-Bibliothek
Eine Möglichkeit, unter der J2ME- und der J2SE-Plattform Web Services zu konsumieren, bietet das im Sourcecode frei verfügbare Projekt kSOAP1 . Dieser SOAP-Parser ist
speziell für in der Hardware eingeschränkte Geräte gedacht und implementiert daher auch
nicht die gesamte Spezifikation von SOAP. Für übliche Web Services ist der Umfang jedoch nach [Yua06] ausreichend.
Zum Parsing von XML-basierten SOAP-Dokumenten kommt die kXML-Bibliothek in
der Version 2 zum Einsatz, die das XML-Pull API (xmlpull.org) implementiert. Mit diesem Parsing-Modell kann man durch die Elemente des XML-Dokuments seriell iterieren
und benötigte Informationen abfragen, wie z.B. Inhalt des Elements und Attributwerte. Im Vergleich zum etablierten Parsing-Modell Simple API for XML (SAX) kann das
Pull-Modell unter Umständen performanter arbeiten, da der Programmierer die Kontrolle
über den Fluß des Parsings hat. Bei SAX wird das gesamte Dokument seriell bis zum
Ende abgearbeitet und entsprechende benutzerdefinierte Handler-Methoden für die Elemente vom Parser werden aufgerufen. Das Document Object Model (DOM) ist für größere XML-Dokumente auf eingeschränkten Endgeräten ohnehin keine Alternative, da eine
Repräsentation des gesamten Dokuments dabei im Speicher gehalten wird.
1
http://ksoap2.sourceforge.net
33
2.4. J2ME - Java 2 Platform Micro Edition
XML-Datentyp
xsd:int
xsd:long
xsd:string
xsd:Boolean
Kapitel 2. Grundlagen
Java-Datentyp
java.lang.Integer
java.lang.Long
java.lang.String
java.lang.Boolean
Tabelle 2.1: kSOAP Mappings für primitive Datentypen
Für die in SOAP verwendeten Datentypen hat kSOAP bereits für die in Tabelle 2.1 enthaltenen Typen eine standardmäßige Zuordnung zu Java-Datentypen.
Alle weiteren primitiven Datentypen, d.h. Elemente ohne Unterelemente, kapselt kSOAP
in einem Objekt der Klasse SoapPrimitive. Diese enthält den Namen und Namensraum des Datenelements sowie dessen Wert in Form eines Strings. Komplexe Datentypen mit Unterelementen werden durch eine Instanz der Klasse SoapObject repräsentiert, die analog Name und Namensraum des Elements als Attribut
aufnimmt. Die Kind-Elemente werden in einem Vektor als Object gespeichert, gepaart mit einer Instanz von PropertyInfo, in der die XML-spezifischen Namensinformationen gehalten werden. Das referenzierte Object kann dabei je nach KindElement eine Instanz von SoapObject, SoapPrimitive oder einer anwendungsspezifischen Java-Klasse sein. Letzteres ist dann der Fall, wenn beim SOAP-Parser
(SoapSerializationEnvelope) eine Klasse für die Deserialisierung der spezifischen Klasse registriert wurde. Eine solche Klasse kann das Interface Marshal implementieren und stellt somit je eine Methode für das Entpacken von XML-Elementen in ein spezifisches Java-Objekt und umgekehrt zur Verfügung. Als Synonym für
(De)Serialisierung wird auch (Un)Marshaling verwendet. Eine Alternative zu dem LowLevel-Zugriff bietet das Interface KvmSerializable (siehe Abbildung 2.7). Ein Objekt, das diese Schnittstelle implementiert, kann durch den SOAP-Parser automatisiert
sowohl serialisiert als auch deserialisiert werden. Für jedes Attribut des Objekts muss
über die Methode getPropertyInfo eine beschreibende PropertyInfo-Instanz,
die als Parameter übergeben wird, gefüllt werden. Darin wird der Name des zugehörigen XML-Elements des Attributs gespeichert, sowie der Java-Datentyp. Der Datentyp
kann ein primitiver sein (siehe Tabelle 2.1) oder es wird auf eine weitere Klasse verwiesen, die KvmSerializable implementiert. Über die Methoden setProperty
bzw. getProperty kann der SOAP-Parser das entsprechende Attribut, das aus dem
XML-Dokument extrahiert wurde, setzen bzw. den Wert des Attributs erfragen und in das
zugehörige XML-Element serialisieren.
34
Kapitel 2. Grundlagen
2.4. J2ME - Java 2 Platform Micro Edition
1 public interface KvmSerializable {
Object getProperty(int index);
3
int getPropertyCount();
void setProperty(int index, Object value);
5
void getPropertyInfo(int index, Hashtable properties, PropertyInfo info);
}
Quellcode 2.7: KvmSerializable-Schnittstelle von kSOAP
2.4.3.6
Optimierungen für mobile Anwendungen
Die Entwicklung von Anwendungen für mobile Endgeräte bringt einige besondere Anforderungen mit sich. Die Fähigkeiten der Hardware sind stark begrenzt (vgl. MIDP in
Abschnitt 2.4.1), und somit müssen CPU-Zeit und Speicher besonders effizient eingesetzt werden, was in [Yua06] Kapitel 7 näher erläutert wird. Um dies zu erreichen, sind
die verwendeten Bibliotheken für mobile Anwendungen leichtgewichtiger als die J2SEAlternativen, haben also sowohl eine geringere Größe als auch eine Anpassung an den geringen zur Laufzeit zur Verfügung stehenden Speicher. An dieser Stelle bietet sich noch
die Möglichkeit, beim Packaging die Größe zu minimieren. Von der Anwendung nicht
benötigte Klassen können aus den Bibliotheken entfernt werden. Dies übernimmt meist
ein sogenannter Obfuscator, ursprünglich dafür gedacht, den Binärcode von Anwendungen zu verschleiern, um eine Decompilierung zu erschweren. Er läßt sich weiterhin dazu
verwenden, den Binärcode durch Umbenennung von Klassen und Methoden noch zu verkleinern und Methodenaufrufe ’inline’ zur ersetzen. Um den Code aus Bibliotheken nicht
in jede MIDlet-Suite hinzufügen zu müssen, gibt es bei BB-Geräten die Möglichkeit, shared libraries zu installieren, die von mehreren Anwendungen gleichzeitig benutzt werden.
Mit der noch in Planung befindlichen Version 3 des MIDP (JSR 271) ist die Aufnahme
von gemeinsamen Bibliotheken in den Standard geplant.
Ein weiterer Ansatzpunkt für Performance-Optimierungen ist die Garbage Collection,
die soweit wie möglich vermieden werden sollte, da sie kostbare CPU-Zeit in Anspruch
nimmt. Empfohlene Möglichkeiten nach [Yua06] den Speicherverbrauch zu reduzieren
sind:
1. Arrays gegenüber Collection Containern bevorzugen.
2. Bei String-Manipulationen eine StringBuffer-Instanz verwenden (Modifikationen von String-Objekten erzeugen neue Instanzen).
35
2.4. J2ME - Java 2 Platform Micro Edition
Kapitel 2. Grundlagen
3. Ressourcen wie Netzwerkverbindungen, RecordStores und Filehandles frühestmöglich wieder freigeben. In Java lassen sich durch den Einsatz von finallyBlöcken Ressourcen auch nach Auftritt einer Exception freigeben.
4. Design Pattern sollten daraufhin überprüft werden, dass sie nicht zu viele Klassen
und Schnittstellen-Schichten mit sich bringen. In [Yua06] wird als Beispiel eine
schlankere Screen-basierte Logik statt einer klassischen Model View Controller
(MVC)-Architektur bevorzugt.
5. Erzeugte Instanzen nach Möglichkeit wiederverwenden, anstatt neue zu erzeugen.
Um Ein- und Ausgabe-Operationen zu beschleunigen, empfiehlt es sich, die vom Endgerät angesprochenen externen Netzwerkschnittstellen nach außen hin nicht zu feingranular
zu gestalten, so dass insgesamt weniger Aufrufe dieser Schnittstellen notwendig sind.
Desweiteren sollten diese Operationen gepuffert und nicht zeichenweise angesprochen
werden. Bei den meisten J2ME-Schnittstellen bietet sich eine Kombination aus einem
byte[]-Puffer und einem ByteArrayOutputStream an (bzw. analog für einen Eingabestrom).
Der Netzwerkverkehr und die Latenz für den Benutzer lassen sich reduzieren, indem
J2ME-Anwendungen Anwendungsdaten lokal speichern. Dies ermöglicht zudem unter
Umständen auch eine gewisse Funktionalität der Anwendung, wenn das Gerät keine Verbindung zu einem Netzwerk herstellen kann. Beim Zwischenspeichern der Daten ist zu
beachten, dass dies möglichst zeitnah geschieht, um Datenverluste zu vermeiden, auch
unter dem Gesichtspunkt, dass leistungsfähige Endgeräte noch unzureichende Betriebslaufzeiten im mobilen Einsatz haben.
Eine benutzerfreundliche Anwendung sollte benutzerspezifische Einstellungen ebenfalls
speichern, lange Operationen auf mehrere Dialoge aufteilen und Rückmeldungen über
den Status geben.
Ein weiterer Aspekt bei der Entwicklung einer Anwendung ist, dass sie auf möglichst
vielen Endgeräten lauffähig sein sollte. Dabei hilft es, wenn sich die Applikation über
einen JAD konfigurieren lässt und die Benutzerschnittstelle im Quellcode leicht angepasst
werden kann.
Für die Entwicklung von J2ME-Anwendungen auf den BB-Endgeräten hat RIM einen
Programmier-Leitfaden in [RIM05] ab Seite 30 integriert, der weitere Java-Optimierungen auf Quellcode-Ebene liefert.
36
Kapitel 2. Grundlagen
2.4.4
2.4. J2ME - Java 2 Platform Micro Edition
Sicherheitskonzept
Über den JAD besteht seit MIDP 2.0 auch die Möglichkeit, MIDlet Suites mittels PublicKey-Verfahren zu signieren. Dazu wird eine Prüfsumme des JARs mit dem privaten
Schlüssel signiert und zusammen mit dem zugehörigen öffentlichen Schlüsssel in Form
eines Zertifikats in den JAD eingetragen. Bei Installation der MIDlet Suite wird die Prüfsumme des JARs gebildet, mittels Zertifikat die Prüfsumme im JAD entschlüsselt und
mit der ermittelten verglichen. Das Zertifikat selbst muss immer von einer Certification
Authority (CA) signiert sein. So ist sichergestellt, dass der Inhalt der sogenannten Trusted MIDlet Suite seit dem Zeitpunkt der Signierung nicht verändert wurde und einem
bestimmten Softwarehersteller anhand des Zertifikats zugeordnet werden kann. Um die
Integrität des Zertifikats zu überprüfen, sind in den Endgeräten üblicherweise die Zertifikate der Root-CAs hinterlegt. Daher muss der JAD eine Zertifikat-Kette bis hin zu einem
Root-Zertifikat beinhalten. Im einfachsten Fall ist dies nur ein Zertifikat (das des Softwareherstellers), wenn es von einer Root-CA signiert ist. Eine MIDlet-Suite, die keine
Signatur im JAD enthält, wird als Untrusted MIDlet Suite eingestuft und unterliegt dadurch Einschränkungen beim Zugriff auf die J2ME APIs. In diesem Fall muss der Nutzer
explizit für Verbindungen über HTTP zustimmen. Alle weiteren Netzwerkfunktionalitäten im Package javax.microedition.io sind ausschließlich durch Trusted MIDlet
Suites benutzbar. Anwendungen gemäß der MIDP 1.0 Spezifikation werden ebenfalls als
untrusted eingestuft.
An dieser Stelle sei noch erwähnt, dass Attribute im JAD gleichnamige im Manifest überschreiben, außer es handelt sich um eine Trusted MIDlet Suite. In diesem Fall wird die
Installation abgebrochen, wenn sich die Werte der Attribute in JAD und Manifest unterscheiden.
37
2.4. J2ME - Java 2 Platform Micro Edition
38
Kapitel 2. Grundlagen
Kapitel 3
Analyse
In diesem Kapitel werden zunächst die Anforderungen an die gesamte Systemarchitektur und die zu entwickelnde mobile Client-Anwendung erläutert, die von nun an auch
mobileCRM genannt wird. Dies geschieht durch die Rahmenbedingungen, die durch die
Betreuung seitens der Firma CSC und der FH Wiebaden festgelegt wurden, sowie durch
eine Beschreibung der Anwendungsfälle, die die Anwendung abdecken soll. Innerhalb
dieses Rahmens werden darauffolgend die Möglichkeiten zur Realisierung untersucht,
aufgegliedert in die einzelnen Systembestandteile Server, Mobile-Gateway und Client.
3.1
3.1.1
Anforderungen
Rahmenbedingungen
Die bei der Themenstellung gemachten Vorgaben beeinflussen Analyse und Design der
Diplomarbeit. Sie begrenzen die möglichen Lösungansätze für die Realisierung und werden in diesem Abschnitt ausführlich beschrieben:
1. Nutzung der BlackBerry-Enterprise-Architektur
Vorgegeben ist die Verwendung der BB-Infrastruktur (siehe Kapitel 2.1). Die für
diese Arbeit wesentlichen Teile dieser mobilen Plattform sind der BES im Unternehmensnetzwerk und ein spezielles mobiles Endgerät, auf dem die mobile Anwendung läuft. Ein BB-Endgerät vom Typ 7100v ist vorhanden. Insbesondere soll auch
die Push-Funktionalität eingesetzt werden, um Daten aus einem SAP-System über
den BES an das mobile Endgerät zu übermitteln.
39
3.1. Anforderungen
Kapitel 3. Analyse
2. Anbindung an SAP-CRM im Unternehmen
Die BB-Anwendung soll mit einem SAP-CRM 4.0 System (siehe Kapitel 2.3.1)
kommunizieren und dadurch prototypisch die Funktionalität zum Verwalten von
Aktivitäten im CRM bieten.
3. Smart-Client-Anwendung
Die mobile Anwendung soll ein sogenannter Smart Client sein. Im Gegensatz zu
einer Browser-basierten Applikation benutzt der Smart Client die lokale Benutzerschnittstelle des BB-Endgeräts und macht von der Möglichkeit Gebrauch, Daten
lokal zu speichern.
4. Einsatz von Web-Service-Technologien
Die Kommunikation zwischen dem SAP-CRM und der mobilen Anwendung soll
durch einen Web Service erfolgen. Die damit in Zusammenhang stehenden Technologien sind speziell für plattformübergreifende Anwendungen sehr gut geeignet
und ein aktueller Technologie-Trend im Rahmen von SOA.
5. Generische Vorgehensweise
Ein weiteres Ziel dieser Arbeit ist es, bei der Realisierung möglichst generisch vorzugehen, so dass bei der Entwicklung von weiteren mobilen Anwendungen auf Basis der SAP- und BB-Infrastruktur oder Web Services davon profitiert werden kann.
Abbildung 3.1: Grobe Systemarchitektur
Aus diesen Vorgaben resultieren zunächst die in Abbildung 3.1 vereinfacht dargestellten
Komponenten, die für diese Arbeit relevant sind und untersucht werden. Diese Systemarchitektur wird in den Unterkapiteln ab 3.2 ff. detailliert betrachtet. Im Folgenden wird
zuerst genauer definiert, welche Anforderungen die mobile Applikation aus Anwendersicht erfüllen soll.
40
Kapitel 3. Analyse
3.1. Anforderungen
Abbildung 3.2: Server-initiierte Anwendungsfälle
3.1.2
Anwendungsfälle
In diesem Abschnitt werden die Anwendungsfälle definiert, die abstrakt beschreiben, welche Interaktionen zwischen dem Benutzer, mobileCRM und dem SAP-System stattfinden.
Die Anwendungsfälle wurden in Server- und Client-initiiert unterschieden. In den Abbildungen 3.2 und 3.3 sind die sogenannten Use-Cases mit UML modelliert.
Die Anwendungsfälle beziehen sich auf das Aktivitätsmanagement. Der Workflow sieht
dabei so aus, dass Änderungen am SAP-CRM-System über eine Push-Nachricht an alle beteiligten Clients propagiert werden, und umgekehrt Änderungen auf dem Endgerät
möglichst direkt zum SAP-CRM-System übertragen werden. Nach Anlegen einer Aktivität kann sie den Status open oder In Process annehmen, und wird durch den Status
Completed oder auch Rejected abgeschlossen. Dabei kann der Erledigungsstatus
noch prozentual hinterlegt werden. Im SAP-CRM-System selbst wird eine Aktivität nie
gelöscht, sondern bleibt als Beleg erhalten.
3.1.2.1
Server-initiiert
• Aktivitätsänderung
Sobald eine Aktivität im SAP-System neu angelegt oder modifiziert wird, muss
an die Ansprechpartner auf Unternehmensseite ein Update auf das BB-Endgerät
geschickt werden. Dazu muss für den Ansprechpartner in der Aktivität seine
BlackBerry-E-Mail-Adresse hinterlegt sein.
• Daten synchronisieren
Nach einer Aktivitätsänderung werden die neuen Daten vom SAP-System über die
Push-Funktion des BES an die zugehörigen BB-Endgeräte geschickt. Die mobile
Anwendung auf dem Endgerät empfängt und speichert die Aktivität.
41
3.1. Anforderungen
Kapitel 3. Analyse
Abbildung 3.3: Client-initiierte Anwendungsfälle
3.1.2.2
Client-initiiert
In die Kategorie Client-initiiert fallen Aktionen, die der Benutzer in der mobilen Anwendung ausführen kann.
• Aktivitäten auflisten
Alle auf dem BB-Endgerät lokal gespeicherten Aktivitäten werden aufgelistet, zur
Auswahl für weitere Aktionen mit einer Aktivität.
• Aktivität anlegen
Der Benutzer kann in der Anwendung eine neue Aktivität anlegen. Dafür werden
die essentiellen Daten einer Aktivität eingegeben und gespeichert. Dabei wird nur
ein Teil der Attribute unterstützt, die im SAP-System hinterlegt werden können.
• Aktivität modifizieren
Ist eine Aktivität auf dem Endgerät bereits vorhanden, so können die Daten verän-
42
Kapitel 3. Analyse
3.1. Anforderungen
dert und abgespeichert werden. Darunter fällt insbesondere auch das Ändern des
Status der Aktivität.
• Aktivität löschen
Eine Aktivität kann vom Anwender gelöscht werden. Dies bezieht sich allerdings
nur auf die lokale Speicherung auf dem Endgerät, im SAP-System werden keine
Datensätze gelöscht. Zum Abschließen der Aktivität wird lediglich der Status auf
Completed gesetzt.
• Aktivität anzeigen
Der Anwender kann eine gespeicherte Aktivität auswählen und sich die Daten anzeigen lassen. Eine Interaktion mit dem SAP-System findet dabei nicht statt. Es
wird nur eine Auswahl der Attribute dargestellt, die im SAP-System hinterlegt werden können.
• Aktivitätenliste anfordern
Alle Aktivitäten, die den Benutzer der mobilen Anwendung betreffen, werden
Benutzer-initiiert auf das Endgerät geladen und abgespeichert. Somit lassen sich
im SAP-System bereits vorhandene Aktivitäten anfordern.
• Daten synchronisieren
Neue oder modifizierte Aktivitäten auf Client-Seite werden automatisch mit dem
SAP-System abgeglichen. Für diesen Vorgang muss das Endgerät eine Verbindung
zum BES haben. Ein Synchronisationsvorgang kann auch vom Benutzer initiiert
werden. Dies ist beispielsweise sinnvoll, falls ein automatisierter Synchronisierungsvorgang zuvor fehlgeschlagen ist.
3.1.3
Problembereiche
Die Analyse lässt sich in verschiedene Problembereiche aufteilen, welche jeweils verschiedene Komponenten der gesamten Systemarchitektur betreffen. Diese sind zur Einordnung im Folgenden kurz umrissen.
• Synchronisation
Konsistenter Datenabgleich zwischen Client und Server bei konkurrierenden Zugriffen.
• Usability
Benutzerfreundlichkeit und Internationalisierung.
43
3.2. Server
Kapitel 3. Analyse
• Web Service
Bereitstellung einer SAP-Schnittstelle durch einen serverseitigen Web Service und
dessen Kommunikation mit dem Client. Dabei geht es um die Auswahl oder Programmierung einer Implementierung auf Server- und Client-Seite, sowie deren
Kompatibilität.
Die nachfolgenden Teile der Analyse sind anhand der einzelnen Systemkomponenten Server, Mobile Gateway und Mobile Client gegliedert. Die Betrachtung beginnt serverseitig,
da das SAP-CRM-System den Informationsfluss, die Beschaffenheit und den Zusammenhang der Daten vorgibt.
3.2
3.2.1
Server
SAP-CRM
Die in den Anforderungen festgelegte Funktionalität der Anwendung in Bezug auf Aktivitäten kann durch Benutzen der BAPI- und RFC-Schnittstellen des mySAP-CRMModuls in der Version 4.0 abgedeckt werden. Die Modifikation von Aktivitäten - also
ändern und neu anlegen - lässt sich über die Funktion CRMXIF_ORDER_SAVE durchführen. Eine Liste von mehreren benutzerspezifischen Aktivitäten kann durch BAPI_ACTIVITYCRM_GETDETAILMULT abgefragt werden. Hierfür werden jedoch die eindeutigen IDs der Aktivitäten benötigt, die in einer vorhergehenden Abfrage ermittelt werden müssen. Dies lässt sich durch den Aufruf von CRM_MY_ACTIVITIES vereinfachen,
der als Parameter den SAP-Benutzernamen erwartet und alle zugehörigen Aktivitäten zurück liefert.
3.2.2
Datenmodellierung
Das graphische Frontend von SAP bietet für das Management von Aktivitäten den in Abbildung 2.7 bereits vorgestellten, umfangreichen Interaktionsdialog, der viele Verweise
zu weiteren Dialogen enthält wie beispielsweise mehr Details zu den Kontaktpersonen.
Diese Menge von Informationen ist für die Bearbeitung auf einem eingeschränkten mobilen Endgerät zu groß, um übersichtlich dargestellt werden zu können. In Tabelle 3.1
sind die auf dem BB-Endgerät verfügbar gemachten Attribute aufgelistet und anhand von
44
Kapitel 3. Analyse
3.2. Server
Beispieldaten verdeutlicht. Zum Einen sind dabei Datenfelder enthalten, die das SAPSystem verpflichtend als belegt voraussetzt. Weiterhin werden für die technische Umsetzung einige Attribute benötigt wie beispielsweise die eindeutige ID und die Version einer
Aktivität. Zum Anderen wurden weitere Attribute abgebildet, die für das Szenario eines
mobilen Einsatzes Sinn ergeben. Dies sind vor allem die Attribute, die den Status, die
Vervollständigung in Prozent und den Zeitpunkt einer Aktivität definieren.
3.2.3
Web Service zum SAP-CRM-System
Um Punkt 2 der Rahmenbedingungen in Abschnitt 3.1.1 zu erfüllen, muss eine Schnittstelle in Form eines Web Service für das SAP-CRM-System geschaffen werden. Dafür
bieten sich mehrere Alternativen:
• Eigene Web-Service-Implementierung innerhalb des Application-Server von SAP
• SAP-XI Middleware
• SAP-CRM Web-Service-Schnittstelle (CRM-spezifische Middleware)
• Middleware von Drittanbietern, die SAP-Adapter besitzt
Das CRM-Modul verfügt erst ab der Version 5 über eine Web-Service-Schnittstelle. Eine
mögliche Alternative bietet sich durch die NetWeaver-Komponente, auf der das CRMModul aufsetzt. Im Application Server Web AS 6.4 kann eine J2EE-Applikation ablaufen,
die über RFC- und BAPI-Aufrufe das CRM ansprechen kann und diese Schnittstellen als
Web Service zugänglich macht. NetWeaver stellt außerdem das XI-Modul (siehe Kapitel 2.3.2) zur Verfügung, das für den Datenaustausch zwischen SAP-Modulen und auch
Fremdanwendungen via Web Services gedacht ist. Um Punkt 5 der Rahmenbedingungen (3.1.1) bestmöglichst zu erfüllen, sollte XI zur Realisierung näher betrachtet werden.
Eine Implementierung auf Server-Seite entfällt dabei und erleichtert weitere mobile Anwendungen. Ein weiterer Vorteil ist die zentrale Konfiguration der zu integrierenden Systeme, die XI prinzipbedingt mit sich bringt. Neben XI gibt es auch weitere MiddlewareProdukte von Drittanbietern wie IBM oder Oracle, die ebenfalls an SAP-Module angebunden werden können. Für die Umsetzung dieser Arbeit wurde XI verwendet, da entsprechende Softwarelizenzen und administrierte Systeme schon vorhanden sind. Innerhalb des Unternehmens kann bereits auf Erfahrung mit dem SAP-System zurückgegriffen
werden.
45
3.2. Server
Kapitel 3. Analyse
Attribut-Bezeichnung
activityPartnerId
activityPartner
category
categoryText
priority
priorityText
goal
goalText
directionText
direct
objectType
validFrom
validTo
fromTime
toTime
contactPersonId
contactPerson
salesRepresentative
employeeResponsible
createdBy
changedOn
createdOn
systemStatusId
systemStatusText
userStatusId
userStatusText
completion
transactionDescription
transactionType
transactionNumber
objectGUID
organizationalUnit
distributionChannel
salesOrganization
changedBy
Beispielwert
0000600039
Tobias Foo / 73365 Flensburg
001
Sales Call
3
High
005
Better cust. retent.
Outbound
1
BUS2000126
2007-06-22
2007-06-22
16:45:00
16:55:00
0000600037
Foo / 76228 Himmelbrug
2000000010
0000500550
AOPATZ
20070214172936
20070122155130
I1002
Open Planned
E0001
Open
000
Wichtiger Anruf, 50 mio projekt
ZMS0
0000000201
urxewgMZdka41RkHMscGgw==
S 50000790
01
O 50000609
Constant
Tabelle 3.1: Übersicht der Attribute einer Aktivität in mobileCRM
46
Kapitel 3. Analyse
3.3. Mobile Gateway
Durch die Benutzung von XI ergibt sich auch, welches der beiden in Abschnitt 2.1.4
vorgestellten Push-Protokolle verwendet wird. Da die ausgehenden Nachrichten von XI
XML-basiert sind, ist das PAP aus der WAP-Spezifikation nicht geeignet, da dieses die
Nachricht als MIME-Multipart-Nachricht aufbaut. Das RIM-Push-Protokoll hingegen
enthält alle für die Übertragung notwendigen Informationen im URI der Push-Anfrage
an den BES oder in optionalen HTTP Headern. Im Gegensatz zu PAP kann die Payload
dadurch XML-konform sein.
3.3
Mobile Gateway
Die Verwendung der BlackBerry-Plattform ist Vorgabe nach Punkt 1 der Rahmenbedingungen in Abschnitt 3.1.1. Daher werden an dieser Stelle keine alternativen Lösungen
betrachtet, die analog zum BES als Mobile-Gateway für mobile Endgeräte eine sichere
Verbindung zum Unternehmensnetzwerk herstellen können.
Unternehmen wie beispielsweise Audi hatten im Jahr 2005 Bedenken gegenüber der Lösung geäußert, da durch die externe BlackBerry-Infrastruktur des Herstellers RIM (siehe
Abbildung 2.1) prinzipiell die Möglichkeit der Industriespionage besteht. Gewissheit würde an dieser Stelle nur Einsicht in den Quellcode bringen, der von RIM allerdings nicht
zur Verfügung gestellt wird. Die Sicherheitsfunktionen der BlackBerry-Architektur sind
formal sehr umfangreich (siehe Abschnitt 2.1). Neben der Verschlüsselung des Datenverkehrs werden auch IT-Richtlinien unterstützt, und die auf dem Endgerät gespeicherten
Daten können ebenso kodiert und drahtlos gelöscht werden. Ein Artikel zur Kritik an der
BlackBerry-Nachrichten-Verschlüsselung ist nachzulesen bei [Sch05], der unter anderem
zwei Sicherheitsstudien zusammenfasst und zu dem Schluß kommt, dass diese Architektur prinzipiell als sicher einzustufen ist, unter der Annahme, dass die Algorithmen korrekt
implementiert sind und keine Hintertüren in der Software vorhanden sind. Der Quellcode
des BES wurde im Rahmen einer der zuvor erwähnten Studien untersucht, offen zugänglich ist der Code jedoch nicht, so dass die Sicherheit dennoch Vertrauen in den Hersteller
voraussetzt.
In Hinblick auf die Performance des BES wurden vom Hersteller weitreichende Funktionen implementiert. Die einzelnen Komponenten des Systems können bei Bedarf jeweils
auf einer eigenen Servermaschine verteilt betrieben werden, so dass die Performance skalierbar ist. Ebenso ist es möglich, mehrere Instanzen des BES bereit zu stellen, um eine
große Anzahl von BB-Endgeräten damit arbeiten zu lassen. Durch das symmetrische Verschlüsselungsverfahren wird der Overhead so gering wie möglich gehalten und gleichzei-
47
3.4. Mobile Client
Kapitel 3. Analyse
tig die Payload durch die Dispatcher-Komponente des BES komprimiert. Dies ist vor allem für GPRS-basierte Endgeräte entscheidend, da die Bandbreite dort sehr eingeschränkt
ist.
Für die Realisierung wird der BES für MS Exchange in der aktuellen Version 4.1 in Kombination mit Windows 2003 Server verwendet. Die Wahl des E-Mail-Systems (IBM Lotus Domino und Novell GroupWise sind die Alternativen) ist dabei nicht von Bedeutung,
da es nur für den BES selbst benötigt wird und die mobile Anwendung keine E-MailFunktionen benutzt. Der BES kann nur auf den Server-Betriebssystemen Windows 2000
Server und Windows 2003 Server von Microsoft betrieben werden. Als Lizenz für den
BES wird eine kostenlose Trial-Version von RIM benutzt, deren Einschränkung darin besteht, dass nur ein Endgerät damit betrieben werden kann, was für diese Untersuchung
jedoch auch ausreichend ist.
3.4
Mobile Client
Die zu realisierende mobile Anwendung für das BB-Endgerät soll gemäß den Rahmenbedingungen über einen Web Service Funktionalitäten des SAP-CRM zur Verfügung stellen.
SAP bietet eine Gesamtlösung für den mobilen Zugriff auf CRM-Systeme, die sogenannte SAP Mobile Infrastructure (MI). MI bietet für PDAs und Laptops eine J2SE-basierte
Anwendung, die Logik, lokales Zwischenspeichern und Arbeiten im Offline-Modus unterstützt. Für eingeschränkte mobile Endgeräte ist nur eine Browser-basierte Lösung vorgesehen, die diese Funktionen nicht unterstützt. Die MI kann daher nicht als gleichwertige Alternative zu dem in dieser Arbeit entwickelten mobileCRM gesehen werden. Die
Kommunikation des BB-Endgeräts mit dem BES (siehe Abschnitt 2.1.1) funktioniert auf
zwei möglichen Wegen. Serverseitig im Unternehmen initiierte Verbindungen werden als
Push-Nachricht über den BES an das Endgerät gesendet, der dabei als Proxy fungiert, und
Nachrichten für Endgeräte im Offline-Modus zwischenspeichert. Client-initiierte Verbindungen werden über das MDS-Modul des BES aufgebaut, das ebenfalls eine Proxyfunktion übernimmt.
Für die Implementierung der mobilen Anwendung bieten sich folgende Möglichkeiten:
• BB-MDS-Studio
• J2ME mit der API in MIDP und CLDC
• J2ME unter teilweiser Nutzung der propietären API von RIM
48
Kapitel 3. Analyse
3.4. Mobile Client
Anwendungen für aktuelle BB-Endgeräte werden prinzipiell in J2ME (siehe Abschnitt
2.4) und ggf. herstellerspezifischen Erweiterungen programmiert. RIM bietet zusätzlich
mit dem MDS-Studio (vgl. Abschnitt 2.1.2) eine Möglichkeit, auf Web Services basierende Anwendungen IDE-gestützt sehr schnell entwickeln zu können. Diese Lösung bietet
jedoch keinen Zugriff auf die Java-API des Endgeräts. Dadurch ist keine lokale Speicherung von Daten möglich, und das Arbeiten im Offline-Modus (Rahmenbedingungen
Punkt 3) wäre folglich nicht möglich. Ebenso ist eine Übertragung von Aktivitätsdaten
in das PIM somit von vornherein ausgeschlossen. Mit MDS-Studio erstellte Programme
werden in einem proprietären XML-Format gespeichert, und von der MDS-Runtime im
Endgerät in Java-Aufrufe umgesetzt. Daher sind an dieser Stelle keine Erweiterungen
möglich.
Eine alternative Lösungsmöglichkeit besteht in einer J2ME-Anwendung, die zudem auch
kompatibel zu anderen Endgeräten ist. Diese Kompatibilität käme allerdings erst zum
Tragen, wenn die Anwendung auf eine andere mobile Plattform portiert werden sollte.
Weiterhin sieht diese Möglichkeit für die Benutzerschnittstelle die abstrakte API des graphischen Framework LCDUI (siehe Abschnitt 2.4.3.3) innerhalb J2ME vor. Der Vorteil
von LCDUI liegt darin, dass die GUI sich leicht auf andere Endgeräte portieren läßt. Dabei ist das Erscheinungsbild der graphischen Komponenten, Bedienelemente und Menüs
automatisch an das Endgerät angepasst, und der Anwender findet sich durch die gewohnte Gestaltung so leichter zurecht. Erreicht wird dies durch angepasste Implementierungen
der LCDUI API durch die Hersteller der Endgeräte. Die Kommunikation mit dem Web
Service muss in J2ME jedoch selbst implementiert bzw. an eine Bibliothek delegiert werden, während MDS-Studio dies kapselt.
Statt die API von MIDP für Benutzerschnittstelle und Netzwerk-Kommunikation zu verwenden, kann auch die proprietäre API des Herstellers RIM verwendet werden. Die zuvor
erwähnten Vorteile entfallen dabei. Um Zugriff auf die API zu erlangen, muss die Anwendung mit kostenpflichtigen Schlüsseln von RIM signiert werden. Als Rahmenumgebung
für die Implementierung von mobileCRM kommt daher J2ME mit den APIs von MIDP
und CLDC zum Einsatz.
3.4.1
Kommunikation mit dem Web Service
Ein wesentliches Merkmal der mobilen Anwendung ist, dass der Datenaustausch mit dem
SAP-CRM-System über einen Web Service stattfinden soll. In diesem Abschnitt geht es
um die Auswahl entsprechender Protokolle und deren Implementierungen, die für den
49
3.4. Mobile Client
Kapitel 3. Analyse
Web Service eingesetzt werden sollen. Als Protokoll kommen die folgenden beiden Möglichkeiten in Betracht:
• SOAP
• REST-basierter Web Service mit XML-Payload gemäß URI-spezifischer XMLSchemata.
Für das SOAP-Parsing gibt es im J2ME-Umfeld mehrere Alternativen:
• kSOAP Bibliothek (Open Source)
• Referenz-Implementierung (RI) des JSR 172 von Sun (Open Source)
• Wingfoot SOAP-Client (Closed Source)
Eine mögliche Protokollkombination wurde mit SOAP und WSDL bereits in Abschnitt
2.2 beschrieben, ebenso wie ein SOAP-Parser für J2ME mit kSOAP in 2.4.3.5. In den
nächsten beiden Abschnitten wird zunächst mit der JSR 172 eine weitere SOAP-ParserAPI vorgestellt, sowie durch REST eine Alternative zum SOAP-Protokoll. Darauf folgen
minimale Testanwendungen für die SOAP-Bibliotheken und die Push-Funktion, bevor es
abschließend zu einer Auswertung und Abwägung kommt.
3.4.1.1
JSR 172 - Web-Service-API für J2ME
Mit dem JSR 172 wurde im März 2004 innerhalb des JCP die endgültige Version einer
Web-Service-API für Endgeräte mit CLDC oder CDC festgelegt (für die Spezifikation
siehe [EY03]). Sun stellt eine Referenz-Implementierung1 für diese API im Sourcecode
frei zur Verfügung. Eine Übersicht bietet Kapitel 17 in [Yua06]. Hersteller von Endgeräten können eine Implementierung dieser API als optionales Paket zur Verfügung stellen
- neuere Mobilfunkgeräte bieten diese Option mittlerweile, die BB-Modelle von RIM jedoch nicht. Die API baut auf Untermengen der Java API for XML Processing (JAXP)
v1.2 und der Java API for XML-based RPC (JAX-RPC) v1.0 auf, die bereits für die J2SE
existieren. Die JAXP wurde auf einen SAX-Parser reduziert.
Primitive Datentypen innerhalb von SOAP werden analog zu kSOAP in entsprechende Datentypen in Java umgewandelt. Für komplexe Typen werden JavaBeans mit Getund Set-Methoden erzeugt. Im Unterschied zu kSOAP bietet JSR 172 keine Möglichkeit,
komplexe SOAP-Datentypen mit eigenen Java-Klassen zu assoziieren.
1
http://www.sun.com/software/communitysource/j2me/wsa/download.xml
50
Kapitel 3. Analyse
3.4. Mobile Client
Abbildung 3.4: Zusammenhang der Komponenten von JSR 172
Sowohl das XML-Parsing als auch die entfernten SOAP-Aufrufe werden durch die
Schnittstelle des JSR 172 vollständig gekapselt. Eine Übersicht der einzelnen Komponenten und der Kommunikation zwischen ihnen kann der Abbildung 3.4 entnommen werden.
Die Aufrufe erfolgen über einen sogenannten Stub, in dem die Operationen des anzusprechenden Web Service als lokale Methoden repräsentiert werden. Der Stub wird mit Hilfe
eines Stub-Generators erzeugt, der die zugehörige WSDL-Beschreibung des Web Service
benötigt. Dies vereinfacht und beschleunigt die Anwendungsentwicklung stark, und stellt
durch die automatisierte Verarbeitung der Web-Service-Beschreibung einen deutlich weniger fehleranfälligen Ansatz dar. Jedoch ist im Gegensatz zu kSOAP bei der JSR 172 API
auch kein Zugriff auf die XML-Struktur der SOAP-Nachrichten vorgesehen. Der Stub ist
Teil der Client-Anwendung und kommuniziert über das Service Provider Interface (SPI)
mit der Implementierung des JSR 172.
Durch diese Interface-Zwischenschicht ist es möglich, die Anwendung inkl. der generierten Stubs beizubehalten, wenn man die Implementierung wechselt, z.B. die Anwendung
auf einem Endgerät eines anderen Herstellers installiert. Ebenso bietet sich dadurch die
Möglichkeit, zwischen dem Client und dem Web Service ein Gateway zu integrieren, das
das SOAP-Parsing übernimmt. Das Protokoll zwischen Gateway und der Implementierung des JSR 172 könnte dadurch ein optimiertes Binärprotokoll sein, das für die ClientAnwendung jedoch transparent wäre.
3.4.1.2
REST-Web-Services
Der REpresentational State Transfer (REST, siehe [Bay02]) ist eine Architektur, die im
WWW schon lange eingesetzt wird. In einem Netzwerk aus Clients und Servern stellen
die Server über das HTTP-Protokoll Ressourcen bereit, die durch einen URI eindeutig
51
3.4. Mobile Client
Kapitel 3. Analyse
identifiziert werden und eine bestimmte Repräsentation haben, z.B. HTML oder XML.
Die Ressourcen können untereinander verknüpft sein. Indem der Client der Verknüpfung
folgt, erhält er von dem Server die Repräsentation der angefragten Ressource - der Zustand des Clients ändert sich damit.
3.4.1.3
Voranalysen
• Push-Test
Die Push-Funktionalität ist ein Teil von Punkt 1 der Rahmenbedingungen (Abschnitt 3.1.1). Um die korrekte Konfiguration des BES und die Funktionsweise der
Push-Registry (siehe Abschnitt 2.4.3.2) auf dem Endgerät zu testen, wurde eine minimale Anwendung implementiert. Code-Beispiele aus dem Developer-Guide von
RIM, Kapitel „Creating client/server push applications“(siehe [RIM05]), konnten
dabei teilweise übernommen werden. Die Testanwendung besteht aus einem ServerTeil, der mittels einer HTTP POST Anfrage an den BES Push-Port Daten sendet,
und einem Client-Teil, der bei eingehenden Daten gestartet wird.
MIDlet-1: PushTestMIDlet,,com.csc.aopatz.bb.test.PushTestMIDlet
2 MIDlet-Jar-URL: PushTestClient.jar
MIDlet-Name: PushTestClient Midlet Suite
4 MIDlet-Permissions: javax.microedition.io.PushRegistry,
javax.microedition.io.Connector.socket,
6
javax.microedition.io.Connector.serversocket
MIDlet-Push-1: http://:7777,
8
com.csc.aopatz.bb.test.PushTestMIDlet, *
MIDlet-Vendor: CSC
10 MIDlet-Version: 1.0.15
MicroEdition-Configuration: CLDC-1.1
12 MicroEdition-Profile: MIDP-2.0
Quellcode 3.1: JAD der Push-Test-Anwendung
Für die Benutzung der PushRegistry und die Kommunikation über die aufgebaute
Verbindung muss die Client-Anwendung (PushTestClient) entsprechende Berechtigungen für die Klassen besitzen. Dies geschieht über den JAD, der in Abbildung
3.1 dargestellt ist. Außerdem muss bei der Installation des MIDlets auf dem Endgerät der Port reserviert werden, auf dem die PushRegistry eingehende Verbindungen
für die Anwendung entgegen nehmen soll. Dazu bedarf es ebenfalls eines Eintrags
im JAD - in diesem Fall wurde Port 7777 gewählt. Für Push-Verbindungen schreibt
die MIDP-Spezifikation nicht vor, welche Protokolle unterstützt werden müssen.
Während das WTK 2.5 von Sun als Protokoll socket:// erwartet, muss für BB-
52
Kapitel 3. Analyse
3.4. Mobile Client
Endgeräte http:// verwendet werden. Nachdem die Applikation von der PushRegistry gestartet wurde, werden die eingehenden Daten gelesen und auf dem
Display in einer Textbox angezeigt.
Der Server (PushTestServer) sendet eine aufgezeichnete SOAP-Nachricht inkl.
HTTP Headern durch das RIM-Push-Protokoll an den BES, wobei die E-MailAdresse und der Port des Endgeräts bzw. der Client-Anwendung spezifiziert werden. Nachdem der Client von der PushRegistry gestartet wurde, öffnet er die eingehende Push-Verbindung und liest die einkommenden Daten. Diese werden in einer
graphischen Komponente als Text angezeigt.
• Test von JSR 172 mit XI Web Service
Die mobilen Endgeräte von RIM stellen zur Zeit keine Implementierung der WebService-API des JSR 172 zur Verfügung. Daher wurde die Referenz-Implementierung (RI) von Sun verwendet. Durch die Testanwendung soll geklärt werden, ob das
WSDL-Dokument des SAP-Web-Service mit dem Stub-Generator aus dem WTK
kompatibel ist und ob das Parsing der SOAP-Nachrichten mit der RI funktioniert.
Weiterhin muss abgeschätzt werden, inwiefern die RI modifiziert werden muss, um
eine Nachricht über eine Push-Verbindung entgegenzunehmen.
Die Testanwendung (sapjsr172test) besteht aus den Packages der Referenz-Implementierung, die mit dem Präfix csc versehen wurden, um Namenskonflikte zu vermeiden, und dem dem Java-Package com.csc.sap_jsr172_test. Der SAPWeb-Service ist zunächst so konfiguriert, dass er eine Aktivität per Request entgegen nimmt und dann über den BES an das entsprechende BB-Endgerät übermittelt. Anhand der WSDL-Beschreibung können die Stubs problemlos generiert werden, Voraussetzung ist allerdings, dass primitive Datentypen verwendet werden.
So muss beispielsweise der Zeitstempel einer Aktivität vom Typ xsd:date als
xsd:string übermittelt werden. Aus dem Stub wird nur der Code benötigt, der
für das Mapping zwischen XML-Elementen mit entsprechenden Datentypen auf der
einen Seite und den Attributen einer Java-Bean auf der anderen Seite zuständig ist.
Das Mapping wird zusammen mit dem InputStream einer eingehenden PushVerbindung an eine Instanz der Klasse SOAPDecoder übergeben, die Bestandteil
der RI ist und nicht der API des JSR 172. Das Parsing der SOAP-Nachricht schlägt
jedoch fehl. Dieses Resultat ist auch mit dem Beispiel-Web-Service Version des
Apache Axis2 Frameworks und unmodifiziertem Client-Stub zu beobachten.
53
3.4. Mobile Client
3.4.1.4
Kapitel 3. Analyse
Evaluierung
Neben den folgenden Entscheidungen bezüglich der Kommunikation von mobileCRM
dienen die Tests auch zur Verifizierung des Systemaufbaus. Dazu zählt hauptsächlich die
Installation und Konfiguration des BES und die Aktivierung des BB-Endgeräts. Durch den
Push-Test wurde zusätzlich noch das Deployment einer Anwendung auf dem Endgerät,
die Benutzung der Push-Registry mit JAD und die Kommunikation zwischen BES und
dem Endgerät getestet.
• Web-Service-Protokoll: REST oder SOAP
Auf SOAP basierende Web Services nutzen das REST-Prinzip nicht. Die Ressourcen und Operationen werden im Rumpf der SOAP-Nachricht statt über den URI
spezifiziert. Alle Nachrichten richten sich an einen URI des Service. Dies hat zur
Folge, dass ein Proxy für SOAP-Nachrichten nur schwer implementiert und gewartet werden kann. Somit entfallen Zugriffsbeschränkungen und Caching durch
einen Proxy. Zudem können auf SOAP basierende Web Services frei Operationen definieren, während Web Services nach dem REST-Prinzip nur die generischen
HTTP-Methoden zur Verfügung stellen. Ein weiterer Unterschied ist, dass bei auf
REST basierenden Web Services jede Ressource für ihre Repräsentation innerhalb
von HTTP ein spezifisches Protokoll nutzen kann. Bei einer REST-basierten WebService-Implementierung entfällt der Overhead von SOAP. Die HTTP-Payload enthält nur die zu übertragenden Daten in Form von XML, beispielsweise gemäß einer
XSD. Die mobile Anwendung muss die Verarbeitung der XML-Daten jedoch vollständig selbst implementieren. Die RI des JSR 172 vereinfacht die Entwicklung an
dieser Stelle, da ein Stub-Generator diese Arbeit erledigt. Für kSOAP ist kein StubGenerator verfügbar, und der Aufwand ist ähnlich wie bei einer REST-basierten
Implementierung. Für beide Varianten ist es jedoch möglich, einen Stub-Generator
zu implementieren. In der neuen Version 2.0 der WSDL-Spezifikation wird auch
die Beschreibung von REST-basierten Web Services möglich. Prinzipiell hat sich
SOAP in Kombination mit WSDL jedoch zur Integration von Softwaresystemen
weit verbreitet und lässt sich mit SAP-XI leichter für den Zugriff auf das SAPCRM-System nutzen, als einen REST-basierten Web Service zu implementieren.
Aus diesem Grund wird die Realisierung mit SOAP-Kommunikation durch SAPXI vollzogen.
• SOAP-Bibliothek: kSOAP oder JSR 172
Die RI des JSR 172 erfüllt Punkt 5 der Rahmenbedingungen am Besten, da für das
54
Kapitel 3. Analyse
3.4. Mobile Client
Type-Mapping größtenteils auf einen Stub-Generator zurückgegriffen werden kann.
Durch die Voranalyse hat sich jedoch ergeben, dass die Test-Anwendung mit der RI
des JSR 172 in Kombination mit dem SAP-XI Web Service nicht funktioniert und
die RI noch instabil ist.
Eine weitere SOAP-Implementierung für mobile Endgeräte ist der WingfootSOAP-Client1 . Der Hersteller bietet die Bibliothek jedoch nur in binärer Form an,
wodurch Anpassungen für eine eingehende Push-Verbindung nicht möglich sind
und man für Erweiterungen, Bugfixes und Support auf den Hersteller angewiesen
ist. Für die Implementierung von mobileCRM kommt Wingfoot deshalb nicht in
Betracht.
Folglich wird mobileCRM mit der kSOAP-Bibliothek implementiert, mit der bei
Kompatibilitätsproblemen auch auf XML-Ebene gearbeitet werden kann, statt Mappings zu verwenden. Für den Empfang einer Push-Nachricht mit kSOAP muss zunächst der entsprechende Codeabschnitt für die eingehende Verbindung aus der Methode call ausgegliedert werden. Daher wurde die Methode receive(InputStream istream, SoapEnvelope envelope) der öffentlichen Schnittstelle der Klasse HttpTransport hinzugefügt. Im Gegensatz zum Stub-Generator für die API des JSR 172 existiert für kSOAP kein frei verfügbarer StubGenerator, so dass die Zuordnungen zwischen XML-Elementen und Java-Datentypen manuell programmiert werden müssen.
3.4.2
Synchronisation und Offline-Modus
Ein wichtiges Merkmal von mobileCRM ist die Realisierung als Smart Client: die Aktivitäten sollen lokal auf dem Endgerät gespeichert und auch neue Aktivitäten ohne FunknetzVerbindung angelegt werden können. Für diesen Offline-Modus wird zum lokalen Zwischenspeichern das RMS verwendet, das in Abschnitt 2.4.3.4 vorgestellt wurde und Bestandteil von J2ME ist. Eine andere Option zur Umsetzung der Zwischenspeicherung auf
BB-Endgeräten gibt es nicht. Jedoch gibt es Produkte diverser Hersteller, die auf dem
RMS aufsetzend eine beschränkte relationale Datenbank realisieren, was jedoch im Rahmen von mobileCRM nicht notwendig ist und nur Overhead wäre.
Sobald Daten aus dem SAP-CRM auf dem Endgerät modifiziert werden, können bei der
Synchronisation zwischen SAP und mobileCRM Probleme bei der Datenkonsistenz auftreten. Dies ist dann der Fall, wenn zwei oder mehr Benutzer eine bestimmte Aktivität be1
http://www.wingfoot.com/download_wsoap.html
55
3.4. Mobile Client
Kapitel 3. Analyse
Abbildung 3.5: Beispiel für ein Lost-Update bei der Synchronisation
arbeiten. Die Synchronisationsprobleme werden in der Datenbanktheorie mit Dirty Read,
Inconsistent Read und Lost Update bezeichnet. Die Anomalien eines Inconsistent Read
und eines Dirty Read sind dadurch ausgeschlossen, dass die RFC- oder BAPI-basierte
Kommunikation mit dem SAP-CRM-System transaktionssicher ist. Ein Lost Update kann
durch das SAP-CRM-System nicht verhindert werden. Ein Fallbeispiel für ein solches
Problem folgt und ist in Abbildung 3.5 visualisiert:
• Der Benutzer ändert eine Aktivität A in mobileCRM, die Änderung wird lokal gespeichert, aber es ist kein Funknetz verfügbar.
• Zwischenzeitlich nimmt die Sekretärin im Unternehmen von einem Kunden einen
Anruf entgegen, der eine Änderung in Aktivität A zur Folge hat, beispielsweise
eine Terminänderung. Die modifizierte Aktivität wird durch die direkt an das SAPSystem angebundene SAP-GUI im CRM abgespeichert und eine Push-Nachricht
an den BES gesendet, die dort vorgehalten wird, bis der mobile Nutzer erreichbar
ist.
• Das mobile Endgerät hat wieder Netzempfang und erhält die Push-Nachricht. Dabei
werden die lokalen Änderungen überschrieben, falls keine speziellen Vorkehrungen
in der Anwendungslogik getroffen werden. Eine weitere Möglichkeit (nicht in Abbildung enthalten) wäre, dass aufgrund von Race Conditions der mobile Nutzer
seine Änderung an das SAP-System überträgt, bevor die Push-Nachricht, die durch
die Änderung der Sekretärin ausgelöst wird, ihn erreicht. In diesem Fall wäre die
getätigte Änderung der Sekretärin im SAP-System überschrieben.
56
Kapitel 3. Analyse
3.4. Mobile Client
Zur Verhinderung solcher Probleme gibt es verschiedene sogenannte Replikationsstrategien (siehe [Rah05]). Unter Replikation versteht man die Vervielfältigung von Daten. Im
konkreten Fall bezeichnet man die Daten im SAP-CRM-System als Primärdaten, und die
Kopien auf den BB-Endgeräten als replizierte Daten. Bei den Strategien unterscheidet
man zwischen Verfahren, die eine strenge Konsistenz garantieren (synchrone Änderungen), und solchen, die nur eine schwache Konsistenz erreichen (asynchrone Änderungen).
Für eine strenge Konsistenz, die eine Transparenz der Replikation gewährleistet, ist eine
Serialisierung der Änderungen an Daten notwendig. Dies wird in den gängigen Verfahren
durch Schreibsperren auf allen oder der Mehrheit der Kopien gelöst. Durch den OfflineModus von mobileCRM ist es möglich, dass parallele Änderungen auf einem Datensatz
stattfinden, ebenso wie nicht immer alle Replikate konsistent sind. Daher ist eine strenge Konsistenz nicht realisierbar. Für mobile Anwendungen eignet sich eine sogenannte
Merge-Replikation. Dabei ist die Konsistenz der einzelnen Kopien nicht sichergestellt,
und es kann beim Synchronisieren zu Konflikten kommen, die dann automatisiert oder
ggf. manuell aufgelöst werden müssen.
Um solche Konsistenzprobleme sicher zu erkennen, müssen in dem Fall die Datensätze versioniert werden, um unterschiedliche Datenstände identifizieren zu können. Eine
sichere Vermeidung von Lost Updates ist nur durch eine Transaktion möglich, so dass
die Versionsüberprüfung und das Schreiben des Datensatzes atomar durchgeführt werden
können. Zur Unterscheidung der Datenstände kann bei den Datensätzen im SAP-CRMSystem das Attribut DocumentNumber herangezogen werden, das bei jeder Transaktion mit der Aktivität automatisch inkrementiert wird.
Für die Umsetzung von mobileCRM werden die folgenden zwei Möglichkeiten zur Synchronisation untersucht:
1. Transaktionslogik zwischen Web Service und SAP-CRM-System (Abbildung 3.6).
2. Keine Transaktionslogik, Lost Updates können auftreten (Abbildung 3.8).
Die Möglichkeit, Transaktionen über den Web Service anzubieten, wird nicht näher betrachtet, da die Realisierung aufwendiger ist und die Dauer einer einzelnen Transaktion
dadurch länger wird. Im schlimmsten Fall müsste eine Transaktion dabei durch einen
Timeout abgebrochen werden, falls das BB-Endgerät die Funkverbindung verliert.
Der Ablauf von Synchronisationslösung 1 ist in Abbildung 3.6 dargestellt, der BES wurde hierbei zur besseren Übersicht nicht dargestellt. Eine lokal als modifiziert markierte
Aktivität wird dabei an den Web Service im SAP-XI gesendet. In einer dort implementierten Transaktionslogik wird innerhalb einer Transaktion mit dem SAP-CRM-System
57
3.4. Mobile Client
Kapitel 3. Analyse
Abbildung 3.6: Synchronisationslösung 1 für Client-initiiertes Aktivitätsupdate
58
Kapitel 3. Analyse
3.4. Mobile Client
Abbildung 3.7: Push-Update, Bestandteil der Synchronisationslösungen 1 und 2
überprüft, ob sich die DocumentNumber im CRM-System geändert hat im Vergleich zu
der Aktivität, die abgespeichert werden soll. Falls die Version gleich geblieben ist, kann
die Aktivität ins CRM geschrieben werden, und die Transaktion abgeschlossen werden.
Anderenfalls wird die Transaktion abgebrochen, und mobileCRM erhält vom Web Service
eine Fehlermeldung. Seitens dem SAP-CRM-System wird nach einer Aktivitätsänderung
eine Push-Nachricht im SAP-XI veranlasst (siehe Abbildung 3.7), die alle Benutzer von
mobileCRM erhalten, die eine Rolle in der modifizierten Aktivität einnehmen.
Wenn die Push-Nachricht eintrifft, muss die Aktivität auf dem Endgerät überschreibbar
sein. Deshalb wird die Markierung vor dem Update bereits auf unmodifiziert gesetzt, so
dass Race Conditions nicht zu einem Fehlschlagen der Push-Nachricht führen können.
Bei einem Push-Update auftretende Versionskonflikte können auf dem Endgerät sicher
erkannt werden. Nachdem ein Konflikt festgestellt wurde, muss geprüft werden, ob er
sich lösen lässt. Betreffen die Änderungen in beiden Datensätzen nicht die gleichen Attribute, können die zwei Datenversionen möglicherweise automatisiert zusammengeführt
werden. Bedingung ist jedoch, dass die geänderten Attribute nicht in einer Abhängigkeit zueinander stehen. Weiterhin muss für eine Zusammenführung auch der unmodifizierte Datensatz auf dem Endgerät vorhanden sein, um die Änderungen in lokalem und
SAP-Datensatz erkennen zu können. Betreffen die Änderungen gleiche Attribute, ist ein
Zusammenführen (oder auch Merging im Englischen) ohne manuellen Eingriff des Benutzers nicht möglich. Die Funktionalität des automatischen Mergens ist auch als Teil der
59
3.4. Mobile Client
Kapitel 3. Analyse
Abbildung 3.8: Synchronisationslösung 2 für Client-initiiertes Aktivitätsupdate
Transaktionslogik im SAP-XI denkbar, so dass kein Fehler an das Endgerät zurückgegeben werden muss und der Vorgang dadurch schneller durchgeführt werden kann. Die
Realisierung eines Merge-Vorgangs ist nicht Bestandteil des Prototyps mobileCRM.
Der besondere Fall eines Lost-Updates auf Client-Seite kann auftreten, wenn der Benutzer
eine Aktivität lokal bearbeitet, während für dieselbe Aktivität ein Push-Update eingeht.
Ohne Vorkehrungen kann der Benutzer die neue Version der Aktivität mit der vorherigen
überschreiben.
Die zweite Synchronisationslösung verwendet keine Transaktionslogik, und daher sind
Lost-Updates in diesem Szenario prinzipiell möglich. Der Fokus dieser Arbeit liegt nicht
bei der Transaktionssicherheit auf SAP-Seite, weshalb für den Prototyp mobileCRM dieses optimistische Verfahren ausreichend ist. Solange das Endgerät keine Push-Nachricht
vom SAP-System erhält, wird davon ausgegangen, dass die lokale Version der Aktivität
noch die aktuelle ist. Die modifizierte Aktivität wird ohne weitere Vorkehrungen direkt an
den Web Service gesendet und SAP-XI kann eine entsprechende Anfrage an das CRMSystem stellen. Nach dem Abspeichern löst das CRM-System Push-Updates für alle an
der Aktivität beteiligten BB-Benutzer aus (siehe Abbildung 3.7). Währenddessen erhält
der Benutzer, der das Update durchgeführt hat, eine Rückmeldung vom Web Service und
markiert die Aktivität lokal als unmodifiziert. Ein Lost-Update kann auftreten, falls ein
anderer Benutzer ein Update mit der gleichen Aktivität durchführt, bevor er das PushUpdate erhält, und zu einem Merge-Vorgang aufgefordert wird. Neben einer verzögerten
Auslieferung einer Push-Nachricht kann dies auch durch eine verloren gegangene PushNachricht hervorgerufen werden. Das Zeitfenster, in dem ein Lost-Update auftreten kann,
60
Kapitel 3. Analyse
3.4. Mobile Client
Abbildung 3.9: Mögliches Lost-Update in Synchronisationslösung 2
beginnt also mit dem Update-Vorgang eines Benutzers und endet, wenn alle mit der Aktivität assoziierten BB-Benutzer die entsprechende Push-Nachricht erhalten haben. Dies
ist in Abbildung 3.9 veranschaulicht. Die SAP-XI und der BES als vermittelnde Systeme
zwischen Client und SAP-CRM wurden der Einfachheit halber nicht dargestellt.
Ein weiteres Problem ergibt sich speziell für den produktiven Einsatz. Die SAP-GUI öffnet Aktivitäten nur lesend, falls ein weiterer SAP-GUI-Client diese Aktivität bereits geöffnet hat. Um keine Konflikte hervorzurufen sollte die Implementierung der mobilen
Anwendung auf die Funktionsweise der SAP-GUI abgestimmt sein. Hierfür ist jedoch
Detailwissen zur SAP-GUI notwendig. Diese Problemstellung wird für den Entwurf des
Prototyps nicht näher betrachtet.
3.4.3
Usability der mobilen Anwendung
Für den erfolgreichen Einsatz einer Anwendung ist die Akzeptanz der End-Anwender
ein wichtiger Aspekt. Die Schnittstelle von Mensch zu Maschine sollte möglichst intuitiv bedienbar sein, so dass der Benutzer die Anwendung als eine Hilfe empfindet und
keinesfalls dadurch ineffizienter arbeitet. Insbesondere bei mobilen Applikationen stellt
dies eine besondere Herausforderung dar, weil die Endgeräte nur eingeschränkte Ein- und
Ausgabemöglichkeiten haben. Im Hinblick auf die zu realisierende Anwendung mobileCRM ergeben sich dabei folgende Schwerpunkte:
• Internationalisierung
Durch die gegebenen Anforderungen, dass die mobile Anwendung ein SAP-CRMSystem durch die BlackBerry-Plattform nutzt, ergeben sich als Zielgruppe der Anwendung Mitarbeiter aus mittelständischen, großen oder global agierenden Unternehmen, da nur dort die entsprechende Infrastruktur vorhanden ist oder sich die
61
3.4. Mobile Client
Kapitel 3. Analyse
Investition in selbige lohnen würde. Daraus ergibt sich, dass mobileCRM oder darauf basierende Anwendungen international einsetzbar sein müssen. Internationalisierung (I18N) zur Bedienung der Anwendung muss eine Einstellung der Sprache
umfassen. Speziell im Kontext von Geschäftsanwendungen müssen dabei auch landesspezifische Währungen und Maßeinheiten beachtet werden.
• Bedienbarkeit
Die Bedienbarkeit - auch Usability genannt - ist entscheidend, wenn es um die Akzeptanz und effiziente Arbeitsweise der Benutzer mit der Anwendung geht. Es ist
von vornherein zu vermeiden, dass End-Anwender aus Effizienzgründen auf Stift
und Papier oder andere Anwendungen zurückgreifen. Dies sollte ebenfalls nicht
aufgrund einer zu komplexen Bedienung der Anwendung passieren. Die Verantwortung liegt dabei nicht ausschließlich beim Entwickler, sondern Usability ist schon
in der Spezifikation der Anforderungen und im Design zu berücksichtigen. Bei Anwendungen mit großem Funktionsumfang sind ein Benutzerhandbuch und Benutzerschulungen ebenso notwendig. Der Grundstein dafür wird bei mobileCRM bereits bei der Datenmodellierung in Abschnitt 3.2.2 gelegt, um die Funktionen und
die Komplexität der Anwendung an das mobile Endgerät anzupassen. Die durch
die mobile Anwendung abzubildenden Funktionen sollen außerdem übersichtlich
angeordnet sein. Hierzu kann das Untergliedern von Menüs in Kategorien mit Untermenüs hilfreich sein. Aufgrund des kleineren Displays kann es sinnvoll sein,
Dialogfelder, wie beispielsweise das der SAP-GUI (siehe Abbildung 2.7), oder Vorgänge auf mehrere Dialoge zu verteilen. Im Gegensatz zu typischen Desktop-GUIAnwendungen mit Menüleiste und personalisierbarer Werkzeugleiste ist die Benutzerschnittstelle von mobilen Endgeräten bereits kontext-sensitiv ausgelegt. Zu
einer angezeigten graphischen Komponente werden spezifische Aktionen definiert,
die damit durchgeführt werden können. Um die Komplexität der Anwendung aus
Benutzersicht zu reduzieren, ist eine weitere Möglichkeit, dem Benutzer Arbeit abzunehmen. Dies wäre innerhalb von mobileCRM beispielsweise denkbar mittels
Autovervollständigung und sinnvoller Vorbelegung in Eingabefeldern, oder indem
die Liste der Aktivitäten nach bestimmten Kriterien sortiert und durchsucht werden
kann.
• Performance
Lange Ladezeiten, in denen der Benutzer auf die Anwendung warten muss, sind
unbedingt zu vermeiden und beeinflussen die Akzeptanz der Applikation negativ.
Infolge der Hardware-Einschränkungen von mobilen Endgeräten ist der Aspekt der
62
Kapitel 3. Analyse
3.4. Mobile Client
Performance bei Design und Implementierung daher besonders wichtig. Durch die
Nutzung eines Web Service kommt erschwerend die Latenz der GPRS-Verbindung
und das Parsing von XML hinzu. Um die Leistung des Endgeräts möglichst effizient
zu nutzen, werden die in Abschnitt 2.4.3.6 zusammengestellten Optimierungsmöglichkeiten beachtet.
Ein Performance-Vorteil ergibt sich bereits aus den Rahmenbedingungen Punkt
3, nach denen die Anwendung als Smart Client realisiert werden soll. Dadurch
ist nicht für jede Operation der Anwendung eine Kommunikation mit dem SAPSystem notwendig und die Latenz, die der Benutzer erfährt, deutlich geringer.
3.4.4
Logging und Unit-Tests
Für die Rekonstruktion von Fehlern und Debugging kann Logging ein gutes Hilfsmittel
sein. In der Java-Welt hat sich unter anderem die Open-Source-Bibliothek log4j etabliert,
bei der verschiedene Ausgabeströme, -formatierungen und unterschiedliche Log-Level
unterstützt werden. Mit Microlog1 gibt es eine log4j-ähnliche Implementierung für den
Einsatz im J2ME-Umfeld, da log4j selbst nur mit J2SE lauffähig ist. Zusätzlich bietet
Microlog noch einen Adapter für das RMS und ein entsprechendes MIDlet zum Auslesen,
so dass ein Logging-Ausgabestrom auch so konfiguriert werden kann, dass er im RMS
gespeichert wird. Dies ist für mobile Endgeräte sinnvoll, die nicht über eine Konsole im
Sinne einer Standard-Ausgabe verfügen.
Das weit verbreitete jUnit Test-Framework ist innerhalb von J2ME nicht verwendbar, so
dass auf J2MEUnit 2 zurückgegriffen wird. Die API für einen Testcase ist dabei äquivalent zu jUnit, jedoch werden Test-Suites aufgrund der fehlenden Reflection-API in J2ME
anders aufgerufen, und es gibt einen weiteren TestRunner, der als MIDlet realisiert ist.
1
2
http://microlog.sourceforge.net/
http://j2meunit.sourceforge.net/
63
3.4. Mobile Client
Kapitel 3. Analyse
64
Kapitel 4
Design
In diesem Kapitel wird das Design für die zu realisierende Anwendung mobileCRM
entworfen. Es basiert auf den Anforderungen aus Abschnitt 3.1 und den DesignEntscheidungen, die während der Analyse getroffen wurden. Zunächst wird ein verfeinerter Architekturüberblick des gesamten Systems gegeben. Der Abschnitt mobileCRM
geht auf die einzelnen Komponenten der mobilen Anwendung ein und erläutert danach
deren Zusammenspiel, um eine Abbildung der einzelnen Anwendungsfälle zu realisieren.
Abschließend wird der Entwurf des Web Service im SAP-XI beschrieben.
4.1
Architekturüberblick
Aufgrund der im Analyse-Kapitel getroffenen Technologie- und Design-Entscheidungen
ergibt sich ein verfeinerter Aufbau der Architektur, die in Abbildung 4.1 dargestellt ist.
Als Endgerät wird von der Firma CSC ein BlackBerry 7100v mit Mobilfunkvertrag bei
Vodafone bereitgestellt. Ebenso kann für SAP-XI und SAP-CRM auf die am Standort
Wiesbaden vorhandene Infrastruktur in einer Testumgebung zurückgegriffen werden. Auf
einer weiteren Servermaschine wurde im Rahmen dieser Arbeit Windows 2003 Server,
MS Exchange 2003 und der BES in der Version 4.1 für Exchange installiert und konfiguriert. Die mit 1 und 2 in der Abbildung gekennzeichneten Systembestandteile sind dabei
im Rahmen dieser Arbeit zu entwickeln bzw. zu konfigurieren. Der Schwerpunkt dieses
Kapitels ist das Design von mobileCRM. Anschließend wird im SAP-XI der zugehörige
Web Service entworfen.
65
4.2. mobileCRM
Kapitel 4. Design
Abbildung 4.1: Verfeinerter Aufbau der Systemarchitektur
4.2 mobileCRM
Die Anforderungen an die mobile Anwendung mobileCRM wurden bereits in Abschnitt
3.1 festgelegt. Weitere Vorgaben für den Client wurden in Abschnitt 3.4 der Analyse
herausgearbeitet.
Daraus ergeben sich Teil-Komponenten der Anwendung, die als Java-Packages realisiert
werden und im Folgenden beschrieben sind:
• com.csc.bb.mobileCRM
In diesem Package befindet sich der Einstiegspunkt der Anwendung, der gemäß
J2ME als MIDlet realisiert ist. In MobileCrmMIDlet wird der Lebenszyklus der
Anwendung gesteuert, weitere Komponenten der Applikation initialisiert und die
eigentlichen Aufgaben der Anwendung an diese delegiert.
• com.csc.bb.mobileCRM.gui
Die graphischen Komponenten der Benutzerschnittstelle, die die LCDUI-API von
J2ME benutzen, sind in diesem Package enthalten.
• com.csc.bb.mobileCRM.model
Die von der Benutzerschnittstelle dargestellten Daten werden in getrennten Komponenten bereitgehalten, ebenso wie deren Synchronisation mit dem RMS auf dem
Endgerät und dem Web Service des SAP-Systems.
66
Kapitel 4. Design
4.2. mobileCRM
• com.csc.bb.mobileCRM.util
In diesem Package befinden sich Klassen für die Internationalisierung und das Logging.
Die Tabelle 4.1 zeigt die Komponenten von mobileCRM mit ihren jeweiligen Zuständigenkeiten in einer Übersicht. Im nächsten Abschnitt werden allgemeine DesignPrinzipien für mobileCRM besprochen. Die darauf folgenden Unterkapitel sind nach der
rechten Tabellenspalte gegliedert und betitelt.
Java-Package
com.csc.bb.mobileCRM.gui
com.csc.bb.mobileCRM.model
com.csc.bb.mobileCRM.util
Zuständigkeit
Benutzerschnittstelle
Model und Backend-Zugriffe
Logging und Internationalisierung
Tabelle 4.1: Übersicht der Komponenten von mobileCRM
4.2.1
Allgemeine Design-Prinzipien
In diesem Abschnitt werden zunächst allgemeine Design-Prinzipien besprochen, die in
mehr als einer Komponente von mobileCRM oder komponentenübergreifend Anwendung
finden.
In [Yua06] werden zwei grundsätzlich verschiedene Architektur-Beispiele für eine mobile Anwendung gegeben. Die Beispielanwendung Smart Ticket von Sun benutzt zahlreiche
Interfaces zur Kapselung. Hinter einer Fassade für das Model findet beispielsweise eine
Unterteilung in local und remote Model statt, während letzteres noch ein Chain-Handling
von einem RMS-Cache und den eigentlich HTTP-Anfragen zu einem Server kapselt. Das
Gegenbeispiel zu diesem schwergewichtigen Design bildet die iFeedback-Anwendung
des Autors ([Yua06]), die ein sogenanntes screen-flow Design verwendet. Der Autor hat
mit dieser Anwendung im Jahr 2002 den University Wireless Developer Contest gewonnen, der von NexTel, Sun und Motorola durchgeführt wurde. In einer MVCComponent
werden dabei graphische Elemente eines anzuzeigenden Screens zusammengefasst, und
die dazu spezifisch erforderliche Programm-Logik für Benutzerinteraktion und Kommunikation mit Backend-Systemen ebenso in dieser Komponente implementiert. Für die Nagivation von einem Screen zum nächsten gibt es keinen zentralen Controller, sondern jede
MVC-Komponente ist selbst dafür zuständig, bei welchen Benutzerinteraktionen eine andere Komponente angezeigt werden muss. Von dieser Klasse wird dann eine neue Instanz
67
4.2. mobileCRM
Kapitel 4. Design
angelegt und diese auf dem Display zur Anzeige gebracht - die Kontrolle liegt somit bei
der neuen Komponente. Da ein graphisches Element nicht mehrfach angezeigt werden
kann (es ist nur ein Display vorhanden), sind die Attribute aller Komponenten statisch
und werden somit nicht mit jeder Instanz neu erzeugt.
Die leichtgewichtige Architektur bietet klare Vorteile in Bezug auf Performance (siehe
dazu Abschnitt 2.4.3.6). Durch den reduzierten Umfang an Klassen wird weniger flüchtiger und nicht-flüchtiger Speicher für die Anwendung benötigt, ebenso wird weniger
Delegation notwendig. Auf der anderen Seite geht dies zu Lasten der Erweiterbarkeit und
Testbarkeit der Anwendung. Insbesondere kann der Code für Backend-Zugriffe nicht sauber wiederverwendet werden.
Für mobileCRM kommt eine Variante des MVC Design Pattern zum Einsatz, auch
Document-View-Architektur genannt, die einen bestmöglichen Kompromiss aus den unterschiedlichen Design-Ansätzen darstellen soll. Die graphischen Elemente sind dabei
View und Controller in einem, und die Navigation von einer zur nächsten Komponente erfolgt ähnlich wie bei dem iFeedback-Beispiel. Dafür sind statische Klassenattribute
notwendig, damit der gegenseitige direkte Zugriff auf Instanzen möglich ist. In mobileCRM wird dies durch das Singleton Design Pattern (siehe [GHJV95] S. 127) realisiert
und auf alle Klassen angewendet, für die auf Anwendungsebene nur eine Instanz benötigt wird. Hierdurch wird die Neuinstanziierung von Objekten minimiert und die Garbage
Collection weniger in Anspruch genommen. Es sei jedoch darauf hingewiesen, dass dies
bei umfangreicheren Anwendungen und weiteren Workflows innerhalb der Anwendung
zu einem zu hohen Speicherverbrauch führen kann, da einmal erzeugte Komponenten
für weitere Benutzungen im Speicher vorgehalten werden. Die Kommunikation mit RMS
und SAP-System wird in einem Model gekapselt, auf das alle graphischen Komponenten
zugreifen. Die folgenden Abschnitte gehen auf das konkrete Design der Benutzerschnittstelle (View) und des Modells (Document) ein.
4.2.2
Benutzerschnittstelle
Die Benutzerschnittstelle besteht hauptsächlich aus graphischen Komponenten, die die
abstrakte Klasse BasicScreen erweitern. Abbildung 4.2 gibt eine Übersicht aller Klassen im Package com.csc.bb.mobileCRM.gui.
Bevor ein Screen auf dem Display mit der Methode show() angezeigt werden kann,
muss zunächst der Inhalt initialisiert werden, wofür jede graphische Komponente die
Methode initData() individuell überschreibt. Benötigt ein Screen vor der Initiali-
68
Kapitel 4. Design
4.2. mobileCRM
Abbildung 4.2: Klassen der Benutzerschnittstelle (View)
69
4.2. mobileCRM
Kapitel 4. Design
sierung noch Daten, so kann dies über zusätzliche Set-Methoden geschehen, die vor
initData() aufgerufen werden müssen. Dies ist beispielsweise bei der Klasse ShowActivityForm der Fall, der man zunächst eine Aktivitäts-ID übergeben muss, bevor
die entsprechenden Daten aus dem Model transferiert werden können.
Da ein Screen auch den Controller-Part des MVC-Designs übernimmt, wird das Interface
CommandListener implementiert, und die Methode commandAction(Command
cmd, Displayable disp) muss in jeder Unterklasse entsprechend überschrieben
werden. Dort können Benutzerinteraktionen verarbeitet und dementsprechend Vorgänge im Screen ausgelöst werden oder andere Screens aufgerufen werden, die wiederum
zuvor initialisiert werden müssen. Damit die GUI während solcher Vorgänge nicht blockiert, werden Aufrufe im Model durch den ModelController gekapselt und in einem anderen Thread ausgeführt. Vom Model angefragte Daten werden asynchron vom
ModelController an die entsprechende GUI-Komponente übergeben. Dafür muss sie das
Interface AsyncDataHandler implementieren, den generischen Parameter der Methode updateData(Object data) zu dem erwarteten Datentyp anpassen (Casting)
und dann adäquat verarbeiten. Während eines Vorgangs im Model wird auf dem Display ein Wartebildschirm angezeigt, der in der Klasse StatusBar implementiert ist.
Zuvor muss mittels setNextScreen(BasicScreen nextScreen) jedoch angegeben werden, welcher Screen nach Abschluß des Vorgangs angezeigt werden soll. Die
Statusanzeige kann modellgetrieben aktualisiert werden, so dass der Benutzer eine Rückmeldung erhält, was im Hintergrund geschieht. Dafür wird im ModelController und
in StatusBar die Schnittstelle ProgressObserver implementiert. So kann vom
Model aus die Methode updateProgress(final int percentage, final
String status) aufgerufen werden, die der Controller zur Statusanzeige delegiert.
Durch die Notwendigkeit der Schnittstellen AsyncDataHandler und ProgressObserver bei der Kommunikation zwischen Model und ModelController in der GUISchicht ist die Model-Fassade unterteilt in die Schnittstelle ModelFacade, die nur
Methoden zu Operationen mit den Datensätzen definiert, und die Klasse Model, die
ModelFacade implementiert und zusätzlich noch die Kommunikation mit dem Controller umsetzt.
Für einen kompletten Übergang von einem Screen zum nächsten ist also auch das Model involviert, weshalb ein Sequenzdiagramm eines solchen Vorgangs erst nach dem Abschnitt zum Model folgt. Der Einstiegspunkt der Benutzerschnittstelle ist das Hauptmenü,
in dem ein Vorgang ausgewählt werden kann, angelehnt an die Anwendungsfälle der Applikation. Eine Übersicht der einzelnen Screens von mobileCRM zeigt Abbildung 4.3.
70
Kapitel 4. Design
4.2. mobileCRM
Abbildung 4.3: Übersicht und Zusammenhang der Screens
So können neben den wesentlichen Punkten Aktivität anlegen, Liste aller Aktivitäten
anzeigen und Synchronisieren auch die Anwendung beendet oder die Benutzereinstellungen angepasst werden. Die zugehörige Implementierung befindet sich in der Klasse
MainMenu. Die Liste aller lokal auf dem Endgerät vorhandenen Aktivitäten zeigt der
Screen ActivityList an, der intern List aus dem LCDUI-Framework für die Darstellung verwendet. Über ein Kontext-Menü kann eine ausgewählte Aktivität angezeigt,
modifiziert oder lokal gelöscht werden. Diese Aufgabe übernimmt die Klasse ShowActivityForm.
Der Screen für die Benutzereinstellungen wird in SettingsMenu nur beispielhaft implementiert, weil für die Testumgebung keine Konfiguration notwendig ist. Im Fehlerfall
kann eine Instanz von BasicAlert angezeigt werden. Vor der Anzeige können ein Fehlertext und ein eigener CommandListener übergeben werden. Bereits vorimplementiert sind die Fälle, in denen nach dem Fehler-Dialog der nächste Screen angezeigt sowie
dass die Anwendung für kritische Fehler beendet wird. Ist Letzteres nicht der Fall, so muss
vor der Anzeige des Dialogs setNextScreen(BasicScreen nextScreen) aufgerufen werden.
Der ModelController erweitert java.lang.Thread, um die Model-Aufrufe in
einem von der GUI getrennten Thread auszuführen. Dabei muss ein Aufruf im GUI-
71
4.2. mobileCRM
Kapitel 4. Design
Thread auf einen Aufruf im Model-Thread abgebildet werden. Der objektorientierte Ansatz ist zunächst, für jeden ModelController-Aufruf im GUI-Thread eine anonyme Klasse
anzulegen, die ModelAction (siehe Quellcode 4.1) erweitert. Dieses sogenannte Command Design Pattern findet sich in [GHJV95] S. 233. Diese Vorgehensweise impliziert
für jede Methode des Models eine weitere Klasse und verstößt damit gegen Prinzipien aus dem Abschnitt Optimierungen für mobile Anwendungen im Grundlagen-Kapitel.
Deswegen wird der Code, um einen Vorgang im Model durchzuführen, in einer HandlerMethode ebenfalls im ModelController implementiert werden. Jede Handler-Methode ist
über eine ID mit der von der GUI aufgerufenen Methode verknüpft. Die ID und ein optionaler Parameter werden in der Handler-Methode gesetzt und in Attributen des ModelControllers gespeichert, und der Model-Thread aufgeweckt, der anhand der ID die zugehörige
Handler-Methode aufrufen kann und dann wieder pausiert. Da der Thread nur eine ModelAnfrage bearbeiten kann, müssen die Aufrufe des ModelControllers serialisiert werden.
Die öffentlichen Methoden sind deshalb als synchronized deklariert. Um das Model
abstrakt zu halten, wurde das Threading und die damit verbundene asynchrone Kommunikation im ModelController im GUI-Package implementiert. Obwohl Model und ModelController die gleichen Methoden für Operationen mit den Model-Komponenten, die
im Interface ModelFacade zusammengefasst sind, implementieren müssen, kann der
ModelController dieses Interface nicht implementieren, da sich die Methodensignaturen
aufgrund der asynchronen Aufrufe unterscheiden.
public interface ModelAction {
void setExecuteParam(Object param);
void execute();
4 }
2
Quellcode 4.1: Interface zur Umsetzung des Command Pattern
4.2.3
Model und Backend-Zugriffe
Im Model von mobileCRM werden die Datensätze repräsentiert, die mit dem SAP-CRMSystem ausgetauscht werden. Neben der Kommunikation mit dem SAP-CRM wird das
Model außerdem noch im RMS des mobilen Endgeräts für den Offline-Modus abgespeichert. Die Model-Schicht besteht aus Klassen für die Datenhaltung und den Datenaustausch mit Backend-Systemen. Diese einzelnen Komponenten werden durch eine einzige Schnittstelle nach dem Facade Design Pattern (siehe [GHJV95] S. 185) nach außen
hin gekapselt, so dass Änderungen an Sub-Komponenten keinen Einfluß auf die View-
72
Kapitel 4. Design
4.2. mobileCRM
Abbildung 4.4: Business Objects in mobileCRM
Komponenten haben. Der Zugriff auf das RMS erfolgt über die Klasse RMSmanager,
die als Singleton implementiert ist und sich im Package com.csc.bb.mobileCRM.model.backend.rms befindet. Die SOAP-Kommunikation mit dem SAP-System
findet über die Schnittstelle der Klasse SAPmanager statt, die alle weiteren Details im
Package com.csc.bb.mobileCRM.model.backend.sap kapselt.
Klassen, die abstrakte Entitäten aus der Anwendungsdomäne enthalten, werden auch
BusinessObjects (BO) genannt. Dabei gibt es im Fall von mobileCRM im Prinzip nur
die Entität einer Aktivität aus dem SAP-CRM. Diese wurde jedoch noch feiner zerlegt,
da dies Vorteile beim Zugriff auf das RMS mit sich bringt. Einen Überblick über die
Schnittstelle der BOs in mobileCRM gibt Abbildung 4.4.
In der Klasse ActivityBO sind dabei alle mit dem SAP ausgetauschten Daten einer Aktivität in Form von Attributen enthalten. Einige Daten, die in mehreren GUIKomponenten benötigt werden, wurden in die Klasse ActivityEntryBO ausgegliedert. Damit die BOs alle serialisierbar sind und die Daten auf Konsistenz überprüft werden
können, ist jedes BO Nachfahre der abstrakten Klasse BasicBO, die eine abstrakte Methode validate() vorsieht, die jedes BO entsprechend implementieren muss. Dadurch
kann jedes BO auf seine Datenkonsistenz hin überprüft werden. Die Serialisierung erfolgt
durch Implementierung der dafür entworfenen Schnittstelle Serializable. Diese wird
vom RMSmanager angesprochen, und ein BO ist dafür verantwortlich, all seine Attribute
in den übergebenen Ein- bzw. Ausgabe-Strom zu serialisieren bzw. wieder zu deseriali-
73
4.2. mobileCRM
Kapitel 4. Design
Abbildung 4.5: Komponenten zur Kommunikation mit den Backend-Systemen
sieren.
Für die lokale Speicherung der Daten verwaltet der RMSmanager den Zugriff auf die
RecordStores. Die zugehörige UML-Darstellung findet sich in Abbildung 4.5.
Für die BOs ActivityBO und ActivityEntryBO werden zur Serialisierung mittels RMSmanager zwei unterschiedliche RecordStores verwendet. Das Schreiben einer
Aktivität impliziert gleichzeitig einen neuen ActivityEntryBO-Datensatz, so dass
beide Identifikatoren gleich sind. Um die Liste der Aktivitäten (Screen Nr 2 in Abbildung 4.3) anzuzeigen, müssen so nicht alle ActivityBOs gelesen werden, sondern es ist
ausreichend, nur die ActivityEntryBOs auszulesen, welche deutlich kleiner sind. Weiterhin können in ActivityEntryBO-Datensätzen Verwaltungsinformationen gespeichert werden wie beispielsweise, ob eine gespeicherte Aktivität auf dem Endgerät bereits modifiziert wurde oder noch im Original-Zustand ist. Bei der Synchronisation mit
dem SAP-System müssen so ebenfalls nicht alle ActivityBOs ausgelesen werden. Die öffentliche Schnittstelle sieht Methoden zum Laden, Speichern und Löschen einer Aktivität vor, welche jeweils auch den zugehörigen ActivityEntryBO-Datensatz beachten.
Der direkte Zugriff auf ActivityEntryBO-Einträge ist nur über die Methode loadAllActivityEntries() für die Liste aller Aktivitäten vorgesehen. Um die Datenkonsistenz zu gewährleisten, sind alle öffentlichen Methoden synchronized, so dass
konkurrierende Zugriffe auf das RMS immer seriell ablaufen. Der RMSmanager ist nach
dem Singleton Design Pattern entworfen. Dies spart Referenzen und Delegation zwischen
Model und dem PushReceiver, schränkt die Funktionalität der Klasse jedoch nicht ein, da
74
Kapitel 4. Design
4.2. mobileCRM
auf die RecordStores nicht parallel zugegriffen werden soll.
Während die Anwendung aktiv ist, muss sie selbst auf eingehende Push-Verbindungen
warten. Um Benutzerinteraktionen nicht zu stören, wird diese Funktionalität in einem eigenen Thread umgesetzt. Die Klasse PushReceiver erweitert java.lang.Thread
und nimmt auf dem angegebenen Port blockierend in einer Endlos-Schleife Verbindungen
entgegen. Eine Verbindung wird dann geöffnet und als InputStream an den SAPmanager
übergeben. Das Ergebnis ist ein ActivityBO und wird im RMS abgespeichert.
Die Kommunikation mit dem SAP-XI Web Service findet über die Klasse SAPmanager
statt (siehe Abbildung 4.5). Um eine Instanz zu erzeugen, werden zunächst die URL des
Web Service sowie Benutzername und Passwort für die Authentifizierung beim SAPXI benötigt. Zum Empfangen eines Push-Updates dient die Methode receivePush(InputStream inputStream), die als Parameter die eingehende Verbindung erwartet und ein ActivityBO zurückgibt. Mit der Methode getActivities() erhält man
einen Vector mit allen Aktivitäten des SAP-Systems, die zum Benutzername gehören.
Um eine modifizierte Aktivität zum SAP-CRM zu übermitteln, wird das entsprechende
BO an die Methode updateActivity(ActivityBO activity) übergeben.
4.2.4
Abbildung der Anwendungsfälle
Anhand von Sequenzdiagrammen wird das Zusammenspiel der Komponenten für die in
der Analyse festgelegten Anwendungsfälle verdeutlicht (vgl. 3.1.2).
4.2.4.1
Server-initiiert
• Aktivitätsänderung
Dieser Use-Case bezieht sich auf Änderungen einer Aktivität im SAP-CRMSystem, die durch einen Client wie mobileCRM (siehe Aktivität modifizieren unter
Client-initiierte Anwendungsfälle) oder der SAP-GUI durchgeführt werden. Dieser
Vorgang ist der Auslöser für die Datensynchronisation durch eine Push-Nachricht,
die nachfolgend beschrieben wird.
• Daten synchronisieren
Der in Abbildung 4.6 dargestellte Ablauf beginnt damit, dass der PushReceiver
einen eigenen Thread startet und auf eingehende Push-Verbindungen wartet, die
75
4.2. mobileCRM
Kapitel 4. Design
Abbildung 4.6: Sequenzdiagramm zum Anwendungsfall Daten synchronisieren
vom SAP-CRM-System bei Änderungen an Aktivitäten initiiert werden. Die Verbindung wird an den SAPmanager übergeben, wo die ankommenden SOAPDaten gelesen und das Parsing durchgeführt werden. Die resultierende Instanz eines
ActivityBO wird vom PushReceiver im RMS über den RMSmanager abgespeichert. Abschließend wird der erfolgreiche Eingang einer Push-Nachricht über das
AsyncEventHandler-Interface an den ModelController als Event übermittelt, und dem Benutzer wird ein entsprechender Informationsdialog angezeigt.
4.2.4.2
Client-initiiert
• Aktivitäten auflisten
Ausgehend vom Hauptmenü von mobileCRM wird die Methode initData() der
ActivityList-Instanz aufgerufen (siehe Abbildung 4.7). Während der Initialisierung soll der Warte-Screen StatusBar mit der Methode show() angezeigt
werden, zunächst wird jedoch als Folge-Screen die initialisierte ActivityListInstanz gesetzt. Zur Initialisierung werden alle Aktivitätseinträge im RMS benötigt, deren Beschaffung durch Aufruf der Methode getActivityEntries()
des ModelControllers angestoßen wird. Die aufgerufenen Methoden der graphischen Komponenten (MainMenu und ActivityList) beenden sich, und der
Kontrollfluss des GUI-Threads liegt wieder beim LCDUI-Framework. Damit im
ModelController hinterlegt ist, welche GUI-Komponente die Daten angefordert hat,
76
Kapitel 4. Design
4.2. mobileCRM
Abbildung 4.7: Sequenzdiagramm zum Anwendungsfall Aktivitäten auflisten
77
4.2. mobileCRM
Kapitel 4. Design
Abbildung 4.8: Sequenzdiagramm zum Anwendungsfall Aktivität anlegen
muss diese zuvor setCaller(this) am ModelController aufrufen. Der angestoßene Worker-Thread arbeitet die Anfrage durch den Aufruf von handleGetActivityEntries() ab. Dabei wird die Aufgabe an das Model und von dort
aus zum RMSmanager delegiert, der alle Aktivitäten als ActivityEntryBOObjekte ausliest und in einem java.util.Vector zurückgibt. Auch in diesem
Fall wird die Statusmeldung des Warte-Screens (StatusBar) wieder vom Model
aktualisiert. Für den Transport der ausgelesenen Daten vom ModelController
(Worker-Thread) zur GUI-Komponente, die das Interface AsyncDataHandler
implementiert, wird die Methode updateData(Object data) genutzt. Abschließend wird der Übergang von StatusBar zum nächsten Screen ActivitList vollzogen.
• Aktivität anlegen
Der Schritt vom Hauptmenü über den Menüeintrag Neue Aktivität anlegen zur graphischen Komponente ShowActivityForm wurde in Abbildung 4.8 zur besseren Übersicht auf die wesentlichen Vorgänge beschränkt. Das Sequenzdiagramm
beginnt an der Stelle, nachdem der Benutzer die entsprechenden Daten eingegeben
hat und die Speicherung der neuen Aktivität veranlasst. Zunächst wird der WarteScreen eingeblendet, bevor dann die eigentliche Speicherung im Model im Thread
78
Kapitel 4. Design
4.2. mobileCRM
des ModelControllers abgearbeitet wird. Wichtig ist dabei, dass das Flag modified
im ActivityBO gesetzt wird, was im Model geschieht. Die Aktivität kann dann
über den RMSmanager gespeichert werden. Danach wird versucht, die Methode
updateActivity erfolgreich aufzurufen, was jedoch nur bei einer Funkverbindung des Endgeräts gelingt. Andernfalls wird die Aktivität beim nächsten Synchronisationsvorgang zum SAP übertragen. An dieser Stelle kommt das modifiedAttribut der Aktivität zum Tragen, woran erkannt wird, dass die Aktivität noch nicht
synchronisiert wurde. Abschließend wird der nächste Screen angezeigt, was in diesem Fall die ActivityList ist.
• Aktivität modifizieren
Dieser Anwendungsfall unterscheidet sich vom vorherigen nur in dem Punkt,
dass zu Beginn die ausgewählte Aktivität in der graphischen Komponente ShowActivityForm dargestellt wird und nicht mit einer leeren Aktivität begonnen
wird. Wie das Laden der Aktivität und das Initialisieren der graphischen Komponente stattfindet, lässt sich im Use-Case Aktivität anzeigen (Abbildung 4.10) nachvollziehen. Der Update-Vorgang ist analog zu dem in Abbildung 4.8.
• Aktivität löschen
Innerhalb der Aktivitätsliste besteht die Option, eine markierte Aktivität zu löschen. Dieser Vorgang ist in Abbildung 4.9 abgebildet und beginnt in der Methode commandAction in der Instanz von ActivityList, der Benutzer hat
also den Menü-Eintrag zum Löschen ausgewählt. Nach dem Vorgang im Model soll wieder die Aktivitätsliste angezeigt werden, weshalb zunächst setNextScreen(this) aufgerufen wird, bevor der StatusBar auf dem Display angezeigt wird. Im Hintergrund wird nun die asynchrone Methode deleteActivity vom ModelController mit der RecordID der zu löschenden Aktivität als Parameter aufgerufen. Nachdem dort der Worker-Thread aufgeweckt
wurde, kehrt der Kontrollfluss des GUI-Threads wieder zurück in die graphische Komponente ActivityList, die ihre graphische Repräsentation anpasst
(nicht in Abbildung dargestellt). Die Methode commandAction() wird verlassen, und Benutzereingaben können so wieder durch das LCDUI-Framework bearbeitet werden, beispielsweise zum Abbrechen des Vorgangs. Während der Bearbeitung im Model kann eine Statusmeldung über die ProgressObserver
Schnittstelle im ModelController mit der Methode updateProgress(int percentage, String status) bis zur GUI propagiert werden. Das
Löschen der Aktivität wird vom Model durch Aufruf der Methode delete-
79
4.2. mobileCRM
Kapitel 4. Design
Abbildung 4.9: Sequenzdiagramm zum Anwendungsfall Aktivität löschen
80
Kapitel 4. Design
4.2. mobileCRM
Abbildung 4.10: Sequenzdiagramm zum Anwendungsfall Aktivität anzeigen
Activity(int recordId) der RMSmanager-Instanz veranlasst. Wenn der
Vorgang im Worker-Thread beendet ist, ruft der ModelController die Methode
showNextScreen() des StatusBar auf, was in diesem Fall zur Folge hat, dass
abschließend wieder die aktualisierte Aktivitätsliste angezeigt wird.
• Aktivität anzeigen
Dieser Anwendungsfall knüpft an Aktivitäten auflisten in Abbildung 4.7 an.
Nachdem in der Liste vom Benutzer eine Aktivität ausgewählt wurde, wird
initData() der graphischen Komponente zum Anzeigen einer Aktivität aufgerufen. Damit der asynchrone Datentransfer vom Model zur GUI-Komponente
über das AsyncDataHandler-Interface erfolgen kann, muss sich die Komponente zuerst beim ModelController mit setCaller(this) registrieren.
Danach wird der Aufruf getActivity(activityId) über den ModelCon-
81
4.2. mobileCRM
Kapitel 4. Design
Abbildung 4.11: Sequenzdiagramm zum Anwendungsfall Aktivitätenliste anfordern
troller im Worker-Thread zum Model delegiert. Über die ProgressObserverSchnittstelle im ModelController kann das Model Statusänderungen des Vorgangs
zum Warte-Screen propagieren. Das eigentliche Auslesen der Aktivität wird an den
RMSmanager delegiert, der anhand der activityId den Datensatz aus dem
RMS auslesen kann, und die Daten als ActivityBO-Instanz zurück gibt. Im
Worker-Thread des ModelControllers wird die Aktivität an die aufrufende GUIKomponente mittels updateData übergeben. Abgeschlossen wird der Anwendungsfall durch anzeigen der initialisierten ShowActivityForm-Instanz.
• Aktivitätenliste anfordern
Der in Abbildung 4.11 dargestellte Anwendungsfall beginnt durch Auswahl im
Hauptmenü, und es wird der Warte-Screen angezeigt. Über den Thread des ModelControllers wird die Methode getActivies(status) im Model aufgerufen.
Der Parameter gibt dabei an, welchen Status die zurückgelieferten Aktivitäten haben sollen, beispielsweise open. Der Aufruf wird an den SAPmanager delegiert,
der eine SOAP-Anfrage abschickt, das Parsing der Antwort durchführt und als Resultat einen Vector mit ActivityBO-Instanzen zurückliefert. Diese Aktivitäten
werden im Model einzeln über den RMSmanager lokal abgespeichert. Nachdem
dieser Vorgang beendet ist, wird wieder das Hauptmenü angezeigt.
82
Kapitel 4. Design
4.3. Integrationsszenarien in SAP-XI
Abbildung 4.12: Sequenzdiagramm zum Anwendungsfall Daten synchronisieren
• Daten synchronisieren
Ausgehend vom Hauptmenü können lokal modifizierte Aktivitäten mit dem SAPSystem synchronisiert werden (siehe Abbildung 4.12). Währenddessen wird dem
Benutzer der Warte-Screen angezeigt, und der Vorgang an das Model bzw. den
Worker-Thread delegiert. In der Methode synchronizeActivities() werden zunächst über den RMSmanager alle modifizierten Aktivitäten ausgelesen.
Für jede dieser Aktivitäten wird die Methode updateActivity aufgerufen, in
der die Kommunikation mit dem Web Service auf SAP-Seite stattfindet. Nach erfolgreichem Update einer Aktivität wird im RMS der Status auf unmodified
gesetzt. Der Vorgang wird durch erneute Darstellung des Hauptmenüs abgeschlossen.
4.3
Integrationsszenarien in SAP-XI
Hier werden die Integrationsszenarien und die dazugehörigen Komponenten aus dem
SAP-XI aufgeführt und erläutert. Die Arbeiten zur Integration im SAP-XI wurden durch
den Betreuer (Herrn Thomas Schneider) von Seiten der Firma CSC durchgeführt und
83
4.3. Integrationsszenarien in SAP-XI
Kapitel 4. Design
Abbildung 4.13: Aufbau eines synchronen Integrationsszenarios im SAP-XI
sind nicht Bestandteil dieser Arbeit. Insbesondere die Definition der Schnittstelle zwischen BB-Endgerät und XI sowie die Auswahl der benötigten BAPIs im SAP-CRM sind
in enger Abstimmung mit der Analyse und dem Design der mobilen Anwendung entstanden.
Anwendungsfälle werden im SAP-XI durch Integrationsszenarien abgebildet. Einem Integrationsszenario sind verschiedene Anwendungskomponenten zugeordnet. Diese sind im
SLD zu pflegen, die Komponente von RIM (BES) muss dort aufgenommen werden. Den
einzelnen Anwendungskomponenten werden im Designprozess ein oder mehrere Actions
zugeordnet. Die Anwendungsszenarien für die SAP-BB-Integration definieren jeweils nur
eine Action pro Anwendungskomponente. In den Actions werden die Message-Interfaces
festgelegt, aus denen XI ein WSDL-Dokument generiert. Zwischen den Actions sind die
Mappings definiert, die für die Transformation der eigentlichen Nachrichten notwendig
sind (siehe Abbildung 4.13). Für ein Mapping gibt es in XI zwei Abstraktionsebenen. Zum
einen das Interface Mapping, welches festlegt zwischen welchen Interfaces ein Mapping
stattfinden soll. Und dann das eigentliche Mapping der Nachrichten (Message-Mapping).
Für ein synchrones Interface Mapping wie im Fall der SAP-BB-Integration werden jeweils zwei Message-Mappings benötigt - eins für die Anfrage und eins für die Antwort.
Für die in Abschnitt 3.1.2 beschriebenen Anwendungsfälle sind im SAP-XI die in Tabelle
4.2 dargestellten Integrationsszenarien definiert. Dabei werden die Anwendungsfälle Aktivität anlegen, Aktivität modifizieren und Daten synchronisieren nur auf dem Endgerät
unterschieden, und alle Resultate über das Szenario ChangeActivity an das SAP-System
übermittelt. Die Anwendungsfälle Aktivität anzeigen und Aktivität löschen finden nur lokal im RMS des Endgeräts statt und haben keine Auswirkungen auf das SAP-System.
84
Kapitel 4. Design
4.3. Integrationsszenarien in SAP-XI
In den folgenden Tabellen 4.3, 4.4 und 4.5 wird der Aufbau der drei Integrationsszenarien
beschrieben. Die aus den Szenarien erzeugten WSDL-Dokumente wurden für die Implementierung verwendet und befinden sich im Projektverzeichnis von mobileCRM auf der
CD-ROM zu dieser Arbeit.
Integrationsszenario
ActionPush
ChangeActivity
GetActivityList
Beschreibung
Push einer neuen oder geänderten Aktivität auf das BB-Gerät
Änderung oder Neuanlage einer Aktivität auf dem BB-Gerät
und Update der Daten im SAP-CRM
Holen einer Aktivitätenliste aus dem SAP-CRM
Tabelle 4.2: Übersicht der Integrationsszenarien
85
4.3. Integrationsszenarien in SAP-XI
Kapitel 4. Design
Objekttyp
Objekt
Integrationszenario ActionPush
Action
ActivityPushCRM
Action
ActionPush
Message-Interface
ActionPush_In
RFC-MessageInterface
Message-Typ
ZACTIVITY_PUSH
Message-Typ
ActionPushResponse
RFC-Message-Typ
ZACTIVITY_PUSH
RFC-Message-Typ
ZACTIVITY_PUSH.Response
ActionPushRequestDatatype
Datentyp
Datentyp
ActionPushRequest
Datentyp
ActionPushResponseDatatype
Activity
Interface-Mapping
ActionPushMapping
Message-Mapping
ActionPushRequestMapping
Message-Mapping
ActionPushResponseMapping
Beschreibung
Definiert das Integrationszenario für
die Push Funktionalität von Aktivitäten
Definiert den serverseitig initiierten
Anwendungsfall Pushen einer Aktivität
Definiert den clientseitigen Anwendungsfall Empfangen eines Aktivität
Schnittstelle zwischen SAP-XI und
BB-Endgerät für Push-Nachricht
Schnittstelle zwischen SAP-CRM
und XI um eine Aktivität zu pushen
XSD zur Definition einer Push-Nachricht zum BB-Endgerät
XSD zur Definition der Antwort vom
BB-Server auf einen PushRequest
Request-Datentyp, welcher die Aktivität beinhaltet
Response-Datentyp als Antwort auf
einen Aktivitäts-Push
Datentyp innerhalb einer Push-Nachricht. Beinhaltet den Datentyp Activity
Datentyp eines Response auf eine Push-Nachricht
Kapselt eine Aktivität und wird im
ActionPushRequestDatatype verwendet
Definiert das Mapping vom Ausgangs-Interface ZACTIVITY_PUSH
auf das Ziel-Interface ActionPush_In
Definiert das Mapping des Requests
von der Ausgangs-Nachricht ZACTIVITY_PUSH auf die Ziel-Nachricht
ActionPushRequest
Definiert das Mapping des Responses
von der Ausgangs-Nachricht ActionPushResponse auf die Ziel-Nachricht
ZACTIVITY_PUSH_RESPONSE
Tabelle 4.3: Integrationsszenario ActionPush
86
Kapitel 4. Design
4.3. Integrationsszenarien in SAP-XI
Objekttyp
Objekt
Integrationszenario ChangeActivity
Action
ChangeActivityAction
Action
ChangeActivityActionCRM
Message-Interface
ChangeActivity_Out
RFC-MessageInterface
Message-Typ
CRMXIF_ORDER_SAVE
ChangeActivityRequest
Message-Typ
ChangeActivityResponse
RFC-Message-Typ
CRMXIF_ORDER_SAVE
RFC-Message-Typ
CRMXIF_ORDER_SAVE.Response
Datentyp
ChangeActivityRequestDatatype
ChangeActivityResponseDatatype
Activity
Datentyp
Datentyp
Interface-Mapping
ChangeActivityMapping
Message-Mapping
ChangeActivityRequestMapping
ChangeActivityResponseMapping
Message-Mapping
Beschreibung
Definiert das Szenario für das Erzeugen
und Ändern von Aktivitäten im CRM
Definiert den clientseitig initiierten Anwendungsfall für das Erzeugen und Ändern einer Aktivität
Definiert den serverzeitigen Anwendungsfall für das Verarbeiten einer Aktivitätenänderung oder einer Neuanlage
von einer Aktivität
Schnittstelle zwischen dem Endgerät
und XI für den Dienst ChangeActivity
Schnittstelle zwischen XI und SAPCRM für den Dienst ChangeActivity
XSD zur Definition der RequestNachricht zwischen BB-Endgerät und
XI für das Erzeugen oder Ändern einer
Aktivität
XSD zur Definition der ResponseNachricht vom XI auf einen ChangeActivityRequest
XSD zur Definition der RequestNachricht
zwischen
XI
und
CRM für den RFC-Aufruf CRMXIF_ORDER_SAVE zum Erzeugen und
Ändern einer Aktivität
XSD zur Definition der ResponseNachricht als Antwort auf den RFCAufruf CRMXIF_ORDER_SAVE
Datentyp innerhalb des ChangeActivityRequest. Enthält den Datentyp Activity
Datentyp innerhalb des ChangeActivityResponse
Kapselt eine Aktivität und wird im
ChangeActivityRequestDatatype
verwendet
Definiert das Mapping vom AusgangsInterface ChangeActivity_Out auf das
Ziel-Interface CRMXIF_ORDER_SAVE
Definiert das Mapping des Requests von
der Ausgangs- zur Ziel-Nachricht
Definiert das Mapping des Responses
von der Ausgangs- zur Ziel-Nachricht
Tabelle 4.4: Integrationsszenario ChangeActivity
87
4.3. Integrationsszenarien in SAP-XI
Kapitel 4. Design
Objekttyp
Objekt
Integrationszenario GetActivityList
Action
RequestActivityList
Action
ProvideActivityList
Message-Interface
RequestActivityList_Out
RFC-MessageInterface
Message-Typ
CRM_MY_ACTIVITIES
ActivityListRequest
Message-Typ
ActivityListResponse
RFC-Message-Typ
CRM_MY_ACTIVITIES
RFC-Message-Typ
CRM_MY_ACTIVITIES.Response
Datentyp
ActivityListRequestDatatype
ActivityListResponseDatatype
Datentyp
Datentyp
Activity
Interface-Mapping
ActivityGetList
Message-Mapping
ActivityGetListRequestMapping
ActivityGetListResponseMapping
Message-Mapping
Beschreibung
Definiert das Integrationszenario für das
holen einer Aktivitätenliste
Definiert den clientseitig initiierten Anwendungsfall für das holen einer Aktivitätenliste
Definiert den serverzeitigen Anwendungsfall für das Suchen nach Aktivitäten für einen Anwender
Schnittstelle zwischen dem BB-Endgerät und SAP-XI für den Dienst GetActivityList
Schnittstelle zwischen XI und SAPCRM für den Dienst GetActivityList
XSD zur Definition der Request-Nachricht zwischen BB-Endgerät und XI für
das holen einer Aktivitätenliste
XSD zur Definition der Response-Nachricht vom XI auf einen ActivityListRequest
XSD zur Definition der Request-Nachricht zwischen XI und SAP-CRM für
den RFC-Aufruf CRM_MY_ACTIVITIES zum Holen einer Aktivitätenliste
XSD zur Definition der Response-Nachricht als Antwort auf den RFC-Aufruf
CRM_MY_ACTIVITIES
Datentyp innerhalb des ActivityListRequest
Datentyp innerhalb des ActivityListResponse. Dieser Datentyp beinhaltet eine
Liste von Aktivitäten in Form des Datentyps Activity
Kapselt eine Aktivität und wird im ActivityListResponseDatatype verwendet
Definiert das Mapping vom AusgangsInterface RequestActivityList_Out auf
das Ziel-Interface CRM_MY_ACTIVITIES
Definiert das Mapping des Requests von
der Ausgangs- zur Ziel-Nachricht
Definiert das Mapping des Responses
von der Ausgangs- zur Ziel-Nachricht
Tabelle 4.5: Integrationsszenario GetActivityList
88
Kapitel 5
Implementierung
Ausgewählte Einzelheiten aus der Realisierung des im Design entworfenen Modells von
mobileCRM werden nun besprochen. Zunächst wird kurz auf die Entwicklungswerkzeuge
eingegangen. Danach wird das mittels kSOAP implementierte SOAP-Parsing vorgestellt.
Darauf folgt mit der RMS-Schnittstelle eine weitere Komponente zum Zugriff auf ein
Backend-System. Im Abschnitt Multi-Threading werden die Feinheiten der in mobileCRM zum Einsatz kommenden Threads dargelegt. Probleme bei der Implementierung,
die sich nicht sauber lösen lassen, sind im Abschnitt Workarounds zusammengefasst. Abschließend wird auf die Qualitätssicherung und den Implementierungsaufwand von mobileCRM eingegangen.
5.1
Entwicklungswerkzeuge
Für die Implementierung der mobilen Anwendung mobileCRM kommt die Java-Entwicklungsumgebung Eclipse1 in der Version 3.2 zum Einsatz. Zum Testen der Anwendung
wird das in der Analyse ausgewählte Framework J2ME-Unit verwendet, ebenso wie das
Logging-Framework Microlog. Die Definition von Namenskonventionen und eine statische Code-Analyse wird mit dem Eclipse-Plugin Checkstyle 2 durchgeführt. Inhaltlich
geht das Unterkapitel Qualitätssicherung (Abschnitt 5.7) näher auf die Unit-Tests, einen
Styleguide und Software-Metriken ein.
Das Eclipse-Plugin Eclipse-ME 3 (Version 1.5.5) erleichtert die Entwicklung mit J2ME.
Es bietet Unterstützung für das Wireless Toolkit von Sun und bindet daraus den Emu1
http://www.eclipse.org
http://eclipse-cs.sourceforge.net
3
http://eclipseme.org
2
89
5.1. Entwicklungswerkzeuge
Kapitel 5. Implementierung
lator und die Bibliotheken in ein J2ME-Projekt ein. Der Build- und Packaging-Prozess
einer mobilen Anwendung, resultierend in einem JAD und einem JAR, kann durch ein
von Eclipse-ME generiertes Ant-Skript automatisiert und konfiguriert werden. Die Erweiterbarkeit der Skripte wird ausgenutzt, um aus einer MIDlet-Suite gemäß MIDP eine Blackberry-spezifische Anwendung zu generieren. Der Codeausschnitt dazu findet
sich in Quellcode-Listing 5.1. Das Programm zur Konvertierung ist Bestandteil der JDEEntwicklungsumgebung von RIM, und wird über das Ant-Skript parametrisiert.
2
4
6
8
10
<target name="makecod"
description="Builds a .cod file for BlackBerry devices from .jar + .jad">
<mkdir dir="${bb.cod.output}"/>
<exec dir="${bb.cod.output}" executable="${bb.jde.bin}\\rapc.exe">
<arg line=" import=${bb.jde.libs}"/>
<arg line=" codename=${midlet.name}"/>
<arg line=" -midlet ../${midlet.name}.jad ../${midlet.name}.jar"/>
</exec>
<copy file="${basedir}/packaging/mobileCRM.alx" todir="${bb.cod.output}"/>
</target>
Quellcode 5.1: build.xml: Target makecod
Durch die bei mobilen Endgeräten typischerweise beschränkte Hardwareleistung spielen Performance-Optimierungen bei mobilen Anwendungen eine wichtige Rolle, so dass
dieser Punkt bereits in Analyse und Design beachtet wurde. Die Optimierungsmöglichenkeiten wurden im Grundlagenabschnitt 2.4.3.6 erläutert. Als Obfuscator bietet sich die
Benutzung von ProGuard1 an, der sich in EclipseME integrieren lässt. Die prinzipielle
Funktionsweise lässt sich in der Dokumentation des Projekts nachlesen. Für mobileCRM
und die zugehörige Testsuite kommen die in Quellcode-Listing 5.2 dargestellten zusätzlichen Parameter für ProGuard zum Einsatz.
-keepnames class *
2 -allowaccessmodification
Quellcode 5.2: Parameter für den Obfuscator ProGuard
Standardmäßig werden Klassennamen von ProGuard verkürzt, zur Erschwerung von
Reverse-Engineering und zur Reduzierung der Applikationsgröße. Dies ist im Fall von
mobileCRM unerwünscht, da die Implementierung von Logging und Internationalisierung auf den ursprünglichen Klassennamen basiert, und wird durch den ersten Parameter verhindert. Der Parameter -defaultpackage ” wurde aus der StandardKonfiguration von EclipseME entfernt, damit die Package-Struktur im JAR erhalten
1
http://proguard.sourceforge.net/
90
Kapitel 5. Implementierung
5.2. SOAP-Parsing
bleibt. Dies ist für das Auffinden der Ressourcen-Dateien notwendig. Mit dem zweiten
Parameter wird ProGuard erlaubt die Access-Modifier innerhalb von Klassen zu ändern.
Dadurch können beispielsweise Attribute als public deklariert werden und Methoden
können dann inline implementiert werden. Der Methodenaufruf entfällt also, und der
Rumpf der Methode wird an die jeweilige Stelle des Aufrufs kopiert, was insbesondere bei trivialen Get- und Set-Methoden sinnvoll ist.
Eine weitere Möglichkeit, um die Performance zu verbessern, bietet sich durch das
Verwenden von Präprozessor-Direktiven. EclipseME unterstützt diese Funktion erst seit
kurzem, und kommt im Rahmen von mobileCRM daher nicht zum Einsatz. Die Direktiven sind in Java-Kommentaren untergebracht, um den Code kompatibel zu halten, so dass er auch ohne Präprozessor compilierbar ist. Durch Einsatz von Preprocessing kann in bestimmten Situationen überflüssiger Code entfernt werden. So ließe sich
für eine Release-Version sämtlicher Debugging- und Logging-Code entfernen, und auch
Endgerät-spezifische Implementierungen realisieren (siehe z.B. Abschnitt Workarounds).
In mobileCRM wird dies zumindest teilweise dadurch erreicht, dass das Logging an zentraler Stelle deaktiviert werden kann.
5.2
SOAP-Parsing
Das SOAP-Parsing ist im Package com.csc.bb.mobileCRM.model.backend.sap vollständig gekapselt, und ist für alle anderen Komponenten transparent. Für jeden komplexen XML-Datentyp innerhalb der verwendeten SOAP-Nachrichten (siehe
Message-Typen in den Tabellen 4.3, 4.4 und 4.5) gibt es eine gleichnamige Klasse, die
für die (De-)Serialisierung zuständig ist. Dafür wird das KvmSerializable-Interface
verwendet, das in den Grundlagen in Abschnitt 2.4.3.5 besprochen wurde. Der Aufbau
der fünf verschiedenen SOAP-Nachrichten-Typen ist in Abbildung 5.1 dargestellt. Dabei
wird der Zusammenhang zwischen konkreten Instanzen der Klassen aufgezeigt, ähnlich
wie es durch die XML-Schema-Definition auf XML-Ebene ausgedrückt wird. Eine PushNachricht stellt eine Besonderheit dar, aus Sicht des SAP-XI handelt es sich um eine
Push-Anfrage an das Endgerät, weshalb die Benennung des Message-Typs als Request
generiert wird. Die Implementierung auf dem BB verarbeitet die Verbindung jedoch als
Antwort, und der Payload ist eine Aktivität.
Das SOAP-Parsing wird vom Model aus über die Schnittstelle der Klasse SAPmanager
(siehe Abschnitt 4.2.3) durchgeführt. Die Vorgehensweise beim Parsing ist anhand der
Methode reveivePush in Quellcode-Listing 5.3 dargestellt. Zunächst müssen die
91
5.3. RMS-Schnittstelle
Kapitel 5. Implementierung
Abbildung 5.1: Aufbau der verschiedenen Nachrichtentypen
Klassen zum (De-)serialisieren der verwendeten Datentypen mit den entsprechenden
XML-Elementen assoziiert werden (Mapping). In kSOAP wird mit der Methode call eine SOAP-Anfrage gesendet und die entsprechende Antwort empfangen, jeweils inklusive
dem SOAP-Parsing. Für das Lesen und Parsing der empfangenen Push-Nachricht wurde
der entsprechende Code aus der Methode call in die Methode receive ausgelagert,
so dass er auch ohne eine Anfrage benutzt werden kann. Nach erfolgreichem Parsing kann
auf die erzeugten Objekte über das KvmSerializable-Interface des Resultats mit der
Methode getProperty zugegriffen werden.
Die Schnittstellen aus MIDP und CLDC stellen keine Möglichkeit zum Abfragen des
aktuellen Funkverbindungsstatus zur Verfügung. Dies wäre für die Methode updateActivity jedoch wünschenswert, um die Methode im Offline-Zustand des Endgeräts
direkt verlassen zu können, statt auf eine Timeout-Rückmeldung des Betriebssystems
warten zu müssen. Für BB-Geräte gibt es eine herstellerspezifische Lösung über die Klasse net.rim.device.api.system.RadioInfo, die eine Anwendung jedoch nur
verwenden kann, wenn sie mit einem kostenpflichtigen Lizenzschlüssel von RIM signiert
ist.
5.3
RMS-Schnittstelle
Die Schnittstelle des RMSmanager wurde im Design schon vorgestellt (siehe Abschnitt
4.2.3). Die MIDP-API für den Zugriff auf RecordStores wurde im Grundlagenteil 2.4.3.4
beschrieben. In Quellcode-Listing 5.4 wird beispielhaft eine der Methoden des RMSma-
92
Kapitel 5. Implementierung
2
5.3. RMS-Schnittstelle
public ActivityBO receivePush(final InputStream inputStream)
throws ApplicationException {
4
final SoapSerializationEnvelope envelope =
new SoapSerializationEnvelope(SoapEnvelope.VER11);
6
// add mappings for complex custom types
envelope.addMapping("http://csc.com/bbsap",
"ActionPushRequest",
new ActionPushRequest().getClass());
envelope.addMapping("http://csc.com/bbsap",
"Activity", new Activity().getClass());
8
10
12
14
// needs not to be initialized with URL,
// because only a Push is received here (no request)
final HttpTransport http = new HttpTransport(null);
16
18
try {
http.receive(inputStream, envelope);
} catch (final IOException e) {
// ... Fehlerbehandlung
}
Object result = envelope.bodyIn;
20
22
24
// get ActivityBO
result = ((ActionPushRequest) result).getProperty(0);
26
28
return (ActivityBO) result;
}
Quellcode 5.3: SAPmanager.java: Methode receivePush
nagers dargestellt. Die Instanzen m_byteOut und m_out der Streaming-Klassen werden von allen Methoden des RMSmanagers wiederverwendet und nach Benutzung lediglich geschlossen. Für InputStream-Instanzen lässt sich diese Optimierung nicht vornehmen. Beim Speichern eines ActivityEntryBO muss unterschieden werden, ob es
sich um einen neuen Datensatz handelt (ID ist -1). In dem Fall muss die nächste zu vergebende ID des RecordStores erfragt werden und im BO gespeichert werden, bevor es dann
serialisiert und mit der RMS-Methode addRecord abgespeichert werden kann. Existiert
der Datensatz bereits, so wird der alte mit der RMS-Methode setRecord überschrieben. Wichtig ist, dass der zu Beginn geöffnete RecordStore immer vor dem Beenden der
Methode wieder geschlossen wird, was durch den finally-Block sichergestellt wird.
Anderenfalls bleiben die Deskriptoren für den RecordStore geöffnet, auch nach beenden
des MIDlets.
Die lesenden Methoden des RMSmanager benutzen einen gemeinsamen Puffer zum Einlesen, welcher mit der Methode assertBufferSize(int size) auf die benötigte
Größe des zu lesenden Datensatzes angepasst ist. Dies spart CPU-Leistung, da nicht für
jede Operation erneut ein Puffer allokiert wird. Bei Datensätzen, deren Größe stark variiert, kann dies zu erhöhtem Speicherverbrauch führen, da der Puffer sich nicht mehr
93
5.4. Multi-Threading
Kapitel 5. Implementierung
1 // ...
private static final String ACTIVITY_ENTRY_STORE = "ActivityEntries";
3 private ByteArrayOutputStream m_byteOut;
private DataOutputStream m_out;
5
private void saveActivityEntry(final ActivityEntryBO activityEntry)
7
throws RecordStoreException{
9
final boolean createIfNecessary = true;
RecordStore rs = null;
11
try {
rs = RecordStore.openRecordStore(ACTIVITY_ENTRY_STORE,
createIfNecessary);
13
15
if (activityEntry.getRecordId() == -1) {
// new record, set id before serialize
activityEntry.setRecordId(rs.getNextRecordID());
activityEntry.serialize(m_out);
final byte[] data = m_byteOut.toByteArray();
// create new record
rs.addRecord(data, 0, data.length);
} else {
activityEntry.serialize(m_out);
final byte[] data = m_byteOut.toByteArray();
// record update
rs.setRecord(activityEntry.getRecordId(), data, 0, data.length);
}
m_byteOut.reset();
} catch (RecordStoreException e) {
throw e;
} finally {
if (rs != null) {
rs.closeRecordStore();
}
}
17
19
21
23
25
27
29
31
33
35
37 }
Quellcode 5.4: RMSmanager.java: Methode saveActivityEntry
verkleinert. Bei Aktivitäten sind die Attribute jedoch statisch vorgegeben, so dass die
Datensatz-Größe nicht stark streut. Dadurch entstehen bei der Wiederverwendung des
Puffers in diesem Fall keine Nachteile.
5.4 Multi-Threading
Im Design-Kapitel wurden bereits die drei in mobileCRM verwendeten Threads entworfen. Der Hauptstrang (GUI-Thread) ist für die Darstellung der graphischen Komponenten
im Package com.csc.bb.mobileCRM.gui zuständig. Die Schnittstelle zum Model,
der ModelController, führt lang andauernde Vorgänge im Model in einem anderen
Thread (Worker-Thread) aus, so dass die Benutzerschnittstelle nicht blockiert. Um PushNachrichten empfangen zu können existiert ein weiterer Thread (Push-Thread), der ein-
94
Kapitel 5. Implementierung
5.4. Multi-Threading
gehende Push-Verbindungen annimmt und abarbeitet. Im folgenden Abschnitt wird näher
auf die Threads im Hintergrund eingegangen, da der Hauptstrang keine Besonderheiten
aufweist, die an dieser Stelle betrachtet werden müssen.
5.4.1
Worker-Thread
Der ModelController erweitert java.lang.Thread und bietet die Funktionalität der Methoden im Interface ModelFacade. Da der ModelController jedoch
für asynchrone Aufrufe gedacht ist, und das Model für synchrone, unterscheiden sich
die Methoden-Signaturen, so dass der Zusammenhang nicht durch class ModelController implements ModelFacade ausgedrückt werden kann. Auf eine
weitere Schnittstelle, die AsyncModelFacade heissen könnte, wurde an dieser Stelle
verzichtet, um die Anwendung so schlank wie möglich zu halten. Die öffentlichen Methoden des ModelControllers, die mit der Ausführung im Worker-Thread zu tun haben,
sind alle durch das Keyword synchronized vor konkurrierenden Zugriffen geschützt.
So ist sichergestellt, dass im Model durchzuführende Vorgänge durch den Worker-Thread
seriell abgearbeitet werden. Deadlocks können dabei nicht entstehen, da jeder Vorgang
im ModelController unabhängig von anderen Vorgängen ist und irgendwann terminiert.
Am Beispiel der Methode getActivity() wird die Funktionsweise des ModelControllers näher erläutert. Die Implementierung für den asynchronen Aufruf aus der GUISchicht findet sich in Quellcode-Listing 5.5.
1 public synchronized void getActivity(final Integer recordId) {
m_action = GET_ACTIVITY;
3
m_param = recordId;
notifyAll();
5 }
Quellcode 5.5: ModelController.java: Methode getActivity
Über das Attribut m_action wird dem Worker-Thread über eine ID mitgeteilt, welche
Methode im Model aufzurufen ist. Ein optionaler Parameter vom Typ Object kann an
das Attribut m_param zugewiesen werden - in diesem Fall die RecordID der auszulesenden Aktivität. Nun wird mit notifyAll() der schlafende Worker-Thread aufgeweckt,
andere Threads warten nicht auf die ModelController-Instanz. Der Worker-Thread führt
die Methode run() des ModelControllers aus. Dort wird in einer Endlos-Schleife je Zyklus ein Vorgang im Model durchgeführt, und der Thread wartet bis zum nächsten Aufruf.
95
5.4. Multi-Threading
Kapitel 5. Implementierung
1 private void handleGetActivity(final Integer recordId) {
try {
3
ActivityBO activity = m_model.getActivity(recordId.intValue());
m_caller.updateData(activity);
5
m_statusBar.showNextScreen();
} catch (ApplicationException e) {
7
// ... error handling
}
9 }
Quellcode 5.6: ModelController.java: Methode handleGetActivity
1 public void stop() {
m_stopped = true;
3
m_instance = null;
try {
5
synchronized (this) {
notifyAll();
7
}
} catch (final IllegalMonitorStateException e) {
9
// Worker-Thread arbeitet gerade
// und beendet sich danach
11
}
m_model.stopPushReceiver();
13 }
Quellcode 5.7: ModelController.java: Methode stop
Anhand der ID in m_action wird in run() die zugehörige Handler-Methode aufgerufen, die in Quellcode-Listing 5.6 dargestellt ist.
Die Aufgabe wird an das Model delegiert, und der Rückgabewert ist eine ActivityBOInstanz. Über die Schnittstelle AsyncDataHandler wird das Business Object an
die aufrufende GUI-Komponente übergeben. Dies setzt voraus, dass diese vor dem
Auruf von getActivity zunächst beim ModelController mittels setCaller(AsyncDataHandler caller) registriert wird. Als Abschluß eines Vorgangs wird
der Folge-Screen des StatusBar angezeigt.
Zum Beenden des Worker-Threads (siehe Quellcode-Listing 5.7) wird die Abbruchbedingung der Schleife in run() erfüllt, und der Worker-Thread aufgeweckt, so dass die
Methode verlassen wird und der Thread sich beendet. Wenn der Worker-Thread gerade
aktiv ist, beendet er sich erst nach Abschluß des Vorgangs im Model. Der Push-Receiver
im Model wird auch durch den ModelController beendet.
96
Kapitel 5. Implementierung
5.4. Multi-Threading
1 public void run() {
// ...
3
try {
m_connection = (StreamConnectionNotifier) Connector.open(m_pushUrl);
5
} catch (IOException e1) {
m_errorHandler.reportError(e1);
7
}
9
while (!m_stopped) {
try {
m_blocking = true;
// wait for Push connection
streamConnection = m_connection.acceptAndOpen();
// connection should NOT be closed by stop()
// while receiving data
m_blocking = false;
inputStream = streamConnection.openInputStream();
11
13
15
17
19
// parse SOAP message
final ActivityBO activity = m_sapManager.receivePush(inputStream);
21
// save activity in RMS
RMSmanager.getInstance().saveActivity(activity);
23
25
streamConnection.close();
}
// ... error handling
27
}
29 }
Quellcode 5.8: PushReceiver.java: Methode run
5.4.2
Push-Thread
Der Thread zum Empfangen neuer Push-Nachrichten ist in der Klasse PushReceiver
implementiert. Die Methode run() ist entsprechend überschrieben und ist in QuellcodeListing 5.8 dargestellt.
Zunächst wird ein Connection-Objekt erzeugt, das auf eingehende Verbindungen wartet. Dabei wird die Art des Protokolls und der Port in Form einer URL angegeben. Die
BB-Endgeräte benötigen für TCP-Verbindungen auf Port 8888 die URL http://8888,
während es beim Emulator von Sun socket://8888 ist. Die MIDP Spezifikation
schreibt nicht vor, welche Protokolle auf einem Endgerät für eingehende Verbindungen
unterstützt werden müssen. Nachdem das Connection-Objekt vorhanden ist, werden in
einer Endlosschleife Verbindungen entgegen genommen und verarbeitet, bis der Thread
beendet werden soll. Mit der Methode acceptAndOpen() wartet das ConnectionObjekt blockierend auf eine eingehende Verbindung. Die Methode kehrt zurück, wenn eine Push-Verbindung aufgebaut ist. Für die weitere Verarbeitung wird der InputStream
des Connection-Objekts zum Einlesen und Deserialisieren der SOAP-Nachricht an den
SOAP Parser (SAPmanager) übergeben. Das resultierende ActivityBO-Objekt wird
97
5.5. Logging und Internationalisierung
Kapitel 5. Implementierung
im RMS gespeichert, und der Datenstrom geschlossen. Falls die Abbruchbedingung nicht
gesetzt wurde, wird dann auf weitere Push-Verbindungen gewartet.
Die Methode stop() (siehe Quellcode-Listing 5.9) zum Beenden des Push-Threads
setzt die Abbruchbedingung auf true, und falls der Thread gerade beim Warten auf
Push-Verbindungen blockiert, wird noch die Connection-Instanz durch close() geschlossen. Dadurch kehrt acceptAndOpen() zurück, und run() wird in jedem Fall
beendet.
1 public void stop() {
Log.info(this, "stopping");
3
m_stopped = true;
if(m_blocking) {
5
// interrupt blocking operations
try {
7
m_connection.close();
} catch (IOException e) {
9
// ...
}
11
}
}
Quellcode 5.9: PushReceiver.java: Methode stop
5.5 Logging und Internationalisierung
J2ME stellt für die Internationalisierung von Anwendungen keine API zur Verfügung.
Um die Daten getrennt vom Code zu halten, bieten sich Key-Value-Paare in Form von
Property-Dateien an, wie sie in J2SE bekannt sind. Für jede Sprache wird dabei eine eigene Datei angelegt, in der der Key ein Bezeichner für eine Ressource wie beispielsweise
die Beschriftung einer Titelleiste ist, und der Wert die zugehörige Beschriftung in der entsprechenden Sprache. Ein Überblick der Klassenhierarchie für Internationalisierung und
Logging findet sich in Abbildung 5.2.
Die Dateien werden im JAR der Anwendung hinterlegt, worauf dann mit der generisch
gehaltenen Klasse PropertyFileReader zugegriffen werden kann - J2ME stellt auch
diese Funktion nicht standardmäßig bereit. Mit der statischen Klasse I18nResources
werden die Konventionen für Dateipfade und -namen der der Sprachdateien sowie für
die Bezeichnung der Ressourcen festgelegt. Die Sprachdateien liegen innerhalb des JARs
in /resources/i18n/ und tragen als Dateinamen die Sprachkennung nach ISO 639
Code mit der zusätzlichen Endung .property, also beispielsweise de.property für
98
Kapitel 5. Implementierung
5.5. Logging und Internationalisierung
Abbildung 5.2: Klassen für Internationalisierung und Logging
die deutsche Sprache. Auf die Sprachkennung kann innerhalb J2ME über die SystemProperty microedition.locale zugegriffen werden. Das WirelessToolkit von Sun
benutzt dabei RFC 4646 (z.B. de-DE), während die BB-Endgeräte die Kennung nach ISO
639 (z.B. de) verwenden. Da aus dem String nach RFC 4646 der Code gemäß ISO 639 extrahiert werden kann, wurde dieser als kleinster gemeinsamer Nenner für die Sprachkennung gewählt, die die Methode loadResources(String locale) erwartet. Die
entsprechende Property-Datei wird eingelesen, und die Key-Value-Paare werden in einer
Hashtable-Instanz gehalten. Der Bezeichner einer Ressource beginnt mit dem Klassennamen in dem die Ressource benötigt wird und einem frei definierbaren Folge-String,
der mit einem Punkt abgetrennt ist. Zum Abrufen einer Ressource aus der Hashtable wird
die Methode getString(Object obj, String resource) bereitgestellt, wobei obj das Objekt ist, das die Ressource anfragt, und resource der Folge-String. Soll
die Methode innerhalb einer statischen Methode aufgerufen werden, so kann statt dem
Objekt auch eine Instanz der Klasse Class übergeben werden. Da die Umwandlung einer
Objekt- oder Class-Instanz in den Klassennamen allgemeingültig ist und auch für das
Logging benötigt wird, wurde diese Funktion in die Klasse StringUtils ausgelagert.
Ein typischer Aufruf der Methode innerhalb des Hauptmenüs MainMenu könnte also folgendermaßen aussehen: I18nResources.getString(this, "title"). Dabei
wird aus der entsprechenden Sprachdatei bzw. der Hashtable der Wert für den Key Main-
99
5.6. Workarounds
Kapitel 5. Implementierung
Menu.title ausgelesen.
Für das Logging wird die in der Analyse ausgewählte Bibliothek Microlog (siehe Abschnitt 3.4.4) verwendet. Um den kompletten Code der mobilen Anwendung nicht von
den Microlog-Klassen abhängig zu machen, wird eine eigene Wrapper-Klasse Log eingeführt, die intern Microlog verwendet. Die Methoden sind an die Microlog-API angelehnt.
Eine Priorisierung der Meldungen erfolgt somit über die Methoden error(), info()
und debug(). Jedoch wird zusätzlich zur zu loggenden Nachricht noch der Klassenname mit geloggt, in der die Meldung verursacht wurde. Weiterhin sind optionale Informationen wie die Zeit der Nachrichtenausgabe in Millisekunden und Informationen zum
ausführenden Thread zuschaltbar. Damit die Meldungen aufgrund des Multithreadings
sich nicht gegenseitig beeinträchtigen, sind alle Logging-Methoden synchronized.
5.6
Workarounds
In diesem Abschnitt werden implementierungsspezifische Probleme besprochen, die im
Zusammenhang mit der Hersteller-Implementierung von MIDP stehen.
5.6.1
javax.microedition.midlet.MIDlet
Die Spezifikation der MIDP-API sieht innerhalb der Methode startApp() vor, dass
im schweren Fehlerfall notifyDestroyed() aufgerufen wird, um das MIDlet zu beenden. Handelt es sich nur um einen temporären Fehler, der beim nächsten Start der Anwendung möglicherweise nicht mehr auftritt, so soll stattdessen eine MIDletStateChangeException geworfen werden. Der Codeausschnitt in Quellcode-Listing 5.10
führt auf dem BB-Endgerät und dem Simulator zu einer Ausnahme in der Implementierung des Herstellers.
2
protected void startApp() throws MIDletStateChangeException {
notifyDestroyed();
}
Quellcode 5.10: Bug in Klasse MIDlet
Anhand einer minimalen Testanwendung (MIDlet_Destroy_Bug) kann der Fehler nachvollzogen werden. Die entsprechende Log-Ausgabe des Endgeräts findet sich in Quellcodelisting 5.11. Erwähnt sei an dieser Stelle noch, dass dieser Fehler mit der Referenzimplementierung im Emulator von Sun (Bestandteil des WTK) nicht auftritt.
100
Kapitel 5. Implementierung
5.6. Workarounds
1 Started mobileCRM(101)
Foreground mobileCRM(100)
3 START_APP
END_APP
5 Foreground net_rim_bb_ribbon_app(63)
Exit mobileCRM(100)
7 RuntimeException
java.lang.NullPointerException
9 net_rim_cldc-2
MIDletMain
11 <private>
0x7042
Quellcode 5.11: Log-Ausgabe der Testanwendung MIDlet_Destroy_Bug
Als Workaround für dieses Problem wird in mobileCRM bei schwerwiegenden Fehlern innerhalb von startApp() stattdessen immer eine MIDletStateChangeException geworfen. Dadurch wird die Anwendung ebenso beendet, der oben beschriebene Fehler tritt jedoch nicht auf.
5.6.2
javax.microedition.lcdui.Gauge
Mit der Klasse Gauge kann dem Benutzer ein Fortschritt angezeigt werden. Dabei kann
unterschieden werden, ob der Vorgang definierte Einzelschritte hat oder nicht, und ob
die Anwendung gerade aktiv ist oder sich in einem Wartezustand befindet. Der Codeausschnitt in Quellcode-Listing 5.12 initialisiert die Darstellung für einen Vorgang mit
undefiniert vielen Einzelschritten in einem arbeitenden Zustand. Die Darstellung auf dem
Endgerät ist meist als drehende Sanduhr realisiert, während definierte Einzelschritte als
Fortschrittsbalken dargestellt werden. Sobald der Konstruktor mit den beschriebenen Parametern aufgerufen wird, ist die CPU des Rechners ausgelastet, auf dem der Emulator
läuft. Beim Emulator des WTK ist dies nicht der Fall. Auf dem Endgerät kann darüber keine Aussage getroffen werden, da es keine Überwachungsmöglichkeit gibt, jedoch scheint
der Fehler dort nicht aufzutreten, die Benutzbarkeit der Anwendung ist im Gegensatz zum
Emulator nicht eingeschränkt. Als Workaround für den Simulator kann die Erzeugung der
Gauge-Instanz auskommentiert werden, was lediglich eine graphische Einbuße ist und
die Funktion der Anwendung nicht beeinträchtigt.
Gauge gauge = new Gauge("test", false, Gauge.INDEFINITE, Gauge.CONTINUOUS_RUNNING);
Quellcode 5.12: Bug in Klasse Gauge
101
5.6. Workarounds
5.6.3
Kapitel 5. Implementierung
Statische PushRegistry-Verbindungen im JAD
Verbindungen, die für die Funktion eines MIDlets zwingend und dauerhaft erforderlich
sind, können nach der MIDP-Spezifikation statisch über einen Eintrag im JAD registriert
werden (siehe [MW06] Seite 89). Das BlackBerry-Endgerät (7100v) bricht die Installation einer MIDlet-Suite jedoch nicht spezifikationsgemäß ab, wenn der zu registrierende
Port bereits von einer anderen Applikation verwendet wird. Schwerwiegender ist jedoch
das Problem, dass die AMS die statische Registrierung entfernt, falls die Anwendung auf
dem registrierten Port eine Server-Verbindung öffnet, ohne dass eine eingehende PushVerbindung verfügbar ist. Eine erneute Registrierung ist nicht möglich, wenn das statische
Registrierungsverfahren über den JAD genutzt wurde. Das Entfernen von statischen Einträgen ist in der Spezifikation nicht vorgesehen und nach [Sch04] S. 223 nicht möglich.
Wenn das entsprechende MIDlet gestartet ist, nimmt die AMS laut MIDP keine PushVerbindungen mehr für die Anwendung entgegen, so dass an dieser Stelle das Öffnen einer Server-Verbindung notwendig ist. Dieses Problem kann umgangen werden, indem die
Verbindung für Push-Nachrichten dynamisch registriert wird. Der Nachteil der dabei entsteht ist, dass die Anwendung einmalig gestartet werden muss, bevor Push-Nachrichten
empfangen werden können.
5.6.4
Initialisierung von statischen Attributen
Ein ClassLoader in Java ist dafür verantwortlich, die zur Ausführung benötigten Klassen einzulesen. Dabei werden auch statische Attribute der zu ladenden Klassen initialisiert. Nach dem Beenden einer Anwendung auf einem mobilen Endgerät würde man
möglicherweise erwarten, dass die statischen Variablen oder gar der gesamte Classloader von der Garbage-Collection aus dem Speicher entfernt werden. Bei den Implementierungen des BB-Endgeräts und des BB-Simulators ist dies jedoch nicht der Fall, bei
erneutem Starten einer Anwendung sind die Variablen noch mit den vormaligen Werten
initialisiert. Als minimale Testanwendung dient ein MIDlet mit einem statischen Zähler
vom Typ int. Um Fehler zu umgehen, werden statische Variablen, insbesondere bei den
Singleton-Klassen, vor Beenden der Anwendung zurückgesetzt, so dass die Variablen
sauber hinterlassen werden, und die dann nicht mehr referenzierten Instanzen entfernt
werden können.
102
Kapitel 5. Implementierung
5.7
5.7.1
5.7. Qualitätssicherung
Qualitätssicherung
Styleguide
Mit dem bereits erwähnten Eclipse-Plugin Checkstyle (siehe Abschnitt 5.1) wird der
Quellcode von mobileCRM anhand von Regeln überprüft. Diese werden durch ein XMLDokument spezifiziert (checkstyle-config.xml), das auch über den Konfigurationsdialog in Eclipse erstellt werden kann. Neben der Benutzung der parametrisierbaren
Standard-Module gibt es auch die Möglichkeit, eigene Checkstyle-Module zu entwickeln.
Im Folgenden werden nur einige ausgewählte Regeln beschrieben, die nicht Bestandteil
der üblichen Java-Konventionen sind:
• Attribute beginnen mit dem Präfix m_ (von Member-Variable), um Attribute von
lokalen Variablen optisch unterscheiden zu können, und um Shadowing zu vermeiden, also das Scope-bedingte Verdecken von Variablen mit gleichem Namen.
• Die Basisklasse Exception und RuntimeException sollten nicht in catchBlöcken verwendet werden (bzw. nur an bestimmten Stellen). Hintergrund ist,
dass mehrere zu fangende Exception-Typen nicht nur einen einzigen catchBlock gefangen werden sollen, da dort beispielsweise auch Nullpointer- und
OutOfMemoryExceptions gefangen würden.
• Die Verschachtelung von try-Blöcken ist nicht zugelassen, bei if maximal bis
zu einer Tiefe von 2. Dies verbessert die Wartbarkeit des Codes und verringert die
Fehleranfälligkeit.
• Referenzen, die nicht modifiziert werden, sollten als final deklariert werden. Dadurch kann die JVM Optimierungen bei der Ausführung vornehmen.
• Klassen mit ausschließlich statischen Methoden sollten Konstruktoren als private deklarieren. Die nicht zweckgemäße Instanziierung solcher Klassen ist somit
unterbunden.
Alle weiteren Regeln können der Konfiguration von Checkstyle entnommen werden. In
der Summe tragen sie zu einem einheitlichen, konsistenten Programmierstil bei, und helfen Programmierfehler zu vermeiden sowie Best-Practices durchzusetzen.
103
5.7. Qualitätssicherung
Kapitel 5. Implementierung
Abbildung 5.3: Kiviat-Graph der Metriken von mobileCRM
5.7.2
Software-Metriken
Die Kenngrößen einer statischen Codeanalyse wurden mit dem Werkzeug SourceMonitor1 ermittelt. Die wichtigsten Kenngrößen sind in Abbildung 5.3 dargestellt. Alle weiteren Messwerte finden sich auf der CD-ROM zu dieser Arbeit. Dabei ist zu sagen, dass die
Komplexität, Anzahl der Statements in einer Methode und vergleichbare Messgrößen erhöht sind. Dies ist darauf zurückzuführen, dass bestimmte Vorgänge mit allen Attributen
einer Aktivität durchzuführen sind. Das Aufsplitten dieser Methoden wäre semantisch
jedoch nicht sinnvoll und würde die Fehleranfälligkeit des Codes auch tendenziell eher
vergrößern.
5.7.3
Automatisierte Tests
Die Durchführung automatisierter Tests mit dem bereits angesprochenen J2MEUnitFramework (Abschnitt 3.4.4) beschränkt sich auf die Model-Schicht, da die GUI nur manuell getestet werden kann. Die Unit-Tests sind als eigenes Projekt (mobileCRMtestsuite)
angelegt, mit Abhängigkeiten zu mobileCRM und der kSOAP-Bibliothek. Dies hält die
1
http://www.campwoodsw.com/sourcemonitor.html
104
Kapitel 5. Implementierung
5.8. Implementierungsaufwand
Datei
MobileCrmMIDlet.java
Lines Of Code
249
Tabelle 5.1: LOC des Package com.csc.bb.mobileCRM
Build-Prozesse der einzelnen Projekte übersichtlicher.
Die wichtigsten Komponenten im Model sind der RMSmanager und der SAPmanager,
in denen die eigentliche Datenverarbeitung stattfindet. Für diese Komponenten wurden
Tests angelegt, die mit lokalen Datenströmen arbeiten, damit die Datenkommunikation verifiziert werden kann, und die Tests ohne SAP-System und Netzwerkverbindung
durchgeführt werden können. Dafür müssen die zu testenden Klassen entsprechende TestParameter erhalten, so dass die darüber liegende Schicht, das Model, nicht mitgetestet
werden kann.
Die Klasse SAPmanager wurde zur Testbarkeit so erweitert, dass eine Verbindung übergeben werden kann, anstatt eine HTTP-Verbindung zu erzeugen. Um diese Möglichkeit
auch auf Ebene des SOAP-Parsers zu haben, wurde die kSOAP Bibliothek um eine überladene Methode call erweitert, die eine ServiceConnection der kSOAP-API entgegennimmt. Die Testdaten liegen als SOAP-Nachrichten in Form von XML-Dateien
vor, die jeweils eingelesen werden, und in einen Datenstrom konvertiert werden, der an
die modifizierte Implementierung der ServiceConnection (MyServiceConnection)
übergeben werden kann. Die Instanz der ServiceConnection wird an den SAPmanager übergeben, der das SOAP-Parsing übernimmt. Das Ergebnis kann mit einer
ActivityBO-Instanz aus der Klasse ActivityTestData verglichen werden. Um
eine eingehende Push-Verbindung zu testen muss diese ServiceConnection nicht verwendet werden, da die Methode direkt einen InputStream entgegen nimmt.
Die Klasse RMSmanager kann auch im Emulator getestet werden, so dass spezielle
Vorkehrungen für das Testen nicht zu treffen sind. Die Methoden werden mit Testdaten
aus der Klasse ActivityTestData getestet, so dass die Ergebnisse verifiziert werden
können.
5.8
Implementierungsaufwand
Dieser Abschnitt gibt den Implementierungsaufwand von mobileCRM in Lines Of Code
(LOC) inklusive Kommentarzeilen an.
105
5.8. Implementierungsaufwand
Kapitel 5. Implementierung
Datei
ActivityList.java
AsyncDataHandler.java
BasicAlert.java
BasicScreen.java
MainMenu.java
ModelController.java
SettingsMenu.java
ShowActivityForm.java
StatusBar.java
Lines Of Code
183
11
140
38
109
385
84
495
108
Tabelle 5.2: LOC des Package com.csc.bb.mobileCRM.gui
Datei
ActivityBO.java
ActivityEntryBO.java
AsyncEventHandler.java
BasicBO.java
Model.java
ModelFacade.java
ProgressObserver.java
SAPUserBO.java
Lines Of Code
733
154
11
53
242
17
9
59
Tabelle 5.3: LOC des Package com.csc.bb.mobileCRM.model
Datei
RMSmanager.java
Serializable.java
Lines Of Code
441
23
Tabelle 5.4: LOC des Package com.csc.bb.mobileCRM.model.backend.rms
Datei
ActionPushRequest.java
Activity.java
ActivityList.java
ActivityListRequest.java
ActivityListResponse.java
ChangeActivityRequest.java
ChangeActivityResponse.java
PushReceiver.java
SAPmanager.java
Lines Of Code
49
480
60
86
48
115
54
122
275
Tabelle 5.5: LOC des Package com.csc.bb.mobileCRM.model.backend.sap
106
Kapitel 5. Implementierung
5.8. Implementierungsaufwand
Datei
ApplicationException.java
I18nResources.java
Log.java
PropertyFileReader.java
StringUtils.java
Lines Of Code
58
60
149
96
57
Tabelle 5.6: LOC des Package com.csc.bb.mobileCRM.util
Datei
ActivityTestData.java
AllTests.java
MobileCRMtestrunner.java
MyServiceConnection.java
RMSmanagerTests.java
SAPmanagerTests.java
Lines Of Code
141
34
18
54
82
226
Tabelle 5.7: LOC des Package com.csc.bb.mobileCRM.tests
Datei
mobileCRM
mobileCRMtestsuite
Gesamt
Lines Of Code
5253
555
5808
Tabelle 5.8: LOC von mobileCRM und mobileCRMtestsuite
107
5.9. Performance-Bewertung
Kapitel 5. Implementierung
Abbildung 5.4: Messaufbau und Bezeichnung der Messwerte
5.9 Performance-Bewertung
An dieser Stelle werden die im Rahmen von mobileCRM durchgeführten PerformanceMessungen zunächst aufgearbeitet und dann bewertet. Diese sind notwendig, um Aussagen über die Praxistauglichkeit der in der Systemarchitektur dieser Arbeit kombinierten
Komponenten treffen zu können. Weiterhin können dadurch die primären leistungsbegrenzenden Komponenten ausgemacht werden.
Die Messungen wurden auf dem BB-Endgerät als J2MEUnit-Test realisiert. Das TestSzenario ist der Anwendungsfall Aktivitätenliste anfordern, da dieser vom Endgerät aus
initiiert wird, Request und Response beinhaltet, und die Nutzlast vom SAP-CRM in Richtung des BBs variabel ist. Die Testimplementierung ruft die Methode SAPmanager.getActivities auf, und die Nutzlast kann über die im SAP-CRM verfügbaren Aktivitäten gesteuert werden. Dadurch wird für jede einzelne Messung eine Verbindung aufund abgebaut, was jedoch erwünscht ist, um einen realistischen Testfall zu haben. Zur
Testumgebung ist zu sagen, dass SAP-CRM, SAP-XI, BES und deren Netzwerkverbindung nur durch den Test-Client benutzt wurden, so dass die Ergebnisse nicht durch andere
Benutzer verfälscht werden.
Dies sind optimale Voraussetzungen, so dass in der Praxis eher mit höheren Latenzzeiten zu rechnen ist. Auf der anderen Seite ist das Testsystem auf nicht so leistungsfähiger Hardware installiert, wie es in Produktivsystemen üblich ist. Zu der Auslastung des Mobilfunkanbieters und der RIM-Infrastructure kann keine Aussage getroffen
werden. Für die Performance-Tests wurden zunächst innerhalb der kSOAP-Bibliothek
Zeitnahmen in den Code implementiert. Dies geschieht durch Aufruf der Methode
System.currentTimeMillis(), die eine Auflösung von 10 Millisekunden hat.
Daraus folgt, dass die ermittelten Durchschnittswerte im schlimmsten Fall eine Ungenauigkeit von 10ms haben. Durch den niedrigsten in allen Messreihen ermittelten Wert von
108
Kapitel 5. Implementierung
5.9. Performance-Bewertung
Abbildung 5.5: Zeit zum Serialisieren der Anfrage in SOAP-XML-Markup
1750ms ergibt sich ein maximaler prozentualer Fehler unter 0,572%. Die Berechnung der
Zeitdifferenzen zwischen Messpunkten und die Ausgabe erfolgt erst nach Abschluss einer
einzelnen Messung, während einer Messung finden keine Log-Ausgaben statt. Das mobile Endgerät befand sich bei allen Messreihen am selben Ort, so dass der Funk-Empfang
vergleichbar ist, der im Übrigen eine gute Signalstärke (-55dBm) aufwies. Der Messaufbau und die Bezeichnung der einzelnen gemessenen Teilstrecken sind in Abbildung 5.4
dargestellt. Die Verbindung zwischen XI und SAP-CRM ist dabei lokal, da beide Anwendungen auf einem Host installiert sind.
Die Auswertung der Messgröße Request Parsing wird den Messreihen vorangestellt, da
diese Zeitspanne unabhängig von der im Response übertragenen Nutzlast ist und im Vergleich zu anderen Messwerten nicht ins Gewicht fällt. Unter Request Parsing ist die Serialisierung zu verstehen, um aus dem Java-Objekt, das die Daten des Requests enthält,
SOAP-XML-Markup zu generieren. In Abbildung 5.5 sind die gemessenen Werte aus den
ersten beiden Messreihen dargestellt. Der größte gemessene Wert beträgt 240ms und die
Payload ist bei allen Messreihen vergleichbar.
5.9.1
Messreihe 1
Der Performance-Unittest ist so konfiguriert, dass nacheinander 100 Anfragen vom BBEndgerät über das XI an das SAP-CRM gesendet werden. Dabei wird in Messreihe 1
zunächst der minimale Testfall betrachtet, bei dem nur eine Aktivität vom SAP-CRM
109
5.9. Performance-Bewertung
Arithmetisches Mittel
Minimum
Maximum
Standardabweichung
Kapitel 5. Implementierung
Gesamtzeit
5540
4580
26680
2168
Resp. Parsing
2097
1930
2980
106
Antwortzeit
3266
2310
24510
2176
XI
308
188
766
83
Tabelle 5.9: Statistische Kenngrößen zu Messreihe 1 (Einheit [ms])
Abbildung 5.6: Messreihe 1: Eine Aktivität als Payload
aus gesendet wird. Die nächste Anfrage wird jeweils erst gesendet, wenn die zugehörige
Antwort vollständig empfangen und durch das Parsing wurde, sowie die Zeitberechnung
stattgefunden hat und ausgegeben wurde. Nach der Ausgabe wird der Test-Thread noch
pauschal zwei Sekunden pausiert, so dass die Vorgänge im Betriebssystem, die mit der
Ausgabe zu tun haben, gänzlich abgeschlossen sind und einen nächsten Testlauf nicht
beeinträchtigen. Die Messergebnisse sind graphisch in Abbildung 5.6 dargestellt. Die statistischen Kenngrößen können Tabelle 5.9 entnommen werden.
Die Gesamtzeit wurde in der modifizierten kSOAP-Bibliothek gemessen. Die Zeitnahme erfolgte dabei vor Deserialisieren der Anfrage und nach dem erfolgreichen Parsing
der Antwort. Durch einen weiteren Messwert vor dem Parsing lässt sich dessen Dauer
ermitteln. Die Antwortzeit berechnet sich aus der Gesamtzeit abzüglich der Parsing-Zeit
von Request und Response. Dem Performance-Monitoring von XI lassen sich die Zeiten für die Bearbeitungszeit der einzelnen Requests entnehmen. Diese Zeit umfasst die
Verarbeitung im SAP-XI, die Übertragung zum SAP-CRM und dessen Verarbeitung sowie den Rücktransport und die erneute Bearbeitung des XI. Dabei sei noch einmal darauf
110
Kapitel 5. Implementierung
5.9. Performance-Bewertung
Abbildung 5.7: Messreihe 2: 14 Aktivitäten als Payload
hingewiesen, dass im konkreten Testaufbau die Anwendungen SAP-XI und SAP-CRM
auf einem Host installiert sind. Von einem Ausreißer im statistischen Sinne wird in den
folgenden Messreihen gesprochen, wenn ein Wert nicht im Intervall des Durchschnitts
plus/minus der zweifachen Standardabweichung liegt.
5.9.2
Messreihe 2
Diese Messreihe wurde unter den gleichen Voraussetzungen wie Messreihe 1 durchgeführt, allerdings mit 14 Aktivitäten als Nutzlast, um das Verhalten der einzelnen Systemkomponenten bei größeren Datenmengen zu testen. Die Darstellung der Messwerte in Abbildung 5.7 zeigt, dass bei dieser zweiten Messreihe starke Schwankungen bei
der Datenübertragung vorhanden sind. Eine der 100 durchgeführten Messungen brach
sogar durch eine Timeout-Exception ab, weshalb nur 99 Messwerte vorhanden sind. In
der Konsolen-Ausgabe des Endgeräts konnten bei der erhöhten Nutzlast deutlich mehr
Garbage-Collection-Aufrufe festgestellt werden. Die Zeit für das Parsing des Requests ist
jedoch sehr stabil, weshalb die Garbage-Collection-Aufrufe nicht als Begründung für die
Ausreißer der Antwortzeit in Frage kommen. Die Antwortzeiten des SAP-XI sind konstant gering, und die Ursache der Schwankungen ist daher vermutlich zwischen dem BES
und dem BB-Endgerät zu suchen, denn die CPU-Auslastung auf dem BES ist gering und
die Internetanbindung ausreichend dimensioniert.
111
5.9. Performance-Bewertung
Arithmetisches Mittel
Minimum
Maximum
Standardabweichung
Kapitel 5. Implementierung
Gesamtzeit
24595
18770
113750
12189
Resp. Parsing
14449
13880
16240
421
Antwortzeit
9950
4140
98310
12098
XI
600
281
1406
211
Tabelle 5.10: Statistische Kenngrößen zu Messreihe 2 (Einheit [ms])
Abbildung 5.8: Messreihe 3: Zehn Aktivitäten als Payload
5.9.3
Messreihe 3
Innerhalb der Messreihe 3 wurden ebenfalls 100 Anfragen vom Endgerät über XI an
das CRM gesendet, jedoch umfasst die Antwort des CRM zehn Aktivitäten als Nutzlast.
Durch diese Messreihe soll erörtert werden, wie sich Parsing und Antwortzeit bei weniger
als 14 Aktivitäten verhalten. Die Darstellung der gemessenen Werte ist Abbildung 5.8 zu
entnehmen, die statistischen Kenngrößen finden sich in Tabelle 5.11. Es zeigt sich, dass
die Schwankungen der Antwortzeit deutlich geringer ausfallen als in Messreihe 2.
Arithmetisches Mittel
Minimum
Maximum
Standardabweichung
Resp. Parsing
10631
10060
11620
331
Antwortzeit
4844
3650
8150
582
XI
383
250
1094
100
Tabelle 5.11: Statistische Kenngrößen zu Messreihe 3 (Einheit [ms])
112
Kapitel 5. Implementierung
Messung
1
2
3
4
5
5.9. Performance-Bewertung
Parsing
3900
3980
3670
3930
3870
Antwortzeit
5850
5310
4140
3640
6310
XI
988
877
1144
628
933
BES
4862
4433
2996
3012
5377
Tabelle 5.12: Daten aus Messreihe 4 (Einheit [ms])
5.9.4
Messreihe 4
Diese Messreihe wurde manuell durchgeführt, wobei je Messung drei Aktivitäten aus dem
SAP-CRM übertragen wurden. Weiterhin wurden alle Datagramme, die den Testvorgang
betreffen, auf dem BES aufgezeichnet. Die gemessenen Werte sind in Tabelle 5.12 dargestellt. Die Spalte XI wurde anhand manueller Auswertung der aufgezeichneten Pakete
errechnet. Die Zeit umfasst dabei Übertragung der Daten vom BES zum SAP-XI, von dort
weiter zum SAP-CRM und zurück bis zum BES, sowie die Verarbeitungszeit im SAP-XI
und im SAP-CRM. Die gemessenen Zeiten der XI-Verarbeitung sind also nicht mit denen
aus den vorangegangenen Messreihen vergleichbar. Die Spalte BES bezeichnet die Übertragungszeit des Requests vom Endgerät zum BES zuzüglich derjenigen des Responses
vom BES zum Endgerät. Sie berechnet sich aus der Antwortzeit abzüglich der gemessenen Zeit des XI. Alle anderen Spalten stammen aus der Aufzeichnung des Clients.
Wie in Abschnitt 2.1.1 beschrieben wurde, findet die Übertragung zwischen einem BBEndgerät und dem BES verschlüsselt und komprimiert statt. Durch die aufgezeichneten
Pakete kann die Komprimierungsrate bestimmt werden, was an der ersten Messung vorgenommen wurde. Die zwischen SAP-XI und BES ausgetauschte, unverschlüsselte Nutzlast
beträgt dabei 4757Byte. Die verschlüsselte und komprimierte Nutzlast zwischen BES und
der RIM-Infrastructure beträgt hingegen nur 1945Byte, was einer Komprimierungsrate
von 59,11% entspricht.
5.9.5
Bewertung
Der Vergleich der Ergebnisse aus den vorangegangenen Messreihen erlaubt Rückschlüsse
auf die Performance und die Skalierbarkeit der Komponenten, aus denen das Gesamtsystem aufgebaut ist.
Zum SAP-XI lässt sich sagen, dass es auf den Umsatz von großen Datenmengen ausgelegt
ist. Die durchschnittliche Verarbeitungszeit zwischen Messreihe 2 mit einer Aktivität und
113
5.9. Performance-Bewertung
Kapitel 5. Implementierung
Messreihe 3 mit zehn Aktivitäten als Nutzlast unterscheidet sich nur um 75ms (19,6%).
Die erhöhte Nutzlast hat also nur eine sehr geringe Auswirkung auf die Antwortzeit. Bei
den absoluten Werten der XI-Messungen ist zu beachten, dass SAP-XI und SAP-CRM
im gegebenen Testszenario auf der selben Maschine arbeiten. Dadurch verringert sich einerseits die Übertragungzeit zwischen beiden Systemen, andererseits jedoch konkurrieren
sie um gemeinsame Ressourcen wie Speicher und CPU.
Auf die Dauer des SOAP-Parsings hat die Verzehnfachung der Nutzlast jedoch deutliche
Auswirkungen. Zwischen Messreihe 1 mit 2097ms Response-Parsing-Zeit und Messreihe
3 mit 10631ms ergibt sich eine Verfünffachung der Dauer. Dass sich die Dauer nicht
proportional zur Nutzlast geändert hat, könnte darauf zurückzuführen sein, dass der XMLParser und die SOAP-Mappings zunächst initialisiert werden müssen, was zusätzlich (eine
vom Umfang der Nutzlast unabhängige) Zeit in Anspruch nimmt. Der Peak der ParsingZeit in Messreihe 1 könnte seine Ursache in Vorgängen auf Betriebssystem- oder VMEbene haben, wie beispielsweise die Garbage-Collection.
Die durchschnittliche Antwortzeit zwischen den Messreihen mit einer und zehn Aktivitäten als Nutzlast unterscheidet sich nur um den Faktor 1,5, obwohl die Zehnfache Nutzlast übertragen wurde. Dieser sehr geringe Faktor lässt sich vermutlich auf den Auf- und
-Abbau der TCP/IP Verbindung zurückführen, die unabhängig von der Größe der übertragenen Nutzlast Zeit in Anspruch nimmt. Bei einer Verbindung mit hoher Latenz und
Übertragung von geringer Nutzlast macht die Summe der für den Verbindungsauf- und
-abbau notwendigen Datagramme einen erheblichen Anteil der Gesamtübertragungszeit
aus.
Die Gesamtzeit aus Messreihe 2 (rund 25 Sekunden) kann einem Benutzer sicherlich
nicht zugemutet werden. Jedoch ist für den Praxiseinsatz Messreihe 1 besser anwendbar,
da der Benutzer auf Dauer nur einzelne Aktivitäten als Push-Nachricht empfängt oder
als Update zum SAP-System sendet. Messreihe 2 und 3 wären also nur für die initiale Synchronisation aller Aktivitäten relevant. Von den rund 5 Sekunden der Gesamtzeit
aus Messreihe 1 entfallen im Schnitt 3 Sekunden auf die Antwortzeit, wobei die Zeit des
SAP-XI und SAP-CRM mit rund 0,3 Sekunden sehr gering ausfällt. Aufgrund der bereits
angewendeten Komprimierung der Nutzlast könnte die Antwortzeit durch Verwendung
eines Binärprotokolls statt SOAP nur minimal verbessert werden. Der Spielraum für eine Optimierung beschränkt sich beim untersuchten Testaufbau also auf die 2 Sekunden,
die das SOAP-Parsing in Anspruch nimmt. Dafür biete sich zwei Möglichkeiten: Die Implementierung weiter optimieren, beispielsweise durch Profiling oder durch den Einsatz
leistungsfähigerer Hardware auf Client-Seite könnte die Zeit für das Parsing reduziert
werden. Die Entwicklungsumgebung von RIM bietet jedoch nur für den Emulator ei-
114
Kapitel 5. Implementierung
5.9. Performance-Bewertung
ne Profiling-Funktion an, nicht für die Endgeräte. Durch bessere Hardware könnte statt
GPRS auch UMTS für die Übertragung der Daten zum Einsatz kommen, was die Antwortzeit verbessern würde.
115
5.9. Performance-Bewertung
Kapitel 5. Implementierung
116
Kapitel 6
Zusammenfassung
Die vorliegende Arbeit entstand als externe Diplomarbeit bei der Firma CSC Deutschland Solutions GmbH in Wiesbaden. Das Ziel bestand darin, ein Konzept zur Integration
zwischen einem SAP-System und einem mobilen BlackBerry-System zu entwerfen und
zu realisieren. Der dabei entstehende möglichst praxisnahe Prototyp soll die Realisierung
zukünftiger ’Real World’-Anwendungen erleichtern. Aus dieser Anforderung resultierte
die Randbedingung, dass ein Web Service als Bindeglied zwischen dem SAP-System und
der BlackBerry-Lösung operieren soll. Darauf aufbauend sollte der Entwurf aus Benutzerund auch aus Infrastruktur-Sicht für den Einsatz in Unternehmen geeignet sein. Weiterhin
sollte die Applikation für das mobile Endgerät als Smart-Client realisiert werden. Dabei
werden die übertragenen Daten lokal auf dem Endgerät zwischengespeichert, wodurch
ein Offline-Modus und Performance-Gewinne ermöglicht werden.
Für die Realisierung der Arbeit wurde als abzubildener Anwendungsfall im SAP-System
das Aktivitätsmanagement eines SAP-CRM-Systems (Customer Relationship Management) ausgewählt. Dabei wurde prototypisch ein Client für ein mobiles BlackBerryEndgerät umgesetzt. Die Nachrichten-orientierte Middleware SAP-XI dient als WebService-Schnittstelle zwischen dem CRM-System und dem BlackBerry Enterprise Server, der für die Kommunikation zwischen Unternehmensanwendungen und den mobilen
Endgeräten zuständig ist. Die Vorteile von SAP-XI liegen in der zentralen Konfiguration der Kommunikation zwischen den zu integrierenden Anwendungen, und es ist keine anwendungsspezifische Implementierung eines Web Service notwendig. Mit diesem
Ansatz können weitere Anwendungen leichter und übersichtlicher, da weniger stark gekoppelt, miteinander verknüpft werden. Die mobile Anwendung (mobileCRM) für das
BlackBerry-Endgerät wurde in J2ME entwickelt, für die Kommunikation mit dem Web
Service über SOAP kam die Bibliothek kSOAP zum Einsatz, die der Analyse entspre-
117
Kapitel 6. Zusammenfassung
chend der Referenz-Implementierung der JSR 172 API von Sun vorgezogen wurde. Die
Daten aus dem SAP-System werden auf dem Endgerät mit der RMS-API aus J2ME zwischengespeichert, wodurch auf den Flash-Speicher des Geräts zugegriffen werden kann.
Die dabei unter Umständen auftretenden Synchronisationsprobleme zwischen Daten auf
Clients und dem SAP-CRM-System wurden theoretisch untersucht und Realisierungsmöglichkeiten zur Lösung vorgestellt. Bei der Abbildung der Attribute eines Datensatzes im SAP-CRM-System auf das mobile Endgerät wurden die technisch notwendigen
und die für den mobilen Einsatz wichtigsten Attribute übernommen. Diese können im
Prototyp durch die implementierten Anwendungsfälle verarbeitet werden. Welche Attribute benötigt werden ist anwendungsspezifisch und hängt von den abzubildenden Geschäftsprozessen bzw. dem Einsatzgebiet der Anwendung ab. Der Schwerpunkt der Implementierung lag auf dem Entwurf einer einfach zu erweiternden Architektur und auf
der Kommunikation über SOAP. Ersteres wurde durch den Einsatz eines Document-View
Architektur-Ansatzes in mobileCRM erreicht, und kann so als Basis für Erweiterungen
dienen. Bei der SOAP-Kommunikation empfängt und verarbeitet die Anwendung PushUpdates vom SAP-System, sendet Updates vom Client in umgekehrter Richtung, und
eine Liste aller Aktivitäten kann manuell in einem bidirektionalen Vorgang angefordert
werden. Das Design der GUI stand nicht im Vordergrund. Im Rahmen der Implementierung hat sich herausgestellt, dass für Anwendungen mit mehr Dialogfeldern und komplexerem Informationsfluss auf jeden Fall eine zentrale Steuerung des Übergangs von
einer graphischen Komponente (Screen) zur nächsten ratsam ist. Weiterhin empfiehlt sich
für mobile Anwendungen allgemein, den Programmcode und den Build-Prozess so flexibel und konfigurierbar wie möglich zu halten. Dies ist darin begründet, dass der Code
Endgerät-spezifisch angepasst werden muss, beispielsweise aufgrund von notwendigen
Workarounds, und den unterschiedlichen Features und APIs, die ein Endgerät zur Verfügung stellt.
Bei den durchgeführten Performance-Messungen hat sich ergeben, dass die meiste Zeit
bei der Übertragung zwischen BES und dem Endgerät sowie dem Parsing der SOAPNachrichten verloren geht. Letztere Größe ist im Gegensatz zur Übertragung deutlicher
von der Nutzlast abhängig. Die Dauer für die Übertragung von 10 Aktivitäten kann bereits
nicht mehr als benutzerfreundlich eingestuft werden, auch wenn sie für mobile Geräte
nicht ungewöhnlich ist. In den Anwendungsfällen von mobileCRM wird jedoch im alltäglichen Einsatz bei einem Aktivitätsupdate vom Endgerät zum SAP-System und umgekehrt
nur eine einzelne Aktivität übertragen, da die Synchronisation kontinuierlich durchgeführt
wird, sofern eine Funknetzabdeckung verfügbar ist. Die Dauer des Parsings macht dabei
ca. 2 Sekunden aus. Daraus ergibt sich, dass SOAP-basierte mobile Lösungen für den
118
Kapitel 6. Zusammenfassung
Einsatz in ähnlichen Szenarien wie dem in dieser Arbeit vorgestellten erwartungsgemäß
nur dann geeignet sind, wenn die Nutzlast der einzelnen Anwendungsfälle nicht zu groß
ist. Der Vorteil einer solchen Lösung gegenüber möglicherweise performanteren aber proprietären Binärprotokollen ist, dass Web Services eine plattformunabhängige und offene
Schnittstelle definieren, und teilweise in Unternehmensanwendungen bereits vorhanden
sind.
Für einen produktiven Einsatz von mobileCRM sollte der Prototyp insbesondere in Bezug auf die Usability optimiert werden. Eine graphisch ansprechendere und übersichtlichere Darstellung könnte beispielsweise durch Benutzen des Frameworks J2ME Polish1
(für den kommerziellen Einsatz kostenpflichtig) erreicht werden. Notwendigerweise zu
implementierende Erweiterungen der Benutzerschnittstelle sind Suchmasken, beispielsweise für die Suche von Aktivitäten nach bestimmten Kriterien, und das Auflösen eines
Namens in die entsprechende Personalnummer, so wie es die SAP-GUI auf PCs bietet.
Durch eine kategorisierte Darstellung der Attribute einer Aktivität können möglicherweise mehr Attribute trotzdem übersichtlich in die mobile Anwendung übernommen werden.
Weiterhin kann die vom Benutzer wahrgenommene Latenz eines Netzwerk-Vorgangs wie
z.b. einem Aktivitätsupdate verkürzt werden, indem dieser Prozess im Hintergrund stattfindet, und der Benutzer weiter arbeiten kann. Eine Rückmeldung könnte der Anwender
erhalten, indem eine nicht zu bestätigende Meldung in einem Statusbereich eingeblendet
wird.
Die an diese Diplomarbeit gestellten Vorgaben, wie sie im ersten Abschnitt der Zusammenfassung aufgeführt wurde, konnten alle umgesetzt werden. Die Praxistauglichkeit des
entstandenen Prototyps mobileCRM wurde weiterhin auf verschiedene Aspekte hin analysiert. Diese Arbeit kann als Machbarkeitsstudie angesehen werden, und dient der Firma
CSC als Demonstrationssystem für Akquisetermine Die Umsetzung einer ansprechenden
graphischen Benutzeroberfläche wie zuvor empfohlen ist dafür jedoch Vorraussetzung.
Für die Weiterentwicklung der Methodik konnten in dieser Arbeit verschiedene Ansätze identifiziert werden. Für die Realisierung weiterer Anwendungen im Projektgeschäft
der Firma CSC ist ein Stub-Generator für die SOAP-Kommunikation ein zeitsparender
Faktor, insbesondere wenn die Web-Service-Beschreibungen komplexer werden. Eine
Möglichkeit könnte dabei die Realisierung oder Lizensierung eines Stub-Generators für
kSOAP sein. Weiterhin könnte ein Tool für die Generierung einer graphischen Darstellung auf Basis eines WSDL-Dokuments entwickelt werden, ähnlich der Funktionalität
des MDS Studio von RIM. Denkbar wäre auch die Integration der Aktivitäten in die
1
http://www.j2mepolish.org/
119
Kapitel 6. Zusammenfassung
PIM-Anwendungen (Kalender und Adressbuch), so dass alle Informationen für den Benutzer zentral einsehbar sind. Jedoch müsste dabei auch die Synchronisation von PIMAnwendungen zu mobileCRM gewährleistet sein.
Auf der Grundlage der in dieser Arbeit vorgestellten Ergebnisse können noch weitere
Studien durchgeführt werden und insbesondere zur Verfeinerung der angestrebten Methodik wären noch weitere Studien empfehlenswert. Zunächst wäre zu prüfen, wie stark
sich die Leistung der Systemarchitektur mit einem leistungsfähigeren BB-Endgerät verbessern lässt. Das BB-Modell Pearl weist beispielsweise 16MB SRAM (statt 4MB im
verwendeten Gerät) und eine leistungsfähigere CPU auf, was die Parsing-Dauer deutlich reduzieren könnte. Weiterhin sind Modelle mit UMTS verfügbar, wodurch die Übertragungszeit sich vermutlich verkürzen ließe. Auch aus Sicht der Bedienbarkeit können
noch andere Endgeräte wie beispielsweise auch PDAs evaluiert werden, insbesondere für
die Dateneingabe. Neben Hardware-Verbesserungen können auch Engpässe in der Implementierung der einzelnen Bestandteile von mobileCRM durch Profiling weiter optimiert
werden. Für Anwendungsfälle mit höherer Nutzlast oder höherer Priorität einer geringen
Latenz kann ein Binärprotokoll zwischen SAP-XI und BB-Endgerät entwickelt werden.
Ebenfalls wäre für den produktiven Einsatz zu testen, wie sich die Performance der einzelnen Systemkomponenten bei massiver, paralleler Nutzung verhält.
In der Einleitung wurde bereits aufgezeigt, dass der Einsatz mobiler Anwendungen im
Vergleich zur großen Verbreitung und den immer besseren Fähigkeiten der mobilen Endgeräte noch sehr gering ist. Die Weiterführung der Untersuchungen, die mit dieser Arbeit
eingeleitet wurden, sind daher von wissenschaftlichem Interesse und haben nicht zuletzt
betriebswirtschaftliche Bedeutung für die Firma CSC, in der weitere Untersuchungen bereits fest eingeplant sind.
120
Kapitel 7
Literaturverzeichnis
[Bay02]
BAYER, Thomas. REST Web Services. http://www.oio.de/public/
xml/rest-webservices.htm. 2002
[BEZ04]
B UCK -E MDEN, Rüdiger ; Z ENCKE, Peter: mySAP CRM - Kundenbezogene
Geschäftsprozesse mit SAP CRM 4.0. Galileo Press GmbH, 2004
[BPE]
BPEL4WS. Business Process Execution Language for Web Services Version
1.1
[DMT06] DMTF. Common Information Model (CIM). http://www.dmtf.org/
standards/cim/. 2006
[EY03]
E LLIS, Jon ; YOUNG, Mark. JSR 172: J2ME Web Services 1.0. http:
//jcp.org/en/jsr/detail?id=172. 2003
[Gei05]
G EIGER, Philipp. Mobilfunk Deutschland 2010. http://www.solon.
de/download_secure/Solon_Mobilfunk_%202010.pdf. 2005
[GHJV95] G AMMA, Erich ; H ELM, Richard ; J OHNSON, Ralph ; V LISSIDES, John: Design Patterns - Elements of Reusable Object-Oriented Software. AddisonWesley, 1995
[HL04]
H AUSER, Tobias ; L ÖWER, Ulrich M.: Web Services - Die Standards. Galileo
Computing, 2004
[MW06]
M ILIKICH, Mike ; WARDEN, James. JSR 118: Mobile Information Device
Profile 2.0. http://jcp.org/en/jsr/detail?id=118. 2006
121
Kapitel 7. Literaturverzeichnis
[Rah05]
R AHM, Erhard. Replizierte Datenbanken. http://dbs.uni-leipzig.
de/skripte/MRDBS/PDF2/kap7.pdf. 2005
[RIM05]
RIM. BlackBerry Java Development Environment - BlackBerry Application
Developer Guide Volume 1: Fundamentals. 2005
[RIM06a] RIM. BlackBerry Enterprise Server für Microsoft Exchange - Funktionen und
technischer Überblick. 2006
[RIM06b] RIM. BlackBerry Enterprise Solution - Sicherheit. www.blackberry.com.
2006
[RIM06c] RIM. BlackBerry MDS Studio - Feature and Technical Overview. 2006
[SA03]
SAP-AG. SAP Schulungsunterlagen, SAP01 SAP-Überblick. 2003
[Sch04]
S CHMATZ, Klaus-Dieter: Java 2 Micro Edition - Entwicklung mobiler Anwendungen mit CLDC und MIDP. dpunkt.verlag, 2004
[Sch05]
S CHMIDT, Michael. Der Pusher - Blackberries Sicherheits-Architektur.
http://www.heise.de/security/artikel/64996. 2005
[SO04]
S TUMPE, Jens ; O RB, Joachim: SAP Exchange Infrastructure. Galileo Press
GmbH, 2004
[Tai03]
TAIVALSAARI, Antero. JSR 139: Connected Limited Device Configuration
1.1. http://jcp.org/en/jsr/detail?id=139. 2003
[W3C00] W3C. Simple Object Access Protocol (SOAP) 1.1. http://www.w3.org/
TR/2000/NOTE-SOAP-20000508/. 2000
[W3C01] W3C. Web Services Description Language (WSDL) 1.1. http://www.
w3.org/TR/2001/NOTE-wsdl-20010315. 2001
[W3C06] W3C. Web Services Description Language (WSDL) 2.0. http://www.
w3.org/TR/2006/CR-wsdl20-20060327. 2006
[Win99]
W INER, Dave. XML-RPC. http://www.xmlrpc.com/spec. 1999
[Yua06]
Y UAN, Michael J.: Enterprise J2ME: Developing Mobile Java Applications.
Prentice Hall Ptr, 2006
122
Anhang A
Abkürzungen
A
AMS
Application Management Software.
B
BB
BlackBerry.
BES
BlackBerry Enterprise Server.
BO
Business Object.
BPEL
Business Process Execution Language.
C
CA
Certification Authority.
CDC
Connected Device Configuration.
CIM
Common Information Model.
CLDC
Connected Limited Device Configuration.
CRM
Customer Relationship Management.
123
Anhang A. Abkürzungen
D
DA
Discovery Application.
DOM
Document Object Model.
E
EAI
Enterprise Application Integration.
J
J2SE
Java 2 Standard Edition.
JAD
Java Application Descriptor.
JAR
Java Archive.
JAX-RPC
Java API for XML-based RPC.
JAXP
Java API for XML Processing.
JCP
Java Community Process.
JDE
Java Development Environment.
JSR
Java Specification Request.
JVM
Java Virtual Machine.
JWS
Java Web Start.
K
KVM
Kilo Virtual Machine.
L
LBS
Location Based Services.
LCDUI
Lowest Common Denominator User Interface.
LOC
Lines Of Code.
124
Anhang A. Abkürzungen
M
MDS
Mobile Data System.
MEP
Message Exchange Pattern.
MIDP
Mobile Information Device Profile.
MOM
Message-oriented Middleware.
MVC Pattern
Model View Controller Pattern.
O
OTA
Over The Air.
P
PIM
Personal Information Management.
PLM
Product Lifecycle Management.
R
REST
REpresentational State Transfer.
RI
Referenz Implementierung.
RIM
Research in Motion.
RMS
Record Management System.
S
SAP MI
SAP Mobile Infrastructure.
SAP XI
SAP Exchange Infrastructure.
SAX
Simple API for XML.
SCM
Supply Chain Management.
125
Anhang A. Abkürzungen
SLD
System Landscape Directory.
SOA
Service-orientierte Architektur.
SOAP
Simple Object Access Protocol.
SPI
Service Provider Interface.
SRM
Supplier Relationship Management.
W
W3C
World Wide Web Consortium.
WSDL
Web Service Description Language.
WTK
Wireless Toolkit.
126